Security
Bitcoin Collateral Vaults combine customer-authorized spending, independent guardian protection and a Bitcoin-enforced recovery path. These protections let holders borrow against BTC while their collateral remains in a dedicated vault on Bitcoin.
Security is built into the vault’s spending conditions and the permissions used throughout the lending lifecycle.
Customer control and independent protection
Each vault requires the customer’s live signature or a transaction the customer authorized in advance. Pre-signed Bitcoin transactions commit to specific amounts and destinations. Protocol operators cannot use their signing authority alone to create a different vault spend.
The Guardian Council independently checks settlements against the lending position. If a settlement is invalid, the required guardian quorum can complete a pre-authorized return to the prescribed vault. This protection depends on an honest, available quorum confirming the return within the committed contest window. Guardian protection explains how that oversight is enforced.
An eligible unspent vault also has a customer-only escape after its Bitcoin timelock. That path does not require a protocol signature or a functioning destination chain. The customer needs their key, public vault records and transaction fees. Recovery explains the process.
Independent audit
Zest Protocol Bitcoin Collateral Vaults have been independently audited by Clarity Alliance . Its Zest Bitcoin Collateral Vaults Demo Security Review, published on 15 September 2026, covers the demo’s Ethereum contracts and related authorization paths.
The report documents the assessment scope, findings and remediation. All six findings are marked resolved in the final review.
Read the Zest Bitcoin Collateral Vaults Demo Security Review (PDF)
External assessment complements customer-authorized transactions, independent guardian protection and Bitcoin-enforced recovery throughout the vault lifecycle.
Wallet permissions
Connecting a wallet shares the selected account’s public details with the application. Spending requires a separate authorization through the wallet. Other holdings do not become collateral simply because the account is connected.
| Action | Authorization |
|---|---|
| Deposit BTC | A Bitcoin transaction paying the selected amount to the vault, with any change returned to the funding address and a network fee. Bitcoin inputs are spent in full, so their total may exceed the deposit amount. |
| Authorize vault transactions | Sign specified transactions for the position, including settlement and protective return paths. Some signatures permit later execution without another prompt; the signed amounts and destinations remain fixed. |
| Borrow USDC | Call the lending pool to borrow against the position. This does not require approval to spend USDC already in the wallet. |
| Repay or supply USDC | Approve the lending pool to spend the entered USDC amount when the existing allowance is insufficient, then confirm the repayment or supply transaction. |
| Withdraw | Authorize the relevant pool or vault withdrawal steps. Bitcoin withdrawals also require replacement coverage and settlement signatures where applicable. |
Ethereum transactions require ETH for network fees. Token approval grants a spending allowance; it is separate from the payment itself.
Limited token allowances
The application requests USDC approvals for the entered amount. Supply and repayment take USDC from the account making the transaction. Liquidation repayments come from the liquidator.
A USDC allowance applies to that token and the specified spender. It does not authorize spending other tokens, NFTs or native ETH. The lending flows do not require Permit2 permissions or blanket NFT approvals.
An existing allowance may cover a later payment. Unused allowance can remain after a cancelled action or a repayment smaller than the amount approved. Disconnecting a wallet does not revoke it; allowances can be revoked separately through wallet controls or an allowance-management tool.
Signing through your wallet
The application requests signatures from the connected wallet. Customers do not import their recovery phrase or private key into the webpage.
Bitcoin signing requests include transaction data through PSBTs. The cheque-signing flow checks the transaction digest before requesting a signature. How much detail is displayed depends on the wallet; a limited display does not change what the signature authorizes.
Use the supported application link and check the network, amounts and recipients before approving a transaction. Support never requires a recovery phrase or private key.
Ethereum contract addresses
For the V3 Ethereum mainnet deployment documented here, the USDC approval spender is SimplePool. The approval transaction itself goes to the USDC token contract.
| Role | Ethereum mainnet address |
|---|---|
| USDC token | 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48 |
| SimplePool, USDC spender | 0x7d791006A910D2c84D56639ca90768Cd6357C5B7 |
| Gateway, collateral actions | 0xCF7CeA2B23E679B49Cfd3E30b8D2AaD23100Dfb3 |
| Reserve, collateral records | 0xff31b2ab1939BF1df377c9080cA9d6d9e1DAa767 |
Use the Deployment reference to identify the supported network and contract configuration. Trust assumptions explains how customer control, guardian protection and lending rules work together.