Covenants

The most discussed application is a vault. A vault is an output that can only be spent to a predetermined destination, or only after a delay, or only through a two-stage process that gives the owner time to react to a theft. A covenant makes the restriction enforceable by the script rather than by a policy the wallet is trusted to follow, which is a meaningful difference for a holder worried about key compromise.

A second application is congestion control. A covenant could commit an output to being spent in a particular way at a particular time, which would allow a group of users to coordinate their transactions without a central coordinator. The idea is that a covenant can encode a schedule that the participants agree to in advance, removing the need to trust whoever runs the coordination.

A third is the construction of more capable payment channels. Several of the proposals would make it possible to build channel designs that are simpler or more flexible than what is available today, which is the same motivation behind the SIGHASH_ANYPREVOUT proposal. The two are often discussed together because they address related limitations.

The argument in favour is that the capability is useful and that the proposals have been reviewed carefully. Vaults address a real problem, congestion control addresses a real problem, and the constructions are designed to be opt-in: a user who does not want a covenant simply does not create one. On this view the change is additive and the risk is manageable.

The argument against is that a covenant changes what an output can be, and that the change is not as contained as it appears. A covenant that restricts how coins can be spent can also be used to restrict them in ways the creator did not intend, and the composability of the new opcodes with existing script is hard to reason about in full. The concern is not that a specific attack is known but that the surface area grows.

There is also a disagreement about urgency. One position holds that the proposals should be adopted once they are well understood; another holds that the burden of proof for a consensus change is high and that the absence of a compelling need is itself a reason to wait. Both positions are represented in the public discussion, and the page presents them rather than resolving them.

What is specified is a family of proposals rather than a single change. Each one sets out an opcode or a restriction, the scripts it would apply to, and the validation rules that would enforce it. The specifications are complete enough to implement, and reference implementations and test vectors have been produced in the proposal process.

What is implemented is limited to that proposal work. No covenant opcode is active on the Bitcoin network, none is part of Bitcoin Core's consensus rules, and no node enforces one. A transaction relying on a covenant would be rejected today. The vault, congestion-control and channel constructions described above likewise cannot be deployed on the main chain without the consensus change.

What is not deployed is therefore everything that depends on the capability: covenant-enforced vaults, covenant-based congestion control, and the more capable channel designs. The proposals carry Draft status or remain discussion documents, and the page presents them as such rather than implying a timeline. A reader should treat every capability described here as proposed, not available.