Case study: fast finality

To understand why BTC staking can solve these two problems, let’s consider an example where Alice sends an L2 transaction to Bob, and Bob can quickly confirm the transaction without worrying about double-spending.

When Alice sends the transaction, the sequencer includes it in an L2 block. The finality providers receive this block immediately, generate EOTS signatures to vote for the block, and submit these signatures to the finality contract on Babylon.

Bob then downloads these finality signatures from the contract and uses the finality gadget to verify if the transaction has enough finality votes. If over two-thirds of the voting power is achieved, Bob can accept the transaction without waiting for it to settle on L1. This process takes only a few seconds compared to over 15 minutes.

Bob is confident in quickly accepting the transaction because the rollup consensus has been modified to include this finality check.

Now, imagine Alice colluding with the sequencer to double-spend against Bob. Since Bob only accepts transactions with finality votes, the sequencer would need finality signatures for a forked block from the finality providers. However, rational finality providers would not support this, as it would result in the slashing of their staked Bitcoin.