Upgrade to Polkadot 2512

.cargo/audit.toml

@@ -1,39 +1,52 @@
 [advisories]
 ignore = [
-	# Coming from outdated libp2p and litep2p dependencies from which
-	# some Polkadot libraries are dependent on. They will be updated
-	# once we update Polkadot packages to latest version
-	"RUSTSEC-2024-0336",
-	"RUSTSEC-2024-0421",
-	"RUSTSEC-2025-0009",
-	"RUSTSEC-2024-0363", # Maybe we should fix the sqlx dependency in our frontier branch
-	# The next two coming from outdated wasmtime dependency from wich polkadot
-	# and substrate crates are dependent on. Unfortunally seams that also the
-	# newver versions still depend from the same wasmtime version.
-	"RUSTSEC-2023-0091", # LOW severity
-	"RUSTSEC-2024-0438", # Just affect Windows where devices are not fully sandboxed.
-	"RUSTSEC-2024-0442", # FROM THE VUNERABILITY DESCRIPTION
-    # Note: this is an internal-only crate in the Wasmtime project not intended for external
-    # use and is more strongly signaled nowadays as of bytecodealliance/wasmtime#10963.
-    # Please open an issue in Wasmtime if you're using this crate directly.
-    # ** We don't use this crate directly, so we can ignore it. **
-	"RUSTSEC-2025-0055", # coming from indirect dependency tracing-subscriber
-	"RUSTSEC-2025-0118", # coming from indirect dependency wasmtime v0.8.1.
+	"RUSTSEC-2025-0009", # ring v0.16.20 — stale lockfile entry (libp2p-quic -> libp2p-tls -> rcgen -> ring 0.16).
+	# Nothing in the workspace actually depends on this chain (`cargo tree` confirms it).
+	# It remains in Cargo.lock because Cargo always resolves optional dependencies in the
+	# lockfile (libp2p's optional `quic` feature pulls it in). Cannot be removed.
+
+	"RUSTSEC-2025-0055", # coming from indirect dependency tracing-subscriber v0.2.25
+	# via ark-relations v0.4.0 (and even v0.5.1 still depends on it).
+	# The std feature of ark-relations unconditionally enables tracing-subscriber 0.2.x.
+	# This is an upstream arkworks issue; no patched version of ark-relations avoids it.
+
+	"RUSTSEC-2025-0118", # coming from indirect dependency wasmtime v35.0.0 via sc-executor-wasmtime v0.43.0.
 	# From https://rustsec.org/advisories/RUSTSEC-2025-0118 ->
 	# https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hc7m-r6v8-hg9q
-	# "This is a bug in Wasmtime's safe Rust API. It should not be possible to cause unsoundness
-	# with Wasmtime's embedding API if unsafe is not used. Embeddings which do not use the wasm
-	# threads proposal nor created shared memories nor actually share shared memories across
-	# threads are unaffected. Only if shared memories are created across threads might an
-	# embedding be affected."
-	# We fall in the case where we don't use wasm threads at all.
-	"RUSTSEC-2026-0002", # coming from indirect dependency in smoldot-light@v0.9.0 and libp2p-identify@0.43.1.
+	# "Embeddings which do not use the wasm threads proposal nor created shared memories
+	# nor actually share shared memories across threads are unaffected."
+	# Substrate explicitly sets config.wasm_threads(false) in sc-executor-wasmtime.
+
+	"RUSTSEC-2026-0002", # lru v0.12.5 unsound IterMut — used by smoldot-light v0.9.0 and libp2p-identify v0.43.1
+	# (polkadot-sdk transitive dependency).
 	# For smoldot-light@v0.9.0, we looked into the code at https://github.com/smol-dot/smoldot.git@light-js-deno-v1.0.17;
 	# all the usage of `lru::LruCache` don't use `iter_mut()` or iterate over `&mut` cache reference.
 	# For the libp2p-identify@0.43.1, we looked into the code at https://github.com/libp2p/rust-libp2p.git@libp2p-identify-v0.43.1
 	# and in protocols/identify/src/behaviour.rs we can see that there isn't any mutable iterator used for
 	# `lru::LruCache`.
 	# We can conclude that the unsound code is never exercised.
+
+	"RUSTSEC-2026-0006", # coming from indirect dependency wasmtime v35.0.0 via sc-executor-wasmtime v0.43.0.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0006 ->
+	# https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-vc8c-j3xm-xj73
+	# The vulnerability (segfault or out-of-sandbox load with f64.copysign on x86-64) only triggers
+	# when signals-based-traps is DISABLED in the wasmtime Config.
+	# Substrate's sc-executor-wasmtime uses wasmtime::Config::new() which has signals_based_traps
+	# enabled by default, and never disables it. Therefore this code path is never exercised.
+
+	"RUSTSEC-2026-0021", # coming from indirect dependency wasmtime v35.0.0 via sc-executor-wasmtime v0.43.0.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0021 ->
+	# https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-243v-98vx-264h
+	# Panic adding excessive fields to a `wasi:http/types.fields` instance.
+	# This is WASI-only, affecting the `wasmtime-wasi-http` crate.
+	# Substrate does not use WASI at all — `wasmtime-wasi` is not in our dependency tree.
+
+	"RUSTSEC-2026-0020", # coming from indirect dependency wasmtime v35.0.0 via sc-executor-wasmtime v0.43.0.
+	# From https://rustsec.org/advisories/RUSTSEC-2026-0020 ->
+	# https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-852m-cvvp-9p4w
+	# Guest-controlled resource exhaustion in WASI implementations (WASIp1/WASIp2).
+	# This is WASI-only. Substrate does not use WASI at all — `wasmtime-wasi` is not in
+	# our dependency tree.
 ]
 informational_warnings = ["unmaintained", "yanked"]
 

