This article is our attempt to explain the covenant debate simply, assess what each proposal would change for BitVM-style bridges, and open our research for anyone to check.
Put simply, a covenant is a Bitcoin script capability that restricts how a coin can be spent in the future: not just who can spend it, but what the spending transaction must look like. Bitcoin does not have covenants today. Every BitVM-style bridge, including ours, emulates them socially instead, using committees that pre-sign transactions and delete keys. The current covenant proposals are, in large part, an argument about how much of that social emulation Bitcoin consensus should take over.
This month Chun Wang (co-founder of f2pool, one of the longest-running Bitcoin mining pools with roughly 10% of network hashrate) posted that "If BIP-119 (or an alternative) gets enough support, we are happy to signal it."
A signaling window for BIP-119 (OP_CHECKTEMPLATEVERIFY), opened by a community-published BIP9-style activation client, has been live since March 30th, with miner signaling effectively at zero as of mid-2026. In response, Robin Linus, the creator of BitVM, quote-posted him: "Time to focus on the BIP-448 covenants proposal. Let's activate it this year."
We are not going to argue for or against activating anything. What we can do, as a team shipping a BitVM3-based bridge on Bitcoin, is explain what these proposals are and what each one would actually change for the systems that need them most.
The committee is a covenant
The fastest way to understand covenants is to look at how bridges work without them.
A BitVM-style bridge locks BTC on Bitcoin and makes it usable on a second layer. The security question is: what stops the locked coins from being stolen? The answer is a transaction graph: a pre-defined set of Bitcoin transactions forming every allowed path the coins can ever take, including deposit confirmation, withdrawal, challenge, and slashing paths. If the graph is the only way the coins can move, the bridge is safe.
Bitcoin Script cannot enforce a transaction graph by itself. So the BitVM2 protocol, designed by Robin Linus and collaborators, enforces it socially. In the BitVM2 paper's own words, "the CheckCovenant is emulated through a committee n-of-n multisig" that pre-signs the transactions during setup. Every committee member signs every allowed path, and then deletes their signing key. As long as one member honestly deletes, no new spending paths can ever be created. The trust assumption is called 1-of-n: one honest participant is enough.
Our own GOAT BitVM3 whitepaper describes the same procedure as a three-step recipe: define the transaction graph, pre-sign the graph, publish the graph. The paper is explicit that this is covenant creation by other means. The Committee role in GOAT BitVM3 exists to be "the n-of-n signers for the pre-signed BitVM2 transaction graph".
This is not just a design on paper. Citrea's Clementine bridge, built on BitVM2, launched on Bitcoin mainnet with exactly this model: publicly disclosed signers, safety enforced by the Bitcoin network under the assumption that one signer is honest. In its first six months it processed 150 BTC. The social covenant is running in production today.
But notice what the emulation costs. The committee must be convened and must cooperate for every deposit, because each new peg-in needs its own copy of the graph signed. Deposits are interactive. The ceremony recurs. And the whole arrangement rests on the belief that at least one signer really did delete their key. It works, and it is the best available answer on Bitcoin as it exists. It is also precisely the machinery a covenant opcode would let consensus take over.
To be clear about what kind of cost this is: pre-signed spends are cheap onchain, often cheaper than the covenant scripts that would replace them. What covenants remove is not fees but coordination and trust: the interactive ceremony, and the assumption that a key was really deleted.
The proposals, explained simply
There are more covenant proposals than most people can track, so it helps to group them by capability rather than by BIP number.
Templates. A template covenant lets an output say: the transaction that spends me must match this exact shape. OP_CHECKTEMPLATEVERIFY (CTV, BIP 119), formalized by Jeremy Rubin more than five years ago, is the original. OP_TEMPLATEHASH (BIP 446) is its modern Taproot-native successor, published as a Draft in March 2026 by Gregory Sanders, Antoine Poinsot, and Steven Roose. Per the authors' announcement in July 2025, TEMPLATEHASH drops CTV's explicit input-count, output-count, and scriptSig fields (the counts remain implicitly committed through the sequence and output hashes) and adds the Taproot annex. A template commits to the spending transaction's outputs, sequences, locktime, and version. It deliberately does not commit to which other coins are spent alongside it. That omission matters, and we will come back to it.
Signatures over arbitrary messages. OP_CHECKSIGFROMSTACK (CSFS, BIP 348) lets a script verify a signature over any message, not just the spending transaction. A version of it has run on Blockstream's Liquid sidechain since the earliest Elements releases, and Liquid's Taproot upgrade brought it to the Schnorr semantics the mainnet proposal mirrors. Combined with a template opcode, this enables rebindable signatures: a signed authorization that can attach to more than one transaction, so a script path can re-key itself without a fresh signing round.
The bundle. BIP 448, "Taproot-native (Re)bindable Transactions", packages TEMPLATEHASH, CSFS, and OP_INTERNALKEY (BIP 349) into one proposal. It was published as a Draft in March 2026 and is the proposal Linus pointed at this month. Its primitives are now live for testing: TEMPLATEHASH activated on the Bitcoin Inquisition signet on July 27th, 2026. There is no activation client and no mainnet signaling for 448.
Programmable introspection. OP_TXHASH (BIP 346), authored by Steven Roose, generalizes the template idea: instead of one fixed template shape, the script chooses which transaction fields to commit to, field by field. Crucially, that includes the other inputs of the spending transaction.
Concatenation. OP_CAT (BIP 347) re-enables a primitive Satoshi disabled in 2010. It sounds trivial, but is not: with known tricks it unlocks general transaction introspection, and it has been used to verify STARK proofs directly in Bitcoin script on test networks. It also shares CSFS's production history, having run on Liquid since the earliest Elements releases, which makes the mainnet standoff instructive: the objection to CAT was never that it does not work. The BIP's own motivation section names BitVM directly, listing trusted-setup elimination and smaller transactions for BitVM2 among its use cases. In principle its introspection reaches everything discussed below, sibling inputs included, but through sighash reconstruction tricks that produce large, awkward scripts rather than a purpose-built opcode. The same generality makes it the most contentious proposal here, since it opens the door to recursive covenants, which some see as the point and others as the risk.
State-carrying outputs. OP_CHECKCONTRACTVERIFY (BIP 443), from Salvatore Ingala's MATT research, lets outputs carry and enforce state across spends, enabling general onchain fraud proofs. The BIP's motivation section names BitVM directly, noting the cost in "complexity, interactivity, and (potentially) in block size occupation" of working without such a primitive.
The maximalist path. Beyond individual opcodes sit whole-language redesigns: Blockstream's Simplicity (live on its Liquid sidechain) and Rusty Russell's Great Script Restoration, which would re-enable and extend much of the original opcode set. Neither has an active mainnet activation push, but they mark where the expressiveness spectrum ends.
None of these is activated. CTV has a live signaling attempt going nowhere; 448 has momentum in discussion but no activation machinery; OP_CAT's specification was marked Complete on March 1st, 2026 under the revised BIP process, still with no activation parameters; the rest are Drafts at various stages of review. That is the honest status as of mid-August 2026.
What each capability buys a bridge
Here is the fundamental assessment, mapped against what bridges actually do.
Non-interactive deposits. With a template covenant, a deposit output can encode the transaction graph in its spending conditions, enforced by Bitcoin consensus, so a user can peg in without convening the signer committee at all (the graph and its challenge game are unchanged; what disappears is the ceremony that creates them). Linus's April 2025 Delving Bitcoin analysis, How CTV+CSFS improves BitVM bridges, argues that CTV eliminates the presigning committee and the existential-honesty assumption for safety, and that CSFS lets anyone derive operator keys non-interactively. He also notes the current designs still require an operator signature at peg-in, which permits censorship, with fully non-interactive deposits as the goal. For a bridge like ours, where every deposit today runs the pre-sign ceremony described above, this is the single largest operational change on the table.
Smaller footprint. BitVM-style constructions commit data onchain with hash-based one-time signatures, which are large. Linus estimated in the same April 2025 analysis that CSFS-based commitments cut the relevant transaction sizes by approximately 10x. The BitVM Alliance's position was unambiguous: "the BitVM Alliance strongly supports the CTV + CSFS proposal."
Re-keying long-lived chains. GOAT BitVM3 anchors its L2 sequencer set to Bitcoin through what our whitepaper describes as a chain of pre-signed Bitcoin transactions, updated by threshold signature each rotation and bootstrapped by a trusted setup ceremony. This is exactly the pattern the 448 bundle's rebindable-signature design targets: with TEMPLATEHASH, CSFS, and INTERNALKEY, a script leaf can re-key to a new signer set without a fresh pre-signing round. The covenant does not just shrink this ceremony. It removes the reason the ceremony exists.
The sibling input problem. Now the omission we flagged. Bridge transaction graphs lean heavily on connector outputs: small UTXOs whose only job is to link transactions together, so that spending one path consumes the connectors that would enable another. Our own transaction graph is dense with them; so is every BitVM2-derived design. Enforcing a connector means enforcing a statement no template can express: this output may only be spent in a transaction that also spends that specific other output. Templates commit to the spending transaction's outputs, not its other inputs. The BIP 446 rationale explains why directly: committing to sibling prevouts "would introduce a hash cycle when the hash is committed in the output itself", along with quadratic hashing costs.
Workarounds exist, and they are fragile. A trick exploiting CTV's scriptSig commitment was analyzed on Delving Bitcoin in April 2025; Jeremy Rubin noted the linked output "can still be spent elsewhere" and remains malleable, and Anthony Towns showed a substitute UTXO can break the intended protocol, while a generic introspection opcode querying an input's txid "doesn't create any cryptographically intractable loops". Gregory Sanders, a 448 co-author, was candid on the bitcoin-dev list in June 2025: sibling-prevout commitment "would be best offered through an explicit method of committing to sibling prevouts", and he later noted in the BIPs repository review that sibling commitment might be well past the point of just going full TXHASH.
This is the sharpest technical distinction in the whole debate, and it is worth stating as a rule: templates shrink the committee's job; sibling-input introspection could eliminate it. Under BIP 448, consensus takes over graph shape enforcement, and deposits stop being ceremonies, but connector linkages still need a pre-signing committee somewhere in the design. Under TXHASH-class introspection, the covenant itself can express the connector relationships, and the committee's remaining role in graph enforcement disappears.
Why not just do TXHASH, then? The most credible answer comes from its own author. Steven Roose wrote during the 2025 activation debate that the technical debt and bug potential are "an order of magnitude bigger for TXHASH than for CTV", and that he would not want it on the table anytime soon. The TXHASH author co-authored the minimal bundle. That arc, more than any single argument, explains where the proposal landscape sits today.
Where garbled-circuit bridges fit
Everything above concerns how a bridge's transaction graph gets enforced. There is a second, independent axis: how a fraudulent withdrawal gets proven wrong. It is worth separating these. Covenants bear mainly on the first axis; garbling transformed the second, and the second is where the field has moved fastest. Covenant-family opcodes still shrink the second axis's onchain plumbing, though, as we will get to.
In BitVM2, the dispute machinery is enormous: the operator's assertion publishes the verifier's intermediate values onchain, and the Disprove transaction executes a chunk of a SNARK verifier in Bitcoin script, with some branches approaching the block size limit. The newer generation moves verification off-chain entirely using garbled circuits. Alpen Labs' current bridge direction, Glock, is one construction on this path; its garbled-circuit verifier shipped for public testing in July 2026. GOAT BitVM3 is another. Our construction integrates the BABE witness-encryption approach: hash-based garbled circuits are prepared at setup, and a valid Groth16 proof becomes the only way for an operator to decrypt a pre-committed secret. Bitcoin never runs the verifier. The onchain dispute reduces to one native hash check, RIPEMD160(SHA256(msg)) against a committed value. To be precise about lineage, since flaws were reported in 2025 in an earlier RSA-based garbling scheme: GOAT BitVM3 is specified over hash-based half-gate garbling with witness encryption, a different construction, with correctness of the circuits enforced by a cut-and-choose protocol across 181 instances per designated verifier, giving soundness error at most 2^-40.
The measured result, from our whitepaper: the operator's Assert witness is 2,058 bytes, a challenger's response carries about 14 KB of circuit labels, and the operator's rebuttal is 64 bytes. Full peg-in setup, including the cut-and-choose and a STARK soldering proof generated by the Ziren zkVM, runs in roughly 25 minutes on CPUs.
So for a garbled-circuit bridge, what do covenants change? Mapping our own components against the capability classes above:
The pre-signed transaction graph and its per-deposit ceremony are template territory: BIP 448 would let consensus enforce much of what our committee emulates, and deposits could stop requiring the committee's participation. The connector outputs throughout our graph, including the Pre-Kickoff chain that lets one operator bond serve sequential withdrawals, are the sibling-input problem: templates alone do not cover them, and this is where TXHASH-class introspection would finish the job. The sequencer-set commitment chain is the rebindable-signature use case almost verbatim. And the dispute mechanism itself splits in two. The cryptographic core, the garbling and witness encryption that reduce the decision to a hash check, is untouched by any covenant proposal: no opcode changes what gets proven off-chain. But the plumbing that binds that dispute to Bitcoin is still paid for in script. Our commitments ride on WOTS one-time signatures, and the script that verifies them against the circuit's public inputs runs to tens of kilobytes. CSFS would replace those one-time signatures outright, and concatenation-class primitives (OP_CAT, or the narrower OP_PAIRCOMMIT from the LNhance lineage) would compress the commitment checks. The 64-byte rebuttal stays 64 bytes; what shrinks is everything around it.
Composition opens a further step. TXHASH lets a script authenticate the current input's prevout (the txid of its parent transaction), and OP_CAT lets the witness supply that parent's bytes and recompute the txid in Script. Together, a script can inspect and constrain the parent transaction itself, and in principle repeat the pattern up a chain of ancestors. The primitive has surfaced in covenant discussions as ancestry proofs; the bridge application, as far as we can find, has not. The payoff is capital efficiency. Today everything the graph will ever spend must exist from peg-in, because pre-signed graphs commit to specific txids in advance: BitVM2-style designs park operator collateral in a pre-kickoff output at deposit time and hold it idle until withdrawal, and our own Pre-Kickoff chain reserves BTC for protocol fees the same way. With TXHASH and OP_CAT together, a script could constrain the required transaction structure and scriptPubKeys without committing to a txid, so those outputs could be constructed at peg-out time, entering the challenge flow from there. Nothing sits idle between deposit and withdrawal. This is speculative: it assumes two proposals activating together, and Script's element-size limits mean it holds for compact graph transactions rather than arbitrary ones. But it shows how much design space opens once introspection composes.
As far as we can find, no dedicated analysis has mapped specific covenant opcodes onto garbled-circuit bridges; the covenant-for-bridges work to date is BitVM2-centric. The connection is acknowledged in passing, as when Liam Eagen noted on the Bitcoin Optech podcast in September 2025 that these designs rely on presigning federations because of the lack of covenants, but what an activated covenant would change, component by component, has not been laid out. Consider this section that first pass, and an invitation to correct it.
The honest counterweights
An assessment that only counts benefits is marketing. Here is what cuts the other way.
OP_CAT changes the question. In July 2024, StarkWare verified a STARK proof directly on Bitcoin's Signet using OP_CAT, at substantial per-verification cost. If onchain proof verification became viable, parts of the optimistic, challenge-based model that BitVM exists to enable would be less necessary, at least for STARK-based systems willing to pay that price per verification. There is a deeper argument some attach to this path: STARK-class systems are built on hash-based primitives that are conjectured post-quantum secure, while pairing-based proof systems are not, so onchain hash-based verification doubles as a quantum-readiness story. Garbled-circuit bridges compete at the opposite end: minimal onchain bytes in exchange for off-chain setup. Both can be true; the trade space is real, and CAT advocates, including commercially interested ones, should be read as advocates.
Maybe no soft fork is needed at all. The most interesting recent argument comes from Linus himself. His Binohash work, published in March 2026, argues that limited transaction introspection is achievable on Bitcoin today, without any consensus change, potentially removing the Bitcoin light client from BitVM bridges. We present that alongside his August call to activate 448 without trying to resolve the tension; researchers are allowed to pursue both tracks, and the existence of a no-fork path changes the cost-benefit of every proposal above.
The skeptics have substance. Matt Corallo argued in June 2025 that fuller introspection "provides a lot of flexibility in the constructs people can build", pushing against minimalism from the opposite direction as Roose, and favoring a design that permits minimal future extensions. Antoine Riard warned the same summer that more powerful script capabilities "could definitely increase risk surface", including MEV-style dynamics, and argued consensus cleanup should come first. Others objected to the 2025 CTV+CSFS letter campaign on process grounds: sixty-six signatures, in their view, is not how Bitcoin measures consensus. The proposal stalled on genuine disagreement, not apathy. Anyone telling you covenant activation is imminent, or obviously correct, is misleading you.
Where we stand
We build on Bitcoin as it is. GOAT BitVM3 was designed for a Bitcoin with no covenants, and it works there: that is the point, and nothing in this article is a dependency or an excuse. But we will not pretend to be neutral about capability. Template covenants would make deposits non-interactive and let consensus enforce most of what our committee emulates today. Sibling-input introspection would finish the job. Rebindable signatures would retire our sequencer commitment ceremony. Progress on any of these is progress for every BitVM-style bridge, whichever proposal carries it and whenever Bitcoin's process, which is not ours to rush, gets there.
The research behind this piece, with full quotes, links, and the claims we could not verify, is published below. If we got something wrong, we want to know.
FAQ
What is a Bitcoin covenant? A script capability that restricts what the transaction spending a coin must look like, not just who can sign for it. Bitcoin does not currently have covenant opcodes; proposals include CTV (BIP 119), OP_TEMPLATEHASH (BIP 446), the BIP 448 bundle, OP_TXHASH (BIP 346), OP_CAT (BIP 347), and OP_CHECKCONTRACTVERIFY (BIP 443).
Do BitVM bridges need covenants to work? No. BitVM2-based and garbled-circuit bridges run on Bitcoin today by emulating covenants with n-of-n pre-signing committees under a 1-of-n honesty assumption. Citrea's bridge has been live on mainnet since January 2026; GOAT BitVM3 is specified and implemented on Bitcoin as it exists. Covenants would simplify and strengthen these designs, not enable them.
What would BIP 448 change for bridges? Its template opcode would let Bitcoin consensus enforce transaction graphs that committees pre-sign today, making deposits non-interactive and narrowing setup trust. Its CSFS opcode enables rebindable signatures and smaller data commitments. It does not commit to sibling inputs, so connector-output linkages would still need pre-signing.
What is the difference between BIP 448 and TXHASH for bridges? Templates shrink the committee's job; TXHASH-class introspection, which can commit to sibling inputs, could eliminate the committee's role in graph enforcement entirely. TXHASH's own author considers it substantially more complex to review and ship, which is why the minimal bundle came first.
Is any covenant proposal activated on Bitcoin? No. As of August 2026, CTV has a live signaling window with negligible miner support, BIP 448 is a Draft with signet testing but no activation client, OP_CAT's specification is marked Complete but carries no activation parameters, and the remaining proposals are Drafts under review.
Sources
Robin Linus, How CTV+CSFS improves BitVM bridges, Delving Bitcoin, April 2025 (thread includes Jeremy Rubin and Anthony Towns replies, April 2025)
Robin Linus, X post on BIP-448, August 2026; Chun Wang, X post, August 2026 (both screenshots are above)
BitVM2 paper, Bridging Bitcoin to Second Layers
GOAT Network Research Group, GOAT BitVM3 White Paper v2.0, May 2026
BIP 446, BIP 448, BIP 346, BIP 347, BIP 443, bitcoin/bips repository
Gregory Sanders and Antoine Poinsot, What's a good stopping point?, bitcoin-dev, June 2025 (thread includes Sanders on sibling prevouts, Matt Corallo, and Steven Roose replies)
Antoine Poinsot et al., Taproot-native (re-)bindable transaction bundle announcement, bitcoin-dev, July 2025
CTV + CSFS: a letter, June 2025, and the bitcoin-dev discussion thread (Steven Roose's TXHASH assessment originates in Delving Bitcoin thread 1509)
Citrea, Citrea Mainnet Is Live, January 2026, and 6 Months of Clementine, August 2026
Alpen Labs, Glock: A new standard for verification on Bitcoin, July 2025, and Testnet III announcement, July 2026
StarkWare STARK verification on Signet, July 2024, as reported by Bitcoin Magazine
Blockstream, Tapscript: New Opcodes, Reduced Limits and Covenants, 2021, on CSFS, OP_CAT, and covenant history in Elements/Liquid
Bitcoin Optech Newsletter #396 (Binohash), March 2026; Newsletter #361 (letter coverage and Towns analysis), July 2025; Optech Podcast #369 recap (Liam Eagen on garbled-circuit bridges), September 2025
