Totally agree with you !
the more explicit the tx structure, the less room for interpretation. ICRC-1/2 is simple enough that there aren’t many ambiguous fields, but ICRC-107’s icrc107_fee_collector is a perfect example.
This is exactly where Cognitive Packets help: they attach a semantic layer to each field, making roles, types, and constraints explicit. Machines (and future AI agents) can then interpret transactions unambiguously, without affecting the canonical ledger or consensus.
Thanks for letting us know. Makes sense now. Perhaps we should convert the old get_transactions into icrc as well and keep it working the same way as now, it seems to be better for on-chain clients. This way icrc3 can focus on off-chain clients and their needs
AFAICR that was indeed the separation we were going for: icrc-3 for off-chain transaction history fetching and get_transactionsfor fetching transactions on-chain, but the latter never got standardized, in part beacuse fetching blocks with icrc-3 methods provides all of the information that get_transactionsdoes (in a potentially less friendly way, if I understand correctly your remark)