We sketch a construction for subchains: blockchains embedded inside the Bitcoin blockchain, with on-chain data availability and trust-minimized two-way pegs. The construction is similar in spirit to Ruben Somsen's spacechains [1], but lifts data availability onto Bitcoin itself and supports a STARK-verified bridge. It assumes (1) OP_CAT [2] and (2) standardness of the taproot annex [3].
- OP_CAT. Restoring
OP_CAT[2] enables recursive covenants and, in combination with Andrew Poelstra's sighash trick [4], allows a script to introspect the transaction that contains it. - Taproot annex standardness. The annex is a witness field that is committed to by the BIP-341 sighash [3]. Standardness is required so transactions carrying annex data relay through the public mempool.
- STARK verification under OP_CAT. Prior work (Bitcoin Wildlife Sanctuary's
bitcoin-circle-stark[5]) demonstrates that a STARK verifier [6] is implementable in Bitcoin Script withOP_CAT.
A subchain is a sequence of Bitcoin transactions, each enforced by a recursive covenant such that spending one transaction produces the next. Each transaction is one subblock. By setting nSequence = 1, the covenant enforces a one-block relative timelock, capping the rate at one subblock per Bitcoin block.
Anyone — miner or user — may advance the chain by broadcasting the next subblock-bearing transaction. The covenant does not restrict the publisher.
Subblock data is carried in the taproot annex of the publishing transaction. Because the annex is part of the transaction's witness, it is published on Bitcoin and inherits Bitcoin's data-availability guarantees — in contrast to spacechains [1], which leave data availability to a separate layer.
Each publishing transaction includes an OP_RETURN output carrying a 32-byte state commitment:
state_i = H(state_{i-1} ‖ sha_annex_i)
This rolling hash commits to the entire history of subblock annex data, enabling arbitrary introspection of the subchain's history from inside Bitcoin Script in subsequent subblocks.
The covenant enforces that the next subblock's OP_RETURN is exactly this hash of the previous state and the current annex hash.
To read annex data inside Script, we use Poelstra's technique:
- Reconstruct the BIP-341 sighash message on the stack via
OP_CATfrom its constituent fields, includingsha_annex. - Verify a Schnorr signature against this reconstructed message.
If the verification succeeds, the script has effectively forced the transaction's actual fields (including sha_annex) to match the values placed on the stack. The covenant can then constrain those values directly.
Crucially, the script does not need to parse subblock data. It only needs sha_annex to update the state commitment and enforce continuity.
Two models are available for what "valid subblock" means at the Bitcoin layer:
Every subblock must be validated by a STARK verifier embedded in the covenant script. Invalid subblocks cannot be published. This gives the strongest guarantees but is expensive: STARK verification under OP_CAT consumes substantial Script resources per block.
The covenant accepts any subblock; invalid subblocks are simply ignored by subchain nodes off-chain. Only withdrawals to the base chain require a valid STARK proof.
Because a malicious publisher can always publish an empty (but technically "valid") block, the dirty ledger is no weaker in practice than the clean ledger with respect to censorship by publishers. Given the cost asymmetry, the dirty ledger is likely the practical choice.
To make the dirty ledger efficient to follow, each subblock includes a Groth16 [7] SNARK proving:
- The previous subblock's SNARK is valid, or if it is invalid, the proof traverses back to the most recent valid ancestor and proves its validity.
- The data in the current annex is valid under the subchain's consensus rules.
This lets light clients establish the canonical valid history without re-executing every subblock.
All user funds on the subchain are held in a single Bitcoin UTXO controlled by the subchain covenant. The covenant must enforce that across each subblock either:
- the full balance is carried into the next funds UTXO unchanged, or
- a STARK proof attached in the witness authorizes specific withdrawals.
OP_CAT is sufficient to enforce the carry-over case (compare input value to output value via the reconstructed sighash), keeping the dirty-ledger regime intact when no withdrawal occurs.
A user creates a deposit UTXO whose only spending condition is being aggregated into the funds UTXO in a subsequent subblock. The covenant on the funds UTXO recognizes such deposit UTXOs and credits the depositor on the subchain. (Exact mechanism TBD — likely a covenant-restricted output template that the next subblock transaction is forced to consume.)
A subblock publisher produces outputs paying withdrawing users directly on Bitcoin. Such transactions must carry a STARK proof attesting that the withdrawals are authorized by valid subchain state. The covenant's STARK verifier gates these payouts; without a proof, the covenant only permits the carry-over branch.
- Liveness. If miners run a subchain node, the subchain is live whenever Bitcoin is live: any subchain transaction will eventually be included via some miner-built subblock. No user can be censored indefinitely.
- Safety. Subchain safety reduces to Bitcoin's safety. Reorgs of the subchain are exactly Bitcoin reorgs.
- Permissionlessness. Anyone can spawn a new subchain with arbitrary consensus rules, subblock format, and transaction semantics. If publishing is profitable, miners will do it; otherwise any user can.
- Trust-minimized peg. The bridge has no trusted custodians; correctness is enforced by STARK verification in Script.
The Poelstra trick requires assembling the sighash message on the stack. Bitcoin Script caps stack items at 520 bytes, so the non-witness portion of the publishing transaction must fit within 520 bytes. Witness data is excluded from the BIP-341 sighash and is therefore unconstrained by this limit, which is convenient since SNARK proofs and annex payloads can be large.
The exact field layout from BIP-341's "Common signature message" [3] is load-bearing: the script must reconstruct it byte-for-byte. Notably, the annex contributes only as sha_annex (a single hash), which is exactly what the construction needs.
Subchain nodes parse annex contents off-chain. Script only needs sha_annex to:
- Update the rolling state commitment in the next
OP_RETURN. - Bind the annex to whatever the SNARK / STARK proves about its contents.
This keeps in-script work small and bounded regardless of annex payload size.
- Precise covenant for deposit UTXO aggregation into the funds UTXO.
- Concrete script size / cost for the dirty-ledger covenant (carry-over branch + STARK-verified withdrawal branch).
- Behavior under conflicting publishers competing for the same Bitcoin block (only one wins; the loser's subblock is dropped — does this interact badly with the SNARK-recursion scheme?).
- Fee-payment model for publishers in the absence of subchain-native MEV.
[1] R. Somsen. Spacechains: Bitcoin sidechains via blind merged mining. Reference implementation and overview, github.com/RubenSomsen/spacechains. See also "Bitcoin Spacechains Explained in 4 Minutes" and "Spacechains inside Spacechains" (2021).
[2] E. Heilman and A. Sabouri. BIP-347: OP_CAT in Tapscript. Bitcoin Improvement Proposal, 2023. github.com/bitcoin/bips/blob/master/bip-0347.mediawiki
[3] P. Wuille, J. Nick, and A. Towns. BIP-341: Taproot — SegWit version 1 spending rules. Bitcoin Improvement Proposal, 2020. See in particular the "Common signature message" section defining the BIP-341 sighash and the annex (sha_annex). github.com/bitcoin/bips/blob/master/bip-0341.mediawiki
[4] A. Poelstra. OP_CAT: The purr-fect solution for covenants. Blockstream Engineering Blog, 2024. blog.blockstream.com/op_cat-the-purr-fect-solution-for-covenants
[5] Bitcoin Wildlife Sanctuary. bitcoin-circle-stark: A Circle-STARK verifier implemented in Bitcoin Script (assuming OP_CAT). github.com/Bitcoin-Wildlife-Sanctuary/bitcoin-circle-stark
[6] E. Ben-Sasson, I. Bentov, Y. Horesh, and M. Riabzev. Scalable, transparent, and post-quantum secure computational integrity. IACR ePrint 2018/046, 2018. eprint.iacr.org/2018/046
[7] J. Groth. On the size of pairing-based non-interactive arguments. EUROCRYPT 2016, LNCS 9666, pp. 305–326. eprint.iacr.org/2016/260