Establish mainnet-launch: adopt DDC work onto the Mainnet line, preserving master's pallet indices

[jaxter03]

What this is

The Mainnet-targeted port of the DDC work from staging. Base is mainnet-launch, which is master unchanged.

⚠️ Migrations are deliberately not wired — and are NOT yet safe to wire

They arrive present and provably inert: migrations::Unreleased has zero references and pallet_migrations::Config::Migrations is (), so a dry run can demonstrate nothing runs. Wiring and fixing them is a separate PR.

That separation matters, because the storage-migration evaluation found the migration set is not safe to apply to Mainnet today. Dry-run against a Mainnet fork at block 26,666,018 found six blockers, including:

Pallet / storage	Finding
DdcPayouts	v2 skips all 58 Mainnet billing reports (decode fails, translate skips rather than deletes); v3 then reads the same bytes under a misaligned layout that is also 167 bytes, succeeds, and writes values inflated ~4.2e12× into PayoutReceipts. try-runtime's pre/post checks pass vacuously — both count 0.
DdcCustomers	v5_mbm emptied 443 of 535 ledgers into free balances with no deposit registered — Mainnet has zero contracts deployed, and the deposit contract cannot exist until the clusters chain reaches v4. v4_mbm also copies rather than moves, stranding all 535 under the old prefix.
DdcClusters	v3's guard is current_version == 3 against an in-code version of 6 — unsatisfiable, so the whole 2→6 chain stalls at 2.
DdcNodes	The one migration that would work (v0_v2) is commented out.
Idempotency	The check fails with a storage-root mismatch; culprit not yet bisected.

This PR removes three further blockers by construction — the Balances::Holds (17.16M CERE), TechComm::ProposalOf and Scheduler::Agenda value-shape breakage — by appending DdcVerification at index 54 rather than inserting at 40. Those needed no migration once the indices stop moving.

One thing this PR improves for the evaluation itself: keeping master's #[cfg(feature = "try-runtime")] type DisabledValidators = () means a runtime built from this line can drive multi-block migrations to completion. Building from staging could not — that is what stalled evaluation round 1.

Full analysis: docs/MAINNET_STORAGE_MIGRATION_DRYRUN.md, and the live memory-bank page 02-cere-protocol/blockchain/mainnet-storage-migration-evaluation.md.

Why it is a port and not a merge

master and staging are two long-lived lines, not one ahead of the other:

Merge base	ffd39b4c
Commits on master not in staging	201
Commits on staging not in master	1,058

Both migrated to polkadot-sdk = 2512.3.2 independently, so a trial git merge origin/staging produced 72 conflicted files in code neither side solely owns. Every change here was adopted deliberately, file by file and hunk by hunk, with master as the default.

	Selective	Bulk copy would be
Files	91	133
Lines	+9,269 / −9,982	+11,997 / −11,435
runtime/cere/src/lib.rs	+276 / −86	+474 / −304
runtime/cere-dev/src/lib.rs	+190 / −36	+360 / −236

Of 93 hunks in runtime/cere/src/lib.rs, 49 were pure import-path churn (staging drops the polkadot_sdk:: prefix) and were rejected. cere-dev: 46 of 85.

The part that matters most — master-only content preserved

Each of these would have been silently replaced by a bulk copy. The first three are Mainnet-correctness issues.

Kept	Staging's value	Consequence if lost
StateMachine::Polkadot(3367)	StateMachine::Kusama(4009)	Mainnet's ISMP bridge would address the Gargantua testnet coprocessor
EitherOfDiverse<EnsureRoot, EnsureMembers<TechCommCollective, 3>>	EnsureRoot only	Technical Committee loses its ismp origin capability
#[cfg(feature = "try-runtime")] type DisabledValidators = ()	absent	try-runtime cannot author blocks against Mainnet state — this is what stalled storage-migration evaluation round 1
pallet-ismp / ismp-grandpa benchmark forwards	dropped	Hyperbridge crates are outside the umbrella and need them
pallet-ddc-clusters-gov/std forward	dropped	staging drops the forward while keeping the dep — appears to be a staging bug
sc-cli = { default-features = true }	absent	rocksdb, which the umbrella does not forward

Deliberate divergence from both branches

DdcVerification appended at index 54, not inserted at 40

Staging inserts it at 40, shifting every pallet below. Three storage items encode a pallet index in their SCALE-encoded values, and none change storage version — so a version sweep cannot see the damage:

Storage	Mainnet exposure
Balances::Holds (RuntimeHoldReason)	24 accounts, 17,164,730.5167 CERE would read as empty
TechComm::ProposalOf (RuntimeCall)	1 proposal, permanently un-closeable
Scheduler::Agenda (OriginCaller)	1 of 3 slots silently never fires

Appending leaves every existing index untouched, so none of those need a migration. Verified programmatically: zero master indices moved.

ddc-customers call indices

Staging inserts deposit_for at index 3, shifting four extrinsics — a caller targeting unlock_deposit at 3 would instead invoke a deposit. Renumbered so deposit_for lands at 7 and Mainnet's encoding is preserved.

Versions

spec_version 73159 (master + 1), transaction_version 26 — the latter must bump, since ddc-customers gained an extrinsic and fee-handler lost one.

One genuine feature loss: fee-handler

Staging's version is taken, which drops fee_distribution_config and its storage, and moves burn_native_tokens from index 2 to 1.

This is a deliberate rework on staging's side, not an accident — it also adds a WeightInfo type, benchmarks, tests and a mock that master never had. But handle_fee differs in behaviour: master splits fees treasury/fee-pot per stored config; staging sends everything to the fee pot.

Relevant facts: the config has never been set on Mainnet (None), and master never wires FeeHandler into anything — so its splitting logic has never run in production. Staging does wire it, so this PR makes fee handling active for the first time.

Open question for whoever owns fee handling: is the configurable treasury split still wanted? If yes it is ~40 lines on top of staging's version. Where payout fees go is an economic decision, not a porting one.

Verification

cargo check --workspace          exit 0, no errors
cargo test  --workspace          38 of 39 suites green

One test failure, in pallet-ddc-clusters-gov's own mock runtime:

mock_clusters_gov::__construct_runtime_integrity_test::runtime_integrity_tests
panicked at pallet-scheduler-46.0.0/src/lib.rs:453: Must be possible to submit a small lookup

Our pallets/ddc-clusters-gov is byte-identical to staging's (empty diff), and the test exercises the pallet's own mock, not the assembled runtime — so it is very likely pre-existing. I could not confirm that directly: building that pallet standalone on a staging worktree fails earlier, on an unrelated pallet-ddc-staking unresolved module std error. Treat as unconfirmed rather than dismissed.

Review guidance

The commits are ordered and each is self-contained: dependency swap → pallets → contract → runtimes → node → docs → lock. The runtime commit (7e45a665) is where the judgement calls are and is worth the most attention.

docs/MAINNET_LAUNCH_PORT_RECORD.md records every decision with its reasoning.

Follow-ups

• Migration wiring and fixes — separate PR
• External crates track branches, not pinned commits; pin before Mainnet
• ddc-payouts' PR is held pending its pallet-ddc-customers dev-dep being repointed at this branch
• Confirm or fix the ddc-clusters-gov integrity test

🤖 Generated with Claude Code