TL;DR

On 2026-06-30 the Polkadot Asset Hub multi-block NPoS election (round 238) failed to finalize and entered a repeating RevertToSignedIfNotQueued loop. In each loop the signed-phase reopened and every submitted solution had its deposit slashed (~221 DOT per submission).

My signed staking-miner account (15qdf…), one of only two signed miners on Polkadot Asset Hub, lost 443.41 DOT (612.24 -> 168.83). Parity's own staking-miner (16ciP5…) was slashed from 882.51 to 0.02 DOT the same morning. Both (and only) signed miners on the network were slashed, which demonstrates this is a protocol-level fault, not operator error. I am requesting reimbursement of the slashed amount.

1. The account and its role

• Address: 15qdfNWg9rgVYY9NH18R6F8hYGbKjQRVG5pqqPjzQEQF28n3
• Role: Staking-Miner, signed-solution submitter for the Asset Hub NPoS election on Polkadot and Kusama
• It was one of only 2 signed miners on Polkadot Asset Hub. Verified on-chain by decoding MultiBlockElectionSigned.SortedScores across rounds 237 (healthy) and 238 (failed): the only two submitters were this account and Parity's 16ciP5rjt4Yqivi1SWCGh7XsA8BDguV4tnTuyr937u2NME6h.
• It was the primary winner, earning the RewardBase (5 DOT) on most rounds.

2. Before the incident: healthy, winning operations

Daily account total (free + reserved), one row per day, growing by ~+4.98 DOT/day (≈ RewardBase 5 DOT/round minus fees), deposits always returned (reserved = 0):

Steady, predictable winning operation for 10+ days, then a single-day collapse of 443.41 DOT on 2026-06-30.

3. The incident: round 238 (2026-06-30)

Normally the Asset Hub election resolves once, at around 03:41 UTC, in minutes. On 2026-06-30 round 238 failed to produce a queued solution and the runtime's AreWeDone = RevertToSignedIfNotQueuedOf logic reopened the signed phase repeatedly (around every 35 min). The election never finalized, round was still stuck at 238 more than 10 hours later (14:33 UTC). Each reopened cycle accepted a submission and then slashed its deposit.

4. On-chain evidence: this account (block-by-block)

Account total (free + reserved) read via state_getStorageAt at each block hash:

Block hashes:

• 17630498 0x1769a73861da7e62185d7c0757ff19d1c5841facbe22493bd311c0fa07a76a9f
• 17630748 0xa365a72fe5181c1b42ff47a2060fe29aa11ebd00268cbd2b0c5c2edcba53cb1f
• 17630998 0x73fdeb31cec0d2f0c866f6e449048f43353c748148f85d1ff93364ba70529c64
• 17631498 0xaa77a47da6a446f5247b9b737e97ef478074a241596e71b882ec494d2135a1c7
• 17631724 0xc7d53049f3335ab5bcb3340ce29d6493cf8dc7e3b72088b9ed6b64fe5cd0ea54

The reserved deposit dropping to 0 while the total falls by the same amount (not returning to free) is the signature of a slash.

5. Proof this is a protocol fault, not operator error: Parity's own miner

Parity's signed miner 16ciP5rjt4Yqivi1SWCGh7XsA8BDguV4tnTuyr937u2NME6h held a stable ~882 DOT for 13 days, then was drained the same morning through 4 successive slashes:

Both, and the only, signed miners on Polkadot Asset Hub were slashed to the point of being forced offline as a result of the network wide election failure.

5b. Incident reporting & official recognition

• The operator (myself) reported the bug in real time in the Polkadot validator lounge (Matrix) at 06:50 UTC, immediately after observing the slashing, i.e. within minutes of the final slash (06:41:36 UTC): message link. This was a good-faith, prompt report that helped surface the incident to the network.
• Official public acknowledgment by Polkadot Devs: on 2026-06-30 15:00 UTC the official @PolkadotDevs account publicly confirmed the incident: i.e. an official statement that this is a protocol-side bug introduced by a governance change, not operator error. (This account had already flagged it on Matrix 8 hours earlier.)
• Why it happened (root cause): a recent governance change let validators below the minimum self-stake be chilled, and 67 of the 600 validators elected in era 2219, backing ~96.6M DOT, chilled, which dropped the best achievable solution's minimal_stake from ~1,160,585 DOT (accepted 29 Jun) to ~666,297 DOT (30 Jun), below the static MinimumScore threshold of 789,555 DOT (calibrated at 70% of the last 30 pre-AHM relay-chain elections), so every submitted solution was rejected as too low and its deposit slashed each cycle. (Threshold independently confirmed on-chain: MinimumScore.minimal_stake = 7895552765679931 planck; the 29 Jun solution was above it, the 30 Jun solution below.)
• Emergency governance fix: an emergency fix was fast-tracked, Referendum #1914 (Whitelisted Caller / Polkadot Fellowship track, which lowers MinimumScore to match the reduced backing so a valid solution can be queued again.

6. The loss: exact accounting

Reimbursement requested: 443.4065311802 DOT (4434065311802 planck), the exact, on-chain-verifiable balance loss.
(Not claimed, but for context: the foregone RewardBase of 5 DOT for the round that would normally have been won.)

7. Root cause (runtime mechanics, asset-hub-polkadot runtime)

• pallet-election-provider-multi-block is configured with type Fallback = multi_block::Continue ("we chill and do nothing in the fallback") and on-chain election is compiled only under #[cfg(feature = "runtime-benchmarks")], i.e. no on-chain rescue exists in production.
• type AreWeDone = multi_block::RevertToSignedIfNotQueuedOf, when no valid solution is queued, the signed phase reopens and the election is prolonged indefinitely.
• The signed deposit (DepositBase = GeometricDeposit, 100·2ⁿ + page deposit) is slashed when a submission is not queued as the valid solution.
• When the election could not queue a valid solution for round 238 (the minimum-score bar was too high, the exact issue fixed by emergency Referendum #1914, which lowers it), it looped via RevertToSignedIfNotQueued and slashed every submitter's deposit each ~35-minute cycle until both signed miners were exhausted/offline. Because the loop fragmented the signed phase, each miner submitted alone (as the first/only submitter, base deposit 100·2⁰ = 100 DOT + page deposits = 221.2736 DOT), and that full deposit was slashed each cycle.