The technology under the hood
Zest Protocol runs on smart contracts that are secured by the Bitcoin blockchain. These are Clarity smart contracts on Stacks, the programming layer for Bitcoin.
Clarity smart contracts on Stacks can interact with Bitcoin by reading Bitcoin-state directly from the Bitcoin blockchain without requiring an intermediary (such as a server). Additionally, Bitcoin and Stacks blocks are produced at the same time allowing for unique cross-chain functionality. Stacks is our secret sauce.
To hold BTC in escrow in Zest liquidity pools, we leverage the Stacks layer’s unique architecture that enables trustless wrapping of BTC into a tokenised version of BTC that can be moved on the Stacks network. When a liquidity provider (LP) sends BTC into a Zest pool through the Zest Protocol UI, the BTC gets pegged-in to a tokenised version of BTC on the Stacks layer (sBTC). The sBTC ends up in the Zest pool. Conversely, when an approved borrower comes to the Zest Protocol UI to borrow BTC, Zest Protocol facilitates a trustless peg-out from sBTC in the Zest pool to BTC directed at the borrower’s Bitcoin address. Stacks’ unique ability to read Bitcoin state in combination with synchronised block production between the Bitcoin blockchain and Stacks layer enables the peg-in from BTC to sBTC to happen trustlessly.

While sBTC sits in a Zest pool, the equivalent amount of BTC is held in a threshold-signature script on the Bitcoin blockchain controlled by Stacks consensus. For security purposes, the BTC can only be moved out of the threshold-signature script every 150 Stacks/Bitcoin blocks, which is when the Stacks layer reaches Bitcoin finality and Stacks blocks can no longer be altered without changing Bitcoin history in a deep reorg. Every 150 Bitcoin/Stacks blocks, Stacks blocks become secured by the entire hash power of Bitcoin.
Let’s dive into each of the steps block-by-block to see how we leverage the Stacks layer’s unique network architecture to enable institutional grade Bitcoin lending.
- Zest Protocol fetches the Bitcoin address for the sBTC threshold-signature script and presents this Bitcoin address in to the LP.
- A threshold signature is a signature whose private key is distributed over multiple addresses. For the sBTC threshold-signature script, the private key is held by an open network of Stackers - who lock up STX as part of Stacks consensus.
- LP sends BTC to the sBTC threshold-signature script on the Bitcoin blockchain.

- Stacks consensus trustlessly confirms the LP’s Bitcoin transaction thanks to the unique ability of Stacks nodes to read Bitcoin state.
- In the same block, sBTC is minted to the Zest Liquidity pool as a claim on the BTC in the threshold-signature script.
- LP tokens are minted to the LP’s wallet address as a claim on deposited BTC.

- An approved borrower seeks to drawdown BTC funds & specifies a BTC address for drawdown on the Stacks layer.

- Zest Protocol liquidity pool moves sBTC to the threshold-signature script.

- Stacks consensus produces signature to release BTC from the threshold-signature script to the borrower.
- The sBTC gets burnt.
- For security purposes, the BTC can only be moved out of the threshold-signature script every 150 Stacks/Bitcoin blocks (~24 hours), which is when the Stacks layer reaches Bitcoin finality and Stacks blocks can no longer be altered without changing Bitcoin history in a deep reorg. As a result, every 150 Bitcoin/Stacks blocks Stacks history becomes secured by the entire hash power of Bitcoin.

Wrapped BTC yield products require the user to wrap BTC before participating in yield bearing activity. The BTC is held by a custodian or a collection of network nodes for the full duration of yield bearing activity, which introduces risk. Most Bitcoin holders rightly deem this risk to be too high for them to start earning yield on their BTC. At the same time, wrapping BTC may be considered a taxable event in some jurisdictions.
With Zest Protocol, on the other hand, users interact only with native BTC and the protocol performs swaps as a back-end operation. Zest Protocol’s technical design limits the risks associated with tokenising BTC only to the moment when BTC is escrowed in a pool in the form of sBTC waiting to be borrowed.
Pool delegates are incentivised to keep the amount of sBTC in their pools as low as possible: the longer the sBTC sits idle, the lower the yield in their pool will be. Based on analysis of lending protocols with a similar design to Zest Protocol, we expect a utilisation rate of 90-95% of deployed capital - leading to only a 5-10% of BTC funds to be held in escrow as sBTC at any given time. As a result, Zest Protocol is more secure than a fully wrapped BTC lending protocol.
No. There is currently no blockchain or Bitcoin layer in operation that has the technical design to facilitate trustless and programmatic movement of BTC. Bitcoin lending pools on other chains would require users to wrap BTC before interacting with the protocol and unwrap BTC after interacting with the protocol, resulting in fees, friction and risks.
This is the best place to learn about Stacks’ trustless tokenised BTC asset and Bitcoin finality: sBTC: Enabling Bitcoin Write
To learn about building decentralised applications that leverage sBTC under the hood, have a look at our contract docs (see sidebar).
Important note: Zest Protocol generates yield on BTC by taking risk. While Zest Protocol's unique technical design exists to reduce risk as much as possible, we would encourage everyone who's considering providing BTC liquidity to check out the risk section to get a full understanding of the risks associated with earning BTC yield on Zest Protocol Which risks are you exposed to?
The Stacks layer requires a hard fork before sBTC is introduced. This consensus upgrade is currently scheduled for Q3 2023. Before the hard fork, Zest Protocol will use trustless atomic swaps between BTC and xBTC (a wrapped version of BTC on the Stacks layer) to allow users to add BTC to Zest pools. Read more about the unique security features of the Zest Protocol design that features trustless atomic swaps below:
Last modified 1mo ago