Keeping coverage current
A continuing loan needs continuing authorization. Zest Protocol’s chequebook is the package of fixed Bitcoin transactions covering the position’s permitted outcomes; its grid organizes liquidation coverage across supported price and debt states.
Coverage keeps the loan usable as debt, prices and collateral change. It tells you which outcomes are already authorized and when an update is needed.
Debt can change within the covered terms
Production grids represent supported borrowing, repayment and interest transitions with defined rounding and boundary rules. Routine changes inside that domain use existing coverage without moving BTC for every balance update.
New borrowing outside the covered domain requires an authorization update before funds are released. Repayment reduces debt first; it does not depend on signing replacement transactions. A later refresh aligns the fixed payouts with the smaller liability.
A new output needs its own coverage
Partial liquidation and withdrawal both create a new V2 remainder. Its position binding and event commitments determine a new address, and its next transactions must reference the exact future outpoint.
For covered liquidation, those child transactions are prepared before the parent executes, so the borrower need not return to sign during liquidation. A customer-initiated withdrawal includes signing and verifying replacement coverage before the withdrawal becomes broadcastable.
| Change | What must continue to match |
|---|---|
| Borrowing, repayment or interest | The debt state represented by the authorized outcomes. |
| Partial withdrawal | The chosen withdrawal, exact remainder and verified replacement package. |
| Partial liquidation | The signed parent output and pre-authorized child transactions. |
| Coverage renewal or band exit | The new event commitments, permitted domain and required customer authorizations. |
Events have a horizon
Oracle commitments cover a defined future period. Each pre-signed child transaction is paired with event authorization available within that period, giving the position an explicit coverage horizon.
Production renewal maintains coverage through authorized transitions; moving outside a price band can require an earlier update. The supported construction determines which operations use existing authorizations and which require fresh customer signing.
An epoch change does not revoke an already published reveal. A completed signature remains usable while its input and Bitcoin locks permit it. Conflicting spends and closure must account for that fact.
Closing a quiet position
Release and lapse are separate cheque families. Release requires finalized debt-zero authorization. Lapse closure handles the defined inactivity and debt conditions, paying the fixed settlement and customer remainder.
The relationship, lapse timer and safety margin must fit before the applicable customer escape delay. A new remainder starts a new Bitcoin relative clock; advancing the oracle epoch alone does not reset it.
Fees are part of coverage
The signed outputs include payouts, remainder, surplus and any anchors; transaction fees reduce the BTC available to those outputs. Fee acceleration through a child can help relay without rewriting the parent’s authorized amounts, but still needs funding and usable relay conditions.
Coverage checks include fee funding, minimum output sizes and the supported price and debt conditions. These checks keep the signed package usable as the position moves through its lifecycle.
The demo uses A and B with a long epoch and explicit refreshes. Production expands the supported outcomes while keeping each Bitcoin payout fixed before signing.