Update to stable2603

[ggwpez]

Updates all runtimes to Polkadot SDK stable2603. Weights to be updated in a follow up.

Added

• PAH&KAH: Bump ParachainHost runtime API to v16
• PAH&KAH: EVM ERC-20 precompiles for foreign assets
• P&K relay: Add max_relay_parent_session_age with 0 (to be configured via governance)

Changed

• Collectives Polkadot: Waive XCM fees for Fellowship/Ambassador Treasury and Salary pallet origins
• PAH&KAH: Activate TransferAllAssets on pallet_bounties to sweep fungibles from closed bounty accounts

Removed

• P&K relay: Remove CoretimeAssignmentProvider pallet

Migration Check Failures

The remaining failing try-runtime checks for KAH and PAH are from the assets pallet and are caused by bad historic state.

PAH triggers here since there are some accounts with the historic USDT ED of 0.1 instead of 1 cent.
KAH triggers a failure here but I did not check why, we newly added this check for 2603.

Tests

I had to tweak a lot of tests and ignore some. Please sanity check it, we can delete the ignored ones afterwards. done

[github-actions]

Found 5 correctness issues in the runtime upgrade changes.

---

Review Suggestions

system-parachains/coretime/coretime-kusama/src/coretime.rs:102

This new early return Ok(()) makes burn_at_relay a no-op after withdrawing/checking the asset locally, so the XCM burn is never sent to the relay. That changes the function from actually burning relay-side funds to silently succeeding without performing the burn, which can leave accounting/state inconsistent. Restore the relay XCM path or return an error until the new implementation is ready.

---

system-parachains/coretime/coretime-polkadot/src/coretime.rs:102

This early return Ok(()) disables the relay burn flow entirely. The function now reports success without sending the XCM that executes BurnAsset on the relay, so callers will believe the burn completed when it did not. Re-enable the previous logic or fail explicitly instead of silently skipping the operation.

---

relay/kusama/src/lib.rs:1557

Removing type AssignmentProvider = CoretimeAssignmentProvider; from the parachains_scheduler::Config implementation changes how the scheduler sources assignments, while other parts of this diff also replace AssignCoretime with ParaScheduler and remove the CoretimeAssignmentProvider pallet from the runtime. That is a behavioral change in coretime assignment, not a mechanical API update, and it risks breaking parachain scheduling if the new default provider is not binary/behaviorally equivalent. Wire the replacement provider explicitly instead of leaving a TODO in the runtime config.

---

relay/polkadot/src/lib.rs:1340

This removes the explicit AssignmentProvider from parachains_scheduler::Config and leaves only a TODO comment. Because the scheduler drives parachain/coretime assignments, relying on an implicit default here can alter runtime behavior and break assignment compatibility across the upgrade. The replacement provider needs to be set explicitly in this diff, with the same compatibility guarantees the existing comment already calls out.

---

system-parachains/bridge-hubs/bridge-hub-polkadot/src/bridge_to_ethereum_config.rs:125

Most of the snowbridge_pallet_inbound_queue_v2::Config associated types were removed and replaced with type MessageProcessor = ();. If () is only a placeholder, inbound bridge messages will no longer be converted/executed, and the runtime can accept verified messages without actually processing them. This should not ship as a silent no-op; provide the real message processor implementation in the same change or make the pallet fail closed.

[github-actions]

Found 5 correctness issues in the runtime upgrade changes.

---

Review Suggestions

system-parachains/coretime/coretime-kusama/src/coretime.rs:102

This now returns Ok(()) immediately after withdraw_asset, which means the funds are withdrawn locally but never sent to the relay and check_out is never called. That changes the function from 'burn at relay' into a silent local withdrawal/balance loss path. Restore the XCM send + check_out flow, or if this path must be disabled temporarily, return an error before withdrawing the asset so caller state stays consistent.

---

system-parachains/coretime/coretime-polkadot/src/coretime.rs:102

Same issue here: the early return Ok(()) leaves withdraw_asset executed but skips the relay burn and skips AssetTransactor::check_out. The result is that assets can be removed from the stash without the intended side effect on the relay. Move the temporary short-circuit before any withdrawal, or keep the original transfer/burn logic.

---

relay/kusama/src/lib.rs:1466, 1556, 2068

