ICRC-1 Token Standard Ledger

Developers
1

Hi everyone,

The DFINITY Foundation has been working on a Ledger that implements the ICRC-1 Token Standard. This Ledger will be used as SNS and ckBTC Ledger and will be available for everybody for their own tokens.
We would like to share the API to facilitate integration with services.
Please keep in mind that this Ledger is still under active development and that the API may change slightly because we are still discussing the standard itself.

Best

17 Likes
2

Hi @mariop , what bout the possibility of moving the approveTransfer, allowance, revokeApproval and commitTransfer methods to a separate standard that can work alongside the base icrc1_balance_of and icrc1_transfer methods? Something like icrc1a_approveTransfer, icrc1a_allowance, icrc1a_revokeApproval, and icrc1a_commitTransfer. With the approve-methods being a separate functionality that most token holders will not use, with additional overhead for a ledger and additional cycles-cost to run and maintain, some SNSs might want to leave that overhead to a separate canister/service or leave it out.

1 Like
3

Do you mind sharing the reasoning behind adding the two-stage transfer API (e.g. approve)? That seems to be a large (and recent) addition.

1 Like
4

Probably for asynchrony

5

Basically it is necessary if you want to build any kind of service/dex. We are struggling through all kinds of user deposit issues trying to use the transfer/deposit pattern at the moment. This pattern makes things much easier for users and service providers.

1 Like
6

We are currently working on a standard for a multifunctional token. The bottom line is that we want to make it possible to give tokens any characteristics. You can read more here DSCVR .
We came to the conclusion that it would be more convenient to create a canister of characteristics, to give them a certain order. And a canister of token registries will address them. That is, when creating such a token, you will only need to register the values.
For example:

“parametr1 = none
…
parametr23 = 2
parametr24 = “description”
and so on

This will standardize the creation and, accordingly, requests to the canister. It will allow you to create explorers and other products on top of this architecture. I suggest you think about this method

2 Likes
7

So it’s like DAB for fungible tokens. (?)
It sounds like it’ll provide a ledger/centralized registry that’ll allow token tracking.

Would this also act as the settlement layer for fungible tokens?
Like, would it provide an environment for synchrony among the tokens in this registry? :eyes:

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
9

Hey @levi, I’d prefer to keep a single standard for now. Having two standards, a core one and a 2-steps transfer extension, would work but would go against our effort to reduce fragmentation and it would increase the complexity of both the SNS, which would have to give the option to configure the Ledger, and the Ledgers themselves.

I’m curious about what you said here though because as far as I know no DEX will support the ICP payment flow. That means that you won’t be able to exchange SNS Tokens on DEXs if you disable 2-steps transfer. This seems counterproductive to me as you want the SNS Ledger to be supported by as many services as possible. In which case it would be fine to not have 2-steps transfer?

3 Likes
10

Thanks for this great summary.

A couple of questions:

  • Will there be a special minting account for mint or burn operations?
  • Why are approvals not added to a block, while transfer revokes and commits are?
  • It seems like the approver has to pay the fee instead of the committer. Is that intentional? Will there be flexibility for other parties to pay the fee in the future?
  • What is the primary use case for subaccounts if they are no longer reserved for payments?

On a high level, this new approveTransfer / commitTransfer seems much safer than ERC-20. However, does it really enable 3rd-party transfers? A cheque is still a transaction between two parties. What if you want to approve a 3rd party to transfer your funds to someone else?

Additionally, is it a problem that the ICP ledger canister doesn’t implement ICRC-1, or will someone just need to wrap it for it to work on DEXs?

1 Like
11

@mariop
The DEXs and CEXs support ICP trades now. They can support SNS-token trades in the same way.

1 Like
12

Most DEXs have minimal to no support for ICP and have alternative wrapped versions of ICP. Even the ones that still have to launch changed their mind about supporting ICP. This brings fragmentation to the IC and the community was not happy. Add the SNS tokens to the picture and you end up with an unwelcoming ecosystem.

What we did then was to sit down with everybody and ask what was wrong with ICP. All DEXs and many DeFi devs pointed out the complexity of the AccountIdentifier and the issues with payment flows. We took the feedback and designed ICRC-1 with the help of the community.

3 Likes
13

Yes

The implementation is still WIP, that’s only the interface. In future approvals will be recorded as blocks

Each operation that uses resources on the Ledger needs to pay a fee. Note that the fee can be temporary: the service can remove the fee from the service cost and effectively pay the fee for the approver.

It can still be used for payments but the main reason is to have multiple accounts per principal. This simplified many flows such as the SNS one.

You can do it right now. The spender is not the receiver of the funds. A can approve B but it’s up to B to decide the destination of the tokens (see to_principal and to_subaccount).

ICP will implement ICRC-1 eventually. We first need to finish the SNS. ICP is next.

8 Likes
14

What are the issues they were having with the payment flows? and How do the approve methods fix those issues?

2 Likes
15

The issue was that the service could not issue a transfer and had instead to ask users to do transfers when ready. The new methods solve this.

2 Likes
16

Once the fungible token standard is decided on, could that be modified into an non-fungible token standard?

I assume yes(?)

Thank you

17

We are considering adding a second standard (ICRC2?) for NFTs following the work done for ICRC1. It’s not clear yet when we are going to do it but it would be nice to do it soon :slight_smile: .

4 Likes
18

Having ICRC-1 will definitely help :slight_smile:

Hopefully the community draws inspiration from ERC-1155 for batch transfer and other improved functions.

Thank you for taking charge on this important matter!

19

Yes, of course… we already have a set of regular tokens. This is easily applicable if you build a single token structure. Then the algorithm will make requests correctly. The essence of MFT is that it is a regular token that can have a description in the form of text or another type of file (like NFT), this token can have characteristics and this token can have an issue like a regular token. And therefore to trade on the exchange.

2 Likes
20

Ah very interesting! Endless possibilities here :exploding_head: