Programmability Without Soft Forks
THE IMPASSE
Bitcoin developers have wanted covenants — spending conditions that restrict where coins can go next — for years. But every proposal requires a consensus change:
OP_CTV, OP_CAT, OP_VAULT (now superseded by OP_CHECKCONTRACTVERIFY), TXHASH. The soft fork process has ground to a halt. No covenant opcode has come close to activation.WHAT ARE COVENANTS?
Normal Bitcoin scripts control who can spend (via signatures). Covenants add a second dimension: what the spending transaction must look like. They can enforce that coins move to a specific address, wait a timelock, or follow a multi-step withdrawal protocol — all without trusting anyone.
ENTER [alloc] init
[alloc] init is a cryptography R&D company that asked: what if we could enforce arbitrary spending conditions purely through cryptography, without touching Bitcoin's consensus rules at all? Their answer is PIPEs v2 — a protocol that uses witness encryption to lock private keys behind cryptographic statements, making covenants enforceable by math alone.
Zero Soft Forks Required
Programmability lives in cryptography, not Script
How It Works: Alice's Vault
SCENARIO
Alice wants to protect her 1 BTC with a vault. The rule: coins can only move to a staging address, with a 144-block (~1 day) timelock before final withdrawal. If she sees theft during the delay, she can claw back. No soft fork needed.
1
Generate a Fresh Key Pair
🔑
sk = a3f8...9c01 pk = bc1p...vault
A brand-new Taproot key pair. The address
bc1p...vault looks like any other Bitcoin address.↓
2
Encrypt the Private Key Under the Vault Rule
🔒
WE.Encrypt( sk, "output[0] must pay to staging address + 144-block relative timelock" )
The private key
sk is now locked inside a ciphertext. The only way to get it out is to provide a transaction that matches the rule. This is witness encryption — the transaction itself is the "witness" that unlocks the key.↓
3
Destroy the Original Private Key
🗑️
The original
sk is securely deleted. From this point, nobody holds the private key — it exists only inside the encrypted ciphertext. The vault rule is now irreversibly enforced by math.↓
4
Send 1 BTC to the Vault Address
📦
1.0 BTC → bc1p...vault
A completely normal Taproot transaction. Miners, nodes, block explorers — nobody can tell this UTXO has a covenant. It looks like every other P2TR output.
LATER — TIME TO SPEND
5
Valid Spend — Follows the Rule ✓
ALICE BUILDS TX
output[0] → staging addr
timelock: 144 blocks
→
DECRYPTION
tx matches rule ✓
sk recovered!
→
RESULT
sign tx with sk
broadcast ✓
The transaction satisfies the encrypted rule, so the key is released. Alice signs and broadcasts. Nodes see a normal Taproot spend.
✗
Invalid Spend — Breaks the Rule ✗
ATTACKER BUILDS TX
output[0] → attacker addr
no timelock
→
DECRYPTION
tx doesn't match ✗
sk NOT recovered
→
RESULT
can't sign
coins safe 🛡️
Wrong destination, no timelock — the math doesn't unlock. Without the key, no valid signature is possible.
THE KEY IDEA
The private key is locked inside a math puzzle. The only way to extract it is to build a transaction that follows the rules. Bitcoin nodes never know — they just see a valid signature on a normal Taproot spend.
What This Enables
VAULTS
Lock coins so they can only be spent through a two-step withdrawal: first to an intermediate "unvaulting" address with a timelock, then to the final destination. If the vault owner detects theft during the timelock, they can claw back the funds. All enforced cryptographically — no
OP_VAULT opcode needed.NON-CUSTODIAL DELEGATION
Delegate spending authority for specific purposes without handing over the private key. For example, allow a cold wallet to authorize a hot wallet to spend only to pre-approved addresses, or only up to a certain amount per day. The delegation is enforced by the cryptographic lock, not by trust.
PESSIMISTIC ZK VERIFICATION
Require a zero-knowledge proof to spend coins — in a single transaction. The statement S can be "a valid ZK proof of computation X exists." This enables on-chain verification of arbitrary computation (rollup settlement, bridge proofs, etc.) without any new opcodes like
OP_ZKP_VERIFY.ARBITRARY SPENDING POLICIES
Since the encrypted statement can be any NP statement, PIPEs can enforce virtually any spending condition imaginable: rate limiting, whitelisted destinations, multi-party approval schemes, hash-locked contracts, and combinations thereof. The expressiveness is limited only by what can be stated mathematically.
NO CONSENSUS CHANGES
All of these features work on Bitcoin today. The enforcement mechanism is cryptographic, not script-level. Bitcoin nodes see a normal P2TR (Taproot) spend with a valid signature — they have no idea covenant logic was enforced behind the scenes.
Implications & Trade-offs
STRENGTHS
No soft fork risk — ships as application-layer software, not consensus code.
Arbitrary expressiveness — any NP statement can be a spending condition.
Composable — combine vaults, delegation, and ZK proofs in the same UTXO.
Opt-in — only users who create PIPEs are affected; no protocol-wide impact.
Arbitrary expressiveness — any NP statement can be a spending condition.
Composable — combine vaults, delegation, and ZK proofs in the same UTXO.
Opt-in — only users who create PIPEs are affected; no protocol-wide impact.
CHALLENGES
Novel cryptography — witness encryption (and AADP specifically) relies on assumptions much newer and less studied than ECDSA/Schnorr.
Key destruction is critical — the original private key must be securely deleted after encryption. Secure deletion is an unsolved problem; there's no way for third parties to verify it happened.
No miner enforcement — if the key leaks or the crypto breaks, miners see a valid Taproot spend. There is no consensus safety net.
Key destruction is critical — the original private key must be securely deleted after encryption. Secure deletion is an unsolved problem; there's no way for third parties to verify it happened.
No miner enforcement — if the key leaks or the crypto breaks, miners see a valid Taproot spend. There is no consensus safety net.
CRITICAL DIFFERENCE FROM SOFT FORK COVENANTS
With
OP_CTV or OP_VAULT, miners enforce the covenant — invalid transactions are rejected at the consensus layer. With PIPEs, enforcement is purely cryptographic. If the underlying crypto is broken or the private key leaks, there's no consensus safety net. The security guarantee comes from mathematical hardness, not from the network.SOFT FORK COVENANTS
OP_CTV / OP_CAT / OP_VAULT
Consensus-enforced, requires network upgrade, limited expressiveness per opcode, battle-tested security model
PIPEs v2
Witness Encryption Covenants
Cryptography-enforced, no upgrade needed, arbitrary expressiveness, novel security assumptions