ICRC naming convention

We’re having some internal debates about ICRC naming conventions, and I would like to gather more inputs from our developer community regarding this choice.


We have created the ICRC-1 fungible token standard in an effort to reducing developer friction and increase composability. To further this effort we’re currently establishing an ICRC standardization system, learning from other open source projects such as Ethereum (EIP/ERC), Rust (RFC), IETF (RFC), etc.

Important Considerations

We decided not to blindly follow one of these ways because ICP itself presents several particularities:

  • Canisters are by default upgradeable, as opposed to ETH. With SNS as the controller of those canisters we have the proper security model to upgrade canisters in a trustless way. This provides the path to building evolving applications, without resorting to smart contract migration.
  • Projects having already deployed on the IC may not have the possibility to upgrade their canisters in a way that is conforming to new standards due to existing data structure limitations, eg. the existing ICP ledger transaction log is not compatible with the upcoming ICRC transaction log.

Overall Goal of ICRCs

  • Have an ICRC process that encourages community contributions (community proposals via GitHub)
  • Provide easy-to-understand documentation and template implementation for easy developer onboarding (similar to the OpenZeppelin experience)
  • Reduce developer integration efforts by unifying the interface.

Problem at Hand

After passing the ICRC-1, the Tokenization Working Group is working on improvements and extensions (possibly named ICRC-2, ICRC-3, ICRC-4, ICRC-5) to the ICRC-1 fungible token standard. Each of ICRC2-5 implements a feature extension to the ICRC-1 and can be cherry-picked by a project (for example a token may decide to implement ICRC-1, ICRC-3 and ICRC-4). While ICRC-6 is the “core” token standard and includes all of ICRC1-5, and we would by default guide developers to use this ICRC-6 standard unless they have a specific reason not to. The question arises whether developers coming into the ICP ecosystem would be confused.

NOTE: this discussion pertains not only to the current fungible token standard but also to all future standards.

Proposed solution A

Let each feature extension have its own ICRC number. Developers can pick which ones to support.

Proposed solution B

Don’t let each feature have its own ICRC number, instead just have ICRC-1 as the minimal implementation and ICRC-2 as the full-fledged implementation.

Arguments for A

  • Fine grained control by the developer about which subfeatures to support.
  • No need to be very selective about the ICRC process in the future.
  • In solution B, some existing canisters may not be able to upgrade to fully support the full feature set.

Arguments for B

  • Too many standards is as good as no standard. Having less standards increases the probability that most projects gravitating to just one standard, simplifying development efforts of complex applications.
  • In most cases developers are not looking for the perfect standard, but rather a common, stable interface. They can anyhow implement their own functions on top of the existing standard.

Which of these options seems more logical to you? Are there any other ways? Your inputs are appreciated.