shielded: note selection never checks num_actions against the effective 6-action (20 KiB) transition bound

[DashBot-0001]

Summary

note_selection.rs computes num_actions for fee purposes but never compares it against the effective per-transition action bound that this codebase documents elsewhere. A spend that genuinely needs more than 6 input notes is therefore selected, built, Halo 2-proved, and only then rejected at submission with:

Grpc(Status { code: InvalidArgument, message: "... exceeds maximum size of 20480 bytes" })

The wasted work includes proof generation, which is the most expensive step in the flow.

The bound is already known and documented here

packages/rs-platform-version/src/version/system_limits/v3.rs:

// NOTE: the Halo 2 proof grows with the action count (~2,273 B/action on top of
// the 408 B serialized action), so a transition's on-wire size is ~2,681 B per
// action + ~2,930 B fixed (measured: 2 actions → 8,294 B, 6 → 19,018 B).
// The effective per-transition action bound under the 20 KiB
// max_state_transition_size is therefore 6, NOT this cap — 16 only becomes
// reachable if the size limit is raised. Pinned by dpp's
// seed_pool_batch_fits_max_state_transition_size signing test.
max_shielded_transition_actions: 16,
max_state_transition_size: 20480, //20 KiB

packages/rs-platform-wallet/src/wallet/shielded/seed_pool.rs caps itself accordingly:

/// The binding constraint is NOT the 16-action consensus cap but the 20 KiB
/// transaction-size limit ... 2 actions → 8,294 B, 6 → 19,018 B,
/// 7 → 21,699 B (rejected by tenderdash as "Tx too large").
/// 6 actions is the largest batch that fits
const MAX_ACTIONS_PER_BATCH: usize = 6;

What the spend path does and does not do

To be fair to the code: selection is action-count aware.

• select_notes is greedy largest-first and is documented as "minimizes the number of inputs, which keeps the Orchard action count low and reduces proof generation time and fees" (note_selection.rs)
• select_notes_with_fee iterates to fee convergence and computes num_actions = selected.len().max(min_actions)
• It already has the up-front-rejection pattern: ShieldedNoUnspentNotes and ShieldedInsufficientBalance { available, required }

What is missing is a comparison of that num_actions against the bound. MAX_ACTIONS_PER_BATCH, max_shielded_transition_actions and max_state_transition_size appear only in seed_pool.rs within rs-platform-wallet — there are no references in note_selection.rs, operations.rs or coordinator.rs (checked on feat/platform-wallet-storage-rehydration).

Reproduction (testnet)

Wallet with notes fragmented across many small inbound shields, then ShieldedTransfer to self at increasing amounts:

amount (credits)	pool notes delta	fee (credits)	result
2,000,000,000	+2	162,851,200	ok
5,500,000,000	+4	225,702,400	ok
12,000,000,000	+6	288,553,600	ok (ceiling)
25,000,000,000	0	—	rejected, 20480

No ShieldedMerkleWitnessUnavailable / invalid frontier in the logs for any of these, so this is unrelated to #4144.

The binding variable is input note count, not amount. Same amount, two outcomes:

wallet state	amount	result
fragmented	25,000,000,000	rejected (20480)
after intervening self-transfers consolidated the notes	same amount	accepted (+2 notes, fee 162,851,200)

Why this matters for self-custody

Note fragmentation can put a wallet into a state where the balance cannot be moved in a single transaction. The remedy — consolidating via z→z self-transfers — is subject to the same 6-action bound, so it converges over several rounds rather than in one step. None of that is discoverable from the error the user receives.

Suggested fix

Add an action-count check alongside the existing ShieldedInsufficientBalance check in select_notes_with_fee, reusing the constant that already exists in seed_pool.rs. On overflow, either split automatically or return an actionable error (e.g. "requires N transactions; consolidate first") rather than building and proving a transition the codebase already knows will be rejected.

Fee observation (possibly worth documenting separately)

Fees are linear in action count: 162,851,200 / 194,276,800 / 225,702,400 / 288,553,600 for 2 / 3 / 4 / 6 output notes — a constant +31,425,600 per action. Single-note spends look like a flat fee, which is what a casual test would show.

---

Testing done on testnet against a self-built DET v1.0-dev pinning feat/platform-wallet-storage-rehydration. Investigation and this report were produced with AI assistance (Claude); all figures are from executed runs, and the source citations were re-checked against this repo before filing.

[DashBot-0001]

Follow-up: I tried to measure the "several rounds" consolidation cost, and the result is worse than "several rounds".

The report says the remedy is consolidating via z→z self-transfers and that it "converges over several rounds rather than in one step". I set out to put a number on that. The number turns out to be the wrong question, because the caller cannot steer which notes get consolidated.

Measured (testnet, one session, self-transfers to own shielded address)

#	amount (credits)	actions	fee (credits)	net change in wallet note count
1	2,000,000,000	2	162,851,200	0
2	3,200,000,000	2	162,851,200	0
3	5,120,000,000	5	257,128,000	−3
4	8,192,000,000	2	162,851,200	0
5	13,107,200,000	3	194,276,800	−1
6	20,971,520,000	2	162,851,200	0
7	33,554,432,000	—	—	failed, but not on size — see note below

The action count does not track the amount. Row 6 moves 20.97 B credits using 2 input notes, while row 3 moves a quarter of that using 5. select_notes is greedy largest-first, so the action count is decided by whether a single sufficiently large note happens to exist, not by how much is being spent.

Because a z→z self-transfer always produces 2 outputs, a 2-action spend is net zero — it consumes two notes and creates two. Only rows 3 and 5 consolidated anything.

An earlier run the same day makes the point sharper: 12 self-transfers, every one of them 2-action, 1,954,214,400 credits of fees, zero notes eliminated. Combined over both runs: 18 self-transfers, 3,057,024,000 credits (~0.0306 DASH) in fees, 4 notes eliminated.

Two independent readings agree

Action counts were taken from the on-chain pool_notes_delta (the commitment tree is append-only, so each action contributes one output commitment) and cross-checked against the linear fee model in this report (2 → 162,851,200, step 31,425,600). All six rows agree on both paths, so no third-party pool activity contaminated these figures.

What I can and cannot conclude

Measured: action count is independent of amount; 2-action self-transfers are net-zero; the observed consolidation rate is very low per fee spent.

Inferred, not observed: that small notes are systematically stranded at the bottom of the greedy ordering. I could not verify this directly — there is no way to enumerate a wallet's notes. det-cli exposes nine shielded subcommands and none of them lists notes or reports note count, so a user cannot see how fragmented their wallet is until a spend is rejected. That gap seems worth closing independently of the selection fix.

Suggestion, in addition to the up-front action-count check

An explicit consolidation operation would be more useful than asking users to approximate one with self-transfers. Selecting the smallest N notes (rather than largest-first) up to the 6-action bound would make each round deterministic and net −4, instead of the current situation where a round may consolidate nothing and the caller cannot tell in advance.

Note on row 7: it failed with no size error at all — it hit the epoch-proof failure that #4231 fixes, whose side effect is banning DAPI addresses until the pool is exhausted. Measurements for that are posted on #4231. Unrelated to this issue, but it is why row 7 is not evidence of a size ceiling.

---

Testnet, self-built DET v1.0-dev pinning feat/platform-wallet-storage-rehydration. All figures from executed runs. Produced with AI assistance (Claude).