The runtime no longer wires in parachains_assigner_coretime: AssignCoretime was changed to ParaScheduler, AssignmentProvider was removed from the scheduler config, and the pallet was removed from construct_runtime!. Those are behavioral changes, not cosmetic TODOs, and they risk breaking/paralyzing coretime assignment or changing the assignment type/layout expected by the scheduler. This needs to be updated to the new stable2603 API with an equivalent provider, not commented out.

---

relay/polkadot/src/lib.rs:1249, 1339, 1861

The Polkadot runtime has the same coretime assignment regression: the dedicated assignment provider pallet was removed and replaced with TODO comments, while AssignCoretime now points at ParaScheduler. Unless the new upstream API explicitly makes the scheduler the assignment provider, this changes parachain assignment semantics and can break coretime-backed scheduling at runtime upgrade. Reconnect the proper provider according to the new SDK interface instead of leaving these items removed.

---

chain-spec-generator/src/common.rs:29, 68-69

Support for encointer-kusama chain specs was removed from the generator, but the repository still contains the Encointer runtime and related code. That means any existing automation or release tooling that generates this chain spec will now fail with Unknown chain 'id'. If Encointer is intentionally unsupported in this upgrade, remove it consistently from workspace/runtime assets in the same change; otherwise keep the match arm and type import.

[bkontur]

Hey @ggwpez do you have any timeline/plan/idea, when we want to merge an release this? (Just asking, because of other planning)

[ggwpez]

Hey @ggwpez do you have any timeline/plan/idea, when we want to merge an release this? (Just asking, because of other planning)

2603 is not out yet, but once its out I would try to get this merged within 2 weeks (hopefully earlier).
But I am not sure if we would immediately release it or wait for more changes to go in.

What exactly are you depending on? Can also DM me.

[github-actions]

Found 3 correctness issues in the runtime upgrade changes.

---

Review Suggestions

relay/kusama/src/lib.rs:1556, 2068

The parachains_scheduler::Config::AssignmentProvider associated type and the CoretimeAssignmentProvider pallet registration were both removed and replaced with TODO comments. This changes the scheduler wiring rather than just adapting to an API rename, and leaves the runtime without the explicit assignment provider that ParaScheduler/paras scheduling relied on before. If the upstream trait still expects an assignment provider, this either breaks scheduling semantics or silently switches behavior during the upgrade. Restore the concrete provider mapping required by the new SDK API instead of leaving the runtime configuration commented out.

---

relay/polkadot/src/lib.rs:1339, 1861

The coretime assignment provider was effectively dropped here by removing both type AssignmentProvider = CoretimeAssignmentProvider; and the pallet from construct_runtime!, replacing them with comments. That is a consensus-critical runtime wiring change, not a cosmetic update, and can alter or disable parachain/coretime assignment after the upgrade. Wire the new stable2603 scheduler/assigner types explicitly, or keep the previous provider if it is still required.

---

system-parachains/bridge-hubs/bridge-hub-polkadot/src/bridge_to_ethereum_config.rs:125

Setting snowbridge_pallet_inbound_queue_v2::Config::MessageProcessor to () drops the real inbound message handling logic that was previously provided through MessageConverter, XcmExecutor, routing, and account/location conversion types. With this config, verified Ethereum inbound messages can no longer be transformed into executable XCM, so the bridge may accept proofs but fail to dispatch the bridged payloads. Replace the placeholder with the proper processor implementation required by the new pallet API before merging.

[acatangiu]

Can we remove the AHM-related code from runtimes (different PR) to simplify things?

[acatangiu]

One useful "SDK bump integration step" is to have Claude compare the runtimes config update against the Westend runtimes configurations on the respective SDK release branch.

Maybe even create a skill describing (automating) the manual process we're currently doing (1. bump deps, 2. git diff for new configs, 3. git blame sdk, 4. check sdk PR, 5. adapt runtime config here with same/similar logic).

L.E.: this comment should've been a new issue actually, sorry 🙈

[github-actions]

Found 3 correctness issues in the runtime update: two relay runtimes drop the coretime assignment provider wiring, and the new Bridge Hub Polkadot inbound queue v2 config disables message processing.

---

Review Suggestions

relay/kusama/src/lib.rs:1556, 2068

