Rollups: BCH vs BitVM
A rollup settles by having its base chain accept a proof that its state changed correctly. Bitcoin Script cannot check such a proof, so Bitcoin rollups settle through BitVM: a committee that presigns every move of a deposit, operators who front withdrawals, a challenge window, and a dispute game for when someone cheats. Bitcoin Cash Script can check the proof itself, so a covenant (a script rule that limits where coins can go next) can accept a new state as soon as its proof verifies. This page compares the two, using Alpen Labs’ bridge as the Bitcoin example. Bitcoin designs are as of November 2026.
On Bitcoin: BitVM
Bitcoin has no covenants and cannot run a proof verifier within its limits. BitVM2 works around both:
- Covenants by presigning. A committee presigns every transaction a deposit can ever take, then deletes its keys. This is safe if one signer is honest.
- Optimistic verification. An operator pays users out of its own funds and claims reimbursement later. The proof is only checked on chain if someone challenges, and then only the one disputed step.
In the one full dispute run on Bitcoin mainnet, settling it took 42 blocks and about $16,000 in fees, with transactions too large to relay normally. The peaceful case is cheap. The design secures BTC itself without a soft fork, and BitVM bridges from Citrea and Bitlayer run on mainnet.
Details and sources
The USENIX Security ’26 preprint reports the dispute on 2025-06-03: 42 blocks, 14.9M sat. The disprove step is spread over 379 scripts of 0.5 to 3.99 MB each. Assert and Disprove exceed Bitcoin’s 400 kB standardness limit and go straight to a miner. The paper puts collateral at about 2 BTC per operator, and the cooperative case under 16.75 kvB. Mainnet bridges: Citrea (January 2026), Bitlayer (July 2025).
Alpen’s bridge
Alpen replaced on-chain dispute scripts with garbled circuits, an encrypted copy of the verifier that other operators run to check a proof (Glock, hardened by Mosaic), now on a signet testnet since July 2026. Per its docs:
- Operators presign each deposit with a key that needs all of them to sign, and front withdrawals from their own funds. A claim can be challenged for 1,064 blocks, about 1.4 weeks.
- Disputes happen off chain. The other operators check the proof by running the garbled verifier for Groth16 (a common, compact type of zero-knowledge proof). A bad proof leaks a secret that blocks the payout.
- Trust: as long as one operator is honest and online, deposits are safe and withdrawals keep working. Admin multisigs can replace the operator keys and the verifying key (which decides what counts as a valid proof).
The cost moves off chain: each garbling table is about 43 GB, set up for every pair of operators. The code has not been externally reviewed.
Details and sources
Alpen’s first bridge (Strata, December 2024) followed BitVM2; that post is now marked historical. In a dispute, a watchtower challenges, the operator answers with an SP1 bridge proof, and the watchtower can counter. The garbled circuit is the SP1 v6 Groth16 verifier (g16); see the strata-bridge code. Mosaic uses 181 garbled copies per setup, 7 of them evaluated (constants); table size from the architecture notes. Alpen calls the on-chain cost “low” without vbyte figures; the related BitVM3 design measures about 2.4 kvB to commit a proof and 93 vB to disprove it. A 2.4 MiB garbled Groth16 exists in research, not deployed. Review status: Mosaic README; permissionless challenging is “the next frontier”. Under the administration docs, key replacement takes a 2,016-block delay and a Security Council can sweep the bridge to a Safe Harbor address; on testnet Alpen Labs holds these keys. As with any presigned bridge, all N operators together could spend a deposit through the N-of-N key.
On Bitcoin Cash: the covenant checks the proof
A Groth16 verifier that passed our soundness review, on the leaderboard checks a proof in one standard transaction of 27.6 KB. A Bitcoin Cash Node validates it in about 3.5 ms and relays it under the default policy (node check). For a bridge that means:
- No challenge window: funds move as soon as the proof verifies.
- No fronting and no stake against fraud.
- No presigning committee: the covenant itself enforces where funds go.
- No dispute transactions: every update is the same small, standard transaction.
Our research verifier for STARKs (larger proofs built only on hash functions, so post-quantum) does the same in one standard transaction of 99 KB (report). What remains to trust is the proof system (Groth16 also needs a one-time setup ceremony whose secret must be destroyed), the covenant code, and who may upgrade the verifying key. Our own soundness reset shows how easily a hand-written verifier gets a subtle gap.
Post-quantum
Neither Bitcoin design is post-quantum. Alpen’s deposits sit behind the operators’ joint signing key, which is public on chain from the moment of deposit, and the checked proof is Groth16. A quantum computer could recover the key or forge the proof. On BCH, the Groth16 verifiers are not post-quantum either, but our research STARK verifier and pool use only hash functions, and a covenant output commits to a script hash, with no key to recover.
Details and sources
Deposit output: Taproot key path with the MuSig2 N-of-N key (strata-bridge code); adaptor signatures are Schnorr over secp256k1 (mosaic code); BitVM2 also relies on an n-of-n multisig. Its Lamport/Winternitz commitments and the AES-based garbling are hash-based, but do not protect the keys or the proof. The BitVM3 paper (May 2026) marks every Groth16 and Glock design as not post-quantum. Our STARK verifier is 128-bit classical, about 85 bits against quantum collision search, the level of SHA-256 itself (report). User wallets on BCH still sign with ECDSA or Schnorr; Quantumroot vaults are a post-quantum option. No post-quantum bridge has been built on BCH.
Extra assumptions
A proof checked by consensus code rests on the proof system and the covenant. Garbled circuits add more: a hash function assumed to have a stronger property than usual, a random spot-check of the garbled copies that a cheater could slip past with tiny odds, a special kind of signature, and security arguments that so far are sketches. These may well hold up; native verification does not need them.
Details and sources
Garbling: privacy-free half-gates with free XOR and an AES-based hash assumed circular correlation robust (ckt). Cut-and-choose: 174 of 181 copies opened, 7 evaluated, at most 2-40 chance all 7 are bad (BitVM3). Mosaic “sketch[es] why Mosaic is secure”; BitVM3 gives proof sketches in the random oracle model, first assuming an honest setup. On BCH: Groth16 has a security proof in an idealised group model plus a trusted setup; our STARK models hashes as random oracles; its batching step applies a published theorem (BCIKS20, Thm 7.2), and the remaining step is proved in our own write-up, reviewed internally but not externally.
What a BCH rollup would take
Bitcoin Cash can host a ZK rollup with today’s rules. The part BitVM works hardest for, checking the proof in a standard transaction, already works and is measured above, and we have built a pool covenant with on-chain state and deposits on top of it. No one has assembled a full rollup yet; that takes the usual rollup engineering: a verifier for its real program, a covenant that holds its state, a way to publish its transaction data on chain, a rule for who orders transactions with a way out if they stall, provers and audits. We know of no part that needs a protocol change, though larger input limits would make it cheaper. And a BCH covenant holds BCH and CashTokens, not BTC; a validity proof does not protect against reorgs or censorship of the chain beneath it.
Details and sources
Data availability would ride in input pushes: OP_RETURN carries 223 B per transaction, and transactions over 100 KB are non-standard (consensus allows 1 MB; BCHN policy). The Bitcoin projects have running code, multiple operators and, for Citrea and Bitlayer, mainnet deployments.