.jpg%3Falt%3Dmedia%26token%3Dd4b91417-1638-468f-bd90-99fbd283d7ba)
.jpg%3Falt%3Dmedia%26token%3Dd4b91417-1638-468f-bd90-99fbd283d7ba)
The technology under the hood (pre-sBTC)
Before reading this section, check out this section:
Zest Protocol runs on smart contracts that are secured by the Bitcoin blockchain. These are Clarity smart contracts on Stacks, a 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.
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
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.
- 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.
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.
Yes. Zest Protocol will switch to a non-custodial tokenised BTC on Stacks as it becomes available. More details on the page below.