ICRC Rosetta v1.2.9 — ICRC-107 Support (Upgrade Required)

Developers
1

We have released ICRC Rosetta v1.2.9 with support for ICRC-107 fee collector blocks.

These new block types are defined in the ICRC-107 Standard (Fee Collector Blocks):

In parallel, the ledger suite pre-release ledger-suite-icrc-2026-02-02 updates the index to correctly surface ICRC-107 blocks.

Why This Is Important

ICRC-107 introduces explicit, standardized, fee collector blocks into ICRC ledgers. Once ledgers adopt ICRC-107, these new block types will begin appearing on-chain. Older versions of ICRC Rosetta (prior to v1.2.9) do not understand these blocks.

As a result:

  • Rosetta may fail to parse new blocks

  • Operation mapping may become invalid

  • The Rosetta node may stop syncing

In short: older ICRC Rosetta versions may simply stop functioning once ICRC-107 blocks appear.

Upgrading to ICRC Rosetta ≥ v1.2.9 ensures continued compatibility.

Who Should Upgrade

  • Exchanges using ICRC Rosetta

  • Custody providers running ICRC Rosetta

  • Block explorers consuming Rosetta output

  • Any infrastructure operator relying on ICRC Rosetta for ICRC ledger ingestion

This update applies only to ICRC Rosetta. ICP Rosetta is not affected.

We strongly recommend upgrading ahead of ledger adoption of ICRC-107 to avoid operational disruption.

If you have questions about the rollout timeline or Rosetta behavior under ICRC-107, please reply in this thread.

2

I’m looking at adding some ICRC 105 blocks to my Motoko ledgers to keep track of installation and upgrade parameters. How do you think Rosetta will handle these? Will it just ignore them or is it going to make it barf?

3

If Rosetta encounters blocks that it doesn’t know it stops (to avoid ingesting relevant stuff without properly digesting it)

4

Is there a GitHub repo where we might be able to send a pull request to define (or explicitly ignore) certain kinds of block?

5

I think our Rosetta repo is not open for external contributions; but what exactly would be the functionality you’d want to implement?

6

I’d just want it to ignore the blocks in icrc-105. I think I need to go back and re do this in light of recent icrc3 discussions, but the goal is to have automated code that puts canister upgrades, and the args, into the blockchain…it also tracks controller changes I believe. ICRC-105 – Enhancing Canister Installation & Configuration Transparency

Basically, ignore blocks with unknown btypes or ops.

7

Ignoring block types that Rosetta does not know about is not really an option: Rosetta should fail in this case to about the backend that uses it going to some inconsistent state from where it’s more complex to recover.

It may be an option to explicitly ignore some block types about it knows that they can be safely ignored.

8

Yes…this basically what would be nice to have…a config value of specific “safe to ignore” block types that hold no account or fee related info.