Summary

This motion authorizes the enactment of runtime-2206 on Astar mainnet. It is phase 2 of 3 in the migration of Astar's collator client from the lookahead Aura consensus to the slot-based Aura consensus variant, following runtime-2204 which exposed the required runtime APIs.

This upgrade sets the relay parent offset to 1 for slot-based block production only. The runtime does not yet enforce descendant validation on incoming candidates; that activation is deferred to phase 3. The intermediate step gives collator operators a graceful migration window during which legacy and slot-based collators continue to coexist without candidate rejection.

Preimage: 0x4aa2f4ca38616c35e54e10e9adce202f8fa84433680e092165223da8bd2b81d7

Forum post: Runtime 2204 upgrade: migrating Astar to slot-based Aura consensus for improved fork resistance in block production

Full changelog: runtime-2206 release notes

What changes in runtime-2206

• Sets relay parent offset to 1 for slot-based block production only. Collators running client v5.49.0 or later will begin authoring blocks at relay parent R minus 1, with one descendant carried in the parachain block. The runtime does not yet validate this on incoming candidates, so collators still running the legacy lookahead client continue to produce valid blocks.
• Removes the pallet_assets chain extension. Breaking change for any ink! smart contract that interacts with pallet_assets via the chain extension interface. Direct extrinsic calls and EVM precompile access to pallet_assets are unaffected.
• Removes Shibuya beta pallets pallet_unified_accounts and pallet_ethereum_checked. No impact on Astar mainnet, as these pallets are not deployed on Astar.
• Fixes runtime benchmarks. Internal correctness fix, no user-visible behavior change.

Three-phase rollout

The slot-based Aura migration is sequenced across three on-chain governance events. The plan was refined from two phases (as originally communicated with runtime-2204) to three following the rollout pattern proven on Shibuya testnet, in order to avoid any risk of candidate rejection during the collator binary migration window.

• Phase 1: runtime-2204 (enacted). Exposed RelayParentOffsetApi and GetCoreSelectorApi, with the relay parent offset held at 0.
• Phase 2: runtime-2206 (this motion). Sets the relay parent offset to 1 for block production. The runtime does not yet validate candidate descendants, so legacy and slot-based collators coexist.
• Phase 3: future runtime (separate motion, once collator migration is confirmed complete). Activates runtime validation of relay parent descendants and required inherent data. After this phase, any collator still running the legacy lookahead client will produce invalid candidates and must upgrade to resume authoring.

Expected impact

• Reduced parachain reorgs caused by relay-tip forks, for any collator producing blocks at offset 1.
• Approximately 6 seconds of additional latency on incoming XCM messages processed by slot-based collators (outgoing XCM unaffected).
• Negligible reduction in usable proof-of-validity space, due to descendant headers carried in each parachain block.
• Breaking change for ink! contracts using the pallet_assets chain extension; affected developers should migrate to direct extrinsic or precompile access.

Risk considerations

• Runtime-2206 itself carries minimal operational risk: candidate validation is not yet enforced, so a mixed fleet of legacy and slot-based collators is tolerated by design during this phase.
• Collator operators that have not yet upgraded to client v5.49.0 should plan their migration during this phase. Detailed operator instructions and the activation signal will be circulated separately.
• The pallet_assets chain extension removal is a known breaking change for a narrow set of ink! contracts. Builders should verify their integration before this runtime activates.