Resubmit the proposal's inner call on multisig execute

[n13]

Updates the CLI for the runtime in chain#675.

Goes with keystone3-firmware #19 and quantus-apps #622 and #623.

What changed on chain

multisig.execute now takes the call it dispatches, and the chain only dispatches it if it re-encodes to the stored proposal bytes:

pub fn execute(origin, multisig_address, proposal_id, call: Box<RuntimeCall>)

handle_execute reads the proposal and resubmits those exact bytes.

Both flows come from one change. submit_transaction already routes a cold wallet through sign_and_submit_cold, so the payload the Keystone shows now carries the executed call. A test asserts that directly on the raw signer payload.

One catch. approve takes BoundedVec<u8>, which is length prefixed. execute takes Box<RuntimeCall>, which is inline with no prefix. So the stored bytes get decoded back into a call rather than passed through. decode_proposal_call fails on bytes this build cannot decode, which beats submitting a call the chain rejects. handle_approve now shares its proposal fetch. Codegen gained codec::Decode and Encode derives for the call surface, recorded in regenerate_metadata.sh so future regens keep them.

Call size limit

Propose and execute refuse a call over 10 KiB, which is the chain's own MaxCallSize. Using the chain's number matters. Anything smaller would refuse proposals the chain accepts, and then no signer could act on them. The five propose call sites now share one build_propose_tx that enforces it.

Runtime surface changes

Regenerating is not only the execute field. The new runtime removes a lot:

Removed on chain	What we did
pallet-recovery	removed the recovery command, its exercise phase, scripts/recovery_examples.sh and the README section
Treasury set_treasury_portion and TreasuryPortion storage	removed tech-referenda submit-treasury-portion, dropped the portion line from treasury info
Balances force_* and upgrade_accounts	removed the upgrade_accounts exercise step
Utility everything except batch_all	see below
ReversibleTransfers::GuardianIndex	see below

Utility phase. It only covered removed calls. It now covers both halves of what batch_all promises: every item applies on success, and none apply when a later item fails. fuzz moves from batch to batch_all.

Governance exercise. It used set_treasury_portion as its referendum payload. It now re-sets the treasury account to its current value. Still a real root call enacted through a referendum, without changing state the exercise does not own.

GuardianIndex. The guardian to accounts reverse index is gone. fetch_entrusted_accounts replaces it by iterating HighSecurityAccounts and keeping the entries naming the guardian. high-security entrusted and wallet list had separate lookups before and now share it.

spec_version 147 and transaction_version 6 were already in COMPATIBLE_RUNTIMES.

QR fixture generator

New examples/generate_qr_fixtures.rs. It builds a signing request per supported call, encodes it through the bundled chain metadata, wraps it in the wallet envelope, UR-encodes it, and writes the QR frames as SVG plus a viewer page.

The output is committed in quantus-apps under cold-wallet-app/test/fixtures/qr and is parsed by tests in both wallets, so all three parsers are checked against the same bytes.

SVG rather than PNG so the corpus needs no image toolchain and works offline. Horizontal runs are merged into one path, which makes a frame about 5 KB instead of 100 KB.

cargo run --example generate_qr_fixtures -- ../quantus-apps/cold-wallet-app/test/fixtures/qr

Tests

decode_proposal_call round-trips the stored bytes through decode and encode, which is the byte equality the chain checks. It rejects undecodable bytes, trailing bytes and oversized calls. execute is asserted to encode its inner call inline. test_cold_payload_carries_the_executed_call walks the raw signer payload the Keystone receives and asserts the inner call sits inline after the proposal id.

cargo test --lib passes, 308 tests. ./clippy.sh is clean.

Runtime 148 and the signing context

The chain released v0.11.1 while this PR was open. Two things broke against it, and both are fixed here.

Bindings were a runtime behind. This branch bundled spec 147 metadata. v0.11.1 reports spec 148 / transaction 6, and spec 148 adds Origins to the recursive OriginCaller/RuntimeCall shape. Static subxt validation then failed with Metadata(IncompatibleCodegen), which hit fee estimation on any call and the new multisig.execute payload in particular, since it now carries a generated RuntimeCall. src/quantus_metadata.scale and src/chain/quantus_subxt.rs are regenerated from a live v0.11.1 dev node through regenerate_metadata.sh, so the recursive codec::Decode/Encode derives are preserved. (148, 6) joins COMPATIBLE_RUNTIMES.

