# Deposit NSP allows BTC holders to deposit assets in any Bitcoin wallets they like and are familiar with, even a withdrawal from a centralized exchange. That is because NSP generates an exclusive Bitcoin deposit address for any user, called ***dAddr***. With the BTC holder’s Bitcoin public key (called ***PK***), and NSP bridge contract (called ***BC***) ID as inputs, this dAddr’s deterministic generation algorithm is public and can be executed off-chain. Any BTC (can’t be too tiny for safety concerns) transferred to that dAddr will be taken as the user’s deposit. NSP will mint the corresponding ***nBTC*** token, a standard near fungible token as the mapping token of BTC in NEAR, to a specific NEAR account called Chain Signature Near Account, aka ***CSNA***. A CSNA is a pretty awesome near account with several interesting features: * It is a Zero-Balance account, which means not a dime of near is needed to maintain this account. Check [NEP-448](https://github.com/near/NEPs/blob/master/neps/nep-0448.md) for details. * It has only one full access key which is derived from the user’s Bitcoin public key, the PK, using NEAR Chain Abstraction Technology. * Any NEAR Tx originated from it, will have a Meta-Transaction relayer to cover the Near token gas consumption and possible deposit. Which means it is not necessary to have any near token in CSNA to take part in NEAR chain activities. Check [NEP-366](https://github.com/near/NEPs/blob/master/neps/nep-0366.md) for details. All the above features lead to one consequence, BTC holders can use their own Bitcoin wallet to play on the NEAR chain directly. The whole NEAR ecosystem now looks like a kind of high-speed Bitcoin layer-2 with the BTC token itself as the gas token, and with a bunch of existing dapps already there.
In the above chart: * The user gets his dAddr from the NSP frontend by connecting his Bitcoin wallet to get PK; * The NSP frontend will also register this dAddr to the NSP DTL (Deposit Tx Listner); * The user transfers BTC to the dAddr using the way he likes; * DTL who watches the Bitcoin network, detects that deposit Tx and reports it with the user’s PK to the NSP BC (Bridge smart contract); * BC will verify that Tx through a Bitcoin light client in the NEAR network and then ask the nBTC token contract to mint the corresponding nBTC to the user’s CSNA. * There is a CSNA creation process behind the scenes if this is a new user to NSP. BC will generate an ECDSA or EdDSA public key through Chain Abstraction with the user’s PK as the path. Then, BC requests the NEAR network to create the user’s CSNA and bind this key to it as its only full access key. This CSNA would have an ID like \[base58-addr from the PK].NSP.near. * At the end, the user would see his nBTC lies in his CSNA account. In summary, at this stage, BTC holders deposit BTC to NSP by only using their normal ways to transfer BTC tokens to their exclusive Bitcoin deposit address and it’s done. They will see the corresponding nBTC received in their non-custodian on-chain account, CSNA. --- # 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/deposit.md?ask= ``` 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.