ICRC-3 Draft and Next Steps


The draft for ICRC-3: A standard to access the Transaction Log is ready for reviews. The timeline for the feature is the following:

  1. the WG is going to address the comments during the 25 Jul meeting
  2. after that, the WG will vote the ICRC-3 proposal
  3. if the vote is positive then a NNS motion proposal will be submitted
  4. if approved then ICRC-3 will be official :tada:

Thanks everyone.



In the draft there is a specification for calculating the hash of a transaction:

This hash function should be used by Ledgers to calculate the hash of the parent of a transaction and by clients to verify the downloaded transaction log.

The hash function is the representation-independent hashing of structured data used by the IC:

the hash of a Blob is the hash of the bytes themselves
the hash of a Text is the hash of the bytes representing the text
the hash of a Nat is the leb128 encoding of the number
the hash of an Int is the sleb128 encoding of the number
the hash of an Array is the hash of the concatenation of the hashes of all the elements of the array
the hash of a Map is the hash of the concatenation of all the hashed items of the map sorted. A hashed item is the tuple composed by the hash of the key and the hash of the value.

A couple of questions:

  1. It isn’t specified what hashing function to use. Is it sha256?
  2. Do we have a leb128 encoding and sleb128 encoding for Motoko anywhere?
  3. What about very large nats and ints that may not fit into 128?

ccing @timo and @quint as I know they’ve done some hashing stuff.

The 128 in leb128 is just the base, it doesn’t limit the size of what can be encoded.

I don’t know about the other two questions.


I created a ticket here:

The certificate here supposes that a canister certifying icrc3 transactions only certifies its own transactions. In reality, many canisters that have a ledger will have many other things they want to certify.


  • certifying json endpoint to retrieve blocks
  • NFT canisters certifying content in the canister.

This x-refs with what @nathanosdev is working on with v2 certification.

cc @mariop

This section is confusing: https://github.com/dfinity/ICRC-1/blob/icrc-3/standards/ICRC-3/README.md#interaction-with-other-standards

The block in the example looks wrong. The ts and the fee seem to be at the top level, but the description describes that the only top level items should be tx and phash. Shouldn’t ts and fee be inside the tx map?

Hello, my friend! I am not a tech developer and I was wondering if icrc3 could support SNS token listings on cex exchanges, or would it significantly help?

CEXs typically need a rosetta node. ICRC3 is nice for storing data to serve a rosetta node. They aren’t directly related, but support each other.


The ability to fetch blocks, which is what icrc3 is about, is required for listing but the current SNS Ledgers already have something in place. What is missing for CEX integration are two features:

  1. The ability to send pre-signed transactions to the Ledger (ICRC-24)
  2. The Rosetta node implementation. We are already working on it and you can see the prototype here.

The ability to list on CEX is a priority for my team and we should be able to deliver it in the next months.


I see that the spec now designates that the values should be at leafs in a certification tree.

last_block_index and last_block_tree.

I’ll be difficult and ask what if the canister has two kinds of ledgers? Imagine an icrc7 nft that has an icrc3 ledger composed with an icrc 1/2 fungible token used for governance.

I guess you could combine them into the same ledger, but another option would be to have some kind of namespace.

I’m either car, should the leaf include the icrc namespace?

It’s been 3 years… Right on time