Repository navigation
Chore update polkadot-sdk to stable2603 - #3746
Merged
Merged
Conversation
Draft tracker carries forward Included rows from stable2512 with TBD commit hashes; rows whose upstream PR is expected to be in stable2603 are pre-marked Dropped pending merge-base verification. UPGRADE doc is a temporary checklist covering forks, moonbeam Cargo.toml swap, benchmarks, bridge regen, migrations, and verification.
Resolved upstream bases for polkadot-sdk, evm, ethereum. Two new blockers: polkadot-evm/frontier has not branched stable2603 yet, and Moonsong-Labs/moonkit has no stable2603 base-bump PR. Also noted frontier #1856 is now in upstream/master (tracker said "PR not merged"); needs correction during verification.
We will author the upstream base-bump PRs ourselves rather than wait on polkadot-evm/frontier and Moonsong-Labs/moonkit. Adds Phase 1.4a (moonkit) and Phase 1.5a (frontier) covering the upstream branches we own, and notes the rebase plan once polkadot-evm cuts an official frontier stable2603.
Branch moonbeam-polkadot-stable2603 pushed with 4 cherry-picks on top of polkadot-stable2603-1. Three previously-Included rows were verified to be in stable2603 upstream and are now Dropped in the tracker: charge_transaction_payment benchmark fix (#10444), storage benchmark --keys-limit, and pallet-revive removal from pallet-xcm. PrecompileWasmCmd needed an adaptation for stable2603's BackendRuntimeCode::new(state, TryPendingCode) signature change.
manuelmauro
added
B7-runtimenoteworthy
Contributor
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughBumps workspace git pins to moonbeam-polkadot-stable2603; migrates XCM TransactAsset APIs to AssetsInHolding with NotionalImbalance; updates runtime/EVM call signatures, node lazy-loading/manual-seal wiring, XCM executor configs, mocks, derives, and tests. ChangesStable2603 Upgrade & XCM Asset Holding Migration
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
The tracker `polkadot-sdk-stable2603.md` was assembled from the prior cycle's tracker plus known deltas — it is not guaranteed to capture every cherry-pick that has actually landed on each fork's `moonbeam-polkadot-stable2512` branch. Insert a pre-Phase-1 audit that enumerates every commit unique to `origin/moonbeam-polkadot-stable2512` for each fork (polkadot-sdk, frontier, evm, ethereum, moonkit) and reconciles it against the tracker, so undocumented cherry-picks surface and get rows added before re-application starts. Parallelizable via one sub-agent per fork.
Run the Phase 0.5 audit against `origin/moonbeam-polkadot-stable2512` on each fork using PR-number set-difference — raw SHA-diff is misleading because both we and upstream apply the same backport PRs under different SHAs. Findings per fork: * polkadot-sdk — 106 of 108 PR refs on our fork are also on upstream/stable2512 (they will inherit on rebase). Three new rows for the genuinely moonbeam-only commits: weight reclaim log improvements, an xcm-emulator BlockProducer trait override for Nimbus, and a bridges GRANDPA-justification experiment plus its revert. * frontier — upstream/stable2512 has been frozen since 2026-01-13, so all 35 fork-only commits are moonbeam-authored. Six new rows (#1881 logs journal memory bound, #247 CI triggers, canonical hash mapping repair, Saturate U256, configurable tx gas-limit cap, MBF ethereum fork pin) and three tracker corrections: row #1820 flipped from `Applied: No` to `Yes` (commit IS on the branch); rows previously listing PRs #1794 and #1787 corrected to #1824 and #1862 (the PR numbers were typos for what is actually on the branch). * evm — one moonbeam-authored commit (MBF ethereum fork dependency pin) added as a row. * moonkit — one row for upstream PR #94 (relay offset dynamic); revisit during Phase 1.4 once the moonkit base-bump lands. UPGRADE-stable2603.md gets the methodology note explaining why we use PR-number set-difference, a per-fork results table, and a Phase 2 follow-up list for rows still TBD on Included vs Dropped.
Sixteen rows in the stable2603 and stable2512 trackers carried no commit SHA and described upstream PRs that landed on our fork via merging upstream/stable2512, not via moonbeam cherry-picks. The Phase 0.5 PR-number set-difference confirmed every one of them is also on upstream/stable2512 — they do not belong in a cherry-pick tracker. stable2506 keeps its rows for the same PR numbers because there every row carries a real moonbeam-foundation commit SHA and `Cherry pick: Included` — those were genuine cherry-picks of that release cycle, not upstream content carried over.
Operational changes on the polkadot-sdk fork branch:
1. Rebase `moonbeam-polkadot-stable2603` from the
`polkadot-stable2603-1` tag onto `upstream/stable2603` head
(`afb51b7a8c6`), absorbing four upstream backports past the tag
(#11964, #11856, #11987, #12017).
2. Cherry-pick the two Phase 0.5 finds that were missing from the
branch:
- `improve weight reclaim logs (call metadata, warn level)` →
`161cd252773`.
- `xcm-emulator: make slot/digest producer overridable for
non-Aura parachains` → `beaf6b6c50a`. Trivial additive conflict
with stable2603's `native_total_supply_tracker` macro arm,
resolved by keeping both arms.
Doc updates:
- Refresh the six polkadot-sdk row commit hashes in
`polkadot-sdk-stable2603.md` to match the post-rebase SHAs.
- Extend the Phase 1.1 checklist in `UPGRADE-stable2603.md` with the
two new cherry-picks plus an explicit `Drop` for the bridges
GRANDPA retry experiment that was reverted on stable2512.
manuelmauro
force-pushed
the
chore-update-polkadot-sdk-stable2603
branch
from
May 8, 2026 10:49
4e7949e to
87c1d45
Compare
…write Rewrote the commit messages of all six cherry-picks on `moonbeam-foundation/polkadot-sdk:moonbeam-polkadot-stable2603` to explain *why* each cherry-pick exists, not just *what* it does. In particular, the auto-generated "Merge pull request #8" subject was replaced with a real description of the pallet-parameters benchmark fix. Each rewritten message now mirrors the context that lived only in the moonbeam tracker, so the polkadot-sdk fork is self-explanatory to anyone reading `git log` without the tracker open. The rewrite changed all six SHAs. Update the tracker's commit links and the Phase 1.1 checklist in `UPGRADE-stable2603.md` to point at the new SHAs.
manuelmauro
force-pushed
the
chore-update-polkadot-sdk-stable2603
branch
from
May 8, 2026 10:58
5353713 to
27487be
Compare
…2603 The row in `polkadot-sdk-stable2603.md` claimed `Applied: Yes` and `Dropped but needs refactoring` against `paritytech/polkadot-sdk#9214`, but that PR was never cherry-picked — the stable2506 tracker noted "Not found on the branch — may not have been carried over". The relevant code (`ParachainTracingExecuteBlock`) reaches stable2603 via upstream's own backport of `#9871`, which superseded `#9214` (the prdoc shipping at `prdoc/stable2509-2/pr_9871.prdoc` is upstream's own metadata). It is pure upstream content, not a moonbeam cherry-pick, so it does not belong in the active-cycle cherry-pick tracker. The moonbeam-side follow-up — wiring `Some(Arc::new(ParachainTracingExecuteBlock::new(...)))` into the parachain service — is already captured in the Phase 3 checklist of UPGRADE-stable2603.md, so no information is lost. The matching row in `polkadot-sdk-stable2512.md` is preserved for historical reasons: it documents `moonbeam-foundation/polkadot-sdk#20`, the attempted cherry-pick of `#9214` that was eventually superseded by upstream's `#9871`. Same policy as the named cherry-pick rows in `polkadot-sdk-stable2506.md`.
manuelmauro
force-pushed
the
chore-update-polkadot-sdk-stable2603
branch
from
May 8, 2026 11:16
8a0042f to
402ca09
Compare
Created `moonbeam-polkadot-stable2603` on `moonbeam-foundation/ethereum`. Since `rust-ethereum/ethereum`'s master has not advanced past the merge-base with our `moonbeam-polkadot-stable2512` branch (`d7bdf2888253a30f160d434688e378636e253870`, which is also master's head), the new branch shares the same tip SHA as stable2512 (`58a5a8a`) — the only commit ahead of upstream is the unmerged rust-ethereum/ethereum#77 cherry-pick, which is preserved as-is. Tick Phase 1.3 boxes in UPGRADE-stable2603.md and replace the `TBD` placeholder in the ethereum row of `polkadot-sdk-stable2603.md` with the actual commit link.
Created `moonbeam-polkadot-stable2603` on `moonbeam-foundation/evm`. Upstream `rust-ethereum/evm` has moved to v1.0; the moonbeam fork stays on the 0.43.x line and there is no new upstream commit to pull. The new branch shares the same tip SHA as stable2512 (`bb9cdde4`) so both moonbeam-only commits — `a656db90` (the EIP-7939 CLZ-opcode cherry-pick of rust-ethereum/evm#400, which was merged upstream only on v1.0) and `bb9cdde4` (the MBF ethereum fork dep pin discovered in Phase 0.5) — are inherited as-is. Tick Phase 1.2 boxes in UPGRADE-stable2603.md and replace the `TBD` placeholder in the EIP-7939 row of `polkadot-sdk-stable2603.md` with the actual commit link.
…3 and stable2512 The "Refactor transaction signature validation" row referenced rust-ethereum/ethereum#75, which is merged into upstream master at `d7bdf28` — exactly the merge-base for our `moonbeam-polkadot-stable2603` and `moonbeam-polkadot-stable2512` branches. The change is therefore on our branches via upstream, not via cherry-pick. The row carried no commit SHA and no moonbeam-side PR link, and the `Applied` field disagreed across cycles (`No` in stable2603, `Yes` in stable2512). It was not documenting a moonbeam cherry-pick action, so it does not belong in either active or recent cherry-pick tracker — same policy as the bulk of the upstream-only Backport PR rows we removed earlier. stable2506 keeps its version of the row because there it carries a real `[moonbeam-foundation/ethereum@933ccae]` commit reference: that documents the actual moonbeam-side work — a fork commit was prepared, never applied (Applied: No, Cherry pick: Included), and the PR was eventually merged upstream, making the cherry-pick moot. That is the historically meaningful record; the 2512/2603 copies had lost the SHA and only kept a now-redundant pointer to the upstream PR.
Created `moonbeam-foundation/frontier:moonbeam-polkadot-stable2603` on top of `upstream/stable2603` (`baf505d8f`) with 12 cherry-picks and one manual `Cargo.toml` dep-redirect commit: - Cherry-picks (#247 CI triggers, #1546 withdraw-ability, #1547 ethereum execution info, #203 dispatch-error decoding, #1564+#224 squashed tx-size, #244 POV underestimations, #1568 lru_cache, #252 parity-db migration, frame-metadata, #254 validate tx size, Saturate U256, canonical hash mapping repair). - One conflict on POV Underestimations (resolved by keeping stable2603's `match` block while adding `mut`); one trivial conflict on parity-db migration (kept upstream's deref form). - Manual dep-redirect commit replaces the prior cycle's two cherry-picks (CI branch ref + MBF ethereum fork pin), pointing polkadot-sdk, ethereum, and evm at moonbeam-foundation forks on the `moonbeam-polkadot-stable2603` branch. Phase 0.5 follow-ups resolved: - 17 frontier PRs were inherited from `upstream/stable2603` (it was cut from the same master commit that absorbed our Phase 1.5a base-bump as PR#1892); their tracker rows are now confirmed `Dropped, PR Upstream Merged`. - Three Phase 0.5–added rows flipped from TBD/TBD to Dropped: #1881 logs journal memory, #1856 latest-on-pruned, and the no-PR "Make tx gas limit cap configurable" (upstreamed as `b2088f29b`). Side effect: `moonbeam-foundation/evm:moonbeam-polkadot-stable2603` bumped to `7dd6ecc6` so its `ethereum` dep points at the stable2603 branch (was stable2512). Without this, cargo pulls in two distinct versions of the `ethereum` crate when frontier consumes both. Phase 1.5a is also marked complete because upstream merged our DIY base-bump as polkadot-evm/frontier#1892 and cut `stable2603` from the resulting master commit; our local `mb/polkadot-sdk-stable2603` branch was redundant and has been dropped. `cargo check --workspace` on the new frontier branch is clean (one harmless unused-const warning from the dispatch-error cherry-pick).
- Add an evm row for the `delegation.rs` test-module fix (moonbeam-foundation/evm@a122857), upstreamed as rust-ethereum/evm#405. - Correct the EIP-7939 row: PR #400 merged into `rust-ethereum/evm:v0.x`, so it is inherited from the upstream base, not a moonbeam cherry-pick (`Included` -> `Dropped`). Fix the matching "v1.0 only" claim in the Phase 1.2 plan.
Create moonbeam-polkadot-stable2603 off the open base-bump PR head (mb/polkadot-sdk-stable2603, PR #95) to unblock moonbeam Phase 3 while the upstream review is pending. PR #95 is linearly main + base-bump, so the release branch already equals what it would be cut from the merge commit; reconcile once #95 lands in main. Verified the moonkit cherry-pick table: #92 (using_fake_author) and #94 (make relay offset dynamic) are both inherited from main, so no extra cherry-picks are needed. Flip the #94 TBD row to Dropped/PR Merged and add the #95 link to the base-bump row.
…al drift Phase 3 of the polkadot-sdk stable2512 -> stable2603 upgrade. - Cargo.toml: repoint all 180 fork deps to the moonbeam-polkadot-stable2603 branches (polkadot-sdk, frontier, evm, ethereum, moonkit). - Cargo.lock: re-resolved to stable2603. moonkit bumped to ba06fb0 (which redirects its polkadot-sdk/frontier deps to the moonbeam-foundation forks), unifying the tree on a single SDK source and eliminating a duplicate polkadot-sdk (canonical paritytech alongside the fork) that caused E0221/ E0308 ambiguous-associated-type errors. - Drop removed crate cumulus-client-consensus-proposer (upstream PR #9947 folded it into sp-consensus/sc-basic-authorship); it was an unused dependency. - Bump num_enum to 0.7.6 to satisfy frontier fp-evm's new ^0.7.6 requirement. - RuntimeDebug -> Debug across 51 sites / 14 files (upstream PR #10582 removed RuntimeDebug from sp_core/sp_runtime/frame_support; it is now plain Debug). - pallet_evm Runner::call: add the new state_override argument (8 call sites). Known remaining: erc20-xcm-bridge and moonbeam-foreign-assets need migrating to the credit-based AssetsInHolding model (stable2603 XCM redesign); tracked separately.
Scope-mapping checkpoint. stable2603 reworked AssetsInHolding to hold fungible::Credit imbalances instead of Asset descriptors; the WeightTrader, TransactAsset and FeeManager trait surfaces moved with it. Mechanical fixes applied: - TransactAsset::internal_transfer_asset now returns Result<Asset> (was Result<AssetsInHolding>); drop the .into(). - FeeManager::handle_fee now takes AssetsInHolding (was Assets). todo!()-stubbed pending the real credit-based migration (tracked): - erc20-xcm-bridge / moonbeam-foreign-assets: deposit_asset, withdraw_asset. - xcm-weight-trader: buy_weight, refund_weight, and the Drop fee re-deposit. These stubs let the compile-fix loop proceed past the XCM pallets to reveal the runtime-layer drift. DO NOT SHIP without completing the migration.
Runtime-integration fixes that get all three runtimes compiling.
B — signature drift in the shared runtime macros (runtime/common):
- pallet_evm Runner::call gained a state_override (Geth-style) argument; thread
it through apis.rs (API call + tracing call) and impl_xcm_evm_runner.rs.
- fp_rpc EthereumRuntimeRPCApi::call gained a state_override parameter.
- SessionKeys::generate_session_keys now takes an owner and returns
OpaqueGeneratedSessionKeys (V2).
C — cumulus_pallet_parachain_system::WeightInfo gained three methods
(block_weight_tx_extension_{max_weight,stays_fraction_of_core,full_core});
add them (Weight::zero, matching upstream) to all three runtime weight files.
XCM Config — stable2603 merged asset claiming into the trap config: AssetClaims
was removed from xcm_executor::Config and AssetTrap must now also implement
ClaimAssets. Implement ClaimAssets for AssetTrapWrapper (delegates to the inner
claimer; erc20 assets are filtered on drop so plain delegation is correct) and
drop the now-invalid type AssetClaims from each runtime's xcm_config.
Gets moonbeam-service compiling; with this, cargo check --workspace passes on default features. - sc_service/cumulus BuildNetworkParams gained spawn_essential_handle. - new_full_parts_record_import gained a pruning_filters argument. - sc_client_api::CallExecutor::runtime_version gained a call_context param; Backend::set_block_data gained a register_as_leaf param (lazy-loading impls). - moonkit: NimbusManualSealConsensusDataProvider dropped its _phantom field; MockValidationDataInherentDataProvider gained relay_parent_offset. - Proof-recording refactor (upstream #9947): sp_consensus::Proposer lost its Proof associated type and Proposal lost its proof field. Rewrite the lazy-loading manual-seal (run_manual_seal/seal_block) to mirror upstream: drop the P generic, record the storage proof via a ProofRecorder wired into the proposal extensions, and drain it after proposing.
moonkit PR #95 (polkadot-sdk stable2603 base bump) merged into main; the moonbeam-polkadot-stable2603 branch was rebased onto main and is now main + the dep-redirect commit. Re-pin Cargo.lock ba06fb0 -> 9d71129 (content-identical tree, branch ref unchanged).
moonkit #95 merged to main 2026-06-18 (squash 4088d76); the moonbeam-polkadot-stable2603 release branch was rebased onto main and moonbeam re-pinned to it. Tick Phase 1.4/1.4a, resolve the moonkit risk, and refresh the stale 'awaiting merge' / 'reconcile when' notes.
Verified frontier + polkadot-sdk cherry-picks against upstream/stable2603 via parallel sub-agents. - frontier: all 13 Included SHAs confirmed present + moonbeam-only; all 18 Dropped/PR-Upstream-Merged 'Verify' rows confirmed in upstream/stable2603; **Verify** flags replaced with confirmation notes. - polkadot-sdk: all 9 Included SHAs confirmed; added the missing ddba2453 row (completes the weight-reclaim-logs cherry-pick b0b4fd52a9e by adding the GetCallMetadata bound to the benchmark where-clause). - Fixed frontier #1856 note: cited 54396433 (the stable2512 cherry-pick) instead of the upstream/stable2603 commit 46cf7a43e. - Ticked Phase 0.5 deferrals and Phase 2 checkboxes in the upgrade plan; header updated to reflect verification complete.
The runtime spec_version bump is a separate release step, not part of the polkadot-sdk upgrade process. Remove it from the Phase 4 checklist and retitle the phase (Runtime, weights, migrations).
Local verification after the moonkit re-pin (2026-06-18): - cargo check matrix (default / runtime-benchmarks / try-runtime): all clean. - cargo test --workspace --no-fail-fast: 1347 passed / 0 failed across 134 suites (incl. moonbase/moonbeam/moonriver integration_test + xcm_tests). - TS dev fixtures touched by the upgrade (D010105, D010701, D022749): pass. - PrecompileWasmCmd subcommand present in the built binary. Smoke (live endpoints) and full zombienet XCM are flagged CI-only.
Remove now-stale claims after Phases 1-3 and Phase 6 completed: - Context: starting pin migrated (Phase 3); moonkit #95 merged; all five forks now have a moonbeam-polkadot-stable2603 branch. - Phase 3: drop the 'TS fixtures pending' qualifier; fixtures ran in Phase 6. - Risks: verification-cost item resolved by Phase 2.
Weights: only cumulus_pallet_parachain_system gained 3 WeightInfo methods, added as Weight::zero() stubs; their sole consumer (DynamicMaxBlockWeight tx-extension) is not wired into moonbeam, so the stubs are safe and no benchmark run is required. No weight regressions. Migrations: none added; migrations.rs unchanged, lists empty. SDK-pallet storage-version validation deferred to the try-runtime step.
…innet)
Lazy-loading is moonbeam-only, so it can't target moonbase. Ran it forking
moonbeam mainnet #16090736 with the new runtime override (4500 vs live 4303):
on_runtime_upgrade executed and 15 blocks imported cleanly, no panics. Caveat:
lazy state under-fetch treated many pallets as fresh-init ('new pallet detected')
rather than migrated, so per-pallet migrations weren't fully exercised. The
earlier try-runtime (moonbase) attempt was stopped mid-scrape. Authoritative
migration validation (full try_state) still open.
create-snapshot vs moonbase was still enumerating keys after a full 10 min (phase 1 of 2, never completed) — public-RPC scrape is impractical locally. Decision: skip the local full try_state, defer to CI. Residual risk low (weights clean, migration lists empty, lazy-loading upgrade green on live mainnet state). Phase 4 closed locally.
stable2603 bumps cumulus-pallet-xcmp-queue STORAGE_VERSION 5 -> 6 (OutboundChannelDetails in OutboundXcmpStatus gains a `flags` field). MigrateV5ToV6 is a standalone VersionedMigration that the pallet does NOT auto-run in its hooks; upstream parachain runtimes wire it explicitly. Moonbeam's migration lists were empty, so on-chain XcmpQueue (v5) would not migrate and OutboundXcmpStatus would fail to decode against the v6 layout, breaking outbound XCMP. Add MigrateV5ToV6 to UnreleasedSingleBlockMigrations (made Runtime-generic so the single common definition covers moonbeam/moonriver/moonbase). Pulls cumulus-pallet-xcmp-queue into runtime-common (std/runtime-benchmarks/try-runtime wired). Self-guarding VersionedMigration<5,6>: no-ops if on-chain isn't v5. Compiles across default / try-runtime / runtime-benchmarks.
…m audit + wired) Upstream-repo STORAGE_VERSION audit found cumulus-pallet-xcmp-queue bumped 5->6 and its VersionedMigration was not wired in moonbeam. Recorded the finding and the fix (commit 39d47d1) in Phase 4; corrected the stale 'migration lists empty' conclusion.
Guards against the migration silently being dropped from the runtime's single-block migration set: sets XcmpQueue on-chain StorageVersion to 5, runs the runtime's wired SingleBlockMigrations, and asserts it ends at 6. Generated for all three runtimes via generate_common_xcm_tests!. Verified passing on moonbase.
…ot-sdk-stable2603 # Conflicts: # test/suites/dev/common/test-xcm/test-transactional-outcomes.ts
Under the stable2603 holding/credit model, assets used by the XCM benchmarks
must be mintable by the executor's AssetTransactor and present in the
worst-case holding. Three sites in the shared benchmark config still
referenced the relay token, which is neither registered nor in the generated
holding, so pallet_xcm_benchmarks::{fungible,generic} failed (AssetNotFound,
AssetUnderflow, claim_asset panic):
- worst_case_for_trader: relay token -> native `Here`, the abundant MockCredit
asset in generate_holding_assets (priced by worst_case_holding).
- claimable_asset: relay token -> native `SelfReserve`, mintable by the real
AssetTransactor that assets_to_holding uses.
- TrustedReserve: relay token from AssetHub -> native `SelfReserve` from origin
`Here`, trusted via MultiNativeAsset.
Verified: both XCM benchmark pallets now run on moonbase, moonbeam, moonriver.
cumulus-pallet-parachain-system gained block_weight_tx_extension_{max_weight,
stays_fraction_of_core,full_core} in stable2603; they were committed as
Weight::zero() placeholders. Replace with benchmarked weights on moonbase,
moonbeam and moonriver.
Note: generated on non-reference hardware; to be regenerated on the reference
machine before release.
The previous fix used the native token for reserve_asset_deposited, whose mint takes the cheaper Balances path and under-counts the realistic cost of a reserve deposit (which always involves foreign assets). Register DOT (RelayLocation) as a foreign asset in the TrustedReserve getter so the instruction is measured through the EvmForeignAssets mint path, trusted from Asset Hub via the RelayChainNativeAssetFromAssetHub reserve filter. On moonbase this raises the measurement from a notional path (proof size 0, 0 reads) to real storage (proof size 3586, 1 read). Verified on moonbase, moonbeam and moonriver.
…ot-sdk-stable2603 # Conflicts: # test/suites/dev/common/test-xcm/test-transactional-outcomes.ts
Contributor
|
LGTM! |
arturgontijo
approved these changes
Jul 2, 2026
librelois
approved these changes
Jul 8, 2026
manuelmauro
added a commit
that referenced
this pull request
Jul 9, 2026
Master brings the polkadot-sdk stable2603 upgrade (#3746). Conflict resolutions: - runtime/*/tests/xcm_mock/*: kept this branch's deletion; these were replaced by the xcm-emulator-tests crates. - Cargo.toml: took master's stable2603 branch pins, re-applied this branch's additions (xcm-emulator-tests workspace members, pallet-delegated-staking, asset-hub-westend-runtime, and xcm-simulator -> xcm-emulator). - Cargo.lock: regenerated on master's stable2603 resolution. Pinned alloy-* to 1.6.3, alloy-eip7928 to 0.3.3 and ruint to 1.17.2, since the latest versions require rustc 1.90/1.91 and rust-toolchain.toml pins 1.88.0. These crates enter only via asset-hub-westend-runtime. - docs/cherry-picks/polkadot-sdk-stable2512.md: kept both master's pruning plus new rows and this branch's xcm-emulator row. Integration fix: Westend's ParachainHost moved to api_version 16 in stable2603, so decl_test_relay_chains! could no longer resolve dmq_contents via ParachainHostV15. Bumped api_version to 16 in all three xcm-emulator-tests network.rs, matching upstream's own emulated Westend declaration.
manuelmauro
added a commit
that referenced
this pull request
Jul 9, 2026
The polkadot-sdk stable2603 upgrade shipped in #3746, so the temporary working doc it introduced has served its purpose. The cherry-pick tracker polkadot-sdk-stable2603.md stays, alongside the stable2512 and stable2506 trackers kept for historical reference.
This was referenced Jul 9, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What does it do?
Upgrades
polkadot-sdk— and thefrontier/evm/ethereum/moonkitforks — fromstable2512tostable2603(upstream tagpolkadot-stable2603-1, released 2026-05-01).Concretely:
Cargo.tomlswapsmoonbeam-polkadot-stable2512→moonbeam-polkadot-stable2603across all five forks (~180 occurrences);Cargo.lockre-resolved.xcm_executor::AssetsInHoldingto carry realfungible::Creditimbalances instead of plainAssetdescriptors. TheTransactAsset,WeightTrader, andFeeManager::handle_feeimpls were migrated accordingly:erc20-xcm-bridgeandmoonbeam-foreign-assetsgain anotional.rsnotional-credit type (erc20 is an EVM-side balance, not a Substratefungible, so it has no realCredit; the token movement still happens via EVM calls inwithdraw_asset/deposit_asset, and the notional credit only threads the asset through holding).xcm-weight-traderreworksbuy_weight/refund_weight/Dropfor the credit model;mint_assetis now implemented inmoonbeam-foreign-assets.runtime-benchmarks/try-runtime):RuntimeDebug→Debug(51 sites / 14 files, upstream #10582); proof-recording refactor and removal ofcumulus-client-consensus-proposerin the lazy-loading manual-seal (upstream #9947);node/serviceclient-side drift; newcumulus_pallet_parachain_system::WeightInfomethods added to weight files; runtime-API and XCM-config signature changes (see Breaking Changes).polkadot-sdk-stable2603.mdand the working upgrade planUPGRADE-stable2603.md.What important points should reviewers know?
moonbeam-polkadot-stable2603branch with the moonbeam-only cherry-picks re-applied. Bases: polkadot-sdk from thepolkadot-stable2603-1tag (rebased ontoupstream/stable2603head to absorb 4 backports); frontier from the officialupstream/stable2603(cut after our DIY base-bump landed upstream as polkadot-evm/frontier#1892); evm stays on the 0.43.x line; ethereum offupstream/master.mainon 2026-06-18 (squash). Themoonbeam-polkadot-stable2603release branch was rebased ontomain— nowmain+ a single dep-redirect commit (head9d71129) — andCargo.lockre-pinned to it; the resulting tree is identical to the pre-merge interim branch.[patch.crates-io]— the fork branches resolve directly from themoonbeam-foundation(andMoonsong-Labsfor moonkit) remotes.--all-featuresis NOT a valid check for moonbeam. It forces the mutually-exclusivedisable-genesis-builderfeature on, which stripsgenesis_config_preset(needed by the node'schain_spec). Verification uses the realistic feature matrix (default /runtime-benchmarks/try-runtime).spec_versionbump and no weight regeneration are included — those are deliberately deferred (see follow-ups). Reviewers should treat this as the dependency/API-drift layer plus that single required migration.StorageVersionmigration is included:cumulus-pallet-xcmp-queuev5 → v6. Surfaced by an upstream-repoSTORAGE_VERSIONaudit — easy to miss (the pallet declares the version insrc/migration/mod.rs, notlib.rs) and a lazy-loading dry-run masked it (it set XcmpQueue to v6 as a "new pallet" rather than migrating). It corresponds to upstream polkadot-sdk#11263 (ConcatenatedOpaqueVersionedXcmnegotiation), which adds a per-channelflagsfield toOutboundChannelDetails.MigrateV5ToV6is a standaloneVersionedMigrationthe pallet does not auto-run — every upstream parachain runtime (asset-hub, bridge-hub) wires it explicitly — and moonbeam's migration lists were empty, so without it on-chain v5OutboundXcmpStatuswould fail to decode against the v6 layout and silently drop outbound-channel state. Wired ascumulus_pallet_xcmp_queue::migration::v6::MigrateV5ToV6<Runtime>inUnreleasedSingleBlockMigrations(runtime/common/src/migrations.rs), madeRuntime-generic so one definition covers all three runtimes. It is self-guarding (VersionedMigration<5,6>: no-op unless on-chain is exactly v5), thexcmp_queue::Configtrait is unchanged (no new runtime support needed), and the new format negotiation is backward-compatible (flags default empty). A test (xcmp_queue_v5_to_v6_migration_is_wired_and_runs) runs the runtime's actual wired migration set and asserts v5→v6 on moonbase/moonriver/moonbeam; the migration's ownpre/posttry_stateis covered by the deferred CI run. Reviewers: this is the one runtime-behavior-affecting change here — please confirm the wiring and thatUnreleasedSingleBlockMigrations(reached viaframe_system::Config::SingleBlockMigrations) is the right home.moonbeam-polkadot-stable2512fork branches surfaced cherry-picks present on 2512 but missing from this 2603 cycle; they are applied here. Three are moonbeam-authored polkadot-sdk node patches re-applied with manual conflict resolution, so reviewers should confirm each is equivalent to its original stable2512 commit: DNS multiaddr filtering (09e2fee3c→f35e2dd), txpool hard-timeout during block authorship (997cc6b→a668034), and the--force-empty-blocksemergency flag (4a9db14→11a87af). The latter two are semantic re-ports onto the stable2603 proposer refactor (BuildBlockAndImportParamscall API, removedPRproof-recording generic), so they are the most important to check;cargo checkon the affected crates passes and the upstreamed--force-empty-blocksunit test passes. The original→re-applied mapping is documented indocs/cherry-picks/polkadot-sdk-stable2512.mdandpolkadot-sdk-stable2603.md.AssetsInHoldingstores realfungible::Creditimbalances instead ofAssetdescriptors, so theTransactAssetsignatures changed (withdraw_asset/deposit_asset/mint_asset/internal_transfer_asset). EVM-contract assets have no Substratefungibleand therefore no realCredit, so botherc20-xcm-bridgeandmoonbeam-foreign-assetsrepresent the amount in holding with the shared, side-effect-freexcm_primitives::NotionalImbalance(an exact mirror of the executor's ownMockCredit; consolidated intoxcm-primitivesin this PR so the two pallets share one definition). The real token movement still happens via EVM, not the credit:erc20-xcm-bridgetraces the origin inXcmHoldingErc20sOriginsand defers a single transfer todeposit_asset;moonbeam-foreign-assetsburns inwithdraw_assetand mints indeposit_asset. Reviewers: the notional credit is pure executor-side bookkeeping (no balance/issuance effects) — correct precisely because these assets have no Substrate issuance to resolve. Forerc20-xcm-bridge, erc20 is also filtered out of the asset trap ondrop_assets, soclaim_assetsdelegates unchanged.Is there something left for follow-up PRs?
Yes — the remaining release-time / CI phases:
Weight::zero()stubs thatcumulus_pallet_parachain_system::WeightInfogained for theDynamicMaxBlockWeighttx-extension, which moonbeam does not wire in — so this is release hygiene, not a correctness blocker. (spec_versionis bumped by the separate release process, not this upgrade.)substrate-relayagainst stable2603, regenerate zombienet relay chain specs, and run the bridge integration tests.try-runtime --checks all(try_state) against production state for moonbase / moonriver / moonbeam, smoke tests, and zombienet XCM cross-chain scenarios — these need CI/archive infra (a local public-RPC state scrape is impractical). Already verified locally: thecargo checkmatrix (default /runtime-benchmarks/try-runtime),cargo test --workspace(1347 pass), the upgrade-touched dev TS fixtures, and a lazy-loading runtime-upgrade dry-run against live moonbeam mainnet state.Resolved since this PR opened (no longer follow-ups):
StorageVersionaudit found the one required migration (cumulus-pallet-xcmp-queuev5→v6); it is wired and tested in this PR (see What important points should reviewers know?).main; the release branch was rebased onto it andCargo.lockre-pinned.upstream/stable2603(all priorVerify/TBDrows confirmed; one missing polkadot-sdk row added, one cited SHA corrected) inpolkadot-sdk-stable2603.md.What alternative implementations were considered?
polkadot-evm/frontierhad not cutstable2603when this started. Rather than block, we did the base-bump ourselves; it was then opened upstream (#1892) and squash-merged, after which upstream cutstable2603. We rebased onto the official branch and dropped the DIY one.rust-ethereum/evmupstream has moved to v1.0; we stay on the 0.43.x fork (the stable2603 branch is effectively a rename of stable2512). Moving to v1.0 was rejected as out of scope — any new upstream EIP/gas work must be backported onto 0.43.x instead.Creditvs. notional credit. erc20 tokens are EVM-side balances with no Substratefungible::Creditto hold. Mirroring the executor's ownMockCredit, a notional amount-only credit threads the asset through holding while the real token movement stays in the EVMwithdraw_asset/deposit_assetcalls.Are there relevant PRs or issues in other repositories (Substrate, Polkadot, Frontier, Cumulus)?
Upstream changes that drove this work:
cumulus-client-consensus-proposer), #10582 (RuntimeDebugremoval). Backports absorbed via rebase: #11964, #11856, #11987, #12017.stable2603cut). Numerous prior moonbeam cherry-picks are now inherited fromupstream/stable2603(EIP-7939/7883/7823/7825, severaleth_*RPC correctness fixes, etc.) — full reconciliation in the tracker.main.delegation.rstest fix, upstreamed).Per-fork branch + cherry-pick detail lives in
docs/cherry-picks/polkadot-sdk-stable2603.md.What value does it bring to the blockchain users?
Keeping Moonbeam current with the latest
polkadot-sdkstable line is what lets users benefit from upstream security fixes, performance improvements, and new protocol features, and keeps the maintenance gap to upstream small. The frontier upgrade also folds in a batch of EVM-RPC correctness fixes (block-resolution, receipt-race, andeth_*consistency fixes now inherited from upstream) and additional Osaka-era EIP support. The user-facing runtime impact is realized once the follow-up Phase 4 work (version bump + weights + migrations) ships; this PR is the dependency/API-drift foundation that work builds on.This upgrades
polkadot-sdk(and thefrontier/evm/ethereum/moonkitforks) fromstable2512tostable2603. Besides the internal API churn, the following are externally-visible breaking changes:SessionKeysruntime API → V2.generate_session_keysnow takes anownerargument and returnsOpaqueGeneratedSessionKeysinstead ofVec<u8>. Tooling that calls the runtime API directly to rotate/generate session keys must be updated.EthereumRuntimeRPCApi::callsignature change. It gained a Geth-stylestate_overrideparameter (API version bump). Code calling the Ethereum runtime API directly (custometh_call/tracing tooling) must pass the new argument.pallet_evm::Runner::callgained astate_overrideargument (frontier). Any integration building EVM calls against theRunnertrait must update.AssetsInHoldingredesign. The XCM executor now tracks realfungible::Creditimbalances instead ofAssetdescriptors. TheTransactAsset(deposit_asset/withdraw_asset/internal_transfer_asset),WeightTrader(buy_weight/refund_weight), andFeeManager::handle_feesignatures changed; custom XCM asset transactors / weight traders must migrate.RuntimeDebugremoved fromsp_core/sp_runtime/frame_support(useDebug). Downstream crates depending on moonbeam/runtime types must adjust.sp_consensus::Proposerlost itsProofassociated type andcumulus-client-consensus-proposerwas removed; manual-seal / dev-service tooling relying on these must update.One required storage migration is introduced —
cumulus-pallet-xcmp-queuev5 → v6 (see "What important points should reviewers know?"). Nospec_versionbump or weight regeneration is included; those remain follow-up (Phase 4) work.