Which risks are LPs exposed to?
Zest Protocol allows liquidity providers to generate Bitcoin yield through professionally managed pools. Zest Protocol is designed to be a set-and-forget solution to earn BTC.
Yield comes from taking risk. Below are the risks you're taking when earning BTC yield on Zest Protocol:
1. Credit Risk
When you provide liquidity in a pool you’re taking credit risk from the borrowers of that pool. It is possible that a borrower defaults, which could result in a loss for the pool. Liquidity providers should review and be comfortable with the underwriting process and results of different pool delegates when choosing which pool to add BTC funds to.
Borrowers enter a Master Loan Agreement (MLA) during onboarding which enables legal enforcement in case of default.
2. Smart contract risk:
Zest Protocol trades-off counterparty risk of CeFi lending for smart contract risk. BTC funds are held in escrow by Clarity smart contracts on Stacks. All smart contracts are vulnerable to exploits. Unlike counterparty risk, smart contract risk slowly scales down close to zero over time as contracts become more battle-tested. Zest addresses smart contract risk through:
Smart contract security audits from leading cybersecurity firms and bug bounty programmes.
Use of Clarity smart contracts instead of Solidity smart contracts: the Clarity language was designed in response to the many hacks of Solidity smart contracts. Clarity trades-off some of Solidity’s expressiveness for safety, enabling developers to build dapps with the safety requirements of financial use-cases in mind (learn more).
The Zest Protocol smart contract team has been a core contributor to Stacks and the Clarity language for many years.
3. Stacks L2 risk
The Zest Protocol pool contract is a smart contract on Stacks, which means that an attack on the Stacks network is a potential risk while BTC is escrowed on the Stacks L2.
Zest Protocol moves incoming BTC onto the Stacks L2. When BTC funds are escrowed in a pool, they exist as sBTC. sBTC is a 1-to-1 backed tokenised version of BTC on the Stacks layer. The BTC backing sBTC is held in a threashold-signature script on Bitcoin L1 by Stacks consensus.
Zest Protocol's unique technical design limits Stacks attack vector risks only to the portion of BTC that is escrowed in a pool in the form of sBTC waiting to be borrowed (when Zest Protocol pegs the sBTC out to BTC). Pool delegates are incentivised to keep the amount of sBTC in their pools as low as possible: the longer the sBTC sits idle in their pools, the lower the yield in their pool will be. Based on analysis of lending protocols with a similar design to Zest, we expect a utilisation rate of 90-95% of BTC capital - leading to only a 5-10% of BTC funds to be held in escrow as sBTC at any given time
4. Bitcoin blockchain 51% attack
Since all funds are in BTC, liquidity providers are exposed to potential attacks on Bitcoin.
Risks FAQ
Is a liquidity provider exposed to counterparty risk from pool delegates? Pool delegates have no direct control over the BTC assets in their pool. When authorizing loans, pool delegates call a function in Zest Protocol in order to make a loan from the pool to a whitelisted borrower.
Can withdrawals be frozen? Unlike CeFi lending, there is no ability to freeze withdrawals. Neither the pool delegates nor the DAO can freeze withdrawals.
Last updated
