The Design and Evolution of the ICRC-1 Fungible Token Standard
A review of the principles and features behind the Internet Computer’s fungible token standard.
On August 14th, the overwhelming majority of NNS voters accepted the ICRC-1 Fungible Token Standard proposal for the Internet Computer. As a member of the Ledger & Tokenization Working Group, I feel humbled by the community’s trust and support.
Many people contacted me after the vote to learn more about the standard, motivating me to write this article. I will explain the reasoning behind the Working Group decisions, highlight interesting features of the accepted standard, and outline future work.
Design principles
If you were to ask five different programmers to each design an application programming interface, the diversity of their solutions might surprise you. People make decisions and design software based on their values and priorities.
Knowing the principles that the Working Group followed when designing the standard will help you better understand the final product.
Interoperability
The compatibility of the new standard with the existing infrastructure was the primary concern of the Working Group.
Hundreds of millions of dollars worth of tokens are locked in existing ledgers hosted on the Internet Computer. Producing a specification incompatible with the storage model of those ledgers would require wrapping those tokens. Wrapped tokens are a reasonable compromise for interoperability between blockchains, but applying this solution to ledgers already hosted on the Internet Computer has many disadvantages:
- Fractured ecosystem. Some actors will continue to use the original ledger; some will move to the wrapped tokens for convenience. These two groups will have to use and support incompatible tools and interfaces.
- User frustration. Every user must decide which token version (wrapped or unwrapped) they need to use. This mental strain is unnecessary and avoidable.
- Operational costs. Wrapping tokens will require setting up and maintaining new infrastructure.
- Security issues. Bridges and token wrappers are usual sources of costly security bugs.
Safety
The standard should expose only features amenable to efficient and safe implementations.
For example, the Working Group considered a payment flow requiring the ledger to send notifications to the payee. Unfortunately, this flow can compromise the ledger upgrade safety, so the Working Group focused on a less convenient but safer (at least from the implementation point of view) flow.
Pragmatism
The standard should not depend on experimental or new platform features.
The Working Group members suggested many brilliant ideas that didn’t make the cut. Continuing the payment notifications example: adding new platform features (e.g., named callbacks) can enable upgrade-safe implementations of notifications. Nevertheless, we decided to postpone the notification feature because having a good standard now is more important than having a perfect one in a year.
Simplicity
The standard should be easy to understand and implement.
Unnecessary complexity is the scourge of software systems. Some of the features discussed in the Working Group, such as the two-step transfer interface, were safe and pragmatic but notoriously hard to implement correctly. Given that there is no immediate need for these mechanisms, we agreed to develop advanced payment flows as future extensions.
Feature highlights
Embedding
The ICRC-1 token standard is embeddable into existing ledger implementations. For example, the ICP ledger and any DIP20-compatible ledger can integrate ICRC-1 safely. Several decisions made such embeddings easy:
- ICRC-1 accounts give ledgers a lot of flexibility in choosing internal representation. For example, the ICP ledger can convert ICRC-1 addresses into account identifiers.
- All methods in the ICRC-1 interface have the icrc1_ prefix. Name conflicts will not stop developers from adding ICRC-1 methods to their interfaces.
- The ICRC-1 interface does not specify access to the transaction log, giving existing ledgers the freedom to use their (incompatible) representations. Sometimes not having something is a feature!
Improving the ICP ledger technology
The ICP ledger is the biggest token ledger deployed on the Internet Computer. It is stable and robust: there haven’t been any significant incidents or unplanned outages since its launch in early May 2021.
The standard draws heavily on the experience of developing and operating the ICP ledger and inherits many of its beneficial traits:
- ICRC-1 allows users to have multiple subaccounts, encouraging additional transparency and enabling a simple and safe payment flow. The NNS Governance is a heavy user of this feature.
- ICRC-1 inherits and improves the transaction deduplication feature crucial for implementing safe transfers over an unreliable network.
At the same time, the standard brings some quality-of-life improvements, such as more transparent account addresses and extended memo sizes.
Layered design
The design goals of the standard precluded the inclusion of many practical features. The Working Group understood the importance of these features and decided to follow the principles of Lean Production practices and deliver results in small batches. The ICRC-1 standard provides the icrc1_supported_standards endpoint to query the ledger capabilities.
As we already discussed, the standard does not specify the interface for fetching transactions. The lack of this interface makes it impossible to build many valuable features. For example, token wallets have no portable way of displaying all past transactions.
The Working Group chose to produce a separate optional extension for accessing the transaction log. Once this specification is ready, some ledgers will implement the new spec and advertise it through the supported standards endpoint. The wallets will be able to query ledgers for extensions and use the new interface when it’s available to provide a better user experience.
The layered design is also great for platform evolution. Plenty of exciting features are coming to the Internet Computer platform, and the extensions mechanism will allow the DeFi ecosystem to evolve in lockstep with the platform.
Extensible metadata
Many token standards follow the ERC-20 example and allow the ledger client to query information about the token, such as the token name and symbol. However, modern applications usually demand more information to provide a good user experience. Wouldn’t it be nice to display the token icon? How about different icons for dark and light color themes? Or maybe a link pointing to the description of the token? The solution proposed by the Working Group is to provide uniform access to metadata enabling application builders to experiment without changing the ledger interface.
Next steps
The ICRC-1 token standard is an important milestone, but it’s just a beginning of a long journey. The Ledger & Tokenization Working Group has plenty of work to do:
- We need to agree on the textual representation for the ICRC-1 accounts.
- Inspired by the Internet Computer Interface Specification, we want to introduce an acceptance test suite allowing developers to test their ledger implementations.
- We are looking forward to developing further specifications enabling new types of applications, such as transaction log access and advanced payment flows.
Stay tuned!
____
