Payment flow for wrapped ICP

I have looked for code repos for “wrapped ICP”. I found only these:

From what I understand they work in this way:

  • different users are sending to the same deposit account id
  • when users claim their wrapped tokens they must do so by calling from the principal that made the deposit on the ICP ledger
  • users (or their frontend) remembers the block height of the deposit and submit it when claiming the wrapped tokens

Does anyone know other repos that do it differently? The approach chosen here is surprising because it does not make use of subaccounts in the ICP ledger. The two downsides of the approach taken here are, if I understand correctly:

  • you cannot deposit funds from an account you do not control (e.g. an exchange) and if you accidentally do then you lose the funds
  • the wrapped token canister has to keep a record of the used block heights forever or otherwise they could get claimed a second time

An approach using one subaccount per user seems preferable and not have these drawback. Am I missing something? Or why was this approach chosen? And is there a public repo that has a different payment flow?

4 Likes

There is also Anvil nftanvil/packages/nftanvil_canisters/mo/pwr.mo at main · infu/nftanvil · GitHub (related functions: pwr_purchase_intent, pwr_purchase_claim, pwr_withdraw, nft_mint)
and Sonic (not OS, GitHub - Psychedelic/sonic-js: Sonic-js is a library that holds an API for interacting with Swap Canister) which wraps wrapped ICP. This way swaps happen with one request without additional inter-canister calls.

The reason we needed to wrap ICP was so we can create the missing notify (or something like it) function and allow our whitelisted canisters to use it. It’s a lot easier and takes 1 update call to the ICP wrapping canister, which makes another call to the canister which consumes it.

We are using dedicated subaccounts for every user depositing ICP and we haven’t had such a problem.

We are finalizing the claim only after the funds get transferred from the user subaccount into the main canister account. Not using block heights at all.

I believe their devs complained they have to load their canisters with complex crypto hashing functions and it was hard for developers to understand subaccounts. One of the reasons why ICRC-1’s implementation doesn’t require hashing functions.

1 Like

Sorry, I couldn’t follow. Are you saying the Sonic swap canister (which I guess isn’t open source?) wraps wrapped ICP, and the outer wrapping has a different flow? But the inner wrapping happens is still based on block height notification?

Yes, it’s not open-source or at least I don’t know where its source is. I know that because I made a blast for it [Internet Computer Content Validation Bootstrap] you can see how it works yourself.
Sonic wraps all tokens including wicp.
I am not sure I understand what you are referring to by ‘inner’ and ‘outer’, but yeah they have different flows.
The first wrapping uses block height.


The second one is using approve flow

Ok, thanks. Yes, inner = first = wicp, outer = second = sonic.