.cargo/config.toml

@@ -1,3 +1,3 @@
 [target.x86_64-unknown-linux-gnu]
 linker = "/usr/bin/cc"
-rustflags = ["-C", "link-arg=-fuse-ld=lld"]
+rustflags = ["-C", "link-arg=-fuse-ld=lld", "-C", "link-arg=-lstdc++"]

.claude/commands/runtime/describe_cfg.md

@@ -0,0 +1,118 @@
+---
+description: >
+  Describe pallet configuration types from the vflow-runtime crate.
+  Provide a pallet name and optionally specific type names to describe.
+  If no types are given, all types from the pallet Config impl are listed
+  and you are asked which ones to describe.
+argument-hint: <pallet> [type1 type2 ...]
+---
+
+# Describe Runtime Configuration Types
+
+You are analyzing pallet configuration types for the `vflow-runtime` crate.
+
+## Input
+
+- **Pallet**: `$0`
+- **Types to describe**: `$ARGUMENTS`
+
+If `$0` is empty or missing, ask the user for the pallet crate name (e.g. `pallet_collator_selection`, `pallet_session`, `pallet_aura`).
+
+## Step 1: Find the Config implementation
+
+Search the `vflow-runtime` crate source (under `runtime/vflow/src/`) for
+`impl $0::Config for Runtime` (or the appropriate pattern — some pallets use
+generic instances like `pallet_bags_list::Config<VoterBagsListInstance>`).
+
+Read the full `impl` block to extract all associated type assignments.
+
+## Step 2: Determine which types to describe
+
+Parse the arguments after the pallet name. If specific type names were provided
+(e.g. `XcmConfig Filter Sort`), describe only those types.
+
+If NO type names were provided beyond the pallet name, list ALL associated types
+found in the `impl` block and ask the user which ones they want described.
+Present them as a numbered list so the user can pick.
+
+## Step 3: For each selected type, provide
+
+For each type, research thoroughly using:
+- The pallet source code in the local cargo registry (`~/.cargo/registry/src/`)
+  to find the trait definition, doc comments, and trait bounds
+- The polkadot-fellows/runtimes repository (https://github.com/polkadot-fellows/runtimes)
+  for all the system parachains on Polkadot and Kusama, such as Asset Hub and Collectives
+- The Moonbeam repository (https://github.com/moonbeam-foundation/moonbeam) for the Moonbeam
+  parachain runtime
+
+Produce the following for each type:
+
+### 3a. Description
+
+What this type is and what trait bound it has. Include the doc comment from
+the pallet's `Config` trait if available.
+
+### 3b. Purpose and application examples
+
+How this type is used within the pallet. What behavior does it control?
+What happens with different values? Reference specific pallet code paths
+where this type is used (e.g. hooks, extrinsics, internal functions).
+
+### 3c. Possible values
+
+List the concrete types that can satisfy the trait bound. For each, explain
+the behavioral difference:
+- SDK-provided implementations (e.g. `()`, `ConstU32<N>`, `ConstBool<B>`,
+  `Disabled`, `HoldConsideration`, etc.)
+- Common patterns from production runtimes
+
+### 3d. System parachains configurations
+
+Look up how this type is configured in the system parachains for the Polkadot and Kusama relay chain
+runtimes from https://github.com/polkadot-fellows/runtimes.
+
+To determine the correct source version, check the currently deployed spec
+version on each chain. For example:
+- Asset Hub: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fpolkadot-asset-hub-rpc.polkadot.io
+- Collectives: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fpolkadot-collectives-rpc.polkadot.io
+- Moonbeam: https://polkadot.js.org/apps/?rpc=wss%3A%2F%2Fmoonbeam.api.onfinality.io%2Fpublic-ws
+
+Then find the corresponding tag/release in the polkadot-fellows/runtimes repo
+and look at the exact configuration. Present a comparison table:
+
+| Parameter | Asset Hub | Collectives | Moonbeam | VFlow |
+|-----------|----------|--------|--------|----------|
+| `TypeName` | value | value | value | value |
+
+### 3e. VFlow current value
+
+Show the exact value configured in the vflow-runtime `impl` block, including
+the constant/parameter definition if it references a `parameter_types!` value
+or a `const`.
+
+## Output format
+
+For each type, use this structure:
+
+```
+#### `TypeName`
+
+**Trait bound**: `TraitName<...>`
+
+**Description**: ...
+
+**Purpose**: ...
+
+**Possible values**:
+- `Value1` -- explanation
+- `Value2` -- explanation
+
+**Asset Hub/Collectives/Moonbeam comparison** (spec version XXXX):
+
+| Parameter | Asset Hub | Collectives | Moonbeam | VFlow |
+|-----------|----------|--------|--------|----------|
+| `TypeName` | ... | ... | ... | ... |
+
+**VFlow value**: `type TypeName = ...;` (defined as `CONST_NAME = value`)
+```
+

.claude/skills/cargo-audit/SKILL.md

@@ -0,0 +1,150 @@
+---
+name: Cargo Audit Triage
+description: >
+  This skill should be used when the user asks to "run cargo audit",
+  "triage cargo audit", "fix audit vulnerabilities", "update audit.toml",
+  "check cargo audit ignores", "clean up audit ignore list",
+  "review audit.toml", "remove stale audit ignores", or mentions
+  resolving Rust security advisories or RUSTSEC identifiers. Provides a
+  systematic workflow for
+  analyzing each vulnerability, attempting updates, and writing motivated
+  ignore entries when updates are not possible.
+---
+
+# Cargo Audit Triage
+
+Systematic workflow for running `cargo audit`, analyzing each reported
+vulnerability, attempting dependency updates, and documenting justified
+ignores in `.cargo/audit.toml`.
+
+## Workflow Overview
+
+1. Read the existing `.cargo/audit.toml` ignore list for context
+2. Run `cargo audit`
+3. For each vulnerability, follow the resolution decision tree
+4. For existing ignore entries, verify they still fire
+
+## Step 1: Read Existing Ignore List
+
+Read `.cargo/audit.toml` before running the audit. Study the existing
+ignore entries and their motivations to understand the project's
+conventions and writing style for ignore comments.
+
+## Step 2: Run Cargo Audit
+
+```bash
+cargo audit
+```
+
+Collect all reported vulnerabilities (errors) and warnings. Separate them
+into:
+- **Vulnerabilities** (errors) — must be resolved or ignored with motivation
+- **Warnings** (unmaintained, yanked) — informational, no action required
+
+## Step 3: Resolve Each Vulnerability
+
+For each vulnerability, follow this decision tree in order.
+
+### 3a. Identify the Dependency Chain
+
+```bash
+cargo tree -i <crate>@<version> --depth 3
+```
+
+Determine whether the vulnerable crate is:
+- A **direct dependency** (listed in a workspace or crate `Cargo.toml`)
+- A **transitive dependency** (pulled in by another crate)
+
+If `cargo tree` reports "nothing to print", try `--target all --edges all`.
+If still nothing, the entry may be a **stale lockfile artifact** — verify
+by searching `Cargo.lock` directly:
+
+```bash
+grep -B30 '"<crate> <version>"' Cargo.lock | grep 'name ='
+```
+
+### 3b. Attempt to Update
+
+**Direct dependency with a patched version available:**
+Update the version in `Cargo.toml` to the fixed version and run
+`cargo check` to verify compatibility.
+
+**Transitive dependency with a compatible patched version:**
+Run `cargo update -p <crate>@<version>` to attempt an in-place update.
+Verify with `cargo audit` afterward.
+
+**Transitive dependency where the patched version is incompatible:**
+Check if the **parent crate** has a newer version that uses the patched
+dependency:
+
+```bash
+cargo search <parent-crate>
+cargo info <parent-crate>@<latest-version>
+```
+
+If a compatible parent update exists, update it. If the parent is pinned
+by an upstream framework (e.g., polkadot-sdk), updating may not be feasible.
+
+### 3c. Analyze the Advisory (When Update Is Not Possible)
+
+When no update path exists, perform a thorough analysis before ignoring:
+
+1. **Read the advisory page** at the URL from the audit output
+2. **Read the upstream security advisory** (usually linked from the
+   rustsec page, often a GitHub Security Advisory / GHSA)
+3. **Identify the trigger conditions** — what configuration, API usage,
+   or code path activates the vulnerability
+4. **Check the project's actual usage** — read the relevant source code
+   to verify whether the trigger conditions are met
+
+Common safe-to-ignore patterns:
+- Vulnerability requires a feature/config that is not enabled
+  (e.g., `wasm_threads(false)` means thread-related vulns don't apply)
+- Vulnerability affects a platform not targeted
+  (e.g., Windows-only issue on a Linux-only deployment)
+- Vulnerable code path is never exercised
+  (e.g., `IterMut` on a cache that is only read)
+- Crate is a stale lockfile entry not actually used by the workspace
+
+### 3d. Add Ignore Entry
+
+Add the advisory to `.cargo/audit.toml` with a **motivated comment**
+explaining:
+- Where the dependency comes from (the dependency chain)
+- A link to the advisory and/or upstream security advisory
+- **Why it is safe to ignore** — the specific condition that makes the
+  project unaffected
+
+Follow the comment style already present in the file. See
+`references/ignore-examples.md` for examples.
+
+## Step 4: Verify Existing Ignore Entries
+
+To clean up the ignore list:
+
+1. Remove **all** entries from the `ignore` list
+2. Run `cargo audit` with the empty list
+3. Note which advisories still fire
+4. Re-add only the entries that still fire, with refreshed comments
+5. Remove entries that no longer fire (dependency was updated or removed)
+
+## Ignore Comment Format
+
+Each ignore entry should follow this pattern:
+
+```toml
+"RUSTSEC-YYYY-NNNN", # <crate> v<version> — short summary of the chain.
+# Link to advisory and/or upstream security advisory.
+# Explanation of why it is safe to ignore in this project's context.
+```
+
+Keep comments concise but complete. The goal is that a future reader can
+understand the decision without re-investigating.
+
+## Additional Resources
+
+### Reference Files
+
+- **`references/ignore-examples.md`** — Real-world examples of well-motivated
+  ignore entries from a production Cargo workspace
+