Announcing "Token Standard" as topic of the first meeting of the Ledger & Tokenization Working Group

That’s still up for discussion. The current options are base32 (some flavour of it) or hex.

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.

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 :fu:

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.

image

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.

FYI The ICP Ledger has been upgraded to support ICRC-1 and we published a javascript library that supports ICRC Ledgers.

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

Slides

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.