Building on Zest Protocol
Ethereum records which confirmed Bitcoin outputs back a customer’s debt. The lending layer uses that collateral record; it does not hold the BTC itself.
The collateral layer is designed to support Ethereum lending integrations through defined accounting boundaries. A particular market’s assets, rates and deployed integration are separate from the Bitcoin vault construction. The current demo deployment uses Gateway, Reserve, SimplePool and a static supply counter; the SPV and facade components below belong to the production path. See Deployment reference.
Production contract responsibilities
| Component | Responsibility |
|---|---|
| BitcoinSPV and transaction parser | Verify Bitcoin header/inclusion facts and extract the output being credited. |
| SPVMintAdapter | Check confirmation depth, replay protection, amount, beneficiary binding and the registered vault script. |
| Gateway | Authorize script registration and covered debt, open claims and coordinate collateral settlement. |
| Reserve | Track collateral outpoints, construction versions, caps and borrowing/pending-settlement gates. |
| ZestFacade | Represent collateral in restricted accounting units, one unit per satoshi. |
| SimplePool and debt/supply tokens | Apply lending rules and record borrowing, repayment and liquidation. |
Deposit proofs have a defined boundary
The SPV route checks that the transaction is included in the accepted Bitcoin chain with sufficient confirmations. It also checks that the output matches the registered V2 script and expected value.
The script registration carries signer-set authorization and is keyed by depositor public key, construction version and position identifier. Each position’s script includes its cheque/event commitments; the same depositor can have multiple distinct vault addresses. Bitcoin inclusion therefore does not eliminate all attestation or construction assumptions.
The beneficiary is bound to the depositor public key on this path; an arbitrary caller cannot substitute its own Ethereum address for that binding.
An attested launch fallback has a different trust boundary and must be explicitly bounded and disclosed if enabled. The production deposit path must not silently substitute that fallback for proof verification.
One position through liquidation
A partial liquidation removes a fixed slice and leaves a V2 remainder. Ethereum records that actual remainder and reduces the same customer’s debt.
A terminal liquidation spends the remaining collateral path. Its Bitcoin payout was fixed earlier; Ethereum separately accounts for the debt repaid, any remaining liability and refunds in the borrowing asset. A Bitcoin surplus output must not be confused with an Ethereum refund.
Settlement signatures are member observations of canonical Bitcoin results. They are distinct from fresh customer signatures for a liquidation grid.
Coverage before new exposure
Gateway records threshold-attested coverage for a specific customer, position, active collateral output and signed grid. The pool permits new borrowing only within that coverage and its lending limits. A prepared replacement does not unlock borrowing against collateral that is not yet active.
Coverage is expressed in 18-decimal USD at the attestation boundary and converted to the pool’s underlying units. Mainnet USDC uses six decimals. Repayment lowers the live debt without first requiring another Bitcoin grid; refresh and settlement reconcile the difference from fixed signed coverage.
Withdrawals and pending actions
A withdrawal claim checks the collateral left behind. Replacement coverage is verified before the Bitcoin spend is completed.
Pending-settlement state constrains further borrowing and conflicting operations. Final accounting follows the canonical confirmed spend, not an intended transaction or a frontend success message.
Representation, caps and deployment
The facade is a restricted collateral-accounting representation, not a general-purpose circulating wrapped BTC asset. Correct mint/burn wiring and supply accounting still matter.
Production exposure controls include aggregate collateral limits and per-vault bounds. The configured mint routes and supply source must enforce them consistently. A per-vault limit is not a substitute for an aggregate limit.
See Protocol parameters, Deployment reference and Verify your position.
Integration references
Use Verify your position for transaction and state checks. Deployment reference identifies the recorded contract set, with Protocol parameters and Demo status for the selected profile.