patrickdugan
commented
4 years ago Adding some numbers here.
12 - BTC/USD Quarterly Future
13 - BTC/USD Next Quarter Future
14 - BTC/EUR Fut.
15 - BTC/EUR Next Fut.
16 - BTC/JPY Fut.
17 - BTC/JPY Next Fut.
18 - BTC/CNY Fut.
19 - BTC/CNY Next Fut.
I am aware the futures grab new propertyIds when they expire and spawn new ones. So that makes this messy. At least the first contracts are all perpetual swaps with fixed propertyId numbers forever, I guess things are reference via Lihki's system of string aliases. These propertyIds should just be the starting configuration of the system.
Note: where BTC is referenced, in the Litecoin version it's LTC, where ALL is referenced, it's TOTAL in the Bitcoin version. Read these interchangeably.
20 - TOTAL/BTC Quarterly Future
21 - TOTAL Next Fut.
Those 21 instruments create a decent little native financial system with the world's top 4 fiat's represented. Should do we XAU/BTC? That's kind of interesting. But there's no physical gold in this decentralized software system, except for the motherboards, which have trace quantities. Feels more legit to model on Fiat? But XAU is a physical money that will probably still exist, devaluaed or revalued higher, whatever, it will exist in history longer than EUR, maybe longer than BTC, maybe not longer, but BTC and XAU are more long-lived by the nature of what they are. So maybe, it does make sense to add XAU for the very long-term thinking. So you'd get 3 contracts for each fiat pair of XAU, etc. However how do you native-settle XAU? Seems like a better fit for an oracle contract.
So maybe not.
Honestly, reference to BTC that's natively data-rich is probably the whole thing with TradeLayer. It exists to augment the transaction flow and data value on the Bitcoin Blockchain. We forget that at our peril.
So, 21! Concise.
Then there are cross pairs.
22- sBTC/BTC
sBTC/BTC n0ative swaps. No futures needed, arguably. I can see how a future on this is a better hedge, you might even be willing to short it with some backwardation, I like the cleanness of just a swap. It's nice to think that people can hedge their perceived risk of the whole thing getting illiquid. What's the hedge worth when you get settled up in more sBTC instead of the hard BTC you wanted? When the swap gets busted out and illiquid itself past some threshold like 0.8. Bankruptcies in this instrument combined with bear raid selling on the UXTO spot-pair, combined with on-chain sBTC/BTC bids failing to deliver and taking the sBTC penalty hit because they say "f it, I'm out" - in theory, if someone can hammer it, they can eliminate the spot bids delivered or not, put their own offers out, of course it's a huge advantage to buy sBTC this cheap in theory, but not if the underlying TOTAL/BTC contract is ~20% bankrupted by liquidations. Also negative funding on TOTAL/BTC basis can really burn sBTC holders. Was thinking of limiting that by making the interest formula more lax for TOTAL/BTC perpetuals.
I dunno, I think a sBTC/BTC swap adds stability, and increase in float from insurance fund payouts isn't so bad, at some point the fee cashflow limits the price dive liquidating TOTAL/BTC longs and the insurance fund payouts aren't infinite so maybe supply/demand wins and the system is metastable at high volatilities of TOTAL/BTC. Anyone who steps in to Chad long after a drop like that is essentially doing so because at a fundamentals level, they believe BTC and TradeLayer will keep being used for decades and it's a good risk/reward play to buy the blood.
Maybe we should have a perpetual swap on the insurance fund native data! Fun idea for later. We could feasibly also do BTC miner fee futures in a later version.
Moving on, how about BTC/dUSD data? That's technically how the BTC/USD contract settles, in addition to the triangulated prices from sBTC/BTC and TOTAL/BTC and TOTAL/USD. TOTAL getting a synthetic BTC supply, then contract arb on BTC, then a synthetic dollar supply, then a TOTAL/dUSD pricing, allows for the TOTAL/BTC price * TOTAL/dUSD price to settle the native BTC/USD contract in addition to dUSD trading against BTC UXTOs, dUSD trading against sBTC, and the sBTC/BTC market as a weight. This soup of interacting price feeds creates, in theory, a lattice, where the arbitrage and maker rebate incentives of different pairs makes manipulation very expensive and making manipulation more expensive becomes profitable. This is where we aggregate value in TOTAL and ALL in a convex way proportional to growing volumes and market depth. Everything ultimately revolves around sBTC/BTC trading, TOTAL/BTC contract health as a rudder, and then the BTC/USD contract, then TOTAL/token pairs.
So there would be a TOTAL/USD native swap, and two futures,
23, 24, 25
They settle based on the TOTAL/dUSD token trading.
Then TOTAL/EUR etc.
26-34
By pricing the USD value of the native tokens in the back, we avoid some of the Ourobouros considerations that plagued a resdesign effort back in August 2018. BTC liquidity is the foundation on which the luxury of our own USD pricing of TOTAL is built.
Token trading for dUSD to sBTC vs. the UXTO equivalent, could be used to reinforce a dUSD Margined set of contracts, to price Bitcoin in parallel. But is this even necessary? Adds confusion. Better to maybe include those token pairs, but they seem mostly to be triangular.
Nice thing about having the core tokens all in the first few property ids is all the token/token pairs are like 1/3, 1/2, 2/3, pretty cool.
santos177
0 - BTC or LTC 1 - TOTAL or ALL 2 - sBTC or LTC 3 - dUSD or dUSD (same symbol on both chains) 4 - dEUR 5 - dJPY 6 - dCNY 7 - TOTAL/BTC or ALL/LTC contract 8 - BTC/USD or LTC/USD contract 9 - BTC or LTC/EUR contracts 10 - JPY contracts 11 - CNY contracts
Question: how many more of these cardinal ISO codes do we want to include? 4 with 12 total cardinal properties seems tidy and usable.
An earlier version considered including every major ISO code plus gold, a future proofed commodity currency and the New World Order Phoenix currency if one were ever to occur, being future-proofed with a wink. But probably the Ghana Cedi, Nigerian Niara and so on are not desired as a payment mechanism, they're already available as payment mechanisms on Mobile Money, having a higher yield mobile money in local currency might be desirable but mostly what people want in these places is dollars. Given Gresham's law, we're likely to see either a Bitcoin Dollarization or perhaps hyperbitcoinization in the future, or SDR-ization etc. If we support overtly just the core currencies that are likely to compose the SDR, minus GBP and CHF, maybe just add CNY. Oracle markets for GPB/USD and other things, USD/BRL, whatever people want, can be facilitated. It's better to not highly clutter