Programmable Covenant

Programmable covenants encode stateful logic directly into a transaction output, dictating the precise conditions under which the funds can be spent next. This is a fundamental shift from Bitcoin's default model, where an output can be spent by anyone with the correct signature. Key mechanisms include:

• Vaults & Delayed Withdrawals: Enforce a mandatory time-locked "cooling-off" period before large withdrawals.
• Recovery Paths: Predefine alternative spending paths for key loss or security breaches.
• Spending Limits: Cap the amount that can be transferred in a single transaction.

A core feature is the ability to constrain the shape of the transaction graph. The covenant can specify properties of the next transaction, such as:

• Output Script Templates: The covenant can enforce that funds must be sent to a specific type of address or script.
• Amount Control: It can require that a certain minimum amount remains in a covenant-controlled output, enabling recursive or looping logic.
• Fee Limits: It can impose constraints on the miner fee of the subsequent transaction. This creates a chain of pre-authorized transactions, enabling complex multi-step protocols.

Unlike off-chain agreements or centralized custodians, programmable covenants are enforced at the consensus layer. The rules are written into the scriptPubKey or taproot leaf and are validated by every full node on the network. This provides:

• Cryptographic Guarantees: Breach of the covenant's rules is mathematically impossible; the network will reject any non-compliant spending transaction.
• Trust Minimization: Eliminates reliance on third-party watchtowers or honest majority assumptions for security.
• Global Verifiability: Anyone can audit the covenant's rules by inspecting the on-chain script.

The proposed Bitcoin soft fork OP_CHECKTEMPLATEVERIFY (CTV) is a canonical implementation path for simple covenants. It enables a specific form of covenant by allowing a script to commit to the hash of a transaction template. Key aspects:

• Non-Turing-Complete: CTV is intentionally limited to prevent unbounded computation, aligning with Bitcoin's security philosophy.
• Template Commitment: The output commits to the hash of a specific future transaction's core fields (version, locktime, sequences, outputs).
• Use Cases: Powers congestion-controlled transactions, non-interactive payment pools, and simplified vault constructions without recursive script execution.

Covenants enable revolutionary self-custody security models that were previously impossible. They allow users to impose their own security policies directly on their bitcoin.

• Recursive Vaults: Funds can be programmed to always return to a more secure, time-locked state after any action, creating a defensive "backstop."
• Fraud Monitoring Delegation: A "watchtower" can be authorized via covenant to move funds to a safe address if fraud is detected, without ever holding custody.
• Inheritance Planning: Pre-programmed, time-released transfers can be set up without needing a will or third-party executor.

By enabling conditional and multi-step logic on-chain, covenants create foundational DeFi primitives for Bitcoin.

• Non-Custodial Escrow: Two-party agreements where funds are released only upon mutual consent or a timeout, enforceable by code.
• Peer-to-Peer Derivatives: Simple options or futures contracts can be collateralized and settled automatically on-chain.
• Decentralized Exchanges (DEX): Enable atomic swap-like protocols with improved liquidity and order book functionality through constructions like payment pools.
• Structured Products: Enable the creation of tokens representing shares in a covenant-controlled pool of bitcoin with defined redemption rules.

Covenants can power non-custodial, on-chain order books. A user can lock funds in a UTXO with a covenant that states: "These funds can only be spent in a transaction that provides a valid signature from a specific counterparty AND delivers a specified amount of another asset." This creates a trustless limit order that is executed atomically without relying on a central operator or complex smart contract layers.

Covenants enable sophisticated wallet recovery schemes. A wallet can be programmed so that after a period of inactivity (e.g., 6 months), the spending authority automatically shifts from the primary private key to a set of backup keys held by family members or a legal entity. This logic is enforced on-chain, providing a decentralized solution for inheritance and key loss prevention without a central service.

