Accessing dApps

In this section, let’s go deep into this question, how we can have users join NEAR network activities only with their Bitcoin wallets.

The core concept is like the following steps:

1. NEAR dApps’ frontend will generate standard NEAR Tx as usual, cause they won’t distinguish CSNA from other near accounts.

2. Instead of invoking any NEAR wallet, the user will indicate the dApp’s frontend to call NSP CA (CSNA Assistant) to further process the Tx.

3. NSP CA lives on the user side, helps to form correct signed messages using Bitcoin wallets, and then sends them to NSP message delivery service (MDS). It has 3 duties:

   1. Evaluate the gas consumption in nBTC satoshi, let’s say g satoshi;

   2. Convert the actions in Near Tx into DelegateActions (as required in MetaTx process);

   3. Let the user choose his favorite Bitcoin wallet to sign a signature (s) on a message (m) with his Bitcoin private key. This message (m) contains the hash of the DelegateActions and the maximum satoshi that the user decides to pay as the gas fee (the user will take g as a reference).

4. MDS acts as a relayer to transit signed messages to the NSP bridge smart contract (BC).

   • CA sends a tuple M = (DelegateActions, m, s, PK) to NSP MDS (Message Delivery Service) through an RPC call. This MDS will call NSP BC (the bridge smart contract) with this M using its own near account. To prevent malicious M sent by attackers to exhaust gas fee in that account, MDS will verify M to ensure the PK comes from NSP users and the signature s matches m and PK.

5. NSP BC signs those DelegateActions through Chain Signature on behalf of the user’s CSNA. Meanwhile, BC will charge nBTC from the user as the gas fee for this Tx.

   • Once receiving an M, the on-chain NSP BC will verify it and try to sign those DelegateActions on behalf of the user’s CSNA through chain signature. Besides the signing, BC will also ask nBTC token contract to claim a calculated nBTC satoshi from the user’s nBTC balance, as the gas fee of this Tx, as long as the calculated gas fee is no more than the maximum satoshi the user sets in the m.

6. NSP MDS then notifies NSP MetaTx relayer to send MetaTx with those signed delegate actions, and return TxID eventually back to dApp’s frontend for further business logic. It is the MetaTx relayer to pay for these Tx’s gas fee and possible near token deposits.

   • Once NSP MDS gets the signature, it will form a DelegateActionMessage with those SignedDelegateActions. And then sends DelegateActionMessage data to the NSP MetaTx relayer.

   • The NSP MetaTx relayer forms a Near Tx according to NEP-366 and sends it to the Near network. Meanwhile, the TxID will go back to MDS, then CA, and finally reach to dApp frontend for further business logic.

In summary, to support BTC holders to access, the 3rd party dApps frontend won’t have a massive modification, just take NSP CA as another Tx signer and sender and that is all. That’s the minimum integration experience in the web3 world so far.

For example, those dapps which support the wallet selector will automatically have NSP available without any modification cause we would embed NSP CA into the wallet selector.

Meanwhile, the BTC holders will enjoy the same experience as regular near users when accessing Near dApps, except they use bitcoin wallets to sign Tx and BTC to pay for gas.