As the ICRC-3 standard matures, it’s worth reconsidering some core design decisions — particularly how transaction blocks are structured. Two key issues have emerged that point to a lack of principled foundations in the current design and suggest that a revision is warranted. Issue: Dual Formats fo…

Thanks for the insights! I think creating an SDK that integrates cognitive packets into the ICRC-3 standard would be a fantastic way to ensure clarity and efficiency. For example, we could classify transactions by type—such as payments, token transfers, smart contract interactions, and governance a…

Can we do something entirely different. We know that different Candid encoding implementation result in different hashes, however tx blocks can include encoded Candid Blob instead of decoded one. Then the Blob can be hashed easily and will work everywhere. Clients will then decode the Blob and get …

The issue with this in the past is there was a understanding that they could not commit to a deterministic and backwards compatible form at for to_candid, to the extent that I was told not to rely that I’d be able to from_candid my to_candid in the future. This may have resolved itself, but we woul…

[image] skilesare: not to rely that I’d be able to from_candid my to_candid in the future we should be calling that Candid2 if it’s not backwards compatible. The binary blocks allow you to encode different types of transactions with different encoders.

Hi all, Thanks for the insightful discussion so far! I wanted to propose a way to combine the strengths of both Infu’s and Bogwar’s approaches while future-proofing ICRC-3 for AI-driven ecosystems. 1. Canonical Blob Base Layer (Infu’s Idea): Store transactions as encoded Candid blobs: { type: Te…

I think it’s useful to separate what Candid is good for, and what it is not so good for in this context. Candid is excellent as an IDL for method calls: it allows services and clients to evolve independently, and it gives us a human-readable, type-rich way of describing arguments. But those same st…

I’d like to understand better the meaning of cognitive packets. What level of the stack do they target? Do they need to be introduced in ICRC-3 or it’s one layer above? (or below? :slight_smile: ).

To figure out Kurt’s idea it may be useful that I spell out the mental model that I have used to guide my work on the ICRC standards. It is ledger-specific, since most of the standards deal with token ledgers, but it is important to note that ICRC-3 itself is more general. One can also imagine using…

Sorry I go on sometimes like everyone knows what I know without a full explanation and understands, it’s a problem I haven’t solved just yet …Let me clarify what Cognitive Packets (CPs) are and where they fit in the stack. CPs are essentially structured metadata units that sit on top of the canonic…

I feel like I must be overlooking a use case that’s important to you. From my experience writing ledgers, ledger clients, and ICRC-3 implementations, I haven’t yet encountered a practical scenario where protection against transaction malleability provides a clear benefit on the IC - aside from this …

Toward a Cleaner ICRC-3: One Format for ICRC-1/2, Clear Rules for the Future

Developers

bogwar September 24, 2025, 1:13pm 24

I’ve made a forum pos t with the details of the proposed changes to ICRC-3.

Topic		Replies	Views
ICRC-3 Draft v2 and Next Steps Developers	79	3165	April 12, 2024
ICRC-3 Draft and Next Steps Developers community-consideration	9	1066	November 10, 2023
Announcing "Token Standard" as topic of the first meeting of the Ledger & Tokenization Working Group Developers	317	15771	November 26, 2024
Proposed Changes to ICRC-3 – Request for Comments Developers	3	222	October 24, 2025
ICRC-1 Token Standard final draft Developers	40	3834	February 28, 2023

Toward a Cleaner ICRC-3: One Format for ICRC-1/2, Clear Rules for the Future

Related topics