Here is a proposal for the next working group meeting which I think might lead to faster acceptance of ICRC-1.
ICRC-1 is supposed to be a base standard.
We acknowledge that it does not cover all future demands.
Through the concept of modular extensions we hope that an existing token can adapt to future demands, i.e. expand its interface by upgrading the ledger, without having to create a wrapped token.
We want to avoid having to create wrapped tokens at all costs, for good reason, because that would create fragmentation in tokens.
In short, I think extensions alone do not cut it.
The limitation of extensions is that they can only extend, they cannot remove and, most importantly, they cannot introduce anything that conflicts the already existing interface.
I want to ask the question how can a single ledger support two conflicting interfaces for the same token?
To make an extreme, hypothetical example, only for the purpose of demonstrating how far-reaching the concept of conflicting interfaces is:
can a ledger at the same time support an account based transaction model and a UTXO based transaction model?
The answer is quite simple.
Yes. All we have to do is version the interface.
Say version 1 is the proposed ICRC-1 interface, a set of functions and corresponding account labels.
Version 2 is some other set of functions which may or may not use the same kind of account labels (the pairs of principal and subaccount of version 1).
Versioning the interface actually means versioning the account labels.
Conflicting means that there is a function in the old interface that cannot be applied to an account of the new version.
When version 2 is introduced then a transfer function must come with it that allows to transfer from a version 1 account to a version 2 account, and vice versa if desired.
So what do we have to do at this point to prepare ICRC-1 for this? Not much. All we have to do is version the account labels. That’s all.
Instead of (principal, subaccount) we have (version, (principal, subaccount)) and the version is set to 1.
Note that when a new version N is created it must be a standard of course, i.e. all tokens that implement version N must implement the same interface including the same transfer functions to and from exisiting versions.
Again, to repeat the power of the concept.
With a new version number we are basically creating a new, non-overlapping realm for the token.
We are allowing everything that a wrapped token could do, but without wrapping and in the same already existing ledger canister.
Versioning the account labels is a very simple, natural change and a good practice.
It helps to make ICRC-1 future proof.
With it we have a good argument that any shortcoming of ICRC-1, known or unknown, can be overcome in the future.