The parachains_scheduler::Config implementation no longer sets type AssignmentProvider, and the CoretimeAssignmentProvider pallet is also removed from construct_runtime!. This is not a cosmetic cleanup: it changes how coretime assignments are sourced and can break parachain/coretime scheduling semantics at runtime. Restore the provider wiring with the new stable2603-compatible type, or add the required migration/compatibility changes before removing the old provider.

---

relay/polkadot/src/lib.rs:1339, 1861

This mirrors the Kusama issue: AssignmentProvider = CoretimeAssignmentProvider was removed and the CoretimeAssignmentProvider pallet was dropped from the runtime without a replacement implementation. Since AssignCoretime was also switched to ParaScheduler, this changes coretime assignment behavior rather than just updating APIs. Reintroduce the correct assignment provider for the new SDK version or include the full migration path proving scheduler compatibility.

---

system-parachains/bridge-hubs/bridge-hub-polkadot/src/bridge_to_ethereum_config.rs:125

Setting snowbridge_pallet_inbound_queue_v2::Config::MessageProcessor to () effectively turns inbound v2 messages into no-ops unless the pallet explicitly special-cases unit. The removed associated types (XcmSender, XcmExecutor, MessageConverter, etc.) were the components that actually converted and executed inbound messages, so this change risks accepting verified messages without dispatching their effects. Wire MessageProcessor to the new stable2603 processor implementation instead of leaving a TODO placeholder in production runtime config.

[github-actions]

Found 3 correctness issues in the runtime upgrade changes.

---

Suggestions that couldn't be attached to a specific line

relay/kusama/src/lib.rs:1556

The parachains_scheduler::Config implementation no longer sets type AssignmentProvider, and the CoretimeAssignmentProvider pallet was also removed from the runtime. This is not just a refactor of names: it changes how scheduler assignments are sourced for parachains while parachains_paras::Config was simultaneously switched to ParaScheduler on line 1466. If stable2603 expects an explicit assignment provider here, leaving it unset changes runtime behavior and can break coretime/on-demand scheduling semantics or storage compatibility. Wire the new provider explicitly according to the SDK migration instead of leaving a TODO in the runtime.

---

system-parachains/bridge-hubs/bridge-hub-polkadot/src/bridge_to_ethereum_config.rs:125

Replacing the entire inbound-queue-v2 processing stack with type MessageProcessor = (); drops the previously configured XCM sender, executor, message converter, and account/location mapping. Unless () is a fully functional processor in this SDK version, inbound Ethereum messages will be accepted but never translated/executed, effectively disabling bridge delivery. Hook this config up to the concrete message processor required by snowbridge_pallet_inbound_queue_v2 instead of leaving the runtime with a placeholder.

[ggwpez]

Can we remove the AHM-related code from runtimes (different PR) to simplify things?

Yes, I can try to merge that in advance.

[github-actions]

Found 4 correctness issues in the runtime and chain spec changes.

---

Review Suggestions

relay/kusama/src/lib.rs:1559, 2071

The scheduler's AssignmentProvider implementation and the CoretimeAssignmentProvider pallet registration were removed but left as TODO comments. This changes runtime behavior, not just wiring: parachains_scheduler::Config no longer names a provider, and the pallet is no longer part of construct_runtime!. If stable2603 still expects the dedicated coretime assigner pallet, this will either break coretime assignment semantics or make the migration incomplete at runtime. Restore the pallet/config or update the runtime to the new API with the equivalent provider type instead of leaving placeholders in production code.

---

relay/polkadot/src/lib.rs:1342, 1864

This has the same issue as Kusama: the dedicated CoretimeAssignmentProvider wiring was removed and replaced with TODO comments. Because these are consensus runtime changes, leaving the scheduler/provider migration half-done can alter parachain scheduling behavior or break compatibility with stored assignments. Replace the TODOs with the actual stable2603-compatible configuration before merging.

---

system-parachains/bridge-hubs/bridge-hub-polkadot/src/bridge_to_ethereum_config.rs:124

snowbridge_pallet_inbound_queue_v2::Config now sets type MessageProcessor = (); // TODO @clara please add while also removing the previous XCM conversion and execution plumbing. Using () here effectively disables message processing for inbound V2 messages, so the pallet can accept verified messages without any runtime path to turn them into XCM effects. Wire in the actual processor required by the new API before enabling this runtime, otherwise Ethereum->Polkadot inbound delivery will silently stop working.

