Bitcoin Cash covenants
Covenants define enforceable transaction paths.
A Bitcoin Cash covenant can require the transaction spending a controlled output to satisfy defined rules. This guide covers what covenants can enforce, common BCH patterns, and the limits teams need to design around.
Illustrative architecture. Not a live deployment.
What a covenant can control
Rules are enforced when covenant-controlled funds are spent.
With the right script and transaction design, the spend conditions are checked at the BCH transaction boundary instead of living only in an application server or an operator checklist.
Recipients
Restrict where a controlled output can send value next.
Amounts
Enforce per-payment, cumulative, or remaining-value limits.
Successor state
For stateful designs, a valid successor advances the workflow; a transaction that violates the rule fails.
Recovery
Make the return or recovery path explicit in the transaction rules.
How it works
The rule is checked at the transaction boundary.
A covenant does not approve a vague request. It evaluates the concrete transaction that attempts to spend the controlled input. The builder and the covenant therefore have separate jobs.
Place BCH or CashToken funds under a covenant rule.
Assemble the intended inputs, outputs, state, and fee.
The script checks the transaction against the permitted path.
For stateful designs, a valid successor advances the workflow; a transaction that violates the rule fails.
Authorization and enforcement
Authorization and covenant rules answer different questions.
A signature proves that an authorized key approved a transaction. A covenant can additionally require the spending transaction itself to satisfy rules about outputs, values, tokens, or continuation state. Many designs use both.
Common Bitcoin Cash patterns
Use covenants where the transaction path matters.
Escrow
Release value only when the transaction satisfies the agreed conditions.
Staged distribution
Move grants, treasury funds, or payouts through defined successor states.
Restricted spend
Limit recipients or transaction shapes for a software-operated workflow.
Token state
Combine CashToken categories, commitments, or capabilities with covenant rules to constrain token-aware state transitions.
Important limitations
Covenants are narrow by design.
A covenant can make a specific transaction path enforceable, but it is not a universal policy engine or a substitute for wallet, builder, and operational design.
A covenant governs funds deliberately placed under that covenant. It does not control unrelated assets or an entire wallet.
The rule can only enforce conditions expressible using the BCH VM and the transaction information available to the script.
A wallet or backend still has to construct the intended outputs, handle fees and change, and preserve or intentionally transform token state.
A recovery path must be included and tested; an incomplete design can make funds difficult or impossible to move.
Continue the technical path
Move from covenant concepts to OPTN’s platform, CashTokens, engineering, or developer resources.
Related reading
Have a covenant pattern in mind?
Bring the transaction path, recovery behavior, and product context. We can help scope the implementation.