Subject: Update on Draft Standards for RWA Ledger Management: ICRC-122, ICRC-123, ICRC-124 (April 2025)

Developers
1

Hi IC Community,

This post provides an update on the ongoing work on new standards for privileged ledger management, crucial for Real-World Asset (RWA) ledgers, stablecoins, and other compliant token systems on the Internet Computer.

As introduced previously, the Token Standards Working Group is developing:

  • ICRC-122: Privileged Minting and Burning
  • ICRC-123: Freezing and Unfreezing Accounts/Principals
  • ICRC-124: Pausing, Unpausing, and Deactivating Ledgers

Current Status (As of late April 2025):

These standards remain active drafts under development. The primary work and latest proposed specifications can be found in the open Pull Requests on the dfinity/ICRC GitHub repository (links below). Community feedback and refinement are ongoing within the working group.

Reminder: Our Approach (Block Formats, Not APIs)

Our core strategy, consistent with ICRC-3, is to standardize the block formats generated by these privileged actions, rather than prescribing specific API methods.

  • Benefits: This ensures transparency, monitorability, and interoperability. External tools (wallets, indexers, dashboards, etc.) can reliably parse and understand the history of privileged actions across different ledgers by consuming the standardized block log.
  • Minimal & Extensible: The standards define the strictly necessary information about the action and its target (e.g., the account being frozen, the amount minted). Crucially, the block format remains extensible, allowing implementers to include additional, custom data within these blocks if their specific use case requires it.
  • API Flexibility: Ledger implementers choose how to expose these functions via APIs (e.g., freeze_account vs. batch_freeze_accounts), as long as the resulting block adheres to the standard format.

Important Note on Initiator: Please be aware that the current drafts for the base standard block formats focus on what action occurred and to whom/what, but do not currently mandate recording the specific privileged principal who initiated the action within the standardized fields. Implementers needing this level of auditability directly in the block data could add an initiator field as part of the extensible/custom data within the block.

Examples of Block Information (Conceptual - Base Standard)

The draft standards define block structures to capture information like:

  • ICRC-122 Mint/Burn Block: Would likely include fields indicating the target account (to/from), the amount minted/burned, a timestamp (ts), and potentially the standard optional transaction memo (opt blob) if the action mirrors ICRC-1 patterns.
  • ICRC-123 Freeze/Unfreeze Block: Would identify the target account (or principal) being frozen/unfrozen, a timestamp, and potentially an optional reason field (opt text) to explain the action.
  • ICRC-124 Pause/Unpause/Deactivate Block: Would record the change in ledger status (e.g., to paused), a timestamp, and potentially an optional reason field (opt text) explaining the state change.

(Refer to the specific PRs for the exact field definitions in the current drafts).

View the Latest Drafts & Participate:

The most up-to-date versions of these draft standards are available in their respective Pull Requests. We encourage review and feedback directly on GitHub or via the working group channels:

Relevant DFINITY Forum discussions:

We invite continued participation from developers, especially those working with wallets, indexers, DeFi, and RWA solutions, as these standards progress towards finalization.

5 Likes
2

Do we have a specific reason that initiator/caller is not included? Maybe an example of when that information would NOT be important or even essential. It seems like a win for opaqueness.

Worst case it could be set to the canister id to indicate that there is some smart contract initiated action.

3

Given that this information will likely strongly differ between implementations e.g. it could be any of the below or a combination:

  • Another canister
  • Another web2 server that makes the call with a fixed key pair (possibly cycled every few days)
  • Automated process triggered by some threshold within the canister itself

Thus, the authorizer could be a person, organization, automated process or anything else.

For example, some RWA ledgers might record names and emails similar to git instead of a principal since the caller principal is coming from internal web2 infrastructure that might change at any moment without prior notice, making this principal information basically not traceable to any given person or organization.

There’s the following clause within the standard that indicates that even though, the standard does not specify how the authorizer is defined, it should still be specified one way or another (implementation specific).

Any suggestions or ideas on how this can be improved are welcome.

Important Note on Transaction Recoverability: The tx field defined below is intentionally minimal, containing only the data strictly necessary to update account balances, total supply, and provide a basic reason according to the block’s semantics. For full auditability and transparency, ledger implementations compliant with ICRC-122 MUST ensure that the complete details of the original transaction invocation can be recovered independently. This includes, but is not limited to, the principal that invoked the ledger operation (the authorizer/caller), the specific ledger method called (e.g., icrc122_burn), and the full arguments passed to that method. Mechanisms for recovering this data (e.g., via archive queries or specific lookup methods) are implementation-dependent but necessary for compliance. The tx field itself is not designed to hold this exhaustive information.