diff --git a/docs/fud-ledger.md b/docs/fud-ledger.md
index 35cd23476..a3b1c34c6 100644
--- a/docs/fud-ledger.md
+++ b/docs/fud-ledger.md
@@ -2091,6 +2091,14 @@ Per tier: no balance anyone can see is wrong (0.0003 percent of a share on the r
 
 Fix (switched, since it changes the EVM state transition): `Params::subsidy_per_block_activation_daa`, a new object field in the subsidy family, never on every network as compiled, in the digest once set; from that chain-block DAA the service fills `SegmentBlock::subsidy` with the block's own `block_subsidy(daa)` and the executor splits it. Known failed first in the executor's test: two blocks a second apart on the ramp and two straddling the first halving boundary, the chain block's subsidy without the rule and their own with it. The harness reports the exact per-row identity beside the N7 bonus ratio and fails on it under `--subsidy-per-block`. Fixed in d840537b on ca3-v4-0318 (09:21 UK; igneum-exec 26, consensus-core 113, consensus 109 plus the two moved targets, kaspad check clean on igneum-build-1). the project lead's ruling (09:5x UK): the testnet active from genesis (the field at 0 in the re-cut object; the digest and the genesis hash move with it), the devnet at an upgrade height carried by 0.3.19 under the fleet's one-box-at-a-time rollout, the height named at that cut. The testnet lane's re-cut gains the one field.
 
+### N9. The proof oracle is installed whatever the verification switch, so a fresh 0.3.18 node demands the proof bytes of every record-carrying block of the live chain and no peer can serve them (the 0.3.18 canary on c18-1, 7 October 2026, 08:00Z)
+
+The e69e8a39 canary passed its headers proof (132,7xx headers, one session) and died in the block stage at block 2,728 (f52e64f4): "carries 1 proof records whose proofs this peer did not deliver in 20 s", 56 asks of pool-1 and the hub, 110 failed IBDs across the hub, both hands and pool-1, every peer 0.3.17, blocks frozen at 2,728. The rule is exec-sync's (40fd8d8c): the daemon installs the proof oracle after the keys branch whatever `proving_consensus_verify_daa` says (`kaspad/src/daemon.rs`), the body rule refuses a block whose carried proofs are not held, and the IBD flow fetches the missing proofs from the syncer before queuing a body (`protocol/flows/src/ibd/flow.rs`, "a syncer that cannot serve them fails this IBD"). The serve flow answers from a peer's bounded pool of recent proofs, not an archive, so a block from months ago is served by nobody: a fresh 0.3.18 node could not join any network, 0.3.17 or 0.3.18. 0.3.17 (b3c228fa) installs no oracle and fetches nothing, which is why its fresh joins worked. A second edge of the same cause: the keys are embedded whatever the switch, so a synced 0.3.18 node would have verified every relayed record natively and refused a block its 0.3.17 peers accept, a consensus split in waiting under a switch that says never.
+
+Per tier: every fresh or wiped 0.3.18 install (a home miner's reinstall, a new pool, a new hand) would have stalled at the first record-carrying block of the chain for ever, alive and never synced; nodes upgraded in place would have carried their state until the first relayed record whose proof fails verification.
+
+Fix on release-0.3.18-node: `ProofOracle::active_from` carries the switch (the sink takes it from `Params::proving_consensus_verify_daa` through `proof_sink`); the body rule, the IBD fetch and (through the rule) the relay retry apply to blocks at or above it only, so at never the node is 0.3.17 on this path, and with the switch set the history below it is not demanded. Known failed first on the pure gate (`the_carried_proof_rule_applies_from_the_switch_only`: the canary's block under never is not under the rule; the testnet's switch at genesis puts every block under it). What a switch set from genesis needs for a fresh join after the pool's retention is the testnet lane's go item: peers must serve the proofs of the pruning window. Commit hash: in the status log once green; the fleet's re-run of the c18-1 wipe on the new sha is the gate.
+
 ## Status updates, 5 October 2026 (ledger sweep, night of 4 to 5 October)
 
 `docs/review/ledger-sweep-2026-10-05.md` holds the runs, the commands and the running table. Every Open, Proposed, Unmeasured or pending entry was read against its experiment line; the status lines above carry the evidence inline, marked "Sweep (5 October 2026)" where a note was added and "Was:" where the status changed. Items owned by the other two night branches (F23, F24, G12, X18, the flood memory growth; the base-fee floor, testnet parameters, G13, G14, public text) were left to them.