Summary

This motion authorizes the enactment of runtime-2204 on Astar mainnet. It is phase 1 of 2 in a coordinated migration that moves Astar's collator client from the lookahead Aura consensus to the slot-based Aura consensus variant, with the goal of improving block production consistency and reducing fork-induced reorgs at authoring time following the asynchronous backing migration.

This runtime upgrade alone does not change observable network behavior. It exposes the runtime APIs required for the new consensus variant and prepares the chain for phase 2, a follow-up runtime upgrade expected in approximately 11 days, once collator operators have migrated their binaries to v5.49.1.

Full technical write-up on the forum: Runtime 2204 upgrade: migrating Astar to slot-based Aura consensus for improved fork resistance in block production

Background

Astar enabled asynchronous backing on mainnet on 2025-06-17 via referendum #24, targeting a 6 second block time. Since then, real-world block intervals have drifted from that target, with variance most visible in:

• Block-based timelines slipping in wall-clock terms (governance referenda, dApp Staking eras, inflation cycles)
• Occasional gaps of tens of seconds during relay-chain reorg windows

Investigation on Shibuya testnet identified that the lookahead Aura consensus variant currently used by Astar collators speculatively builds parachain blocks against the relay-chain tip. When the relay chain reorganizes at the tip, that work has to be discarded, contributing to the observed drift.

What changes in runtime-2204

This runtime upgrade introduces the onchain pieces required for the slot-based Aura collation loop. It does not yet change consensus behavior; the relay parent offset stays at 0 during this phase, so migrated and non-migrated collators continue to produce indistinguishable candidates throughout the transition window.

Key changes included in this release:

• Adds two new runtime APIs, RelayParentOffsetApi and GetCoreSelectorApi, required for the slot-based Aura consensus variant
• Sets RelayParentOffsetApi::relay_parent_offset() and cumulus_pallet_parachain_system::Config::RelayParentOffset to 0 (no behavior change at this phase)
• Removes native price usage in dApp Staking and updates the Oracle, OracleMembership, and PriceAggregator pallets accordingly
• Adds routing validation in the XCM precompile and restricts SendXcmOrigin to root

Full changelog: runtime-2204 release notes

Rollout: two governance phases, three operational events

This motion authorizes phase 1 only. The full sequence is:

Phase 1 (this motion):

1. Enact this referendum, then complete the manual activation step that swaps the onchain runtime to 2204 with relay parent offset = 0. Onchain governance event followed by a manual operation. No observable behavior change at activation.
2. After activation, collator operators migrate to client v5.49.1. Off-chain operational event, no onchain action required. Migration progress is tracked via telemetry and the collatorSelection pallet. Expected duration: approximately 11 days.

Phase 2 (separate motion, expected in ~11 days):

3. Runtime upgrade that sets the relay parent offset to 2. Onchain governance event. At activation, slot-based collators begin authoring at relay parent R minus 2.

Important for collator operators: do not upgrade to client v5.49.1 before runtime-2204 is activated on Astar mainnet. Referendum enactment alone is not sufficient; activation is a separate manual operation performed after enactment that swaps the runtime to 2204. The v5.49.1 client depends on the RelayParentOffsetApi runtime API introduced by this upgrade; running it against the current (pre-2204) runtime will cause the collator to stop producing blocks. Binary migration should only begin once runtime-2204 is live onchain, confirmed by the spec version increment.

Expected impact (after phase 2 activation)

• Reduced parachain reorgs caused by relay-tip forks, leading to more predictable block production from the collator perspective
• Approximately 12 seconds of additional latency on incoming XCM messages (outgoing XCM unaffected)
• Approximately 0.5% reduction in usable proof-of-validity space, considered negligible for Astar's typical block contents

Risk considerations

• Phase 1 in isolation carries no operational risk: the offset stays at 0 and no candidate is rejected.
• Collator operators that upgrade to client v5.49.1 before runtime-2204 is activated onchain will stop producing blocks, because the new client requires runtime APIs that do not yet exist. Note that referendum enactment alone does not activate the runtime: activation is a separate manual operation performed after enactment. This risk is mitigated by clear operator communication: the binary upgrade window opens only after runtime-2204 is confirmed live onchain.
• The migration risk in the broader plan sits in phase 2 and is gated by a separate referendum, which will only be initiated once collator migration is independently verified via telemetry and onchain authorship.