Chore update polkadot-sdk to stable2603

[manuelmauro]

What does it do?

Upgrades polkadot-sdk — and the frontier / evm / ethereum / moonkit forks — from stable2512 to stable2603 (upstream tag polkadot-stable2603-1, released 2026-05-01).

Concretely:

• Dependency pins + lockfile. Cargo.toml swaps moonbeam-polkadot-stable2512 → moonbeam-polkadot-stable2603 across all five forks (~180 occurrences); Cargo.lock re-resolved.
• XCM credit-based holding migration — the substantive piece. stable2603 reworked xcm_executor::AssetsInHolding to carry real fungible::Credit imbalances instead of plain Asset descriptors. The TransactAsset, WeightTrader, and FeeManager::handle_fee impls were migrated accordingly:
  • erc20-xcm-bridge and moonbeam-foreign-assets gain a notional.rs notional-credit type (erc20 is an EVM-side balance, not a Substrate fungible, so it has no real Credit; the token movement still happens via EVM calls in withdraw_asset/deposit_asset, and the notional credit only threads the asset through holding).
  • xcm-weight-trader reworks buy_weight / refund_weight / Drop for the credit model; mint_asset is now implemented in moonbeam-foreign-assets.
• API drift fixes to compile green across the realistic feature matrix (default / runtime-benchmarks / try-runtime): RuntimeDebug → Debug (51 sites / 14 files, upstream #10582); proof-recording refactor and removal of cumulus-client-consensus-proposer in the lazy-loading manual-seal (upstream #9947); node/service client-side drift; new cumulus_pallet_parachain_system::WeightInfo methods added to weight files; runtime-API and XCM-config signature changes (see Breaking Changes).
• Regenerated TypeScript API types and updated the dev / XCM TS test fixtures for the new relay and credit-model XCM events.
• Docs: adds the cherry-pick tracker polkadot-sdk-stable2603.md and the working upgrade plan UPGRADE-stable2603.md.

What important points should reviewers know?

• Fork branches. Each fork has a fresh moonbeam-polkadot-stable2603 branch with the moonbeam-only cherry-picks re-applied. Bases: polkadot-sdk from the polkadot-stable2603-1 tag (rebased onto upstream/stable2603 head to absorb 4 backports); frontier from the official upstream/stable2603 (cut after our DIY base-bump landed upstream as polkadot-evm/frontier#1892); evm stays on the 0.43.x line; ethereum off upstream/master.
• moonkit is on an interim branch. moonbeam-polkadot-stable2603 is cut off the head of the still-open base-bump PR Moonsong-Labs/moonkit#95 (main + base-bump, linear). It must be reconciled against the merge/squash commit once that PR lands in main — see follow-ups.
• No [patch.crates-io] — the fork branches resolve directly from the moonbeam-foundation (and Moonsong-Labs for moonkit) remotes.
• --all-features is NOT a valid check for moonbeam. It forces the mutually-exclusive disable-genesis-builder feature on, which strips genesis_config_preset (needed by the node's chain_spec). Verification uses the realistic feature matrix (default / runtime-benchmarks / try-runtime).
• Scope of this PR. It gets the workspace compiling green and the dev/integration fixtures updated. No spec_version bump, no StorageVersion migrations, and no weight regeneration are included here — those are deliberately deferred (see follow-ups). Reviewers should treat this as the dependency/API-drift layer, not a runtime-behavior change.

Is there something left for follow-up PRs?

Yes — the post-compile phases of the upgrade plan:

• Runtime / weights / version (Phase 4): re-run benchmarks for every pallet whose weight signature changed, run weight-regression analysis over the diff, bump spec_version in each runtime, author migrations for any pallet whose StorageVersion advanced upstream, and run try-runtime against production state for moonbase / moonriver / moonbeam.
• Bridge maintenance (Phase 5): rebuild substrate-relay against stable2603, regenerate zombienet relay chain specs, and run the bridge integration tests.
• moonkit reconciliation: once moonkit#95 merges to main, reset/rebase the moonbeam-polkadot-stable2603 release branch onto the merge commit and confirm content parity.
• Tracker finalization (Phase 2): run merge-base verification per fork for the rows still marked Verify/TBD in polkadot-sdk-stable2603.md.
• Full verification sweep (Phase 6): workspace tests, smoke tests, and XCM cross-chain scenarios.

What alternative implementations were considered?

• frontier base — wait vs. DIY. polkadot-evm/frontier had not cut stable2603 when this started. Rather than block, we did the base-bump ourselves; it was then opened upstream (#1892) and squash-merged, after which upstream cut stable2603. We rebased onto the official branch and dropped the DIY one.
• moonkit base — wait vs. author + interim branch. No upstream base-bump existed, so we authored #95 and cut an interim release branch off its head to unblock moonbeam Phase 3, rather than waiting for the PR to merge first.
• evm — stay on 0.43.x vs. move to v1.0. rust-ethereum/evm upstream 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.
• erc20 in the credit model — real Credit vs. notional credit. erc20 tokens are EVM-side balances with no Substrate fungible::Credit to hold. Mirroring the executor's own MockCredit, a notional amount-only credit threads the asset through holding while the real token movement stays in the EVM withdraw_asset/deposit_asset calls.

Are there relevant PRs or issues in other repositories (Substrate, Polkadot, Frontier, Cumulus)?

Upstream changes that drove this work:

• polkadot-sdk: #9947 (proof-recording refactor; removed cumulus-client-consensus-proposer), #10582 (RuntimeDebug removal). Backports absorbed via rebase: #11964, #11856, #11987, #12017.
• frontier: #1892 (the base-bump we authored, merged upstream → stable2603 cut). Numerous prior moonbeam cherry-picks are now inherited from upstream/stable2603 (EIP-7939/7883/7823/7825, several eth_* RPC correctness fixes, etc.) — full reconciliation in the tracker.
• moonkit: #95 (base-bump, open), with #92 and #94 already inherited from main.
• evm: rust-ethereum/evm#400 (EIP-7939 CLZ, inherited from the 0.43.x base), plus #405 (stale delegation.rs test fix, upstreamed).
• ethereum: rust-ethereum/ethereum#77 (encoded-length methods, still carried as a cherry-pick).

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-sdk stable 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, and eth_* 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.

⚠️ Breaking Changes ⚠️

This upgrades polkadot-sdk (and the frontier/evm/ethereum/moonkit forks) from stable2512 to stable2603. Besides the internal API churn, the following are externally-visible breaking changes:

• SessionKeys runtime API → V2. generate_session_keys now takes an owner argument and returns OpaqueGeneratedSessionKeys instead of Vec<u8>. Tooling that calls the runtime API directly to rotate/generate session keys must be updated.
• EthereumRuntimeRPCApi::call signature change. It gained a Geth-style state_override parameter (API version bump). Code calling the Ethereum runtime API directly (custom eth_call/tracing tooling) must pass the new argument.
• EVM pallet_evm::Runner::call gained a state_override argument (frontier). Any integration building EVM calls against the Runner trait must update.
• XCM AssetsInHolding redesign. The XCM executor now tracks real fungible::Credit imbalances instead of Asset descriptors. The TransactAsset (deposit_asset/withdraw_asset/internal_transfer_asset), WeightTrader (buy_weight/refund_weight), and FeeManager::handle_fee signatures changed; custom XCM asset transactors / weight traders must migrate.
• RuntimeDebug removed from sp_core/sp_runtime/frame_support (use Debug). Downstream crates depending on moonbeam/runtime types must adjust.
• Proof-recording refactor. sp_consensus::Proposer lost its Proof associated type and cumulus-client-consensus-proposer was removed; manual-seal / dev-service tooling relying on these must update.

No runtime storage migrations are introduced in this PR; StorageVersion bumps and weight regeneration are tracked as follow-up (Phase 4) work.

[coderabbitai]

Note

Reviews paused

It 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 reviews.auto_review.auto_pause_after_reviewed_commits setting.

Use the following commands to manage reviews:

• @coderabbitai resume to resume automatic reviews.
• @coderabbitai review to trigger a single review.

Use the checkboxes below for quick actions:

• ▶️ Resume reviews
• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Bumps 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.

Changes

Stable2603 Upgrade & XCM Asset Holding Migration

Layer / File(s)	Summary
Dependency upgrade and upgrade docs Cargo.toml, docs/cherry-picks/*	Workspace git pins moved from moonbeam-polkadot-stable2512 → moonbeam-polkadot-stable2603; upgrade planning and cherry-pick tracker docs added/updated.
Runtime API & EVM call signature updates runtime/common/src/apis.rs, runtime/common/src/impl_xcm_evm_runner.rs, pallets/moonbeam-foreign-assets/src/evm.rs, runtime API tests	Session key generation now takes an owner and returns opaque session keys; Ethereum RPC call and EVM runner Runner::call add a state_override parameter; call sites and tests updated; benchmark wiring adjusted.
Notional imbalance and TransactAsset migration pallets/erc20-xcm-bridge/*, pallets/moonbeam-foreign-assets/*, pallets/*/notional.rs, tests	Introduces NotionalImbalance; TransactAsset impls now accept AssetsInHolding and return Result<(), (AssetsInHolding, XcmError)>; withdraw/deposit/mint internals updated to use notional credits and storage transactions; ERC20 bridge trap/claim added.
XCM weight trader and mocks pallets/xcm-weight-trader/*, pallets/xcm-transactor/src/mock.rs, precompiles/*/src/mock.rs, precompiles/xcm-utils/src/mock.rs, precompiles/xtokens/src/mock.rs	Trader stores withheld fees as AssetsInHolding; buy_weight/refund_weight/Drop updated; many mock TransactAsset/WeightTrader signatures and test helpers adjusted to new AssetsInHolding and error-tuple shapes.
Node service lazy-loading & manual sealing node/service/src/lazy_loading/*, node/service/src/lib.rs, node/service/Cargo.toml, node/service/src/lazy_loading/substrate_backend.rs	CallExecutor::runtime_version gains CallContext; manual sealer removes explicit proof generic and uses ProposeArgs with ProofRecorder; build_network calls pass spawn_essential_handle; set_block_data signature extended.
XCM executor config rewiring (runtimes & mocks) runtime/*/src/xcm_config.rs, runtime/*/tests/xcm_mock/*	Removed AssetClaims associated type and re-wired Trader, ResponseHandler, and AssetTrap across moonbase/moonbeam/moonriver and test mocks.
Debug derive consolidation & runtime limits various pallets/*, primitives/*, runtime/*	Replaced RuntimeDebug with standard Debug derives across many public types/enums; BlockLength config updated to builder API in runtimes.
Integration & unit test adjustments test/suites/dev/*, pallets/*/tests.rs, pallets/xcm-weight-trader/src/tests.rs	Tests updated to reflect new XCM holdings/return types, EVM state_override argument, mocked relay expectations, and XCM fee extraction from balances.Deposit events.

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Possibly related PRs

• moonbeam-foundation/moonbeam#3682: Related workspace dependency pin updates for Frontier/Ethereum crates.
• moonbeam-foundation/moonbeam#3740: Related lazy-loading relay-parent offset and validation-data wiring changes.
• moonbeam-foundation/moonbeam#3633: Related node consensus proposer/proposer-factory and consensus wiring changes.

Suggested labels

dependencies

Suggested reviewers

• librelois
• arturgontijo

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch chore-update-polkadot-sdk-stable2603

[coderabbitai]

Actionable comments posted: 5

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (2)

pallets/xcm-weight-trader/src/mock.rs (1)

137-163: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Reject multi-asset holdings explicitly in this mock transactor.

deposit_asset processes only the first fungible asset from what and returns success, which can silently drop additional assets and hide failures in tests. Please enforce “exactly one fungible asset” (or iterate and handle all) before depositing.

Suggested patch

-		// Extract the (single) fungible asset from the holding.
-		let asset = what.fungible_assets_iter().next();
-		let asset = match asset {
+		// This mock supports exactly one fungible asset; reject bundles.
+		if what.fungible_assets_iter().count() != 1 {
+			return Err((what, XcmError::AssetNotFound));
+		}
+		let asset = match what.fungible_assets_iter().next() {
 			Some(asset) => asset,
 			None => return Err((what, XcmError::AssetNotFound)),
 		};

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@pallets/xcm-weight-trader/src/mock.rs` around lines 137 - 163, The mock
transactor currently takes only the first fungible asset from `what` and can
silently drop others; in the `deposit_asset` implementation check that
`what.fungible_assets_iter()` contains exactly one fungible asset before
proceeding (e.g., pull the first item, then assert the iterator has no second
item), and if there are zero or more-than-one fungible assets return an explicit
Err((what, XcmError::...)) (choose an appropriate XCM error variant or add a new
one) instead of proceeding; adjust the logic around `XcmAssetId(location)` /
`Fungibility::Fungible(amount)` to run only after this exact-one check so extra
assets are rejected rather than ignored.

node/service/src/lazy_loading/substrate_backend.rs (1)

605-613: ⚠️ Potential issue | 🟠 Major | ⚡ Quick win

Propagate register_as_leaf instead of discarding it.

The new parameter is ignored, but leaf tracking is applied unconditionally later. If callers pass false, this backend will still register leaves and diverge from import semantics.

Suggested fix

 struct PendingBlock<B: BlockT> {
 	block: StoredBlock<B>,
 	state: NewBlockState,
+	register_as_leaf: bool,
 }

 // ...
 fn set_block_data(
 	&mut self,
 	header: <Block as BlockT>::Header,
 	body: Option<Vec<<Block as BlockT>::Extrinsic>>,
 	_indexed_body: Option<Vec<Vec<u8>>>,
 	justifications: Option<Justifications>,
 	state: NewBlockState,
-	_register_as_leaf: bool,
+	register_as_leaf: bool,
 ) -> sp_blockchain::Result<()> {
 	// ...
 	self.pending_block = Some(PendingBlock {
 		block: StoredBlock::new(header, body, justifications),
 		state,
+		register_as_leaf,
 	});
 	Ok(())
 }

- pub fn insert(..., new_state: NewBlockState) -> sp_blockchain::Result<()> {
+ pub fn insert(..., new_state: NewBlockState, register_as_leaf: bool) -> sp_blockchain::Result<()> {
   // ...
-  storage.leaves.import(hash, number, *header.parent_hash());
+  if register_as_leaf {
+      storage.leaves.import(hash, number, *header.parent_hash());
+  }
 }

 self.blockchain.insert(
   hash,
   header,
   justification,
   body,
-  pending_block.state
+  pending_block.state,
+  pending_block.register_as_leaf
 )?;

Run this to verify current behavior and impact scope:

#!/bin/bash
set -euo pipefail

echo "1) Updated trait method signature and ignored parameter:"
rg -n "fn set_block_data\\(|register_as_leaf|_register_as_leaf" node/service/src/lazy_loading/substrate_backend.rs -C 3

echo
echo "2) Leaf registration path (check if conditional or unconditional):"
rg -n "leaves\\.import\\(" node/service/src/lazy_loading/substrate_backend.rs -C 3

echo
echo "3) Local call sites passing set_block_data args in lazy-loading code:"
rg -n "\\.set_block_data\\(" node/service/src/lazy_loading -C 4

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@node/service/src/lazy_loading/substrate_backend.rs` around lines 605 - 613,
The new boolean parameter _register_as_leaf is ignored in set_block_data causing
unconditional leaf registration; update set_block_data (and any local call
sites) to propagate the caller's register_as_leaf value so the leaves.import
call is executed only when register_as_leaf is true: locate the set_block_data
function in substrate_backend.rs, replace the unconditional leaves.import(...)
invocation with a conditional guarded by the register_as_leaf parameter (or
rename _register_as_leaf to register_as_leaf and use it), and update any callers
of set_block_data to pass the intended boolean so import semantics match the
caller's intent.

🧹 Nitpick comments (1)

pallets/moonbeam-foreign-assets/src/notional.rs (1)

31-60: 💤 Low value

Consider extracting NotionalImbalance to a shared crate.

This type is identical to the one in pallets/erc20-xcm-bridge/src/notional.rs. Extracting it to a shared primitives crate (e.g., primitives/xcm-notional or similar) would avoid the duplication and ensure both pallets stay in sync.

This is a low-priority suggestion since the current approach keeps each pallet self-contained.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@pallets/moonbeam-foreign-assets/src/notional.rs` around lines 31 - 60, The
NotionalImbalance type and its trait impls (NotionalImbalance,
UnsafeConstructorDestructor::unsafe_clone/forget_imbalance,
UnsafeManualAccounting::saturating_subsume, and
ImbalanceAccounting::amount/saturating_take) are duplicated in another pallet;
extract this struct and its impls into a shared primitives crate (e.g.,
primitives/xcm-notional) and replace the local definition with a re-export or
use of that shared type in pallets/moonbeam-foreign-assets and
pallets/erc20-xcm-bridge so both pallets import the single canonical
NotionalImbalance implementation.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/cherry-picks/polkadot-sdk-stable2603.md`:
- Line 35: The table row shows contradictory tracker fields: "Applied = No"
while "Cherry pick = Included" with a concrete commit; update the row so the
state is consistent (e.g., set "Applied" to "Yes" to match "Cherry pick =
Included" and the listed commit), and ensure any adjacent status columns or
notes reflect the same resolution (remove or update the "Upstream PR not merged"
remark if it conflicts); verify the commit link
([moonbeam-foundation/evm@a122857]) and PR reference ([rust-ethereum/evm#405])
remain intact.

In `@docs/cherry-picks/UPGRADE-stable2603.md`:
- Line 210: Update the Phase 6 checklist to remove or replace the invalid "cargo
check --workspace --all-features" verification step: locate the Phase 6
checklist entry referencing "cargo check --workspace --all-features" and change
it to use the realistic feature matrix (e.g., default / runtime-benchmarks /
try-runtime) or a workspace-level check that does not pass --all-features, and
add a short note referencing the earlier guidance that --all-features forces
disable-genesis-builder and breaks Moonbeam's chain_spec and pallet standalone
tests.

In `@node/service/src/lazy_loading/manual_sealing.rs`:
- Line 18: Replace the brittle private import
frame_benchmarking::__private::codec::Encode with the public
parity_scale_codec::Encode in this module: update the use line to import
parity_scale_codec::Encode so calls like proof.encoded_size() still compile;
keep the existing logic around ProofRecorder::<B>::default(),
ProofSizeExt::new(storage_proof_recorder.clone()), passing
storage_proof_recorder: Some(storage_proof_recorder.clone()) into ProposeArgs,
and the storage_proof_recorder.drain_storage_proof() flow unchanged.

In `@pallets/erc20-xcm-bridge/src/lib.rs`:
- Around line 172-176: The current deposit_asset implementation collects assets
from what and performs per-asset executor drains and EVM transfers inside the
loop, but on a later failure returns Err((what, err)) with the original
AssetsInHolding, making already-processed assets appear unspent; fix by making
the whole batch atomic or by returning only the actual remaining/unspent
holding: either wrap the entire per-asset loop (including the drain and
transfers) inside a single frame_support::storage::with_storage_layer call so
any transfer/drain side-effects roll back on failure, or alternatively
update/remove processed assets from what (or build a new remaining holding) as
each asset succeeds and return that remaining AssetsInHolding on error; adjust
deposit_asset, matches_fungibles handling and any usage of drain/executor
context and outcome to follow the new atomic or incremental semantics.

In `@pallets/moonbeam-foreign-assets/src/lib.rs`:
- Around line 830-872: deposit_asset currently mutates state per-asset and can
return early leaving partial writes; wrap the entire per-asset processing loop
in a single atomic storage transaction or do a pure validation pass first.
Specifically, move the frame_support::storage::with_storage_layer(...) to
encompass the whole loop in deposit_asset (so all PendingDeposits::<T>::insert
and EvmCaller::<T>::erc20_mint_into calls happen inside one closure) or
alternatively first iterate assets calling
ForeignAssetsMatcher::<T>::match_asset, check for
AssetStatus::FrozenXcmDepositForbidden, compute and overflow-check new totals
for PendingDeposits::<T> without writing, and only after all validations succeed
perform the writes/erc20_mint_into; ensure no early returns outside the
storage::with_storage_layer and keep references to AssetStatus,
PendingDeposits::<T>, EvmCaller::<T>::erc20_mint_into, and
ForeignAssetsMatcher::<T>::match_asset to locate the changes.

---

Outside diff comments:
In `@node/service/src/lazy_loading/substrate_backend.rs`:
- Around line 605-613: The new boolean parameter _register_as_leaf is ignored in
set_block_data causing unconditional leaf registration; update set_block_data
(and any local call sites) to propagate the caller's register_as_leaf value so
the leaves.import call is executed only when register_as_leaf is true: locate
the set_block_data function in substrate_backend.rs, replace the unconditional
leaves.import(...) invocation with a conditional guarded by the register_as_leaf
parameter (or rename _register_as_leaf to register_as_leaf and use it), and
update any callers of set_block_data to pass the intended boolean so import
semantics match the caller's intent.

In `@pallets/xcm-weight-trader/src/mock.rs`:
- Around line 137-163: The mock transactor currently takes only the first
fungible asset from `what` and can silently drop others; in the `deposit_asset`
implementation check that `what.fungible_assets_iter()` contains exactly one
fungible asset before proceeding (e.g., pull the first item, then assert the
iterator has no second item), and if there are zero or more-than-one fungible
assets return an explicit Err((what, XcmError::...)) (choose an appropriate XCM
error variant or add a new one) instead of proceeding; adjust the logic around
`XcmAssetId(location)` / `Fungibility::Fungible(amount)` to run only after this
exact-one check so extra assets are rejected rather than ignored.

---

Nitpick comments:
In `@pallets/moonbeam-foreign-assets/src/notional.rs`:
- Around line 31-60: The NotionalImbalance type and its trait impls
(NotionalImbalance, UnsafeConstructorDestructor::unsafe_clone/forget_imbalance,
UnsafeManualAccounting::saturating_subsume, and
ImbalanceAccounting::amount/saturating_take) are duplicated in another pallet;
extract this struct and its impls into a shared primitives crate (e.g.,
primitives/xcm-notional) and replace the local definition with a re-export or
use of that shared type in pallets/moonbeam-foreign-assets and
pallets/erc20-xcm-bridge so both pallets import the single canonical
NotionalImbalance implementation.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 77543f61-3c39-4aa5-8321-fc1a016d16ff

📥 Commits

Reviewing files that changed from the base of the PR and between 19a706e and 1f68990.

⛔ Files ignored due to path filters (22)

• Cargo.lock is excluded by !**/*.lock
• runtime/moonbase/src/weights/cumulus_pallet_parachain_system.rs is excluded by !**/weights/**/*.rs
• runtime/moonbeam/src/weights/cumulus_pallet_parachain_system.rs is excluded by !**/weights/**/*.rs
• runtime/moonriver/src/weights/cumulus_pallet_parachain_system.rs is excluded by !**/weights/**/*.rs
• typescript-api/src/moonbase/interfaces/augment-api-query.ts is excluded by !typescript-api/**
• typescript-api/src/moonbase/interfaces/augment-api-runtime.ts is excluded by !typescript-api/**
• typescript-api/src/moonbase/interfaces/augment-api-tx.ts is excluded by !typescript-api/**
• typescript-api/src/moonbase/interfaces/lookup.ts is excluded by !typescript-api/**
• typescript-api/src/moonbase/interfaces/registry.ts is excluded by !typescript-api/**
• typescript-api/src/moonbase/interfaces/types-lookup.ts is excluded by !typescript-api/**
• typescript-api/src/moonbeam/interfaces/augment-api-query.ts is excluded by !typescript-api/**
• typescript-api/src/moonbeam/interfaces/augment-api-runtime.ts is excluded by !typescript-api/**
• typescript-api/src/moonbeam/interfaces/augment-api-tx.ts is excluded by !typescript-api/**
• typescript-api/src/moonbeam/interfaces/lookup.ts is excluded by !typescript-api/**
• typescript-api/src/moonbeam/interfaces/registry.ts is excluded by !typescript-api/**
• typescript-api/src/moonbeam/interfaces/types-lookup.ts is excluded by !typescript-api/**
• typescript-api/src/moonriver/interfaces/augment-api-query.ts is excluded by !typescript-api/**
• typescript-api/src/moonriver/interfaces/augment-api-runtime.ts is excluded by !typescript-api/**
• typescript-api/src/moonriver/interfaces/augment-api-tx.ts is excluded by !typescript-api/**
• typescript-api/src/moonriver/interfaces/lookup.ts is excluded by !typescript-api/**
• typescript-api/src/moonriver/interfaces/registry.ts is excluded by !typescript-api/**
• typescript-api/src/moonriver/interfaces/types-lookup.ts is excluded by !typescript-api/**

📒 Files selected for processing (65)

• Cargo.toml
• docs/cherry-picks/UPGRADE-stable2603.md
• docs/cherry-picks/polkadot-sdk-stable2512.md
• docs/cherry-picks/polkadot-sdk-stable2603.md
• node/service/Cargo.toml
• node/service/src/lazy_loading/call_executor.rs
• node/service/src/lazy_loading/helpers.rs
• node/service/src/lazy_loading/manual_sealing.rs
• node/service/src/lazy_loading/mod.rs
• node/service/src/lazy_loading/substrate_backend.rs
• node/service/src/lib.rs
• pallets/crowdloan-rewards/src/lib.rs
• pallets/erc20-xcm-bridge/src/erc20_trap.rs
• pallets/erc20-xcm-bridge/src/lib.rs
• pallets/erc20-xcm-bridge/src/notional.rs
• pallets/erc20-xcm-bridge/src/xcm_holding_ext.rs
• pallets/ethereum-xcm/src/lib.rs
• pallets/moonbeam-foreign-assets/src/evm.rs
• pallets/moonbeam-foreign-assets/src/lib.rs
• pallets/moonbeam-foreign-assets/src/notional.rs
• pallets/moonbeam-foreign-assets/src/tests.rs
• pallets/moonbeam-orbiters/src/types.rs
• pallets/parachain-staking/src/auto_compound.rs
• pallets/parachain-staking/src/delegation_requests.rs
• pallets/parachain-staking/src/inflation.rs
• pallets/parachain-staking/src/set.rs
• pallets/parachain-staking/src/types.rs
• pallets/xcm-transactor/src/lib.rs
• pallets/xcm-transactor/src/mock.rs
• pallets/xcm-weight-trader/src/lib.rs
• pallets/xcm-weight-trader/src/mock.rs
• pallets/xcm-weight-trader/src/tests.rs
• precompiles/gmp/src/mock.rs
• precompiles/relay-encoder/src/mock.rs
• precompiles/xcm-transactor/src/mock.rs
• precompiles/xcm-utils/src/mock.rs
• precompiles/xtokens/src/mock.rs
• primitives/account/src/lib.rs
• primitives/rpc/txpool/src/lib.rs
• runtime/common/src/apis.rs
• runtime/common/src/impl_xcm_evm_runner.rs
• runtime/moonbase/src/governance/origins.rs
• runtime/moonbase/src/lib.rs
• runtime/moonbase/src/xcm_config.rs
• runtime/moonbase/tests/runtime_apis.rs
• runtime/moonbase/tests/xcm_mock/parachain.rs
• runtime/moonbase/tests/xcm_mock/relay_chain.rs
• runtime/moonbase/tests/xcm_mock/statemint_like.rs
• runtime/moonbeam/src/governance/origins.rs
• runtime/moonbeam/src/lib.rs
• runtime/moonbeam/src/xcm_config.rs
• runtime/moonbeam/tests/runtime_apis.rs
• runtime/moonbeam/tests/xcm_mock/parachain.rs
• runtime/moonbeam/tests/xcm_mock/relay_chain.rs
• runtime/moonbeam/tests/xcm_mock/statemint_like.rs
• runtime/moonriver/src/governance/origins.rs
• runtime/moonriver/src/lib.rs
• runtime/moonriver/src/xcm_config.rs
• runtime/moonriver/tests/runtime_apis.rs
• runtime/moonriver/tests/xcm_mock/parachain.rs
• runtime/moonriver/tests/xcm_mock/relay_chain.rs
• runtime/moonriver/tests/xcm_mock/statemine_like.rs
• test/suites/dev/common/test-block/test-block-mocked-relay.ts
• test/suites/dev/common/test-xcm/test-transactional-outcomes.ts
• test/suites/dev/moonbase/test-precompile/test-precompile-relay-verifier.ts

💤 Files with no reviewable changes (14)

• docs/cherry-picks/polkadot-sdk-stable2512.md
• runtime/moonbase/tests/xcm_mock/parachain.rs
• runtime/moonbase/tests/xcm_mock/relay_chain.rs
• node/service/Cargo.toml
• runtime/moonriver/tests/xcm_mock/statemine_like.rs
• runtime/moonbeam/src/xcm_config.rs
• runtime/moonriver/src/xcm_config.rs
• runtime/moonbeam/tests/xcm_mock/parachain.rs
• runtime/moonbeam/tests/xcm_mock/statemint_like.rs
• runtime/moonbeam/tests/xcm_mock/relay_chain.rs
• runtime/moonriver/tests/xcm_mock/relay_chain.rs
• runtime/moonriver/tests/xcm_mock/parachain.rs
• runtime/moonbase/tests/xcm_mock/statemint_like.rs
• runtime/moonbase/src/xcm_config.rs

[manuelmauro]

@coderabbitai full review

[coderabbitai]

✅ Action performed

Full review finished.

[coderabbitai]

Actionable comments posted: 3

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

test/suites/dev/common/test-block/test-block-mocked-relay.ts (1)

18-36: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Recompute the setValidationData index for the second block.

index is resolved against blockData and then reused against blockData2. If the extrinsic ordering changes between blocks, Line 33 will read the wrong extrinsic or undefined, so the second assertion stops validating the second block's relay parent.

Proposed fix

         const index = blockData.block.extrinsics.findIndex(
           (e) => e.method.method === "setValidationData"
         );
+        expect(index).toBeGreaterThan(-1);
         expect(
           (
             blockData.block.extrinsics[index].method
               .args[0] as CumulusPrimitivesParachainInherentParachainInherentData
           ).validationData.relayParentNumber.toString()
         ).to.eq("0");
         const blockResult2 = await context.createBlock();
         const blockData2 = await context.polkadotJs().rpc.chain.getBlock(blockResult2.block.hash);
+        const index2 = blockData2.block.extrinsics.findIndex(
+          (e) => e.method.method === "setValidationData"
+        );
+        expect(index2).toBeGreaterThan(-1);
         expect(
           (
-            blockData2.block.extrinsics[index].method
+            blockData2.block.extrinsics[index2].method
               .args[0] as CumulusPrimitivesParachainInherentParachainInherentData
           ).validationData.relayParentNumber.toString()
         ).to.eq("1");

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@test/suites/dev/common/test-block/test-block-mocked-relay.ts` around lines 18
- 36, The test captures an `index` by searching
`blockData.block.extrinsics.findIndex(...)` for the `setValidationData`
extrinsic and then reuses that same `index` for `blockData2`; recompute the
index against `blockData2.block.extrinsics` after fetching `blockData2` (i.e.,
run the same findIndex call again before accessing
`blockData2.block.extrinsics[index]`) so the second assertion reads the correct
extrinsic for the second block when using `context.createBlock()` and
`context.polkadotJs().rpc.chain.getBlock`.

🧹 Nitpick comments (1)

pallets/moonbeam-foreign-assets/src/tests.rs (1)

28-31: ⚡ Quick win

Fail fast for non-fungible assets in the holding test helper.

Silently converting non-fungible assets to 0 can hide broken test setup and produce false positives. Make this helper explicit by panicking/asserting on non-fungible input.

Suggested change

 fn holding(asset: &Asset) -> xcm_executor::AssetsInHolding {
 	let amount = match asset.fun {
 		Fungibility::Fungible(amount) => amount,
-		_ => 0,
+		_ => panic!("holding() expects a fungible asset in these tests"),
 	};
 	xcm_executor::AssetsInHolding::new_from_fungible_credit(
 		asset.id.clone(),
 		Box::new(crate::notional::NotionalImbalance(amount)),
 	)
 }

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@pallets/moonbeam-foreign-assets/src/tests.rs` around lines 28 - 31, The match
in the holding test helper silently maps non-fungible assets to 0 (matching on
asset.fun and extracting Fungibility::Fungible), which can hide test setup
errors; change this to fail-fast by replacing the fallback arm with an explicit
panic or assert (e.g., assert!(matches!(asset.fun, Fungibility::Fungible(_))) or
panic! with a clear message) so that any non-fungible input to the holding
helper immediately surfaces as an error; update the match in the holding helper
that binds amount from Fungibility::Fungible to remove the `_ => 0` branch and
use the assertion/panic instead.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/cherry-picks/UPGRADE-stable2603.md`:
- Line 208: Update the checklist item "- [ ] Update `tests/` TS fixtures
referencing changed types/RPCs." in UPGRADE-stable2603.md to reflect that TS
test/fixture updates are included in this PR: either change the box to checked
("- [x] ...") or revise the description to narrow the remaining follow-up work
(e.g., specify which fixtures still require a built node binary) so the
checklist accurately matches what was shipped; locate the exact line containing
that checklist text and modify it accordingly.
- Line 11: The document contains two inconsistent dates for the same release
identifier `polkadot-stable2603-1`; update the two occurrences of the release
date (the `Target upstream:` line and the later mention on Line 37) so they
match—pick the correct date (either 2026-05-01 or 2026-05-04) and replace the
other occurrence so both references to `polkadot-stable2603-1` use the same
release date.

In `@pallets/xcm-weight-trader/src/mock.rs`:
- Around line 137-143: The deposit_asset implementation currently only reads the
first fungible from what.fungible_assets_iter().next() and silently ignores
additional assets in the AssetsInHolding; update
MockAssetTransactor::deposit_asset to explicitly reject or handle multi-asset
holdings by checking for extra fungible assets (e.g., call
fungible_assets_iter() and ensure only one item or test
iterator.next().is_some() after the first) and return a clear error (add or
reuse an XcmError variant such as MultiAssetNotSupported/TooManyAssets) instead
of proceeding, and adjust tests that use holding_vec(...) to expect the new
explicit rejection when multiple fungibles are present.

---

Outside diff comments:
In `@test/suites/dev/common/test-block/test-block-mocked-relay.ts`:
- Around line 18-36: The test captures an `index` by searching
`blockData.block.extrinsics.findIndex(...)` for the `setValidationData`
extrinsic and then reuses that same `index` for `blockData2`; recompute the
index against `blockData2.block.extrinsics` after fetching `blockData2` (i.e.,
run the same findIndex call again before accessing
`blockData2.block.extrinsics[index]`) so the second assertion reads the correct
extrinsic for the second block when using `context.createBlock()` and
`context.polkadotJs().rpc.chain.getBlock`.

---

Nitpick comments:
In `@pallets/moonbeam-foreign-assets/src/tests.rs`:
- Around line 28-31: The match in the holding test helper silently maps
non-fungible assets to 0 (matching on asset.fun and extracting
Fungibility::Fungible), which can hide test setup errors; change this to
fail-fast by replacing the fallback arm with an explicit panic or assert (e.g.,
assert!(matches!(asset.fun, Fungibility::Fungible(_))) or panic! with a clear
message) so that any non-fungible input to the holding helper immediately
surfaces as an error; update the match in the holding helper that binds amount
from Fungibility::Fungible to remove the `_ => 0` branch and use the
assertion/panic instead.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8b1a4c90-404b-4b4d-9bef-e947327f9032

📥 Commits

Reviewing files that changed from the base of the PR and between 19a706e and bf0c0d1.

⛔ Files ignored due to path filters (22)

• Cargo.lock is excluded by !**/*.lock
• runtime/moonbase/src/weights/cumulus_pallet_parachain_system.rs is excluded by !**/weights/**/*.rs
• runtime/moonbeam/src/weights/cumulus_pallet_parachain_system.rs is excluded by !**/weights/**/*.rs
• runtime/moonriver/src/weights/cumulus_pallet_parachain_system.rs is excluded by !**/weights/**/*.rs
• typescript-api/src/moonbase/interfaces/augment-api-query.ts is excluded by !typescript-api/**
• typescript-api/src/moonbase/interfaces/augment-api-runtime.ts is excluded by !typescript-api/**
• typescript-api/src/moonbase/interfaces/augment-api-tx.ts is excluded by !typescript-api/**
• typescript-api/src/moonbase/interfaces/lookup.ts is excluded by !typescript-api/**
• typescript-api/src/moonbase/interfaces/registry.ts is excluded by !typescript-api/**
• typescript-api/src/moonbase/interfaces/types-lookup.ts is excluded by !typescript-api/**
• typescript-api/src/moonbeam/interfaces/augment-api-query.ts is excluded by !typescript-api/**
• typescript-api/src/moonbeam/interfaces/augment-api-runtime.ts is excluded by !typescript-api/**
• typescript-api/src/moonbeam/interfaces/augment-api-tx.ts is excluded by !typescript-api/**
• typescript-api/src/moonbeam/interfaces/lookup.ts is excluded by !typescript-api/**
• typescript-api/src/moonbeam/interfaces/registry.ts is excluded by !typescript-api/**
• typescript-api/src/moonbeam/interfaces/types-lookup.ts is excluded by !typescript-api/**
• typescript-api/src/moonriver/interfaces/augment-api-query.ts is excluded by !typescript-api/**
• typescript-api/src/moonriver/interfaces/augment-api-runtime.ts is excluded by !typescript-api/**
• typescript-api/src/moonriver/interfaces/augment-api-tx.ts is excluded by !typescript-api/**
• typescript-api/src/moonriver/interfaces/lookup.ts is excluded by !typescript-api/**
• typescript-api/src/moonriver/interfaces/registry.ts is excluded by !typescript-api/**
• typescript-api/src/moonriver/interfaces/types-lookup.ts is excluded by !typescript-api/**

📒 Files selected for processing (65)

• Cargo.toml
• docs/cherry-picks/UPGRADE-stable2603.md
• docs/cherry-picks/polkadot-sdk-stable2512.md
• docs/cherry-picks/polkadot-sdk-stable2603.md
• node/service/Cargo.toml
• node/service/src/lazy_loading/call_executor.rs
• node/service/src/lazy_loading/helpers.rs
• node/service/src/lazy_loading/manual_sealing.rs
• node/service/src/lazy_loading/mod.rs
• node/service/src/lazy_loading/substrate_backend.rs
• node/service/src/lib.rs
• pallets/crowdloan-rewards/src/lib.rs
• pallets/erc20-xcm-bridge/src/erc20_trap.rs
• pallets/erc20-xcm-bridge/src/lib.rs
• pallets/erc20-xcm-bridge/src/notional.rs
• pallets/erc20-xcm-bridge/src/xcm_holding_ext.rs
• pallets/ethereum-xcm/src/lib.rs
• pallets/moonbeam-foreign-assets/src/evm.rs
• pallets/moonbeam-foreign-assets/src/lib.rs
• pallets/moonbeam-foreign-assets/src/notional.rs
• pallets/moonbeam-foreign-assets/src/tests.rs
• pallets/moonbeam-orbiters/src/types.rs
• pallets/parachain-staking/src/auto_compound.rs
• pallets/parachain-staking/src/delegation_requests.rs
• pallets/parachain-staking/src/inflation.rs
• pallets/parachain-staking/src/set.rs
• pallets/parachain-staking/src/types.rs
• pallets/xcm-transactor/src/lib.rs
• pallets/xcm-transactor/src/mock.rs
• pallets/xcm-weight-trader/src/lib.rs
• pallets/xcm-weight-trader/src/mock.rs
• pallets/xcm-weight-trader/src/tests.rs
• precompiles/gmp/src/mock.rs
• precompiles/relay-encoder/src/mock.rs
• precompiles/xcm-transactor/src/mock.rs
• precompiles/xcm-utils/src/mock.rs
• precompiles/xtokens/src/mock.rs
• primitives/account/src/lib.rs
• primitives/rpc/txpool/src/lib.rs
• runtime/common/src/apis.rs
• runtime/common/src/impl_xcm_evm_runner.rs
• runtime/moonbase/src/governance/origins.rs
• runtime/moonbase/src/lib.rs
• runtime/moonbase/src/xcm_config.rs
• runtime/moonbase/tests/runtime_apis.rs
• runtime/moonbase/tests/xcm_mock/parachain.rs
• runtime/moonbase/tests/xcm_mock/relay_chain.rs
• runtime/moonbase/tests/xcm_mock/statemint_like.rs
• runtime/moonbeam/src/governance/origins.rs
• runtime/moonbeam/src/lib.rs
• runtime/moonbeam/src/xcm_config.rs
• runtime/moonbeam/tests/runtime_apis.rs
• runtime/moonbeam/tests/xcm_mock/parachain.rs
• runtime/moonbeam/tests/xcm_mock/relay_chain.rs
• runtime/moonbeam/tests/xcm_mock/statemint_like.rs
• runtime/moonriver/src/governance/origins.rs
• runtime/moonriver/src/lib.rs
• runtime/moonriver/src/xcm_config.rs
• runtime/moonriver/tests/runtime_apis.rs
• runtime/moonriver/tests/xcm_mock/parachain.rs
• runtime/moonriver/tests/xcm_mock/relay_chain.rs
• runtime/moonriver/tests/xcm_mock/statemine_like.rs
• test/suites/dev/common/test-block/test-block-mocked-relay.ts
• test/suites/dev/common/test-xcm/test-transactional-outcomes.ts
• test/suites/dev/moonbase/test-precompile/test-precompile-relay-verifier.ts

💤 Files with no reviewable changes (14)

• runtime/moonriver/tests/xcm_mock/statemine_like.rs
• runtime/moonriver/tests/xcm_mock/relay_chain.rs
• runtime/moonbase/src/xcm_config.rs
• runtime/moonbeam/tests/xcm_mock/relay_chain.rs
• runtime/moonbeam/tests/xcm_mock/statemint_like.rs
• runtime/moonbase/tests/xcm_mock/relay_chain.rs
• node/service/Cargo.toml
• runtime/moonriver/src/xcm_config.rs
• docs/cherry-picks/polkadot-sdk-stable2512.md
• runtime/moonriver/tests/xcm_mock/parachain.rs
• runtime/moonbase/tests/xcm_mock/parachain.rs
• runtime/moonbase/tests/xcm_mock/statemint_like.rs
• runtime/moonbeam/src/xcm_config.rs
• runtime/moonbeam/tests/xcm_mock/parachain.rs

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Use one release date for polkadot-stable2603-1.

Line 11 says 2026-05-04, but Line 37 says 2026-05-01. Please align these so the tracker stays internally consistent.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/cherry-picks/UPGRADE-stable2603.md` at line 11, The document contains
two inconsistent dates for the same release identifier `polkadot-stable2603-1`;
update the two occurrences of the release date (the `Target upstream:` line and
the later mention on Line 37) so they match—pick the correct date (either
2026-05-01 or 2026-05-04) and replace the other occurrence so both references to
`polkadot-stable2603-1` use the same release date.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Phase 3's TS-fixture status is stale.

This line still marks the TypeScript fixture work as pending, but this PR already includes TS test/fixture updates. Please mark it done or narrow the remaining follow-up so the checklist matches the shipped work.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/cherry-picks/UPGRADE-stable2603.md` at line 208, Update the checklist
item "- [ ] Update `tests/` TS fixtures referencing changed types/RPCs." in
UPGRADE-stable2603.md to reflect that TS test/fixture updates are included in
this PR: either change the box to checked ("- [x] ...") or revise the
description to narrow the remaining follow-up work (e.g., specify which fixtures
still require a built node binary) so the checklist accurately matches what was
shipped; locate the exact line containing that checklist text and modify it
accordingly.

[coderabbitai]

⚠️ Potential issue | 🟡 Minor

🧩 Analysis chain

🏁 Script executed:

#!/bin/bash
# Verify whether tests currently exercise multi-fungible holdings for this mock.

rg -n -C3 'deposit_asset\(|fungible_assets_iter\(\)\.next\(\)|AssetsInHolding' pallets/xcm-weight-trader/src/mock.rs pallets/xcm-weight-trader/src/tests.rs
rg -n -C3 'MultiAssets|Fungibility::Fungible|AssetId|AssetNotFound' pallets/xcm-weight-trader/src/tests.rs

Repository: moonbeam-foundation/moonbeam

Length of output: 10343

---

🏁 Script executed:

#!/bin/bash
# Inspect where multi-asset holdings are used and what the tests assert.
set -euo pipefail

rg -n "holding_vec\(" pallets/xcm-weight-trader/src/tests.rs

# Show the surrounding test blocks for multi-asset usage.
# (Pick the likely region around the first match.)
awk 'NR>=540 && NR<=700 {print NR ":" $0}' pallets/xcm-weight-trader/src/tests.rs

# Also inspect the mock implementation fully (for any other relevant logic).
awk 'NR>=110 && NR<=200 {print NR ":" $0}' pallets/xcm-weight-trader/src/mock.rs

Repository: moonbeam-foundation/moonbeam

Length of output: 8463

---

🏁 Script executed:

#!/bin/bash
set -euo pipefail

rg -n "holding_vec\(" pallets/xcm-weight-trader/src/tests.rs

# Print small context around every holding_vec usage
rg -n -C5 "holding_vec\(" pallets/xcm-weight-trader/src/tests.rs

# Also search for any direct multi-asset construction without holding_vec
rg -n "subsume_assets\(|new_from_fungible_credit\(" pallets/xcm-weight-trader/src/tests.rs

Repository: moonbeam-foundation/moonbeam

Length of output: 1008

---

Reject or handle multi-asset holdings explicitly in MockAssetTransactor::deposit_asset

deposit_asset pulls only what.fungible_assets_iter().next() and matches that single fungible asset, ignoring any additional fungibles in the AssetsInHolding. The mock’s tests don’t cover the success path with a multi-fungible holding—holding_vec(...) is only used to assert TooExpensive when the supported asset isn’t first—so this mock fidelity gap can hide issues in multi-asset credit/deposit flows.

Suggested guard to keep mock behavior explicit

 	) -> Result<(), (xcm_executor::AssetsInHolding, XcmError)> {
-		// Extract the (single) fungible asset from the holding.
+		// Mock supports exactly one fungible asset; reject multi-asset holdings explicitly.
+		if what.fungible_assets_iter().nth(1).is_some() {
+			return Err((what, XcmError::AssetNotFound));
+		}
+
+		// Extract the (single) fungible asset from the holding.
 		let asset = what.fungible_assets_iter().next();
 		let asset = match asset {
 			Some(asset) => asset,
 			None => return Err((what, XcmError::AssetNotFound)),
 		};

📝 Committable suggestion

‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.

Suggested change

	// Extract the (single) fungible asset from the holding.
	let asset = what.fungible_assets_iter().next();
	let asset = match asset {
	Some(asset) => asset,
	None => return Err((what, XcmError::AssetNotFound)),
	};
	match (asset.id.clone(), asset.fun.clone()) {
	// Mock supports exactly one fungible asset; reject multi-asset holdings explicitly.
	if what.fungible_assets_iter().nth(1).is_some() {
	return Err((what, XcmError::AssetNotFound));
	}
	// Extract the (single) fungible asset from the holding.
	let asset = what.fungible_assets_iter().next();
	let asset = match asset {
	Some(asset) => asset,
	None => return Err((what, XcmError::AssetNotFound)),
	};
	match (asset.id.clone(), asset.fun.clone()) {

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@pallets/xcm-weight-trader/src/mock.rs` around lines 137 - 143, The
deposit_asset implementation currently only reads the first fungible from
what.fungible_assets_iter().next() and silently ignores additional assets in the
AssetsInHolding; update MockAssetTransactor::deposit_asset to explicitly reject
or handle multi-asset holdings by checking for extra fungible assets (e.g., call
fungible_assets_iter() and ensure only one item or test
iterator.next().is_some() after the first) and return a clear error (add or
reuse an XcmError variant such as MultiAssetNotSupported/TooManyAssets) instead
of proceeding, and adjust tests that use holding_vec(...) to expect the new
explicit rejection when multiple fungibles are present.