Extrinsic signatures now need a FIPS 204 context. Chain commit 85296439 binds on-chain signatures to the context string QUANTUS_EXTRINSIC. ML-DSA sign/verify always took a ctx argument; the published qp-dilithium-crypto still passes None, so sp_core::Pair::sign produces a signature the node rejects with "Transaction has a bad signature". I reproduced that against a live v0.11.1 node before fixing it.

New src/chain/signing.rs signs and verifies under that context, going straight to qp-rusty-crystals-dilithium, which does expose ctx. Every extrinsic signature the CLI makes or checks goes through it: the three subxt Signer impls, the cold-sign-sim device simulator, and the QR response check in validate_signature_response. Nothing else changes signing paths, and litep2p node identity is not involved.

main is merged in for the dilithium 4.1.1 and zk-circuits 4.3.0 bumps, which the v0.11.1 chain is built against.

The QR fixture generator moves to SPEC_VERSION = 148. The committed corpus in quantus-apps is not regenerated here: that repo pins bundledSpecVersion = 147 and its test asserts the manifest matches, so the corpus has to move with the app's own metadata bump. That is tracked separately, along with the same signing-context change for the Dart SDK, the cold wallet and the mobile wallet.

Tests

src/chain/signing.rs covers the round trip for ML-DSA-87 and ML-DSA-65 and asserts that an empty-context signature does not verify as an extrinsic signature, which is exactly what the node rejects.

Live exercise against chain v0.11.1

A full run against a v0.11.1 dev node (spec 148 / tx 6) passed 49 of 50 steps, including [multisig] lifecycle, which creates a 2-of-3 multisig, approves and executes a proposal, and verifies the payout. That is the flow this PR changes. The one failure was this PR's own new rollback assertion: it expected an insufficient-funds error but sent an amount near u128::MAX, which underflows the balance arithmetic first and returns Arithmetic(Underflow). The step now sends twice the sender's balance and gets Token(FundsUnavailable). The utility phase re-ran 5 of 5 after the fix.

Before the signing-context fix, every extrinsic was rejected at the pool with "Transaction has a bad signature" and the run could not get past funding the ephemeral accounts.

Follow-ups in other repos

The same context change is needed wherever else a Quantus extrinsic is signed. Both are open:

• quantus-apps #626: the SDK's Rust binding, which covers the cold wallet and the mobile wallet, plus the same dependency bumps.
• keystone3-firmware: rust/apps/quantus/src/lib.rs signs with ctx = None, so the device's signatures are rejected the same way.

[n13]

Reviewer model: GPT Sol

Verdict (advisory): Request changes

Blocking finding:

• [P2] Require the rollback exercise to observe the intended on-chain failure (src/cli/exercise/scenarios/utility.rs:79). submit_ok(...).await can fail because batch_all reached the deliberately failing second transfer, but it can also fail because of an RPC error, pool rejection, metadata mismatch, or failure to include the extrinsic. Discarding every error leaves the fresh recipient at balance zero, so the next check reports a successful rollback even when the batch never ran. Validate a specific expected dispatch failure (and therefore inclusion) before using the unchanged balance as rollback evidence.

Validation on exact head 65d40ac6c9bb3c3ab422ed3f26ce828e6106cbe4:

• git diff --check 6245cd0...65d40ac: passed.
• cargo test --locked --lib: 308 passed.
• SKIP_CIRCUIT_BUILD=1 cargo clippy --all-targets --locked -- -D warnings: passed.
• cargo run --locked --example generate_qr_fixtures -- <temp-dir>: generated 9 cases / 60 files; the output matched the referenced quantus-apps fixture corpus byte-for-byte.
• GitHub CI at review time: format, dependency cooldown, Clippy/docs, and security audit passed; Ubuntu/macOS build-test jobs and examples were still running.

[n13]

Reviewer model: GPT Sol

Verdict (advisory): Request changes

Blocking finding:

• [P1] Regenerate the bindings for the released spec-148 runtime (src/quantus_metadata.scale; examples/generate_qr_fixtures.rs:20). This head bundles spec 147 / transaction 6 metadata, while the current chain release, v0.11.1, reports spec 148 / transaction 6. The CLI accepts that node with only its newer-runtime warning, but a utility-only exercise against a fresh v0.11.1 dev node fails during fee estimation with Metadata(IncompatibleCodegen). Spec 148 adds Origins to the recursive OriginCaller/RuntimeCall shape; consequently the changed multisig.execute payload, which now contains a generated RuntimeCall, fails the same static Subxt validation on the current release. Please regenerate the metadata and bindings against spec 148 with the existing recursive codec derives, add (148, 6) to the compatible runtime list, update the fixture spec version/corpus as needed, and rerun the live exercise.

