Search…
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.
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). Clarity is our secret sauce.
To hold Bitcoin in escrow in Zest liquidity pools, we use a Clarity-enabled application called Magic Protocol. Magic is an independent protocol that uses Clarity to allow for decentralised, automated, and trustless atomic swaps between BTC and xBTC.
xBTC is similar to wBTC on Ethereum. It is a fully-collateralized BTC asset on Stacks minted by Wrapped.com which stores the BTC backing xBTC in Anchorage, a trusted custodian.
Let’s run through how Zest Protocol and Magic Protocol work together:
  • The liquidity provider sends BTC to a Hash Timelock Contract (HTLC) escrow address on the Bitcoin blockchain, as specified by the Zest Protocol UI - this escrow address can be used by the Magic Protocol to trustlessly swap escrowed BTC to xBTC
  • xBTC is held in escrow in a Zest liquidity pool
  • When an appropriate borrower has been found, the pool delegate (manager of the Zest pool) authorises a loan by signing a transaction on the Stacks network
  • The borrower now initiates withdrawal of loaned BTC funds and provides a BTC address to Zest Protocol
  • A Zest pool contract facing Magic Protocol swaps xBTC from the pool for BTC where the recipient address of the swap is the borrower BTC address
  • Borrowed BTC is in the borrower wallet
  • BTC repayments and borrow rate payments follow a similar flow to the above in reverse
Magic Protocol is able to make trustless swaps between BTC and xBTC thanks to Stacks’ read-access to Bitcoin state and the fact that Stacks & Bitcoin blocks are created at the same time.
Let’s dive into each of the swaps block-by-block to see how we leverage Stacks' unique features:

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.

  • 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).

  • 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

  • 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​
Visual representation of a Liquidity Provider adding BTC funds to a Zest protocol pool (borrowers follow a similar flow for making (re)payments back into the pool)
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.

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

  • xBTC moves from the Zest pool into escrow

  • 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.
Visual representation of a borrower drawing down a BTC loan from Zest Protocol (LPs follow a similar flow for withdrawing BTC funds from the pool)
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.

How does Zest Protocol’s design differ from wrapped Bitcoin lending protocols on other chains?
Wrapped Bitcoin yield products require the user to wrap Bitcoin before participating in yield bearing activity. The Bitcoin is held by a custodian or a collection of network nodes for the full duration of yield bearing activity, which introduces custody risk. Most Bitcoin holders rightly deem this custody risk to be too high for them to start earning yield on their Bitcoin. At the same time, wrapping Bitcoin may be considered a taxable event in some jurisdictions. With Zest Protocol on the other hand, users don’t have to wrap any Bitcoin. While incoming Bitcoin is swapped for wrapped Bitcoin (xBTC) by the protocol, this wrapped Bitcoin is swapped again to real BTC once a borrower takes out borrowed BTC funds. Zest’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 Bitcoin on Stacks as it becomes available. The Zest Protocol team has been contributing to a design for a unique non-custodial tokenised Bitcoin 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?​
Copy link
On this page
Adding BTC to a pool: BTC—>xBTC swaps
Drawing down BTC from a pool: xBTC—>BTC swaps
FAQ: Zest Protocol’s technical design