Withdrawal

There is a standard FT interface, “ft_transfer_call”, that allows users to transfer tokens to a smart contract with additional information. We leverage that feature to start withdrawal from the users’ side: the user transfers his nBTC to NSP BC with specific withdrawal information.

So, generally speaking, the withdrawal is just another dApp access process. In this section, we will focus on the management of those UTXOs that belong to NSP and how we organize safe and efficient withdrawal BTC transactions in the Bitcoin network.

From those deposits, NSP accumulates a bunch of UTXOs we call NSP UTXOs. The reason why NSP could expend them is that those dAddrs are all Chain Abstraction keys, and NSP can request corresponding signatures by itself.

The withdrawal flow looks like the following chart:

1. The user starts withdrawal on the bridge front end by requesting a transfer of nBTC (the mapping asset token) to the bridge contract with ft_transfer_call;

2. The bridge front end chooses the bridge UTXOs wisely with the help of UTXO management service, and builds the raw withdrawal TX. Then the bridge front end fits the raw TX into the msg fields of ft_transfer_call to the bridge contract.

3. Once received the transfer, the bridge contract parses the msg to get rawTX, and verify it to match both the user’s request and the bridge logic (such as UTXO validation, reasonable change UTXO and TX fee, etc).

4. Once passing the verification, those UTXOs are removed from the bridge UTXO scope, and can NOT be used by other withdrawals. And the raw TX will be on a list waiting for the signing trigger to invoke the signing process.

5. The signing trigger scans all raw withdrawal TX and invokes the signing process by calling sign_withdrawal_TX_input(...) interface of the bridge contract, and the bridge contract would sign those inputs one by one by calling NEAR Chain Signature on-chain service.

6. Once the last input in a raw withdrawal TX has been signed, the whole TX will be moved to the signed TX zone in the bridge contract, waiting for the withdrawal TX relayer to broadcast it.

7. The withdrawal relayer scans all signed TXs and broadcasts them.

8. withdrawal TX Listener would detect if the TX got enough miners’ confirmation.

9. Once enough miners accumulate, the withdrawal TX Listener reports to the Bridge Smart Contract. And the bridge contract will verify the TX validation through the BTC light client on the NEAR chain.

10. Once the TX is valid, the bridge includes all changes UTXO into bridge UTXO scope. and call the bridge token contract to burn the corresponding amount of nBTC that was previously transferred from the user to the bridge.