Covenants can enforce participation in CoinJoin transactions to improve privacy. A UTXO can be created with a rule that it must be spent in a transaction with at least 5 other specific input types (other covenant-bound UTXOs). This forces coins to be mixed according to a predefined protocol, reducing the ability for chain analysis to trace funds and enabling stronger, protocol-level privacy guarantees.

Covenants can encode the rules for bonds, options, or recurring payments. For instance, a bond covenant could automatically distribute coupon payments to token holders at specific block heights, with the principal repayable only after maturity. This creates self-executing financial instruments on a base layer, reducing counterparty risk and operational overhead compared to traditional systems.

A programmable covenant is a smart contract that places constraints on how a specific UTXO (Unspent Transaction Output) can be spent in the future. Unlike general-purpose contracts, its logic is bound to the asset itself, creating a self-contained state machine. Key components include:

• Stateful Logic: The contract's internal state (e.g., a counter, a hash) is stored directly within the UTXO.
• Pre-signed Transactions: Often uses a set of pre-defined, partially-signed transaction templates that are the only valid spending paths.
• Deterministic Execution: The outcome is fully determined by the current state and the spending input, enhancing predictability and security.

A primary use case is creating recovery vaults or time-locked wallets. These covenants enforce multi-signature rules and introduce mandatory delay periods for large withdrawals. For example:

• A withdrawal may require 2-of-3 signatures.
• If a "fast" key is used, a 24-hour timelock is triggered, allowing a separate set of guardian keys to freeze the transaction.
• This design mitigates theft by introducing a cooling-off period for suspicious transactions, a significant improvement over simple multisig.

Covenants enable non-custodial trading protocols without centralized order books. In a covenant-based DEX:

• Liquidity is locked in a covenant that only allows swaps following a specific constant product formula (e.g., x*y=k).
• The covenant validates swap transactions directly, ensuring the pool's rules are enforced at the protocol level.
• This creates trust-minimized Automated Market Makers (AMMs) where the liquidity cannot be withdrawn except as defined by the covenant's immutable logic.

Covenants are foundational for scalable payment systems like payment pools and state channels. They allow multiple users to fund a single UTXO with rules governing how it can be redistributed.

• Key Features:
  • Users can join/exit without on-chain transactions for every update.
  • Internal balances are managed off-chain, with the covenant enforcing the final settlement.
  • Enables complex routing protocols for instant, low-fee micropayments across a network, similar to the Lightning Network but with different technical trade-offs.

Covenants enable native NFTs with embedded logic, moving beyond simple ownership records. The NFT itself can enforce rules for its future sale or use.

• Example Applications:
  • Royalty Enforcement: A covenant can mandate that a percentage of any sale is sent to the creator's address, enforceable at the protocol level.
  • Licensing Logic: The NFT could contain code that restricts transfers unless certain conditions are met.
  • This creates programmable digital assets whose behavior is intrinsic, not dependent on a marketplace's policy.

Implementation varies by blockchain due to differing scripting capabilities.

• Bitcoin: Requires creative use of OP_CHECKTEMPLATEVERIFY (CTV) or Taproot with ANYPREVOUT to simulate covenants, as direct recursive covenant opcodes are not present.
• Ethereum & EVM Chains: Achieved through delegatecall patterns or storing logic in proxy contract storage slots, though not as UTXO-native.
• Utxo-based Altcoins (e.g., Stacks, Liquid): Some have explicit covenant opcodes (like cltv in Clarity) that make these constructs more straightforward and efficient to implement.

Once deployed, a covenant's logic is typically immutable. This creates a critical trade-off:

• Permanent Bugs: A logic error or vulnerability is frozen on-chain, potentially locking or exposing funds forever.
• Upgrade Mechanisms: If an upgrade path is included (e.g., via a multisig), it introduces a centralization risk and becomes a high-value attack target.
• Example: A flawed withdrawal condition could make assets permanently inaccessible.

Covenants often rely on external data (oracles) to trigger state changes, creating significant attack surfaces:

