Recursive Covenant

A recursive covenant is a covenant whose restrictions reproduce themselves in the outputs it creates, so the same rules can apply not just to the immediate next spend but to every transaction descending from it. Where a non-recursive covenant constrains a single forward hop and then lets go, a recursive one can, in principle, carry its conditions forward indefinitely — a spending rule that photocopies itself onto its own children. Recursive covenants are not active on Bitcoin; they are a property of certain proposed and experimental covenant designs, and much of the covenant debate is really a debate about whether, and how safely, recursion should be possible.

Recursive versus non-recursive

The distinction is about scope. A non-recursive design such as OP_CHECKTEMPLATEVERIFY commits coins to one predetermined next transaction — a fixed template — and once that transaction executes, the covenant is spent and the coins are free. A recursive design lets the spending transaction re-impose covenant rules on its own outputs, effectively maintaining state across an unbounded chain of spends. Recursion typically emerges from generality rather than intent: give Script enough introspection — the ability to examine the spending transaction — plus a way to compose data (for example, concatenation via OP_CAT combined with signature checks), and constructions can be built where an output's script requires its successor to carry the same script. Narrowly scoped opcodes like CTV are deliberately designed so this self-reference is not expressible; that restraint is a feature, not a limitation.

What recursion would enable

Recursion is what makes the most ambitious Bitcoin applications conceivable on the base layer: long-lived vaults whose protections persist across partial withdrawals, sidechain-style pegs where coins remain governed by the peg's rules until formally released, payment pools with evolving membership, and general state machines whose logic survives every transition. Anything that needs rules to outlive a single spend needs something recursion-shaped. That expressive power is exactly why researchers keep circling it, and exactly why reviewers are cautious.

A concrete picture

The cleanest mental model is a quine — a program that prints its own source code. Imagine an output whose script says: "this coin may only be spent by a transaction whose first output carries this exact script." To satisfy it, the spender must reproduce the rule verbatim, and the new output then imposes the same demand on the next spender, forever. Nothing in that loop requires exotic machinery — just the ability for a script to inspect the transaction spending it and compare bytes — which is why seemingly modest introspection opcodes carry outsized consequences in review.

Why it is contentious

The core objection is permanence: coins could become encumbered by rules they can never escape, creating a class of UTXOs that are forever "less than" ordinary bitcoin — which touches fungibility, one of money's load-bearing properties. Skeptics also raise the specter of externally imposed conditions traveling with coins indefinitely; proponents respond that covenants are opt-in (a covenant can only ever bind coins someone voluntarily sends into it, never reach out and grab yours) and that dangerous-sounding constructions are often economically irrational to sustain. There is even genuine expert disagreement about which constructions deserve the "recursive" label at all, which says something about how young this design space is. The practical takeaway for a sovereign Bitcoiner: recursion is a design dimension to be weighed — expressiveness against permanence, capability against fungibility — not something automatically good or bad. See the general concept of a covenant for the family this belongs to. D-Central offers this as a neutral explainer of an open research area: nothing described here is consensus today, and the debate over whether it should be is one of the most consequential conversations in Bitcoin protocol development.