Sending funds to the pool
To send funds to the liquidity pool, contract calls have to be made to the supplier-interface contract. Funds can only be sent through that contract.
After the supplier is initialized and the funds are sent, the users are ready to send funds to whichever pool to be able to provide liquidity.

(define-public (initialize-swapper))

(define-public (send-funds
(block { header: (buff 80), height: uint })
(prev-blocks (list 10 (buff 80)))
(tx (buff 1024))
(proof { tx-index: uint, hashes: (list 12 (buff 32)), tree-depth: uint })
(output-index uint)
(sender (buff 33))
(recipient (buff 33))
(expiration (buff 4))
(hash (buff 32))
(swapper-buff (buff 4))
(suppler-id uint)
(min-to-receive uint))

block: block header (the 6 fields, unhashed) and Stacks height. The height corresponds to the Stacks block that is associated to the Bitcoin block in which the Bitcoin transaction is in.
prev-blocks: the block headers of the previous 10 blocks blocks to the one the bitcoin transaction is in. Only used in case of a flash block.
tx: The raw bitcoin transaction in bytes
proof: The proof demonstrating that the tx is in the block. tx-index, is the leaf position of the tree in the Merkle Tree. hashes, the leaves of the Merkle Tree of the transactions in the block, tree-depth: the height of the Merkle Tree.
output-index: the output in the Bitcoin transaction that we need to parse.
sender: the public key of the sender used to claim back the funds from the HTLC. The private key has to be kept by the user.
recipient: the public key of the supplier. This can be fetched from the bridge contract (
expiration-buff: the expiration time given in the HTLC (500 is the default).
hash: hash of the pre-image used to unlock the HTLC.
swapper-buff: supplier id of the supplier supplier in 4 byte little-endian form.
supplier-id: supplier-id of the chosen supplier
min-to-receive: amount of xBTC to be received minus supplier inbound fee. Can fetch inbound-fee from (

(define-public (send-funds-finalize
(txid (buff 32))
(preimage (buff 128))
(factor uint)
(lp-token <lp-token>)
(token-id uint)
(zp-token <dtc>)
(lv <lv>)
(xbtc-ft <ft>)
(rewards-calc <rewards-calc>))

txid: id of the transaction used in the previous send-funds transaction.
preimage: preimage of the hash used in the previous send-funds transaction.
factor: number of cycles that the user is committing their funds for (range from [1 - 32]).
lp-token: Contract principal using the lp-token-trait (current deployment is .lp-token).
token-id: the ID of the pool that the funds are being sent to, first pool is 0.
zp-token: Contract principal using the distribution-token-cycles-trait (current deployment is .zest-reward-dist).
lv: Contract principal using the liquidity-vault-trait (current deployment is .liquidity-vault-v1-0).
xbtc-ft: Contract principal using the SIP-010 trait of the Bitcoin token (current deployment is .Wrapped-Bitcoin).
rewards-calc: Contract principal using the rewards-calc-trait (current deployment is .rewards-calc)
Copy link
On this page
1. Bitcoin has to be sent to the generated address of the supplier (an HTLC contract)
2. If the swapper is not registered in the bridge, they have call the function initialize-swapper to initialize:
3. After the Bitcoin transaction is confirmed on Stacks, call send-funds on the supplier-interface
4. Finalize the transfer to send funds to the liquidity pool by calling finalize