Skip to content

Instantly share code, notes, and snippets.

@moonsettler
Last active September 2, 2023 20:46
Show Gist options
  • Star 2 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save moonsettler/e0c24863fda418a2fb504a307fda8a19 to your computer and use it in GitHub Desktop.
Save moonsettler/e0c24863fda418a2fb504a307fda8a19 to your computer and use it in GitHub Desktop.

Surfchains

The Sponsor locks up a certain amount of liquidity for a certain number of blocks, like for example 10'000, which is roughly 3 months. For locking up his liquidity and allowing people to use it on the sidechain he is rewarded with interest, for example 1%. The Sponsor is also the primary market maker, his function is to provide a stable peg, thus make the sidechain desireable for people to use. The Sponsor has no way to claw back the coins he locked up, they are predetermined to go to the mainchain miners can only regain custody of his 10% escrow if the covenant chain is played out block by block all the way to the end.

Example schedule

duration:		10'000 blocks
bitcoin locked up:	100%
tokens issued:		90%
burn schedule / block:	0.009%
paid to miners / block:	0.0089%
paid to miners total:	89%
final unlocked escrow:	11%

Consensus

Consensus is reached via blind merged mining, which means anyone can assemble a valid block for the sidechain, and bid for that block hash on the mainchain where a covenant chain (like CHECKTEMPLATEVERIFY or ANYPREVOUT) is used to trustlessly set up the escrow. This means the Sponsor has no control whatsoever over consensus, and can only censor sidechain transactions, if he chooses to outbid everyone on the mainchain which would be sufficiently costly, and not economically rational behavior. When someone creates a sidechain block candidate, they will gather the fees offered on the sidechain, substract the amount determined by the burn rate, and reward themselves with those fees as "coinbase".

Mechanism

Blind merged mining and driving the withdrawal forward happens atomically with the same CTV or APO covenant chain. For 10'000 blocks the mainchain transaction has 2 inputs and 1 output the first input is the remaining escrow balance, the second is the blind merged mining fee bid input. The single output of predetermined value which gets decreased by 8'900 sats each time for every bitcoin in initial funding, until it reaches the final 11% value released to the Sponsor's custody. When someone assembles a sidechain block the hash of this block is put into an OP_RETURN output in the transaction that creates the UTXO that is used as the second fee bid input in the escrow chain. Assuming package relay is already available this first transaction can pay 0 fees, and pay for its inclusion when the bid is won through its child the escrow chain transaction. The bmm bid transaction would typically have 1 input and 3 outputs, the first output is the OP_RETURN containing the sidechain block hash, the second output is the fee bid, and the third output is the change.

Incentives

The Sponsor can sell 90% of the bitcoin value of sidechain tokens and gets 11% back in the end. If he sells the sidechain tokens at price parity he basically makes 1% over 3 months. But if nobody uses the sidechain, he loses money on fees trying to get his 10% escrow out. For 1 btc locked in, he would pay out 8'900 sats each block to the miners, this is how much the locked in amount decreases with each block forward on the mainchain. If he dumps the coins and runs, he also potentially loses a lot of money on slippage and the escrow. The Sponsor has to make the sidechain desirable so that he can sell the 90% sidechain tokens at price parity or slight premium, and get his 11% out in the end without having to pay a lot of mainchain fees for it.

On the sidechain each block needs to burn 9'000 s-sats for 1 btc funding value, that means if 3'000 transactions are in each block, then 3 s-sats/tx is the fee rate. That's 0.01 s-sat/vbyte min feerate (which gets burned). Assuming the bmm bid cost on mainchain is 20k sats then 0.02+ s-sat/vbyte is more realistic. People have to offer higher fees if there is less demand for the next block inclusion it's not like they get a block automatically every 10 minutes and can get in for "free" if there is no demand, if there is no demand, the next block will come later.

Appending the chain

The Sponsor can append new epoch one after the other, the sidechain tokens become available for him to sell with sufficient confirmation on locking new liquidity into the covenant withdrawal chain in a non-trusted manner. A sidechain beacon address could be used to inform sidechain clients of the consecutive founding epochs, using anyone can spend similarly to how blind merged mining would be done without covenants. The main advantage of this is the Sponsor can actually be replaced without a sidchain fork or without his consent. In fact anyone could bid for an epoch with their liquidity but only one can win a specific block period, there is no ambiguity.

Graceful wind down

Surfchain incentives can work great while there is relatively constant or increasing demand for the sidechain tokens utility and block space. When demand for the sidechain utility comes to an end, normally the Sponsor is not incentivized in any way to buy the tokens back without the prospect of selling them to the users again in the future. It is possible to optionally change the covenant chain rules a little, so that Sponsor can claim the remaining funds in the sidechain escrow if nobody makes a new blind mered mining transaction for 10'000 blocks (3 months). Any new sidechain block mined resets this counter. This way the users can sell their tokens to traders who then swap their sidechain token with the Sponsor (at a slight discount) for mainchain bitcoin at sufficient batch sizes. After only the Sponsor owns sidechain tokens (that are not simply lost) the sidechain merged mining stops and the withdrawal timeout would start. This would make surfchains almost a two-way-peg but only for the Sponsor.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment