# 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:

<figure><img src="https://confluence.refburrow.top/download/attachments/721933/image-2024-8-14_10-3-22.png?version=1&#x26;modificationDate=1723601003668&#x26;api=v2" alt=""><figcaption></figcaption></figure>

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.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.satos.network/introduction/protocol/technology-introduction/withdrawal.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.