BIP 443 Gives Bitcoin Stateful Smart Contracts Without a Trust Layer
BIP 443's OP_CHECKCONTRACTVERIFY embeds contract state into Taproot output keys and enforces valid state transitions on-chain, making stateful Bitcoin contracts possible without a trusted third party.
OP_CHECKCONTRACTVERIFY commits contract state directly into Taproot keys, enforcing valid transitions on-chain and enabling compact fraud proofs without a trusted sequencer.
Key takeaways
- BIP 443 (OP_CCV), authored by Salvatore Ingala, embeds contract state into Taproot output keys via key-tweaking, enabling stateful UTXOs that carry and update committed data across multiple transactions.
- OP_VAULT (BIP 345) was withdrawn in May 2025, superseded by BIP 443, and the proposal has since been assigned Bitcoin Inquisition identifier BIN-2026-0002, putting it on track for signet testing.
- No covenant proposal has been activated on Bitcoin mainnet as of late 2026; the technical case for BIP 443 is strong, but the gating factor is now social consensus among Bitcoin developers.
BIP 443, the formal specification for OP_CHECKCONTRACTVERIFY (OP_CCV), is the most fully-specified path Bitcoin has to stateful smart contracts, and it does so without adding computational complexity to base-layer nodes. The proposal, authored by Salvatore Ingala and merged into the BIPs repository in May 2025, is now assigned Bitcoin Inquisition identifier BIN-2026-0002 for signet testing, per Bitcoin Optech Newsletter #405.
How State Gets Into a Taproot Key
Standard Bitcoin script evaluates each transaction independently with no memory of prior executions. That means no stateful contracts natively, and every workaround to date has been a kludge.
OP_CCV changes the primitive. Every Taproot output contains an internal key that can be cryptographically tweaked to commit to extra data. Formally: Q = P + t·G, where P is the internal key, G is secp256k1's generator, and t is a tagged hash of P and the committed data. BIP 443 applies this same mechanism to embed contract state alongside the standard taptree commitment.
The result: a UTXO whose key commits to both the set of spending conditions and the current contract state. When that UTXO is spent, OP_CCV verifies the state data provided on the witness stack, enforces any computation on it, and requires that the resulting updated state is correctly re-committed in a specified output. State transitions are enforced on-chain, without a trusted intermediary.
The opcode supports three value-handling modes. Default routes the entire input value to the specified output. Deduct routes a partial amount, leaving the remainder available for additional outputs. Ignore checks the script and data commitment without constraining the amount at all. Because the amount-checking semantics are designed to preserve the entire input amount across outputs, BIP 443 requires fees to be paid exogenously via a separate input, a clean solution to a known weakness in OP_CTV and presigned-transaction covenants where amounts are fixed at signing time.
The MATT Architecture and What It Actually Enables
OP_CCV is the core primitive of MATT (Merkleize All The Things), a smart contract framework Ingala first proposed on the bitcoin-dev mailing list in November 2022 following a presentation at BTCAzores. The framework encodes computation as a sequence of state commitments rather than executing logic directly in Bitcoin script.
Ingala's framing from that original post:
"I believe this construction gets close to answering the question of how small a change on bitcoin's layer 1 would suffice to enable arbitrary smart contracts."
When OP_CCV is paired with OP_CAT, the MATT framework gains full Merkle proof verification on-chain. Two distinct Merkle trees sit alongside a Taproot output: the standard taptree for spending scripts, and a separate state tree whose leaves contain the contract's data. OP_CAT enables byte concatenation in script, making it possible to construct and verify Merkle proofs against that state tree directly on-chain. This is how MATT achieves compact fraud proofs: execution happens off-chain, and disputes are settled on-chain by verifying a Merkle path against the committed state root.
The fraud-proof architecture matters because it breaks the standard binary in the smart contract debate. Ethereum-style execution pushes everything on-chain, which requires trusting the validator set and accepting the complexity that entails. MATT pushes execution off-chain and settles disputes on-chain, keeping Bitcoin's conservative validation model intact. No trusted sequencer. No separate validator set. BIP 443's own motivation text names BitVM as a direct beneficiary, noting that building BitVM-style cross-chain bridges without this primitive carries a heavy complexity tax. If activated, OP_CCV could substantially reduce the trust assumptions and block-space footprint of Lightning channel factories and BitVM constructions.
The covenants field is also narrowing, which matters as much as the technical merits. OP_VAULT (BIP 345) was withdrawn in May 2025 in favor of BIP 443. BIP 443 has been merged, assigned a BIN identifier, and is headed for signet. The question is no longer whether Bitcoin should have covenants. It is whether BIP 443 is the right primitive and when developers build rough consensus around it.
What to Watch
Bitcoin Inquisition identifier BIN-2026-0002 means OP_CCV is approaching signet deployment, the first real test environment. Watch the Bitcoin Optech MATT topic page and the bitcoin-dev mailing list for two things: meaningful technical objections from Core maintainers (not noise, actual attack vectors), and the results of signet testing once BIN-2026-0002 goes live.
The thesis breaks if the research community surfaces a viable attack, whether covert transaction pinning, recursive covenant DoS, or a demonstration that "compact fraud proofs" require interaction levels that make them impractical at scale. Short of that, BIP 443 is the most credible path forward in the covenants debate, and the gating factor is now entirely social, not cryptographic.
Sources
- BIP 443, official text
- BIPs #1793, GitHub PR (merged May 2025)
- Salvatore Ingala, original MATT bitcoin-dev post, November 8, 2022
- Salvatore Ingala, concrete MATT opcodes post, July 30, 2023
- Bitcoin Optech MATT topic page
- Bitcoin Optech Newsletter #405 (BIN-2026-0002 assignment, May 2026)
- Covenants.info, CCV and MATT wiki
- Salvatore Ingala research page
Frequently Asked Questions
What is a "state-carrying UTXO" and why can't Bitcoin script already do this?
A state-carrying UTXO is one that holds committed data and passes an updated version of that data to the next transaction in a chain. Standard Bitcoin script evaluates each transaction in isolation with no memory of prior spends, so there is no native way to carry or update state across transactions. Every existing workaround either uses pre-committed addresses to represent a finite set of states (which cannot handle numerical logic elegantly) or requires trusting an external party to manage state off-chain. OP_CCV enables state to be committed directly into the Taproot output key and enforced at spend time, closing that gap without a trusted intermediary.
How is MATT / OP_CCV different from Ethereum smart contracts?
Ethereum executes smart contract logic fully on-chain: every node validates every computation, which requires the entire validator set to agree and creates the complexity and trust model Ethereum is known for. MATT runs computation off-chain and settles disputes on-chain via compact fraud proofs verified against a committed state tree. The on-chain footprint is minimal: a Merkle proof path, not full execution. Bitcoin nodes never run arbitrary computation; they only verify that a state transition is valid relative to the committed root. That is the distinction between fraud-proof-based programmability and full on-chain execution.
What would it take to actually activate BIP 443 on Bitcoin?
Activation requires a soft fork, which means rough consensus among Bitcoin Core developers, followed by a deployment mechanism (historically BIP 9 or BIP 8 signaling) that gives miners and nodes time to upgrade. The technical bar is high: the BIP must be fully specified, reviewed, implemented in Core, and deployed to a testing environment like signet or Bitcoin Inquisition before any mainnet proposal. BIN-2026-0002 covers the Bitcoin Inquisition step. After signet testing surfaces no critical issues, the proposal needs sustained, broad developer support, something no covenant proposal has achieved on mainnet as of late 2026. The cryptographic work is largely done; the social coordination work is not.
