Hi, I’m building a shared/unified wallet in motoko, and I’m having a dilemma whether I should:
A) only allow users to deposit ckBTC/ckETH/ckERC20 via ICRC-2 into my Motoko dapp, and if they have native assets, they should convert them via NNS first, or …
B) make my dapp to allow native BTC/ETH/ERC20 to be deposited and update the internal balance, making my dapp a one-stop deposit experience
but tbh I’m not that experienced and I might be ignorant of the risks that I dont know yet. I’ve been asking Caffeine, ICP.Ninja and Docs AI… both Caffeine and Ninja recommend only allow ckTokens deposit while Docs AI hallucinates a lot (haha).
I think this is a broader question, not limited to Motoko only.
Before providing a more detailed answer I would first like to make sure I understand the use case by asking some questions:
Is your dapp actually intended to be a wallet or what kind of functionality does your dapp provide? (e.g. like OISY)
If yes, do you plan to run the wallet functionality fully in the backend? Meaning that all users would deposit their tokens into accounts which are 100% controlled by your backend
Note: OISY is mostly “just” a frontend which uses the chain-fusion-signer to let their users control funds on other chains
What do you mean with “shared/unified”? Do you mean that all funds are controlled by your backend? (see above question)
Basically it’s a single canister that holds multiple user’s deposit of different assets. Perhaps I misused the word “wallet”. Then, the canister will credit internal balance for each deposit per user per asset.
alright, so few additional comments/thoughts from my end to this in terms of risks:
route A) is the easiest for you to choose in terms of development, that is what I would recommend to start with at least
in case your users are familiar with OISY Wallet (cc @yellingfore), they could also use OISY to convert the native tokens directly within OISY (no need to use the NNS dapp in this case).
if you rely on the ICRC-2 flow anyway, you can let the users connect with OISY and request the funds to be transferred to your application
if you would rely on Internet Identity (II) login only, the users would first need to transfer the funds in to the principal of the delegation identity which is derived for your dapp and then approve the funds to be transferred to your backend. you can still use both: Internet Identity to authenticate on your application and OISY Wallet connection to request from the user and associate those funds with the II principal
route B) is definitely possible and might be preferred if you want your users to provide a “native experience” from their ecosystem. here you can consider two routes:
manage EVERYTHING on your canister side (derive and advertise native addresses for deposits, propose transactions for BTC/EVM/…, calculate/estimate fees) from within your canister in case you want users to move out the funds or if you want to do sth. with the tokens on the native chain
in this case, you would not convert the tokens into ck-assets and manage the funds natively from within your canister
use the ckBTCMinter and ckETHMinter in the background and manage conversion to ckBTC/ckETH/… behind the scenes
this is e.g. what odin.fun does
OC recently also enabled this flow
so in general you have a lot of different options. in the end you need to determine yourself what is targeting best your potential userbase. I hope this answer helps a bit to find the right direction.
note: if your single canister manages all funds, this canister will become a honey pot for attackers, so be sure to have it properly secured and tested
Given the level of my skills (never do Bitcoin or Ethereum developments), I have decided to go with Route A (accept only ICRC-2 deposits), and then later on follow OpenChat’s route which is enabling native deposits but convert them to CK twins directly to improve the experience a bit for people outside of ICP.
This is an elegant way. It works very well for BTC. There are some limitations though because you are bound by the existing ck-minters. That means for example:
token choice is limited to the existing ck-tokens
configuration parameters such as 6 BTC confirmations are fixed
ETH and ERC20 deposits require smart contract calls (on Ethereum), i.e. cannot be made with any ETH wallet or from exchanges. They have to go through Oisy which is capable of making the smart contract call.
In either case, doing any of this requires quite a bit of knowledge/experience.
but the flow is not limited to OISY. the UI of the dapp could also let users connect their EVM wallet (additionally) and request the user to approve the required contract calls on Ethereum.
note: I am not saying this is very convenient, but it can be done
@sea-snake as of writing the above I am wondering if the identity and wallet-standards working group ever discussed the possibility to extend the signer standard so that it could also support existing EVM standards if feasible, it might be quite cool being able to request tx’s for multiple chains if connected to a multi-chain wallet like OISY.
,
if feasible, it might be quite cool being able to request tx’s for multiple chains if connected to a multi-chain wallet like OISY.