The previous rollback-exercise blocker is fixed at this head: the scenario now requires the intended insufficient-funds dispatch failure before checking the rolled-back balance.

Validation on exact head 1ee52ef9bd48890ec4389e88c6cd2dcca8b164e1:

• git diff --check, pinned nightly formatting, Taplo formatting, and SKIP_CIRCUIT_BUILD=1 cargo clippy --all-targets --locked -- -D warnings: passed.
• cargo test --locked --lib: 308 passed after generating the circuit binaries.
• Regenerating quantus_subxt.rs from the bundled metadata reproduced the committed file exactly.
• The QR generator produced 9 cases / 60 files matching the shared quantus-apps fixture corpus byte-for-byte.
• Live exercise against chain v0.11.1 (spec 148 / transaction 6): failed at static payload validation with Metadata(IncompatibleCodegen).
• GitHub CI: all eight current checks passed.

[n13]

Reviewer model: GPT Sol

Verdict (advisory): Request changes

Blocking finding:

• [P1] Preserve the signature-context boundary for pre-148 runtimes (src/chain/signing.rs:21-30; src/config/mod.rs:19-30). This head signs every hot-wallet and simulated-cold-wallet extrinsic with Some(b"QUANTUS_EXTRINSIC"), but QuantusClient::new still accepts specs 134–147 as compatible. Those runtimes use the previous empty-context verifier (for example, chain v0.10.0/spec 145 calls ML-DSA verification with None), and FIPS 204 contexts are domain-separated, so they reject these signatures as Transaction has a bad signature. Make signing and cold-response verification select the context from the connected runtime, or remove/reject all pre-context runtime pairs before any transaction can be signed. Please add a regression test covering both an older accepted pair and spec 148.

The previous spec-148 metadata and utility rollback blockers are fixed at this head. I found no additional blocking issue in the multisig call reconstruction, runtime-surface removals, or regenerated metadata.

Validation on exact head 4e6fbb84cf7dc1588410d7d13687cae76134e433:

• git diff --check ecc1f363...4e6fbb84, pinned nightly Rust formatting, and Taplo formatting: passed.
• cargo test --locked --lib: 311 passed.
• SKIP_CIRCUIT_BUILD=1 cargo clippy --all-targets --locked -- -D warnings: passed.
• Regenerating quantus_subxt.rs from the bundled metadata with the recursive codec derives reproduced the committed file exactly.
• Chain history verification: the pre-context spec-147 source and released v0.10.0/spec 145 verifier use no ML-DSA context; v0.11.1/spec 148 uses QUANTUS_EXTRINSIC.
• GitHub CI at review time: format, Ubuntu build/test, Clippy/docs, security audit, and dependency checks passed; macOS build/test and examples were still running.

[n13]

Reviewer model: GPT Sol

Verdict (advisory): Approve

No blocking findings. The previous signing-context blocker is fixed at this head: the connected runtime now selects the empty context for the listed pre-148 runtimes and QUANTUS_EXTRINSIC for spec 148 and newer, and that selection reaches both hot-wallet signing and cold-response verification. The regression coverage pins both sides of the boundary and rejects cross-context signatures.

Non-blocking documentation follow-up:

• README.md:545 and src/cli/treasury.rs:3,29,39 still describe the treasury as receiving a portion of mining rewards, while this PR removes TreasuryPortion and the runtime now funds the treasury independently of an ongoing reward split. Updating that wording would keep the CLI documentation aligned with the new runtime surface.

Validation on exact head cd9a0642cf58febf4d8e8978e30d84f74b0a5255:

• git diff --check ecc1f363...cd9a064, pinned nightly formatting, and Taplo formatting: passed.
• cargo test --locked: 315 library tests and 313 binary tests passed; one generated-binding doctest was ignored.
• SKIP_CIRCUIT_BUILD=1 cargo clippy --all-targets --locked -- -D warnings: passed.
• Regenerating quantus_subxt.rs from the bundled metadata with the recursive codec derives reproduced the committed file exactly.
• generate_qr_fixtures produced the expected spec-148 / transaction-6 corpus: 9 cases and 60 files.
• Live read-only compatibility check against Planck (spec 144 / transaction 3): passed.
• GitHub CI: all eight current checks passed, including Ubuntu/macOS build-test, Clippy/docs, examples, and security audit.