A test release with two defensive boundaries
Parity Technologies published Polkadot SDK's stable2609-rc1 release candidate on September 4. The package brings together changes developed between the stable2606 and stable2609 branches, including an additional Snowbridge origin check and a repair for transaction tracing during finalized-block replay. These are implementation changes for developers and network teams to test, not evidence that every Polkadot-based chain has installed them.
The release page is unusually direct about that boundary. It labels the build a pre-release for testing and warns that errors or unexpected behavior remain possible. It also identifies 87 changes as breaking under Rust semantic-versioning rules, meaning at least one affected software crate requires a major version change. That count does not prove 87 user-facing disruptions, but it signals meaningful integration work for teams that compile runtimes, node software or supporting services against the SDK.
An origin check close to the asset boundary
The Snowbridge change concerns how an outbound message's origin is represented before instructions move toward Ethereum. Snowbridge connects Polkadot and Ethereum through onchain verification, relayers and system-chain components. Within that path, software must preserve not only what a message requests but also which account or privileged location is allowed to request it. If origin information is transformed incorrectly, valid instructions and unauthorized ones can become difficult to distinguish.
Polkadot's Cross-Consensus Messaging format, commonly called XCM, provides instructions and location descriptions used across connected systems. An alias operation can permit one recognized location to act through another representation when the configured rules allow it. That flexibility is useful for interoperability, but it makes the allowlist around sensitive identities a security boundary. A broad alias rule should not let an ordinary signed user present itself as a system-level location.
Pull request 12159 changes the relevant Snowbridge outbound configuration so that the Asset Hub location is explicitly excluded from origins that may be created through this alias path. Its review history separates two tests. An early integration test failed at an upstream check before reaching the new AllowedAliasOrigin filter, so it could not demonstrate that local refusal rule. Before the July 10 merge, developers added a direct converter unit test for the Asset Hub exclusion and renamed the integration test to describe the upstream origin-leak regression it actually exercises. The unit test is the targeted evidence for the new filter; the separate regression test covers an earlier boundary in the route.
The developers describe the check as defense in depth against a possible upstream XCM regression. That distinction is material. The record does not report that someone exploited Snowbridge or controlled the agent account. Instead, the local converter gains an additional refusal rule so that a failure elsewhere does not automatically become authority at the bridge's primary agent account, which is derived from Asset Hub's root location and holds ERC-20 assets. It is the software equivalent of checking an identity again at the vault, even when an earlier checkpoint is expected to have done so.
Why layered checks improve interoperability
Cross-system infrastructure depends on assumptions made by several components maintained and upgraded on different schedules. A sender is interpreted by an XCM configuration, passed into bridge logic, converted into another system's message and ultimately associated with actions on Ethereum. Correctness at one layer cannot permanently guarantee correctness at every later layer, especially as types, filters and routing behavior evolve.
A narrow check near the consequential action reduces that dependency. It does not replace upstream authorization or prove the whole bridge secure. It limits one specific failure path by refusing to derive the protected agent identity through an alias operation. This kind of local invariant is valuable because reviewers can describe it precisely, encode it in a test and preserve it when surrounding components change.
The benefit is practical for users even though they never see the converter. Bridges support applications that need assets or instructions to move between otherwise separate networks. Their reliability depends on preserving authority across that boundary. Adding a focused check can make a future regression less likely to reach held assets, provided the correct runtime adopts the code and the test continues to cover the deployed configuration.
Replaying a block without losing its tail
The second change addresses a different kind of integrity: whether developer tools faithfully reproduce transactions that already succeeded in a finalized block. Transaction tracing re-executes operations so developers, explorers and diagnostic services can inspect contract calls, storage access and failures. A trace is an analytical reconstruction. It should not silently omit successful transactions merely because replay accounting differs from the original block execution.
Pull request 12374 documents how that mismatch occurred. Each extrinsic, Polkadot's term for an externally submitted or system-generated operation, can initially be charged for a worst-case proof size. Proof size estimates how much state evidence an operation may require. During normal block production, a recorder observes the state actually read, allowing unused weight to be reclaimed. The replay path lacked that recorder, so worst-case charges accumulated rather than being reduced.
Once the accumulated proof-size charge crossed the block limit, the replay could reject later transactions with a resource-exhaustion error even though those same transactions had succeeded in the finalized block. Runtime tracing interfaces could then lose the rejected tail. The blockchain's finalized history was not being reversed or altered. The defect affected the diagnostic reconstruction and could give developers an incomplete account of the block.
The merged fix introduces an unsafe-gated state_callRecorded method that runs the relevant call with a proof-size recorder. Here, unsafe-gated is an access classification for a node interface, not a statement that the repaired calculation is inherently unsafe. Node operators decide whether to expose such methods because they can carry operational cost or access implications. When a stored recording exists, the method reuses it to match the block's execution more faithfully; otherwise, it can use a fresh recorder.
Per-transaction status replaces an inference
Pull request 12374 also established compatibility fallbacks for nodes that lack the recorded-call method or refuse unsafe remote procedure calls. The Ethereum-compatible RPC layer could use the older trace path and mark the block-level result as degraded. That historical mechanism made an infrastructure limitation visible, but it still required the RPC layer to infer which omitted transaction had not been traced.
The release candidate includes a later follow-up, pull request 12796, merged on August 19. Its versioned runtime results carry a status for each relevant transaction: a completed trace, an explicit not-traced result, or no trace entry when there was nothing to trace. The Ethereum-compatible RPC prefers that newer result, so block tracing can return an error alongside the affected transaction hash and transaction tracing can return an error instead of misreporting the trace as not found. Older interfaces retain the block-level degraded fallback.
This sequence matters. The recorder and stored-recording reuse from pull request 12374 address why replay accounting could exhaust resources. The follow-up changes how the assembled candidate reports a transaction that still cannot be traced. The project repository supplies implementation tests for these paths, including versioned results and fallbacks. They are not independent performance measurements, a security audit or evidence from production networks.
Merged code is not deployed code
The Snowbridge restriction was merged on July 10, the recorded replay repair on August 3 and the per-transaction reporting follow-up on August 19. Their appearance in stable2609-rc1 shows that the code entered a packaged testing milestone. It does not activate the changes through a governance decision or update nodes already running on Polkadot, Asset Hub or another SDK-based network.
Polkadot SDK is a construction set used by multiple networks and runtime teams. Each integrator must examine breaking interfaces, build compatible components, test its configuration and follow its own deployment process. A release candidate can reveal integration failures before a stable release, which is progress in itself. Treating it as production would erase the purpose of that testing stage.
The strongest lesson from stable2609-rc1 is therefore operational. Infrastructure becomes more dependable when authority is checked again near valuable assets and diagnostic tools disclose when they cannot reproduce history faithfully. Both changes turn broad safety goals into bounded software behavior. Their real-world effect will depend on final release quality, network adoption and continued testing across the configurations that Polkadot SDK supports.