Runtime 215 — bounded state
Substrate allows a storage item to be unbounded — a vector or map with no maximum. Convenient in development; dangerous in production, because block import time and proof size can grow without limit, and a hostile transaction can bloat state cheaply.
Runtime 215 enforced the rule that every storage item is bounded (BoundedVec, BoundedBTreeMap, explicit maxima) across all 140 pallets.
The audit that verified it learned something worth writing down. The obvious check — grep for pallets declared without_storage_info — finds pallet-level opt-outs. It misses #[pallet::unbounded], a per-item escape hatch that leaves the pallet's storage info intact while exempting one item. The audit had to search for both. The review checklist for new pallets now names both.
Runtime 217 — wire it or retire it
The September audits kept finding the same thing: dispatchables that existed, compiled, passed tests and did nothing real — a DEX that could not swap, reward calls nobody had authorised, IoT trait providers bound to (), buttons in apps that called nothing. Each sat in a status document as done or as pending decision, in green.
Runtime 217 applied a rule: every dispatchable in the runtime either has a real circuit — exercised end to end, with a mutation test proving the path can fail — or is removed, with a storage migration if it held state. "Pending decision" is never displayed as complete.
The same sweep walked every economic constant against TOKENOMICS.json and found the treasury spending window set to 12 hours instead of a year (see the treasury postmortem). Corrected in 217.
Why together
Both upgrades are about the difference between what the runtime declares and what it does. Bounded state closes the gap between declared limits and real ones; wire-or-retire closes the gap between declared features and real ones. Neither adds a capability; both make the existing ones true.
Against the mainnet gate
Bounded state is a prerequisite for weight benchmarking (unbounded items have no meaningful worst case). Wire-or-retire is a prerequisite for the external audits: an auditor's time should go to code that runs.
The old page
Described another network's validators adopting a client version. These two runtimes changed no consensus and added no feature; they made the runtime honest, which on this chain is the update that mattered.
Based on the runtime 215 bounded-state audit and the runtime 217 wire-or-retire sweep (September 2026).