B++ Logo
Feedback

Covenants

Covenants are a proposed type of Bitcoin Script constraint that would restrict how outputs from a transaction can be spent in future transactions. Unlike today’s scripts, which only define “who can spend and under what conditions,” covenants would allow “this UTXO may only be spent in a transaction that looks like X” (e.g., only to certain address types, or only after passing through a timelocked recovery path).

No covenant opcodes are in consensus today. This page describes the design space and main proposals. A covenant restricts the shape or destination of the transaction that spends an output:

  • Shape: e.g., “the spending transaction must have exactly N outputs” or “the first output must be to this script.”
  • Destination: e.g., “outputs may only go to addresses of type P2WPKH” or “only to this prespecified script.”
  • Recursion: Some designs allow outputs that are again covenant-constrained, creating multi-step flows (vaults, Lightning-like channels, etc.).

Covenants enable:

  • Vaults: Funds can only move to a “cooling-off” or recovery script first; direct spending is disallowed.
  • Layered security: e.g., “can only be sent to a 2-of-3 multisig or to a timelocked recovery path.”
  • L2 and protocols: Channel factories, Lightning-style constructs, and other protocols could use covenants to enforce on-chain structure.

Main Proposals

OP_CAT (and similar)

OP_CAT (concatenate two values on the stack) was disabled in early Bitcoin. Re-enabling it (or adding a constrained variant) could, in combination with hashing and equality checks, allow scripts to inspect and constrain parts of the spending transaction (e.g., by sighash or by committing to a hash of allowed shapes). OP_CAT is very general; the main concern is that it might enable scripts that are complex, hard to analyze, or that risk consensus or performance issues. Proposals often restrict what can be concatenated or how the result is used.

OP_CTV (CheckTemplateVerify)

OP_CTV (or OP_CHECKTEMPLATEVERIFY) commits to a hash of a specific spending transaction template. The script would specify the exact inputs (by outpoint) and outputs (scriptPubKey + amount) of the only transaction that can spend the UTXO. This is a one-step covenant: the next spend is fully fixed; you cannot recursively chain OP_CTV in arbitrarily complex ways without further opcodes.

Use cases: vaults with a single recovery path, Lightning anchor or channel-like structures where the on-chain spend must match a known template, and congestion-control or batch-spend patterns.

  • BIP: BIP 119 (OP_CTV / CheckTemplateVerify)

SIGHASH_ANYPREVOUT (APO)

SIGHASH_ANYPREVOUT (APO) is a sighash flag that would allow a signature to be valid when the signed input comes from any outpoint (or from a set of allowed ones), rather than a single outpoint. That makes signatures reusable across different transactions that share the same structure (e.g., same outputs), which can be used to build covenant-like behavior: the signer effectively agrees to “this spend is only valid if the rest of the tx looks like X,” and the script can enforce that the signer only signs such shapes.

APO is particularly relevant for Lightning and channel designs: commitment and HTLC transactions could use a more flexible signing model. It is also a building block for vaults and other covenant patterns.

Other and Combined

Other ideas (e.g., OP_TXHASH, OP_TX, or limited forms of OP_CAT) aim to expose part of the spending transaction to script so it can be constrained. Some designs combine:

  • OP_CTV for “exactly this next spend,” and
  • APO or similar for “this signature is valid for any prevout with this structure,”

to get both one-off templates and more flexible, multi-step covenant flows.

Risks and Trade-offs

  • Recursion and complexity: Covenants that can chain arbitrarily may make scripts harder to reason about, audit, and fee-estimate. Proposals often limit recursion or the power of the opcode.
  • Fungibility and censorship: Very strict covenants could create outputs that are distinguishable and easier to blacklist or to treat differently in mempool or mining policy.
  • Consensus and consensus risk: New opcodes require soft fork and careful consensus review. The community weighs benefits (vaults, L2, etc.) against added complexity and risk.

Status

As of this writing:

  • OP_CTV: BIP 119 exists; no soft fork has been adopted. Discussion continues on bitcoin-dev.
  • SIGHASH_ANYPREVOUT / APO: Active design and discussion; not yet in consensus.
  • OP_CAT: Re-enable or constrained variants are discussed; not in consensus.

Implementations (e.g., Miniscript) and higher-level tools may add draft support for CTV or APO so that, if one of these is adopted, wallets and smart contracts can use them quickly.

  • Smart Contracts - Covenant-like patterns and Miniscript
  • Miniscript - Policy and script; future covenant targets
  • Sighash Types - How signing commits to transaction parts; APO extends this
  • Lightning - Potential use of covenants / APO
  • Governance - How opcodes and soft forks are proposed and adopted

Resources