ICRC-3 Draft v2 and Next Steps

Developers
45

Hi,
I got a couple of requests for change for the ICRC-3 standard from outside the working group. This was the feedback I was waiting for before moving on with ICRC-3. The two suggestions are the following:

  1. point 2 of the Generic Block Schema section requires ICRC-3 blocks to have a field tx: Map with a field of type op: Text inside. The change request is to drop this requirement in favour of having a field type: Text at top level which defines the type of the block. This type should follow a schema such as <standard_number><field_type> e.g. for ICRC-1 transfer block it would be 1xfer. We should also propose a schema for custom blocks, e.g. prefix the type with c plus a unique code of some sort, so that custom standards could be supported. Note that for this to work <field_type> should never start with a digit. For backward compatibility with existing Ledgers (ck, SNS, …) we should still support the current approach of having tx: Map with the op: Text field inside but mark the new block style with the type at top level as the favored approach.
  2. Add a new endpoint icrc3_supported_block_types to list all the supported block types. Given the open nature of ICRC-3 each client will always have to query the supported blocks from the Ledger to understand if they can interpret all the blocks. The original plan was to use the icrc1_supported_standard endpoint from ICRC-1 to query this info. Some people proposed to instead have an endpoint in ICRC-3 so that any Ledger, including the ones not supporting ICRC-1, could use ICRC-3. The endpoint icrc3_supported_block_types is also more fine grained compared to icrc1_supported_standards. Both the name icrc3_supported_block_types and the type returned are yet to be clarified.

We could discuss this tomorrow in the working group but I wanted to write it here first so that everybody can have a look.

What do you think?

3 Likes