See video: https://youtu.be/kTl-y6_6z_A
Presenting a bitcoin sidechain with on-chain utility of hedging price risk of future coinbase cashflows for bitcoiner miners.
Futures contracts are agreements to buy a specific commodity or asset at a specific price and time in the future. Since the actual transaction does not happen until the settlement date, the buyer does not have to pay the seller until that time. At the end of the futures contract, the buyer must pay the seller the agreed upon price, and the seller must "deliver" the commodity to the buyer.
However, before delivery time, the buyer (or seller), can close the contract by selling (or buying) to somebody else. Assuming the price of the futures contracts trade relative to the underlying commodity, these can be used to hedge risk in the underlying commodity, or to speculate with leverage.
The fact that futures contracts has delivery, ensures that the price of the contract trades relative to the underlying asset. This is due to the fundamental No Arbitrage Theory, where traders would otherwise earn free profits.
We propose a futures contract on bitcoin block rewards, were miners can hedge the future price of bitcoin, by locking in today's price for future block rewards.
- Hedgers - miners can hedge their investment and risk against bitcoin price
- Speculators - users can speculate on the price of bitcoin, with leverage, as only a small Good Faith Deposit is required to buy or write a futures contract. They can also speculate on the price of bitcoin falling.
- Market Makers - can earn profits by providing liquidity to speculators and hedgers.
Each node will have full price-time priority limit order book and matching engine.
To implement this, the sidechain will be account based and not UTXO based. This enables the separation of the transactions from the state. It also enables explicit deterministic code, similar to smart contracts, to update account balances based on profit-and-loss from trading.
We define static transaction types and deterministic state, as implemented in protoblock, which has been running live for many years now.
High Frequency Trading bots pay centralized exchanges millions of dollars to co-locate near the matching engines. Even a single nano second latency advantage could mean the difference between a profitable or losing operation.
As described in On Dex, all decentralized exchanges have a major front-running problem, as trading bots get to see all order before they even hit the matching engine.
Even with honest miners that do not try to to game the protocol, and just add transaction in order received, traders will attempt to locate their nodes as close to miners as possible, or even pay miners for co-location. As miners then become the equivalent of centralized exchange matching engines.
We solve this by separating block-consensus, from order-consensus. Block-consensus is consensus on which transactions to include in the block. Order-consensus is consensus on the order of processing of the transactions in said block.
After block-consensus is reached, a bidding process is used where the highest bidder determines the order-consensus. In this implementation we propose bribing of the bitcoin miners for order-consensus similar to @RubenSomsen spacechains
This is akin to a virtual co-location, since after the block we allow nodes to pay to reorder the transactions in the previous blocks, as if they were co-located with the miner of the previous block.
Spacechains is a bitcoin sidechain, that is blind merged mined. Meaning, a single hash that corresponds to a sidechain block will be included in each bitcoin block. This is accomplished using covenant transactions and replace-by-fee, which essentially means that each block on the sidechain is "mined" by the highest bidder on the main-chain. technical details video
For our DEXchain, we use this same technique, only instead of the highest bidder deciding the contents of the next block in the sidechain (block-consensus), the highest bidder gets to decide the order the transactions in a block(s) that already reached consensus in the sidechain (order-consensus).
In the original spacechain idea, it was thought that the main-chain bid would be based on the amount of fees received on the sidechain block. It turns out, for DEXs and many other protocols, the ordering of transactions has value itself. This is sometimes referred to as Miner Extracted Value (MEV) on ethereum. So traders would bid the amount that they value this new reorder, independent or in addition to fees.
Any DEX with on-chain matching needs a token for margin and settlement, otherwise fills from matching in the order-book can not be guaranteed. Guaranteed settlement of fills, is a basic requirement for price-discovery in open markets. Atomic swaps, for example, cannot guarantee settlement, they can only guarantee no funds are lost, in case one party reneges.
Instead of creating a new alt token, we use bitcoin and convert it to dexdollars
Similar to Rubens spacechain, we use a perpetual one way peg (P1WP) to create tokens on the dexchain. Only instead of generating 1 token per bitcoin we generate the dollar value of 1 bitcoin, and call them spacedollars or dexdollars.
Example: A bitcoin transaction can burn bitcoin on main-chain, and receive 40,000 dexdollars on the sidechain (based on bitcoin/dollar rate of $40,000).
A naive implementation would be to use some kind of price feed oracle to determine the rate. However, given the fact that our futures contract can be held for delivery of actual real bitcoin, using no-arbitrage pricing model, it turns out that the futures contract price itself will represent the going rate of $btcusd!
note: original space dollars ideas come from research of Fernando Nieto
It could be that bitcoin sellers would charge a 20% markup for dexdollars over real usd, in this case instead of 40,000, the rate would be 50,000. The mechanism to solve this is to allow delivery to be done in real USD or USDC/USDT. Even if only 1 or 2 contracts reach delivery with honest/altruistic buyers and sellers, by them completing the bitcoin to USD swap for delivery, this would be enough to keep the futures contract and the dexdollars priced around USD.
When there are no contract sellers willing to actually deliver bitcoin, the contract is instead settled in cash dexdollars. So buy 1 contract for 10,000 dexdollars, and by settlement the contract is worth 40,000 dexdollars. In this case, the buyer gets the 40,000 dexdollars, for a 30,000 profit.
note: over 99% of futures contract are closed before delivery. It's the option to deliver that matters.
Within the DEX sidechain, there are two distinct consensus needs. 1 Preventing double-spends for dexdollar coin transfers. 2 Low-latency mempool replication with ~5 second blocks for DEX ExchangeOrder transactions.
For dexdollar transfers, we only need to prevent double-spends, as long as the balance available to transfer is not be tied to the exchange data. This can be done by keeping the UTXO bitcoin model, with a special deposit and withdrawal address. Sending coins to deposit would burn that UTXO, and add the dexdollars to account for DEX trading. After settlement, a withdrawal would be like a new coinbase, with an output to a UTXO.
The simple implementation would be to include these transactions within the hash that will be blind-merged-mined with bitcoin. This would require waiting for at least 1 bitcoin block for a transfer.
A more realistic implementation would be to enable transfers independent of the DEX consensus. This can be implemented within a spacechain hierarchy. Bitcoin => P1WP => spacechain <=> P2WP <=> dexchain
Dexchain transactions pay fees in dexdollars. All transactions go into a mempool. The goal is coming to consensus on the entire mempool, every ~5 seconds. There can potentially be 100 or more dexchain blocks in-between each bitcoin block.
Note that DEX nodes require "all" transactions in order to build a mempool order-book state, in order to make trading decisions and sign new ExchangeOrder transactions. In contrast to bitcoin, where nodes only really care about transactions there are a party to.
DEX Consensus Protocol (DCP), is a modified Stellar Consensus Protocol (SCP) which is a Federated Byzantine Agreement (FBA) protocol.
We borrow the ideas and consensus from Stellar, described by David Mazieres, in this video and pdf.
Insight: the Internet hypothesis The Internet is a globally connected network
- Structure results from individual peering & transit relationships
- Decentralized decisions could have yielded many internets, but didn’t
- Transitively, everyone wants to talk to everyone
Hypothesis: counterparty relationships transitively converge
- Clearing houses are effectively the tier one ISPs of banking
- For the secondary order-consensus to work, we first must reach consensus on the set of orders for the block-consensus
- The goal is to have very fast blocks of around 5 seconds
- Hypothesis: dex trader relationships transitively converge. In a DEX, trader nodes need and want to share transactions with "adversarial" nodes of other traders, in order to create a local limit-order-book for their nodes matching engine.
- With low latency needs, we use a networked PBFT like protocol, which anyways relies on a semi-centralized internet overlay network
- Market makers, high volume traders, and exchanges are the tier1 ISP equivalent of DEXchain
- Sybil resistant federated BFT protocol
- Each Node chooses a Quorum Slice of nodes it cares about, and wants to stay in sync with
- Each Node comes to consensus via a quorum election process
- The safety of DCP is always known after the main-chain block. A break in safety (fork), will stop consensus and require a hard-fork to move forward. This is similar to how forks are dealt with in the spacechain proposal.
- Guarantees liveliness between bitcoin blocks
- Guarantees safety or failure after every bitcoin block
- Liveness is guaranteed by optimistically choosing to accept the claims from nodes of your quorum slices that "their quorum slices accepted a block". This enables nodes to continue even when their quorum failed to vote on the block, as an alternative is being permanently stuck.
- In dexchain, we are just kicking "getting stuck" down the road, to be dealt with after the order-consensus on the bitcoin main chain.
- Your transaction fees can only be claimed by correct nodes in your quorum
- Alternatively, transaction validity can be tied to the blocks voted on by a nodes quorum slices
Like the Internet, no central authority appoints top tier - but market can decide on de facto tier one organizations - doesn't even require exact agreement on who is a top tier node
Eventually market forces should converge on honest, high volume, stable uptime, and well known nodes to use as tier1 for quorum slices.
We propose a decentralized explicit way of doing this on-chain, with a mechanism for initially choosing tier1 nodes. Mechanism is designed to align with the incentives of bitcoin miners participating in DEX for hedging and delivery.
- Proof of POW - special signals inside a coinbase op_return with public-keys are added to a default tier1 list
- Proof of coinbase burn - creating dexdollars via a burn from virgin coinbase coins are also added to the default tier1 list
- This enables non miners to become default tier1, by buying and holding futures contracts, and taking delivery via the coinbase
This added benefit of becoming tier1, may potentially cause futures contracts to trade at a premium, thus putting upward price pressure on dexdollars relative to real dollars. This can be used in addition to Fernando's demurrage ideas in Soft pegged sidechains to lower the "volatility of the convenience yield of the token".
This value of being a "well-known" tier1, can also be used to disincentivize malicious nodes with slashing techniques. You lose "default tier1" status, when caught being "malicious"
Stellar Transaction Lifecycle Crafting a candidate transaction set (Validator): When it’s time to close the ledger, each stellar-core validator (a stellar-core node participating in consensus) takes all valid transactions it is aware since the last ledger close and collects them into a candidate transaction set. If it hears about any incoming transactions now, it puts them aside for the next ledger close.
Jan 21 2021
dexchain telegram: https://t.me/dexsidechain
spacechains telegram: https://t.me/spacechains
Latest updates