Question about the ICRC-1 implementation by the foundation

Developers
1

I just saw that the IC repo now contains an ICRC-1 ledger implementation separate from the ICP ledger. Fantastic! I’d really like a implementation that is created and reviewed by experts like the foundation. It even has an index to query transactions by users which will be great for applications like transactions explorers or canister who need that info.

I can’t find anything about it on the forum though. The current “deploy a token” instructions still talk about using the ICP ledger and the .did file doesn’t even contain the ICRC-1 interface. Is there a timeline for when the ICRC-1 token implementation will be considered production ready?

Also will there be a create with the ICRC-1 types similar to the ic_ledger_types crate?

@roman-kashitsyn

2

The ICP Ledger is already ICRC-1 compatible but the did file doesn’t contain the interface because there is already an icrc1.did file in the repository and we don’t want to duplicate that. You can find the test that proves this here.

The ICRC-1 token implementation is production ready. The repository directory of the ICRC-1 Ledger contains a README.md with all the steps on how to deploy your own token locally.

Yes. Personally I would add the crate to the ICRC-1 repository so that anybody can contribute to it. At DFINITY we have an internal crate for ICRC-1 but it’s not public because it allows to use also the legacy cdk and it directly imports the types from our ledger crate. You can import it via cargo but it will drag a lot of dependencies so I would suggest to not do so.

If anybody wants to work on a generic client for ICRC-1, then feel free to make a PR to the ICRC-1 repository.

3

Thanks for answering! a few more questions

  • I see the ICRC-1 ledger doesn’t implement the rosetta API will that be added in the future or should you use the ICP ledger in that case?
  • If so, does the ICP ledger make assumptions around being deployed to a system subnet that could cause problems?
  • Are there any differences between the two ledgers in terms of cycle consumption / efficiency?
  • For devs who want to launch a token that isn’t under an SNS but do want to upgrade the ledger in the future if additional parts of the standard are added trust is an issue. Is there any update on this proposal? Canister History Proposal - #6 by mraszyk
1 Like
4

It might also be a good idea to publish a list of hashes somewhere so that people can verify easily that the code hasn’t been changed.

Also one additional question: Should you always upgrade to the next blessed release without skipping any intermediate releases to prevent problems with pre/post upgrade? If so it might be useful to include a warning for that in the readme

1 Like
5

We’re making progress on implementing canister history, but still don’t feel confident to announce a precise date of its roll out.

6

This motoko version has a rosetta server: GitHub - NatLabs/icrc1: A full implementation of the ICRC-1 fungible token standard

1 Like