TL;DR
This runtime upgrade improves the consistency of block production by removing a major source of relay-tip-induced reorgs at authoring time.
However, this runtime upgrade alone does not eliminate variability in wall-clock block intervals, since relay-chain congestion, backing delays, and inclusion timing can still introduce latency beyond the collator’s control.
Hello everyone,
We’re preparing the next major runtime upgrade for Astar mainnet, runtime-2204, which improves block-production consistency by reducing fork-induced reorgs during authoring after the asynchronous-backing migration. This post explains what’s changing, why it matters, and the staged rollout plan.
Unlike most runtime upgrades, this one is part of a coordinated three-step deployment that requires both a runtime upgrade and a collator client upgrade. Please read carefully if you operate a collator.
Background
Astar enabled asynchronous backing on mainnet on 2025-06-17 via referendum #24. Async backing is a Polkadot-SDK feature that allows parachain blocks to be authored and submitted to the relay chain in parallel rather than strictly sequentially. The expected benefit was higher throughput, more efficient use of relay-chain backing and a shift from a 12s to a targeted 6s block time.
Since that upgrade, real-world block intervals have drifted from the idealized 6s target when measured in wall-clock terms. The drift is most visible in three places:
Time-based estimates derived from block counts have been slipping. Governance referendum timelines, dApp Staking era boundaries, and the inflation reward recalculation cycle all depend on the chain advancing at roughly 6s per block. Because the actual cadence is slower, eras complete later than wall-clock projections suggest, and protocol reward distribution (collator rewards, dApp Staking rewards, treasury allocations) follows the same lag.
The block-time variance itself, not just the mean, has grown. Occasional gaps of tens of seconds appear during relay-chain reorg storm windows.
It’s worth saying explicitly here: governance timelines and eras should not be reasoned about as “days counting.” They are fundamentally block-based for deterministic execution.
Problem
The async-backing drift has several contributing factors and one of them is the consensus variant the collator client uses. Astar’s current production client runs the lookahead Aura consensus, which speculatively builds parachain blocks against the relay chain’s tip. Because the relay chain occasionally reorganizes at the tip, lookahead collators end up building on relay forks that turn out not to be canonical, and the work has to be discarded.
Three specific issues emerge from this:
Relay-tip reorgs invalidate parachain work, particularly within the unincluded segment. The unincluded segment is the queue of parachain blocks that have been authored locally but not yet included on the relay chain. It specifies how many blocks can be proposed in advance before the relay will accept new ones. When a relay-tip reorg happens, blocks in the unincluded segment built on the orphaned relay fork have to be rebuilt against the new canonical fork. The deeper the segment, the more work is at risk during any given reorg.
With 26 collators, each relay reorg cascades into competing parachain candidates at the same height. Every collator builds on the relay tip independently, so a single relay fork sprays parachain forks across many candidates. Chain selection eventually settles, but the time spent racing inflates the wall-clock interval between consecutive canonical blocks.
Lookahead collators sometimes produce duplicate pairs: two blocks built on the same relay parent consecutively. This is consistent with a collator that sees the relay chain forks differently from its peers and rebuilds when its view changes. The effect is that the parachain block number can advance “twice” in a way that doesn’t represent real slot progress, which is misleading both for block-time accounting and for collator reward attribution (since a collator that builds twice on the same relay slot may register that work in ways that don’t reflect actual slot occupation).
Together, in addition to network latency, these create the gap between the 6s target and the observed mean. They are not bugs; they are inherent to building speculatively on the relay tip. The polkadot-sdk team documents this exact failure mode and its mitigation, and our investigation confirmed it applies directly to Astar.
What’s New
The mitigation, per the polkadot-sdk parachain forks guide, is to stop building on the relay tip. Instead, the collator picks a relay parent two blocks deeper, where forks have already settled. This is the slot-based Aura consensus combined with a RELAY_PARENT_OFFSET of 2.
Three coordinated changes make this possible:
This runtime upgrade 2204 that exposes necessary RuntimeAPIs to retrieve relay parent offset collators are expected to build blocks on. The initial offset is set to 0.
Collator client upgrade to v5.49.0. The new client implements the slot-based Aura collation loop, which selects relay parent R−offset when authoring blocks and carries the intervening relay headers as descendants. This is a binary-level change that each collator operator deploys independently, there is no on-chain coordination.
Upcoming runtime upgrade 2205 to set the new offset to 2. The pallet validates that incoming blocks carry the correct number of relay-parent descendants for the configured offset. Once enabled, any collator still running the old lookahead client will produce invalid candidates, which is why the rollout sequence matters.
The expected outcome: parachain reorgs caused by relay-tip forks should be significantly reduced, because by R−2 the relay has already likely settled on one branch. Remaining variance comes from relay reorgs that happen during the backing window (after the parachain block has been built, while it is in flight toward inclusion). These backing-time reorgs can still orphan an already-backed parachain block, but they reduce the chances of the parachain itself to reorg, because the parachain block was built against a relay parent that remains canonical. The orphaned candidate simply has to be re-backed against the new canonical relay state. This is a much milder failure mode than the lookahead-induced reorgs we see today but still produces spikes that adds extra drift to the block time.
This remaining variance is not addressed by the slot-based Aura change itself. It is inherent to relay-chain-driven inclusion latency and asynchronous backing behavior, and therefore requires separate consideration if the goal is tighter wall-clock alignment.
Research and Testing on Shibuya
Before proposing this upgrade for Astar mainnet, we ran an extended investigation on Shibuya testnet over several weeks. The work went through multiple iterations of analysis, with each iteration refining our understanding of the spike mechanism. The investigation was driven by structured data captures (block production traces, inclusion latency, fork detection, segment depth) combined with detailed log forensics on individual spike events.
The headline findings:
-
Build-phase fork resistance - At authoring time, the collator picks a relay parent. Offset=2 means picking R−2 instead of R. By the time the parachain candidate exists, the relay chain has had 12 extra seconds to settle on one canonical branch at R−2, so the relay parent is virtually guaranteed canonical.
Offset=2 fixes this. -
Backing-phase fork resistance - At backing/inclusion time, the parachain candidate is being processed by relay validators at the relay tip (R, R+1, R+2…). If the relay chain reorganizes at the tip during this window, a candidate that was already backed can be orphaned because the backing votes live on a relay branch that didn’t extend.
Offset=2 doesn’t fix this.
The diagram below represents this:
Slot-based + offset=2 substantially reduces parachain reorg incidence by removing relay-tip fork visibility from the collator’s authoring path.
The migration must be sequenced carefully. Deploying the runtime upgrade before all collators have switched binaries causes silent candidate rejection (the runtime guard rejects candidates built without the required descendants) and the affected collators have no visible error path. Telemetry shares every active collator version and the collatorSelection pallet on-chain confirms the last authored block from a collator with descendantsCount > 0 before any runtime change.
Shibuya, with only 5 collators on Paseo testnet, does not predict Astar’s improvement precisely. Paseo’s relay tip reorgs more often than Polkadot’s, and Shibuya’s small collator set produces different rebuild concentration patterns than Astar’s 26-collator set. We expect Astar to see a different (likely larger) improvement than Shibuya did. A detailed technical writeup will be published as a follow-up blog post with concrete before/after numbers from production.
Three-Step Rollout Plan
Because this migration requires both runtime and collator changes, the order is critical. The plan below is designed so that no intermediate state ever causes candidate rejection, and that no collator is financially penalized for migrating early.
Step 1: Runtime upgrade to 2204. This upgrade adds slot-based consensus support to the runtime (new APIs) and sets both RelayParentOffsetApi::relay_parent_offset() and cumulus_pallet_parachain_system::Config::RelayParentOffset to 0. No observable behavior change for users.
Step 2: Collator client upgrade to v5.49.0. Because the runtime API returns offset=0, migrated collators produce candidates indistinguishable from lookahead candidates, and authoring rates remain uniform across the fleet during the transition. Migration progress is tracked via telemetry-reported client version. We expect this window to last approximatively 11days, the duration between the 2 referendums.
Step 3: Runtime upgrade aligning the pallet offset. Once all collators are confirmed migrated, a follow-up runtime upgrade simultaneously sets RelayParentOffsetApi → 2 and RelayParentOffset = ConstU32<2>. At the block this upgrade activates, slot-based collators immediately begin authoring at relay parent R−2 with 2 descendants, and the pallet enforces this configuration. Any collator still running the old binary at this point will produce invalid candidates and must upgrade immediately to resume authoring.
The three-step structure ensures that no misconfiguration can cascade into a chain halt or candidate-rejection storm. Each step is reversible independently, and each step’s safety is verified before the next is initiated. By aligning both the runtime API and the pallet validation at offset=0 in step 1, this plan eliminates the race asymmetry that would otherwise penalize early migrants, removing financial pressure to delay migration.
Tradeoffs
Per the polkadot-sdk guide, building on older relay parents has two known tradeoffs:
XCM message latency increases by 12 seconds. With offset=2, incoming XCM messages from the relay chain or other parachains are processed against a relay parent that is two relay blocks (12 seconds) behind the tip. Messages still arrive and are processed, just on the next available relay parent cycle. This applies to cross-chain transfers, governance messages from Polkadot, and any other XCM traffic.
PoV space is slightly reduced. Carrying the relay-parent descendants in each parachain block consumes a small fraction of the available proof-of-validity budget. The polkadot-sdk guide estimates this at approximately 0.5% of a 10 MB PoV — a negligible amount for Astar’s typical block contents.
We consider both tradeoffs strongly favorable compared to the current drift. 12 seconds of XCM latency in exchange for stable block production and predictable era timing is a clean win.
Impact
More predictable block-production behavior from the collator perspective, with reduced variance introduced by relay-tip reorgs. Governance timelines, era boundaries, and reward cycles remain block-based and deterministic, and their wall-clock interpretation may still vary under relay-chain conditions.
For collator operators: a required binary upgrade to v5.49.0, with no on-chain action needed. The detailed upgrade guide and migration verification instructions will be circulated to all collator operators ahead of step 2. We will not proceed to step 3 until every collator has confirmed migration.
For dApps and integrators using XCM: ~12 seconds of additional latency on incoming XCM messages. Outgoing XCM is unaffected.
For governance: no parameters change in this upgrade beyond the consensus machinery.
Next Steps
Runtime 2204 governance proposal will be submitted to Astar referenda following standard procedure. Collator operators will receive direct outreach with the v5.49.0 upgrade instructions. The follow-up alignment runtime will be proposed once collator migration is verified, expected approximatively 11days (the duration between the 2 referendums) after step 2 begins.
If you have any questions about the migration, the staged rollout, or the testing methodology, please reach out in this thread.
Thank you,
Igor