---

chain-spec-generator/src/common.rs:29, 68-69

Support for encointer-kusama chain specs was commented out rather than migrated. That makes the generator reject an existing supported chain type at runtime, which is a behavior regression unrelated to a WIP compile fix. Either port EncointerKusamaChainSpec to the new version or keep the old branch intact until the migration is ready; don't ship the generator with a previously valid prefix removed.

[github-actions]

Found 2 issues in the runtime and test changes.

---

Review Suggestions

relay/polkadot/src/xcm_config.rs:214,220

The new waived-fee origin is built from polkadot_runtime_constants::TREASURY_PALLET_ID, but that constant is the pallet's runtime index, not a stable external location identifier. Pallet indices can change across runtime upgrades, so governance-origin XCMs emitted before or after an index shift would silently stop matching WaivedLocations and start paying fees. Define this location from the actual pallet index via PalletInfoAccess (as done in collectives), or otherwise use a value that is guaranteed to track the runtime's current treasury pallet index.

---

integration-tests/emulated/tests/assets/asset-hub-polkadot/src/tests/teleport.rs:827,841

These teleport tests are now ignored instead of being updated to the new SDK accounting semantics. Because the PR explicitly changes teleport behavior and mentions teleport regressions, removing these assertions from CI drops coverage for exactly the area most likely to break and can let issuance/accounting bugs ship unnoticed. Update the assertions to the new fee calculation model (or narrow the checked invariants if total issuance is no longer stable) rather than blanket-ignoring the tests.

[acatangiu]

FYI: I am currently investigating all the failing and ignored tests following the SDK upgrade - have fixed most, still struggling with some weird bridge failures

[acatangiu]

ignored tests fixed here: #1136

[github-actions]

Found 2 correctness issues in the Asset Hub bounty sweeping changes.

---

Review Suggestions

system-parachains/asset-hubs/asset-hub-polkadot/src/treasury.rs:67-93

The new BountyRelevantAssets list hard-codes only a small subset of assets (DOT, USDT, USDC, DED, MYTH). TransferAllFungibles will only sweep the locations listed here, so any closed bounty account holding other fungible assets will now keep those balances stranded instead of transferring them out as intended. This is especially risky on Asset Hub where bounties can receive many foreign/local assets over time. Use a transfer implementation that sweeps all fungibles held by NativeAndAssets, or derive the set from asset storage/config rather than a fixed allowlist.

---

system-parachains/asset-hubs/asset-hub-kusama/src/treasury.rs:126-140

The Kusama BountyRelevantAssets allowlist has the same problem: it only includes KSM, USDT, and RMRK. After this change, closing a bounty will leave any other fungible assets on the bounty account untouched, which defeats the purpose of enabling TransferAllAssets to sweep closed bounty accounts. Replace the fixed location list with a mechanism that covers all fungible asset classes supported by NativeAndAssets, or at least ensure the sweep source is not limited to a manually curated subset.

[github-actions]

Found 1 issue in the Asset Hub bounty sweep changes.

---

Review Suggestions

system-parachains/asset-hubs/asset-hub-polkadot/src/treasury.rs:66-93

The new BountyRelevantAssets allowlist hard-codes only a small set of assets (DOT, USDT, USDC, DED, MYTH) for TransferAllFungibles. Closed bounty accounts can still hold any other foreign or local fungible asset that was sent there historically or by mistake, and those balances will now remain stranded even though TransferAllAssets is intended to sweep fungibles from closed bounty accounts. Either broaden this to cover all fungibles supported by NativeAndAssets, or document and enforce at the pallet boundary that bounty accounts can never receive assets outside this list.

[sigurpol]

LGTM staking-wise

[claravanstaden]

Looks good! @acatangiu I see you increased the Snowbridge EXECUTION_IN_ETHER in the tests considerably, which made me a bit worried. But I see the actual increase required is closer to 23x than the 8x you increased it to, which is okay I guess, because it is a test. I've made a mental note XCM execution cost increases in this runtime.

[ggwpez]

/merge

[fellowship-merge-bot]

Enabled auto-merge in Pull Request

Available commands

• /merge: Enables auto-merge for Pull Request
• /merge cancel: Cancels auto-merge for Pull Request
• /merge help: Shows this menu

For more information see the documentation