The work on ICRC-3 refinement has largely converged so we’re planning to submit a motion proposal to update ICRC-3. The text of the motion proposal is as follows:
Motion Proposal: Update to the ICRC-3 Standard
Summary
We propose to replace the currently accepted version of ICRC-3 (Proposal 128824) with the updated version now available in PR #199.
The new version of ICRC-3 refines and expands the standard, clarifying its scope and solidifying it as a domain-agnostic framework for exposing verifiable, append-only block logs on the Internet Computer.
While ICRC-3 was originally designed for ledgers, the revised text generalizes it so it can be used by any canister that emits a sequence of verifiable events — including governance systems, oracle services, and other auditable applications.
Motivation
This update consolidates extensive experience from multiple ICRC ledger implementations and related standards (e.g., ICRC-107, ICRC-122/123/124).
It strengthens the foundation of ICRC-3 by clarifying semantics, improving precision, and making the standard applicable beyond token ledgers.
The changes fall broadly into three categories:
-
Generalization: ICRC-3 is now explicitly domain-neutral, suitable for any certified event log.
-
Clarifications: Tightened definitions and harmonized terminology reduce ambiguity and improve interoperability.
-
Guidance for future standards: The new “Interaction with Other Standards” section defines how new ICRC standards should introduce block types and tx mappings in a consistent, non-colliding way.
Main Normative Changes
1. New or Strengthened Requirements
-
“ts” : Nat" — now required in every block, with defined monotonic semantics (ts[i] ≥ ts[i-1]); previously optional.
-
“btype” — required for standards that define new block types (e.g., ICRC-107, ICRC-123); legacy ICRC-1/2 blocks continue to infer type from tx.op.
-
Genesis block rule — the genesis block MUST NOT include “phash”.
-
Tip certificate — standardized to contain exactly two labeled values:
- last_block_index (leb128 nat)
- last_block_hash (blob).
-
Interaction guidance — new section providing explicit rules for how future standards define block types, tx mappings, and op namespacing.
2. Clarifications and Tightenings
-
Value hashing — clarified that map entries are ordered lexicographically by UTF-8 key bytes, and each item is hashed as hash(key) || hash(value).
-
Value semantics — unchanged core type, but a new non-normative “Common Encodings” section provides interoperable conventions for principals (as Blob), bools (Nat 0/1), and optionals (tagged arrays or omitted map entries).
-
Terminology cleanup — consistent use of producer canister (replacing “ledger” or “producer”) to generalize the standard.
-
Certificate structure — cleaner, more explicit description but functionally unchanged from the previous version.
-
Explicit ledger independence — clarifies that ICRC-3 is a domain-agnostic standard usable for any verifiable event log (not only token ledgers).
-
Legacy blocks — clarifies that for ICRC-1 and ICRC-2, only legacy (untyped) blocks remain valid.
Broader Impact
The refined ICRC-3 provides a stronger, more general foundation for the entire ICRC family of standards. It defines clear guidance for how future standards — such as ICRC-107 (fees), ICRC-122/123/124 (privileged operations), and others — should record state transitions using consistent, verifiable blocks.
By separating structure and verification (ICRC-3) from semantics (higher-level ICRC standards), this version enables a unified, composable ecosystem of auditable on-chain behaviors — from token ledgers to governance systems and beyond.
Call for Adoption
This proposal requests adoption of the updated ICRC-3 as the new canonical version of the standard. Once adopted, this version supersedes Proposal 128824 and becomes the authoritative specification for ICRC-3. Implementers of ICRC-3 APIs and block libraries should align their implementations with this version of the standard.