ICRC-1 Token Standard Ledger

Developers
8

One of the main reasons why we wanted to discuss a common standard is to decide a common payment flow that could be implemented right now on the IC. We sit down with the community in the Ledger&Tokenization working group and decided that a ERC-20 like approach, with some changes to make it more robust, was the best flow. The rationale is that out of the three main payment flows, the only one widely supported by both the platform and the community is the 2-steps transfer. Let me summarise here the payment flows and the why we decided for/against each one of them.

  1. ICP Payment Flow (account_balance/transfer): this is a combination of the methods account_balance and transfer plus the idea of reserving subaccounts for payments. This was rejected by the community. There is no DEX supporting it at the moment nor interest in support it as far as I can tell. Note that this is still in the final standard because it uses only the base building blocks of the standard.
  2. DIP-20 Payment Flow (approve/transfer): the most common payment flow as far as I can tell with support from at least half of the community based on a recent vote. We evaluated it at DFINITY and had some security concerns which lead to the creation of the 2-steps transfer. 2-steps transfer is basically a variant of the approve/transferFrom flow that increases its robustness by adding some bounds around them. We asked if the variation was fine and most people agreed with it. Moreover, most DEXs said that they will support this payment flow.
  3. IS-20 Payment Flow (transfer/notify): a different payment flow that removes the need for the service to check that a payment is valid or not. In other payments flow, the user needs to notify the service that a payment happen and then the service needs to check the Ledger to verify the payment. With notify, the user asks the Ledger to notify the service and that means the service is notified only when the payment effectively happened. This is a great idea but the TL;DR is that it requires changes at the replica level to either support named-callbacks or one-shot calls in order to be properly supported by existing Ledgers. We want the payment flow to be implementable right now and that’s what ultimately made us decide to not support this payment flow but maybe revise it in future. I can elaborate more if needed, maybe during a working group session.

ICRC-1 is the combination of the basic building blocks of a Ledger, e.g. balanceOf and transfer, and the 2-steps payment flow.

I understand that the standard is not as simple as it could be but look at the bright side: we finally have a payment flow on the IC that everybody can and want to support. This is the first standard that is supported by both DFINITY - SNS, ckBTC and later ICP will all support ICRC-1 - and the community and it doesn’t preclude extensions or new standards.

It’s a win for everybody.

7 Likes