Protocol parameters
Production V2 combines construction parameters committed on Bitcoin with lending and operating parameters published for a deployment.
This page explains what each parameter controls. It is not a table of currently verified mainnet settings. A production release must publish the complete numeric profile alongside its contract addresses.
Vault and authorization
| Parameter | What it controls | V2 design reference |
|---|---|---|
| Protocol aggregate key and signing threshold | The distributed protocol half of the vault lock. | Independent FROST participants; customer authorization remains separately required. |
| Council keys and threshold | Completion of customer-authorized veto transactions. | Fixed by construction. |
| Position and cheque commitments | Which position and oracle events the address commits to. | Customer Bitcoin key, Ethereum owner, session/child binding and the ordered event-keyed cheque leaves. |
| Escape delay | When the customer-only script path becomes spendable. | A concrete construction-specific Bitcoin block count, with room for the selected relationship, lapse delay and safety margin. |
| Veto delay | Earliest exercise of the council path. | Approximately two days, shorter than escape. |
| Veto template budget | Number of pre-authorized chained re-vaults. | At most three. |
| Settlement contest delay | Time available for the bounded watchdog process before the delayed claimant path. | 1 Bitcoin block in this deployment (SETTLEMENT_CSV_BLOCKS); publish the actual construction value. |
The relative clocks belong to specific outpoints. A new remainder or re-vault starts a new clock. Configuration changes cannot rewrite the script already committed in an existing output.
Coverage and lifecycle
The deployment must specify the grid epoch, announcement horizon, supported price/debt domain, boundary rounding, renewal schedule and band-exit response.
It must also specify lapse and settlement timers with enough margin before customer escape. No child may be treated as covered beyond the availability of its required oracle event.
These windows are related but not interchangeable. An epoch is neither a loan maturity date nor a way to revoke an already-published reveal.
Lending and exposure
| Parameter | User-facing effect |
|---|---|
| Maximum LTV | Limits new borrowing and collateral withdrawals. |
| Liquidation threshold | Determines when debt and collateral permit liquidation. |
| Interest model and debt units | Determine how the loan balance evolves and how coverage must represent it. |
| Liquidation sizing and settlement terms | Determine the pre-signed payout, residual collateral and customer surplus. |
| Aggregate supply and borrow caps | Bound total exposure. |
| Per-vault minimum and maximum | Bound individual positions, including meaningful fee/dust margins. |
| Asset addresses and decimals | Define what is supplied, borrowed, repaid and valued. |
No single LTV, minimum deposit or asset list should be inferred from a demonstration configuration.
Finality and fees
V2 requires finalized Ethereum reads and at least six confirmations for Bitcoin-derived actions. Parent-dependent transactions must also carry their required Bitcoin locks.
Review the signed transaction’s baked fee, anchor value and net payouts. Additional fee funding and fee-acceleration policy must be specified; neither provides an unlimited confirmation guarantee.
Demo values are separate
The reduced profile uses a 180-day relationship and oracle/grid epoch, vaults capped at 0.001 BTC and a small set of fixed settlement outcomes to keep the grid to two liquidation signatures. Live debt can change through repayment, additional borrowing and interest; coverage is managed separately. Its selected escape delay is 28,800 blocks, approximately 200 days. The complete target values and implementation status are in Demo status.
Those values simplify a demonstration. They do not define production capacity, repayment flexibility or signing UX.