Bitcoin Cash covenants
Give Bitcoin Cash transactions clear rules.
Covenants let a BCH product define the paths controlled funds may take. Use them when a workflow needs more than a signature—such as escrow, staged payouts, recovery, or restricted spending.
Reference covenant flow · Implementations vary
What a covenant can control
Build guardrails into the transaction itself.
With the right script and transaction design, 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
Turn a business rule into a permitted path.
A covenant evaluates the actual transaction that attempts to spend the controlled input. The builder assembles the transaction; the covenant checks whether it follows the permitted path.
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.
Design considerations
Design for explicit transaction paths.
Covenants work well when a financial workflow can be expressed as explicit rules about transaction inputs, outputs, values, tokens, or continuation state. The surrounding wallet or application still constructs the transaction and manages the user experience.
Covenant rules apply to funds deliberately placed under them; they do not govern unrelated assets or an entire wallet.
A covenant enforces conditions expressible using the BCH VM and transaction information available to the script.
A wallet or backend constructs the intended outputs, handles fees and change, and preserves or intentionally transforms token state.
Include a recovery path in the transaction design and test it; incomplete designs 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.