Kapow (Kheckpoint-Anchored Proof-of-Work) introduces a Bitcoin-backed checkpointing mechanism for the Liquid Network. It provides Bitcoin-equivalent finality guarantees to Liquid blocks on a ~10-minute interval, backed by the full power of Bitcoin's proof-of-work. Once a Liquid block has been checkpointed on Bitcoin, it cannot be reorged by the Liquid block producers without them also performing a reorg (51% attack) on Bitcoin itself.
This would be especially beneficial if Liquid moves to a BitVM-based bridge, since Liquid's current consensus mechanism would become a weak point in the trust model and undermine the security of the BitVM bridge, invalidating its 1-of-n trust assumptions.
Liquid's original design made a sensible tradeoff: since the peg itself depended on a federation with an honest-majority trust assumption, Liquid consensus could also depend on the same federation. Adding a separate proof-of-work or merge-mined consensus layer would have added complexity without removing the dominant trust assumption, because BTC custody still depended on the federation.
However, there has been recent interest in implementing a BitVM bridge for Liquid. A BitVM bridge can significantly improve peg security from an m-of-n honest-majority trust assumption to a 1-of-n honest-minority trust assumption. But if Liquid block production remains secured only by the existing block signer threshold, then the consensus layer becomes the weakest link. A colluding threshold of block signers could attempt to reorganize Liquid history in a way that undermines BitVM bridge exits.
Put differently, while a BitVM bridge could validate Liquid consensus with an extremely strong honest-minority trust assumption, the Liquid consensus mechanism that it is validating relies on a much weaker honest-majority trust assumption. A malicious majority of Liquid block signers could collude to create conflicting (but valid) Liquid chain histories to trick the BitVM bridge into processing the same exit multiple times, thereby draining funds from the bridge.
This can be solved by having a checkpoint UTXO on the Bitcoin blockchain that is spendable under the same conditions as the Liquid block producer federation. The same 11-of-15 threshold of Liquid functionaries that produce Liquid blocks can spend the UTXO. They must only spend the UTXO in a "checkpoint transaction". A checkpoint transaction signals RBF, spends the checkpoint UTXO back to the same address, and commits to the current Liquid block hash and height in an OP_RETURN output.
Each time a new Liquid block is produced, the same block signers who produced the block should collaboratively extend the Bitcoin checkpoint transaction chain by spending the most recently confirmed checkpoint UTXO in a new checkpoint transaction. If there is already an unconfirmed checkpoint transaction in the Bitcoin mempool from a previous Liquid block, the new checkpoint transaction should have a higher fee to replace it under RBF rules. In other words, there is one pending checkpoint candidate in the mempool, updated via RBF until a Bitcoin block confirms it.
This results in a linear chain of Bitcoin transactions, one in every block, that commits to the state and height of the Liquid network at the time that Bitcoin block was mined. This acts as an immutable checkpoint history for the Liquid network every ~10 minutes.
Liquid clients that are validating the Liquid chain can follow this chain of transactions on the Bitcoin chain and verify that all Liquid blocks they are validating match the expected height and hash in the Bitcoin transaction chain. Valid Liquid blocks that do not match the expected Bitcoin checkpoint height/hash are rejected. This prevents the Liquid block signers from being able to collude to rewrite the Liquid chain history past the last Bitcoin checkpoint.
With this consensus modification, the finality guarantees of a Liquid block with a Bitcoin checkpoint inherit the same finality guarantees as Bitcoin itself. This means Liquid consensus is no longer the weak point in a BitVM-bridge-enabled Liquid Network, enabling Liquid to inherit the full 1-of-n trust assumptions of BitVM.
To make sure BitVM operations are secure, they should require Liquid transactions with a Bitcoin checkpoint that has been buried under a sufficient number of additional Bitcoin blocks.
The rest of Liquid's consensus system still relies on the federation, so it does not inherit Bitcoin's permissionless or censorship-resistant properties. What is inherited from Bitcoin is finality, which is the important property for keeping the BitVM bridge secure. A dishonest majority can still censor or halt the network, including censoring or halting bridge exits.
This means Liquid does not inherit the typical BitVM 1-of-n liveness properties. A dishonest majority can freeze the funds. However, Liquid does inherit 1-of-n custody properties: a dishonest majority cannot steal the funds, and a single honest bridge operator can prevent theft. This is still a significant improvement.
To achieve 1-of-n liveness and permissionless, censorship-resistant consensus, Liquid would need an entirely new consensus system. This would be a much more complex change, but it may also be an interesting area for further research.
A much simpler alternative design is Liquid block reorg fraud proofs. A BitVM exit could be blocked if anyone can provide two Liquid blocks extending the same previous block. This doesn't require any consensus changes to Liquid, but it also doesn't provide a canonical source of truth for the Liquid chain. A malicious pegout can be stopped with this approach, but there's no way to do valid exits after a reorg has occurred. The approach in this proposal is also beneficial outside of just the BitVM bridge. It provides Bitcoin-level finality guarantees to all transactions on the Liquid Network once they have acquired a checkpoint.
In the protocol outlined above, every Bitcoin block is expected to contain a checkpoint transaction for the latest Liquid block, but this is not a requirement. To reduce Bitcoin fee requirements, the Liquid network could target a checkpoint transaction once an hour, or even once a day for example. Even when targeting every Bitcoin block, if two Bitcoin blocks are mined close together and no new Liquid block has been produced, there is no need for another checkpoint transaction.
In times of high Bitcoin transaction congestion, the checkpoint transactions could get delayed. Ideally, the checkpoint transactions would always target next-block fee rates and would be fee-bumped with RBF to ensure that. But if checkpoint transactions get delayed, it's not a problem. Liquid users simply need to wait longer for a checkpoint before receiving the increased finality guarantees.
A malicious majority of Liquid block signers could halt the Liquid chain by submitting a checkpoint transaction that commits to a Liquid block that doesn't exist. Liquid nodes would halt at this height and not be able to sync the Liquid chain past that checkpoint. This is not an issue because, in Liquid's current consensus, a malicious majority of block signers can already halt the Liquid chain by refusing to sign new blocks.
In Liquid today, a malicious majority can halt or rewrite the chain history. With this proposal, they can only halt, not rewrite past the last checkpoint, so it's a strict improvement.
This change is a backward-compatible soft fork from the perspective of the Liquid Network. Existing Liquid clients do not need to update to be compatible with this change. However, they do need to update to get the benefit of the increased finality guarantees provided by the Bitcoin checkpoint transactions.
I think Liquid with 1-of-n trust assumptions offers very attractive tradeoffs for bootstrapping other exotic L2/protocol designs. There are many proposed protocol designs that require covenants, ZK proof verification, or other techniques that are not natively possible on Bitcoin today. These systems can be bootstrapped on Bitcoin today by running a federation or BitVM operator set that emulates the required functionality, but the coordination, responsibility, and regulatory risk involved are significant hurdles to deploying these systems.
Liquid could be used to bootstrap these systems today, but they inherit Liquid's honest-majority trust assumptions and finality. The motivation for many of these protocols is extending the scale or feature set of Bitcoin without significantly increasing trust, so Liquid is not currently attractive.
Liquid with BitVM, plus this proposal, allows these protocols to bootstrap themselves on Liquid instead of directly on Bitcoin while only inheriting a very reasonable 1-of-n trust tradeoff, and without having to take on the burden of running federation or BitVM infrastructure themselves.
Parts of this proposal were inspired by Blind Merged Mining by Paul Sztorc and the Spacechains fee-bidding consensus mechanism by Ruben Somsen.