That’s still up for discussion. The current options are base32 (some flavour of it) or hex.
Announcing "Token Standard" as topic of the first meeting of the Ledger & Tokenization Working Group
Dear working group members!
Here is the proposed agenda for the ledger and tokenization WG meeting tomorrow, Tuesday, January 10, 2023. See the working group calendars (Google Calendar, calendar browser link) for details and dial-in information.
- ICRC-2: Next Steps
- ICRC-3: A standard for accessing the transaction log
- Textual encoding format for ICRC-1 account addresses (forum discussion)
Looking forward to the meeting tomorrow!
Dear working group members!
Here is the proposed agenda and draft slides for the ledger and tokenization WG meeting on Tuesday, January 24, 2023. See the working group calendars (Google Calendar , calendar browser link ) for details and dial-in information.
Agenda
- Textual encoding format for ICRC-1 account addresses
Draft slides
If there’s time, there are two other topics on the agenda (see slides).
I summarized the options that have been proposed for the textual encoding and included the key aspects of the forum discussions. Please have a look at the slides before the meeting!
It would be great if all people who have been actively involved in the encoding discussion could make it to the meeting!
@timo , @Maxfinity , @benji , @skilesare , @mparikh , @levi , @mariop , @roman-kashitsyn
Looking forward!
1 Like
Reminder: Next standards meeting on Jan 24. See 
TTYT
More of an instinct than a thought but something just feels off about all this visual variety being valid encodings, especially if we add existing IC encodings for eg principals and canister IDs to the set of all valid identifiers on the IC.
In general I get the impression that the IC makes many distinctions where other systems use a single category. Eg notions like Principal, Subaccount, Account ID, canister principals vs user principals, in say Ethereum all are a fixed-length output of a single hashing function of a single type of input. Some of those distinctions may be necessary or convenient, but each one adds a layer of conceptual and implementation complexity, and it’s impossible to prevent that from turning into a degree of mental drag and confusion for users and developers (this very discussion and associated meetings for example are a consequence of having more than one type of identifier). Whether we like it or not, all friction is a barrier to adoption, for devs and users, and all complexity a source of error.
I just have a bad gut feeling about adding yet another substantially different format.
No overwhelming feelings and I’m certainly no expert, but I’d consider staying with the familiar IC-style of #55 or something like it (maybe a fixed-length version?), especially if I’m correct (not sure) in thinking that if you want to view or make available all subaccounts for a given principal at once, eg on an explorer, you can just decode the textual representation of #55, extract the principal, and use it to programatically obtain all principal-oriented data/assets, without any (or at most one?) conditional statements being required from the developer.
Just my two cents and I understand there’s a history too.
1 Like
2 Likes
Dear working group members!
Here are the proposed agenda and draft slides for the ledger and tokenization WG meeting on Tuesday, February 07, 2023. See the working group calendars (Google Calendar , calendar browser link ) for details and dial-in information.
Agenda
-
Textual encoding format for ICRC-1 account addresses
If time - Standard for and replacing DAB
- ICRC-3: A standard for accessing the transaction log
It would be great if all people who have been actively involved in the encoding discussion could make it to the meeting!
@timo , @Maxfinity , @benji , @skilesare , @mparikh , @levi , @mariop , @roman-kashitsyn
Looking forward!
1 Like
See here for the summary of the discussion of the previous meeting of January 24 and here for the video.
New ICRC proposal
There’s a new ICRC extension proposal on batch transfers by @skilesare on the table: ICRC-1/readme.md at Icrc4 · skilesare/ICRC-1 · GitHub
If you are interested in the subject, feel free to comment or make a PR.
1 Like
The slides, recording, and minutes of the WG Meeting of February 7 are available:
Slides
Recording
Minutes
Dear working group members!
Here are the proposed agenda and draft slides for the ledger and tokenization WG meeting on Tuesday, February 21, 2023. See the working group calendars (Google Calendar , calendar browser link ) for details and dial-in information.
Agenda
-
Textual encoding format for ICRC-1 account addresses
If time - Standard for and replacing DAB
- ICRC-3: A standard for accessing the transaction log
The main question is whether we can settle on having the checksum suffixed to the principal with a “-” separator:
4kydj-ryaaa-aaaag-qaf7a-cai principal = subaccount 0 (default subaccount)
4kydj-ryaaa-aaaag-qaf7a-cai-1bef.1 subaccount 1
4kydj-ryaaa-aaaag-qaf7a-cai-7ab1.3fce35d21aa8 subaccount 3fce35d21aa8
Let’s finish the encoding discussion tomorrow and tackle new items soon!
2 Likes
The slides, recording, and minutes of the WG Meeting of February 21 are available:
Slides
Recording
Minutes
3 Likes
Dear working group members!
Here are the proposed agenda and draft slides for the ledger and tokenization WG meeting on Tuesday, March 7, 2023. See the working group calendars (Google Calendar , calendar browser link ) for details and dial-in information.
Agenda
- Textual encoding format for ICRC-1 account addresses: Checksum
- ICRC-2: Recurring payments
Upcoming items
- ICRC-3: A standard for accessing the transaction log
- Standard for and replacing DAB
Talk to you tomorrow!
2 Likes
Hi Everyone,
See this about keeping separate approval balances for each approval even for the same approver-spender combo. ICRC-2 Expiration Inconsistencies & long-term unused approval allowance build-up · Issue #93 · dfinity/ICRC-1 · GitHub.
If we do, implementing periodic/recurring approvals is straightforward.
1 Like
I thought an important point of having transferFrom was that the spender didn’t have to know a block height and thus the payment flow was simplified.
It is a bit late for me to think of a solution, but “in the real world” each additional notification of something or waiting for something is another friction point that is causing our users issues.
Ideally I’d like for my user to be able to approve and then I’m able to pull those funds without them having to know the id of the block…searching for them is hard and in a flow where two separate systems maybe making the notification and sending the payment it makes things more complex.
I’ll think more on it.
1 Like
Of possible interest to the working group: https://twitter.com/Tyler_Did_It/status/1632781451514073090?s=20
Details:
1 Like
Let me share the following extensive report about the IC token standardization efforts:
3 Likes
Hi Everyone!
See this correction for the ICRC-2 standard: ICRC-2 Separate approval allowances and honor the set expiration in an approval-request. by levifeldman · Pull Request #101 · dfinity/ICRC-1 · GitHub.
Fixes #93.
@skilesare This change does not require the spender to know any approval-block-ids. The TransferFromArg stays the same.
1 Like
The slides, recording, and minutes of the WG Meeting of March 07 are available:
Slides
Recording
Minutes
Dear working group members!
Here is the proposed agenda and draft slides for the ledger and tokenization WG meeting on Tuesday, March 21, 2023. See the working group calendars (Google Calendar , calendar browser link ) for details and dial-in information.
Agenda
- ICRC-2: Recurring payments
If time
- ICRC-3: A standard for accessing the transaction log
- Standard for and replacing DAB
Talk to you tomorrow!