Thoughts on the token standard

Developers
111

I’m not sure the ICP ledger canister model is developer-friendly or safe.

Having two separate methods transfer and notify just pushes the burden of cross-canister atomicity to the client. (Actually, notify is being deprecated, and the sender will need to call the recipient directly.)

For example, let’s say a user wants to convert ICP to some other token using some DEX canister running on the IC.

  1. The user calls transfer on the ICP ledger canister to send ICP to a DEX canister.
  2. The user calls some custom function on the DEX canister to notify it that some ICP was sent to it.
  3. The DEX canister then does some stuff with the ICP (i.e. swapping it for another token), which will require at least two inter-canister calls.

What if the DEX canister is out of cycles, or even worse, malicious? Then, after step 1 nothing else would happen, and the user just lost their ICP. Basically, we’re back to the Dark Ages of DeFi when only ERC-20 existed. This is the problem that ERC-223 and ERC-677 tried to solve.

I feel like a good token standard should take care of cross-canister atomicity, and clients shouldn’t have to care. Trusting clients to implement two-phase commits and saga transactions correctly is a recipe for disaster IMO. I would rather have the community implement that here in this token standard and save future developers/users a lot of pain.

5 Likes