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 atomic swaps between BTC and xBTC without risk of losing BTC funds during the swap. When a liquidity provider (LP) deposits BTC in a Hash Timelock Contract (HTLC) on the Bitcoin blockchain, Zest Protocol facilitates a trustless swap between the BTC to xBTC. When an approved borrower comes along to borrow BTC, Zest Protocol facilitates a trustless swap from xBTC in the pool to BTC directed at the borrower’s Bitcoin address. Stacks’ unique ability to read Bitcoin state enables these atomic swaps to happen trustlessly, without risk of forking.
The trustless BTC-xBTC atomic swaps in the background are provided by an open-source application called Magic Protocol that the Zest Protocol team contributed to. xBTC is a wrapped version of BTC, backed by BTC held in Anchorage (as publicly auditable here).
Let’s dive into each of the swaps block-by-block to see how we leverage the Stacks layer’s unique network architecture to perform these atomic swaps.

Adding BTC to a pool: BTC—>xBTC swaps

Pre-block 1:

If this is the first time an LP adds BTC funds, they have to initialise their STX address with Magic Protocol. This is a Stacks transaction that does one simple thing - it creates a unique ID (an integer) associated with their STX address. This ID is later used to form a unique Bitcoin deposit address.

Block 1:

  • Zest Protocol generates a unique Bitcoin HTLC deposit address for the LP from Magic Protocol. This HTLC in essence a Bitcoin smart contract between the LP & Magic protocol, where the LP controls the secret which can unlock the BTC funds to one of the parties.
  • The LP sends BTC funds to the HTLC Bitcoin address.
  • Upon confirmation of block 1, the BTC is in escrow on the Bitcoin blockchain. The LP remains in control over their BTC (through their control of the secret) until the deposit is finalized on the Stacks chain (block 3).

Block 2:

  • Magic Protocol, on the Stacks layer, verifies that the BTC has entered the HTLC (Stacks read access to Bitcoin state) and escrows xBTC on the Stacks layer
  • In the unlikely event that the xBTC escrow in block 2 were to fail, the LP can simply reclaim their BTC funds from the HTLC since they still own the secret

Block 3:

  • Once the xBTC escrow is confirmed on the Stacks layer, the LP finalises the deposit by signing a transaction on the Stacks layer that reveals the secret of the HTLC to Magic Protocol.
  • Upon confirmation of this secret-revealing transaction on the Stacks layer, Magic controls the BTC in the HTLC while the escrowed xBTC now moves into the Zest liquidity pool & Zest Pool Tokens (ZPT) are minted on the Stacks layer which represent a claim on behalf of the LP to BTC funds in the Zest liquidity pool.
  • The Stacks layer has the unique capacity to do all these transactions in a single block thanks to Stacks' unique network architecture where Bitcoin and Stacks blocks are created at the same time: when Bitcoin forks, Stacks also forks - therefore, users don’t need to worry about chain re-orgs as they do in most atomic swaps. For more details, check out inbound swaps in Magic’s docs
It is important to note that the LP is always in control of their BTC funds, up until the exact Bitcoin/Stacks block where the LP receives their ZPT which functions as a claim on their BTC. The visual below recaps how the progression of funds through the system achieve this unique security model.

Drawing down BTC from a pool: xBTC—>BTC swaps

Block 1:

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

Block 2:

  • xBTC moves from the Zest pool into escrow

Block 3:

  • Magic Protocol has a limited window to send BTC to the borrower’s specified BTC address
    • In the unlikely event that no BTC is sent to the borrower address, the xBTC moves back to the Zest pool
  • A clarity smart contract independently verifies whether the BTC was sent to the borrower address (Stacks read access to Bitcoin state) and unlocks the escrowed xBTC to Magic Protocol within the same Stacks/Bitcoin block (enabled by Stacks-Bitcoin block creation being synchronised). For more details, check out outbound swaps in Magic’s docs.
Once again, it is important to note that the Zest pool contract remains in control of the xBTC funds up until the exact Bitcoin/Stacks block where the BTC moves to the borrower address. The visual below recaps how the progression of funds through the system achieve this unique security model.

FAQ: Zest Protocol’s technical design

How does Zest Protocol’s design differ from wrapped Bitcoin lending protocols on other chains?
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 high custody risk. Most Bitcoin holders rightly deem this custody 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 custody risk only to the moment when BTC is escrowed in a pool in the form of xBTC waiting to be borrowed. Pool delegates are incentivised to keep the amount of xBTC in their pools as low as possible: the longer the xBTC sits idle, the lower the yield in their pool will be. Based on analysis of lending protocols with a similar design to Zest and strong borrowing demand, we expect a utilisation rate of 90-95% of Zest’s TVL - leading to only a 5-10% of BTC funds to be held in escrow as xBTC at any given time. As a result, Zest Protocol reduces wrapping risk over the funds it manages.
Could Zest Protocol’s design be replicated on other chains by wrapping and unwrapping wrapped Bitcoin?
No. Chains other than Stacks don’t have native read access to Bitcoin state. Without read access to Bitcoin state, swapping BTC for a wrapped BTC without relying on a third party isn’t possible.
Does using xBTC for escrow introduce a centralised element?
Yes. It would make sense for Zest Protocol to switch to a non-custodial tokenised BTC on Stacks as it becomes available. The Zest Protocol team has been contributing to a design for a unique non-custodial tokenised BTC by the Stacks core blockchain engineers, which would allow for free peg-in/outs within one confirmation
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?