Bitcoin PIPEs: How Researchers Are Building Covenants Without a Soft Fork
Bitcoin developers have spent five years arguing about which covenant opcodes to activate. OP_CTV was proposed in 2019. OP_VAULT came in 2023. OP_CAT got a BIP number in 2024. All three are still stuck in debate.
On February 13, 2026, cryptographers published a way to build covenants without touching consensus at all.
Bitcoin PIPEs v2 uses witness encryption to lock private keys behind predetermined conditions. If the condition is met, the key is revealed and you can spend. If not, recovering the key is computationally infeasible. Bitcoin sees only a standard Schnorr signature. All the conditional logic happens off-chain, in the cryptography.
This could give Bitcoin vaults, trustless bridges, and zero-knowledge proof verification without waiting years for a soft fork.
What covenants are and why Bitcoin doesn’t have them
Covenants let a script restrict how bitcoin can be spent in future transactions. Examples:
- “This UTXO can only be spent to address X”
- “This UTXO requires a 7-day delay before spending”
- “This UTXO requires a valid zero-knowledge proof to spend”
They enable use cases currently impossible or impractical on Bitcoin:
Vaults: Lock bitcoin such that spending requires a time delay. If your hot wallet keys are compromised, you have time to move funds to a recovery address before the thief can act.
Payment pools: Multiple parties share a single UTXO with exit conditions. Reduces blockchain footprint and fees.
Trustless bridges: Lock bitcoin on L1 with exit conditions enforced cryptographically. Prevents unauthorized withdrawals without relying on multisig federations.
Advanced contracts: Conditional payments based on oracle data, automated recurring payments, trustless escrow with programmable conditions.
Bitcoin Script doesn’t support any of this natively. The scripting language can validate signatures and check conditions on the current transaction, but it cannot introspect or restrict future transactions. To add covenant functionality, Bitcoin needs new opcodes, which requires a soft fork.
The soft fork deadlock
For years, developers have proposed covenant-enabling opcodes. All are stuck:
OP_CTV (CheckTemplateVerify): proposed by Jeremy Rubin in 2019. Commits to a transaction template. The UTXO can only be spent to transactions matching the template. Still no activation consensus after six years.
OP_VAULT: proposed by James O’Beirne in 2023. Purpose-built for vault functionality with time delays. According to Bitcoin Magazine, “OP_VAULT cleanly addresses all the major limitations of a pre-signed transaction or CTV based vault. No restrictive pre-decided denominations or pre-decided fees, no danger in reusing addresses.” Still in debate.
OP_CAT: enables concatenation of stack elements, which combined with other opcodes allows Script to introspect transaction data. Assigned BIP 420 in April 2024. Considered “too powerful” by some. No activation timeline.
Why the delay? Bitcoin consensus is conservative. Every soft fork is high-stakes. Bugs could be catastrophic. There’s no agreement on “the right way”: OP_CTV (simple), OP_VAULT (specialized), or OP_CAT (general-purpose)? Political and social consensus is required across miners, node operators, developers, and users.
The result: covenant functionality remains unavailable on Bitcoin mainnet despite years of proposals.
How PIPEs work
PIPEs (the name likely relates to Polynomial Inner-Product Encryption) is a protocol that enforces covenant-like spending conditions without changing Bitcoin’s consensus rules. Instead of adding opcodes to Bitcoin Script, PIPEs use witness encryption to lock the private key itself behind a condition.
According to Bitcoin Optech Newsletter #393, “Bitcoin PIPEs adds prerequisites on whether a valid signature can be produced or not. In other words, a private key is cryptographically locked behind a predetermined condition. If and only if the condition is fulfilled, the private key is revealed, allowing for a valid signature. While the Bitcoin protocol only has to validate a single schnorr signature, all the conditional logic is processed off-chain.”
Setup phase:
- Generate a standard Bitcoin keypair using Schnorr signatures
- Encrypt the private key using witness encryption such that it can only be decrypted if a valid witness for a predetermined condition is provided
- Publish the public key on-chain (this becomes the Bitcoin address)
- Store the encrypted private key off-chain
Signing phase (when spending):
- Provide a witness proving the condition is satisfied
- If the witness is valid, the encryption scheme reveals the private key, allowing production of a Schnorr signature
- If the witness is invalid, recovering the private key is computationally infeasible
- Bitcoin validates the Schnorr signature normally
From Bitcoin’s perspective: a normal P2TR (Taproot) output and a normal Schnorr signature when spent. No difference from any other transaction.
PIPEs v2: binary covenants and SNARK verification
The February 13, 2026 release focuses on binary covenants: spending conditions with yes/no outcomes. From the abstract of the ePrint paper:
“We formalize how PIPEs v2 enable arbitrary spending conditions on Bitcoin by enforcing predicates on signatures through cryptography, without requiring any consensus changes.”
Bitcoin Optech explains: “Bitcoin PIPEs v2 focuses on a limited set of spending conditions, enforcing binary covenants. This model naturally captures a wide range of useful conditions whose outcomes are binary, such as providing a valid zk-proof, satisfying an exit condition, or existence of a fraud proof. Basically, it all comes down to a single question: ‘Is the condition satisfied or not?’.”
Examples of binary conditions:
- ZK proof verification: “Is there a valid SNARK proof?”
- Fraud proof: “Does a fraud proof exist?”
- Time delay: “Has 7 days passed?”
- Multisig threshold: “Do N-of-M signatures exist?”
PIPEs v2 introduces a new cryptographic primitive called Witness Signatures (WS), which captures conditional signing under hard relations. The paper explores Arithmetic Affine Determinant Program (AADP)-based witness encryption as a concrete implementation approach. This provides an explicit arithmetic framework for enforcing SNARK-verifiable conditions within the PIPEs architecture.
Translation: PIPEs can verify zero-knowledge proofs on Bitcoin without OP_CAT or other covenant opcodes.
What this enables
Vaults with recovery mechanisms:
Current problem: if your hot wallet keys are stolen, funds are gone immediately.
PIPEs solution: lock bitcoin behind witness encryption with condition “valid signature from hot key AND 7-day time delay has passed, OR valid signature from cold key.” For normal spending, provide hot key signature plus proof that 7 days passed. The encryption reveals the private key, you produce the signature, done. For emergency recovery, if the hot key is stolen, use the cold key to sweep funds to a new vault before the 7-day delay expires.
Advantage over pre-signed transactions: no need to store transaction data off-chain. The covenant is enforced cryptographically.
Trustless bridges and zkRollups:
Current problem: Bitcoin L2s rely on federations (multisig) or optimistic verification (challenge periods).
PIPEs solution: lock bitcoin on L1 with witness encryption requiring a valid SNARK proof of L2 state transition. To withdraw, provide a SNARK proof that the withdrawal is valid according to L2 state. Bitcoin validates the signature; cryptography validates the proof.
From the paper’s abstract: “Covenants and ZKP verification directly on Bitcoin L1 have long been regarded as infeasible due to the limited expressiveness of Bitcoin Script and the absence of covenant-enabling opcodes such as OP_CAT, OP_CTV, OP_VAULT or OP_CSFS. These limitations have prevented the realization of zkRollups, trustless bridges, and programmable vaults natively on Bitcoin.”
BitVM improvement:
Current BitVM uses optimistic verification: a prover publishes a claim off-chain, verifiers can challenge with fraud proofs within a challenge period (typically 7 days), and if there’s no challenge, the claim is assumed correct.
PIPEs offers pessimistic verification: lock bitcoin behind witness encryption requiring a valid SNARK proof. No challenge period needed. The proof is verified cryptographically before spending.
Misha Komarov, lead author and founder of cryptography research firm [[alloc]init], describes this as “pessimistic single-transaction ZK verification.”
The tradeoffs
PIPEs aren’t free. They trade computational efficiency and cryptographic maturity for immediate availability without consensus changes.
Computational requirements:
According to Blockspace Media, “The PIPEs scheme will require hefty computation to generate and verify the proofs to ‘unlock’ a PIPE. However Komarov says ‘people could still run it with commercially available hardware’.”
An estimate from April 2025 (for PIPEs v1) suggested it requires “about 30 hours of the whole Bitcoin network hash rate compute to spend one covenant.” v2 may have improved efficiency, but exact benchmarks aren’t public yet.
This limits practical use to high-value transactions where security benefits outweigh computational cost.
Single-use keys:
Once you spend a PIPE-locked output, the private key is revealed (because the witness decrypts it). You cannot reuse the same address. Each covenant requires a fresh keypair.
Opcode-based covenants (OP_CTV, OP_VAULT) don’t have this limitation. Addresses can be reused, and the covenant logic in Script doesn’t reveal keys.
Novel cryptography:
Witness encryption is cutting-edge and not as battle-tested as Bitcoin’s existing cryptography (SHA-256, secp256k1). If witness encryption is broken, covenant guarantees fail. However, Bitcoin itself remains secure because it still validates Schnorr signatures normally.
Scott Odell, [[alloc]init]‘s COO, told Blockspace Media: “We’ll put out incentives for people to crack it. We’re off to a very strong start.”
Binary covenants only (in v2):
v2 focuses on yes/no conditions. Complex state machines with many conditional branches may not fit the model. What works: “Is there a valid proof?” “Has time passed?” “Does a fraud proof exist?” What might not work: complex multi-party logic or general-purpose computation (though SNARKs can encode arbitrary computation).
Comparison: PIPEs vs. soft fork covenants
| Dimension | Bitcoin PIPEs v2 | Opcode Covenants |
|---|---|---|
| Consensus change | None required | Requires soft fork |
| Deployment timeline | Available today | Years of debate |
| Cryptography | Novel (witness encryption) | Battle-tested (Script + Schnorr) |
| Key reuse | Single-use keys | Reusable addresses |
| Computational cost | High (SNARK generation/verification) | Low (Script validation) |
| Privacy | Key reveal on spend | No key exposure |
| Flexibility | Binary covenants (v2) | General-purpose (depends on opcode) |
| Trust model | Relies on witness encryption security | Relies on Bitcoin Script |
| Political risk | No consensus needed | Must convince community |
PIPEs trade efficiency and maturity for immediate availability. That’s the bet.
Who’s building this
Bitcoin PIPEs v2 was published by [[alloc]init], a cryptography research firm focused on zero-knowledge infrastructure. The paper has 10 authors: Michel Abdalla, Brent Carmer, Muhammed El Gebali, Handan Kilinc-Alper, Mikhail Komarov, Yaroslav Rebenko, Lev Soukhanov, Erkan Tairi, Elena Tatuzova, and Patrick Towa.
Mikhail (Misha) Komarov, the lead author and [[alloc]init] founder, has a background in cryptography and zero-knowledge technology. He previously founded =nil; Foundation, which focuses on Ethereum L2 infrastructure, and developed zkLLVM (a native circuit compiler), Proof Market, and the Placeholder proof system.
Komarov describes the vision: “PIPEs introduce cryptographic covenants to Bitcoin, enabling vaults, non-custodial delegation, and pessimistic single-transaction ZK verification. There is no need for multisigs, DLCs, or changes to Bitcoin’s consensus. Programmability lives in cryptography, not Script.”
The 2026 roadmap includes deployment, further cryptographic research, and exploring which Script extensions PIPEs can emulate, allowing more types of covenants without modifying Bitcoin consensus.
The bigger question
If cryptography can emulate missing opcodes, does Bitcoin need consensus changes at all?
Maybe not. PIPEs enable experimentation today. If use cases prove valuable and the cryptography holds, Bitcoin gains covenant functionality without a soft fork. If PIPEs prove insufficient (too expensive, too risky, too limited), the soft fork debate continues with stronger evidence about what’s actually needed.
There’s also a hybrid path: PIPEs enable experimentation, builders deploy vaults and bridges in production, users prove demand, and that evidence strengthens the case for opcode activation. Consensus-layer features (opcodes) are more efficient, better understood, and don’t rely on cutting-edge cryptography. But getting consensus takes years. PIPEs let builders move now.
Bitcoin Optech gave PIPEs v2 prominent coverage in Newsletter #393 (February 20, 2026), one of only two main news items. That signals significant interest from Bitcoin’s technical community. Komarov posted details to Delving Bitcoin, the forum for technical protocol discussion, and is actively engaging with developers.
I keep coming back to the same idea: this is a test. If PIPEs work in practice (security holds, performance is acceptable, builders actually ship), Bitcoin just gained covenant functionality without touching consensus. If they don’t, we’re back to the opcode debate. Either way, it’s a creative end-run around one of Bitcoin’s longest-standing technical stalemates.
Sources: Bitcoin PIPEs v2 Paper (ePrint), Bitcoin Optech Newsletter #393, Blockspace Media: PIPEs v2 Whitepaper Release, Delving Bitcoin: PIPEs v2 Discussion, Bitcoin Optech: Covenants Topic. Data as of February 22, 2026.