• Oracle Manipulation: An attacker compromising the data feed (e.g., price oracle) can trigger unauthorized covenant actions.
• Data Liveness: If the required external data becomes unavailable, the covenant may be bricked, freezing assets.
• Solution: Use decentralized oracle networks and implement circuit breakers for critical price dependencies.

The expressiveness of covenants increases system complexity, which is inversely proportional to security.

• State Explosion: Managing numerous conditional states and paths increases the chance of unhandled edge cases.
• Composability Risks: Interacting with other smart contracts (DeFi protocols) can lead to reentrancy or unexpected interactions.
• Best Practice: Formal verification and exhaustive property-based testing are recommended for complex covenant logic.

Covenants delegate authority through cryptographic proofs, shifting key management challenges.

• Signature Logic Flaws: Bugs in the multisig or threshold signature verification can allow unauthorized spends.
• Key Loss: If a covenant's spending condition requires an n-of-m multisig and keys are lost, funds may become unrecoverable.
• Social Engineering: The rules themselves (e.g., "transfer to this address after 90 days") can be targeted for manipulation off-chain.

The specific construction of covenant-enforced transactions can introduce new vulnerabilities.

• Fee Bumping Attacks: A malicious actor might front-run or replace a covenant transaction by paying a higher fee, altering the intended outcome.
• Chain Reorgs: A blockchain reorganization could invalidate a transaction that a covenant's state depends on, requiring logic to handle reorg resilience.
• Solution: Use anti-malleability techniques and sequence numbers, and design for probabilistic finality.

The transparent nature of covenants on a public blockchain creates unique privacy concerns.

• Wealth Identification: Covenants can make high-value, long-term locked assets easily identifiable on-chain, painting a target for attacks.
• Pattern Analysis: The predictable flow of funds according to public rules allows for sophisticated chain analysis, potentially deanonymizing users.
• Mitigation: Techniques like Scriptless Scripts or integration with privacy-preserving L2s can help obfuscate covenant logic and state.

A self-executing program stored on a blockchain that defines the rules and logic for transactions. Programmable covenants are a specific, advanced application of smart contracts that impose constraints on how a UTXO or asset can be spent in the future, beyond simple ownership checks.

• Foundation: Covenants are built using smart contract languages like Bitcoin Script, Clarity, or Solidity.
• Key Difference: While all covenants are smart contracts, not all smart contracts are covenants. Covenants specialize in controlling future spending paths.

The Unspent Transaction Output model, used by Bitcoin and Cardano, where blockchain state is represented as a set of spendable "coins." Programmable covenants are natively expressed in this model by attaching conditions to specific UTXOs.

• Mechanism: A covenant's script is attached to a UTXO, dictating the valid conditions for its next spend.
• Contrast: The account-based model (Ethereum, Solana) implements similar logic via smart contract state, but the UTXO model provides a more direct analogy for "locking" an asset with future rules.

A proposed Bitcoin opcode (BIP-119) designed to enable vaults and covenants with enhanced security and efficiency. It allows a script to verify that the spending transaction matches a pre-committed template.

• Function: Enforces where funds can be sent next, without revealing full spending paths in advance.
• Use Case: Primarily for recursive covenants, enabling secure, non-custodial vaults with withdrawal limits and time-delayed recovery on Bitcoin.

A covenant that can re-apply its own (or similar) constraints to the output of a transaction that spends it. This creates a chain of enforced rules, allowing for complex stateful protocols.

• Capability: Enables assets to carry persistent rules across multiple transactions (e.g., a vault that always requires a 24-hour delay).
• Implementation: Requires specific opcodes (like CTV) or language features (like in Clarity) to be feasible and secure.

A security-focused application of programmable covenants designed to protect assets from theft. A vault typically uses a combination of covenant constraints to enforce withdrawal limits, timelocks, and recovery procedures.

• Mechanism: Funds are locked with a covenant that requires a "slow" withdrawal to a pre-defined address or a "fast" withdrawal with a multi-signature approval after a security delay.
• Purpose: Mitigates the risk of private key compromise, providing a self-custodial security model.