Q1. The multiplier arithmetic is right: with STALE_DEVIATION_MULTIPLE = 2 and a 2,000 bps cap, N attestations bought within one hour and relayed together move the value by at most 1.4 x 1.2^(N-1) (the first re-anchors a stale value at 40%, every later one is measured against a now-fresh value at 20%); six give 3.484. Nothing in SwarmFeed bounds N below the number of distinct advancing toBlocks inside the 300-block recency window, so N = 6 is an economic choice, not a contract limit. The window rules do not prevent the chain: with span 300 and a monotone pool path, window [T-300, T]'s 13-sample median is the sample at T-150, so six windows ending at B+150..B+155 have medians equal to the pool price at blocks B..B+5. Two errors in the cost arithmetic follow.

1. Using the doc's own per-rung fees ($58k, $93k, $130k, $174k, $221k, $273k, cumulative $281k/$455k/$676k/$949k at rungs 3-6) and gain = line x (1 - 1.7/m), the walk breaks even at line = $1.79M (2.016x), $1.53M (2.419x), $1.63M (2.903x), $1.85M (3.484x). The cheapest profitable walk flips at a $1.53M line, so the revisit rule's threshold ('roughly HALF the pool's depth (about $2M today)') is above the point where the attack is already positive: a proposeLine of $1.6M-$2M would pass the stated rule while the 4-rung walk nets ~$20k-$140k.
2. The $950k assumes the pool is pushed and restored at each of seven sample blocks per rung. An attacker who instead ramps the pool 20% per block at blocks B..B+5 and HOLDS it at 3.48x for the following 150 blocks produces the same six medians (samples before B sit at the base, the centre sample at the rung, samples after B+5 at the top) and the six spot readings at B..B+5, and pays one round trip: 841 x (sqrt(3.484) - 1) = 729 ETH (~$1.97M) in and out at 1% = ~$39k (rung 4 alone: ~$25k). At the committed $1M line the gain is $297k-$512k, so 'round-trip fees alone ... negative at every rung' does not hold across strategies; what actually defends the walk at launch is the attacker's exposure to IMD holders selling into a 3.5x pump during a ~30-minute hold, which the doc does not model. This is the one safety condition the doc attaches to raising line, so it should be restated with the hold model, a quantified exposure estimate, and a threshold at or below $1.5M (and lower if the pool thins). Doc inconsistency in the same file: line 36 still says the Treasury pays at 'half a feed's deviation bound'; the committed constants are a quarter of the cap on falls and never on rises.

Q5/Q9 (the Treasury-vault-asker seam at day zero). Treasury.fundOracle pays the asker only from sIMD the Treasury already holds (available = maxWithdraw(treasury), Treasury.sol:494), and the Treasury's only sIMD income is the protocol's liquidation cut and cover's dust sweeps; stability fees arrive as imdUSD, which the Intake does not take.

On a freshly deployed stack the Treasury holds nothing, fundOracle returns 0 without reverting, OracleAsker.ask(nhiFeed, body) reverts inside IIntake.request when the Intake pulls 0.5 IMD from an asker with no balance, and NhiFeed -- seeded by hand in runbook step 7.1 -- goes stale 24 hours later. _pricingStale() then refuses draw, free-with-debt, bark, bite, cash and cover's dust path for the whole vault until an NHI attestation is bought with askPaid.

The keeper policy in docs/PARAMETERS-2026-10-05.md:190-192 buys with its own IMD only for a fall past the trigger and 'never to refresh a quiet stale price', so nothing in the documented sequence keeps NHI alive until the first liquidation happens to land sIMD in the Treasury (and 15 IMD/day of budget needs ~2 sIMD a day thereafter). Neither verify() nor the runbook's section 7 checks or seeds the oracle budget.

Smallest fix: a runbook step before announcing that transfers IMD straight to ORACLE_ASKER (fundOracle tops up only to the budget, so prefunding the asker is harmless) or sIMD to the Treasury sized for N days of NHI asks, plus a line in verify()/the keeper's start-up that refuses to run while asker IMD + Treasury maxWithdraw < one day's budget; or have the keeper's fallback cover a near-stale keep-alive feed as well as a fall.

Q4 (the lock(1) freeze, F2). The dust path sweeps collateral strictly below _oneWeiSeizure(price) = 1.2e18 / price raw units, which at the launch sIMD price (~8.7e13 per 1e18 raw) is ~13,800 raw units, i.e. 1.4e-20 sIMD.

Collateral of that seizure plus one unit is worth nothing but is 'collateral a bite could still reach', so cover reverts NoRealizedBadDebt and the only way back to a coverable position is bark, the full lull (6 h at NHI >= 0.85) and a bite that pays the liquidator ~14k raw units.

Unlike accepted finding D9 (re-collateralising to health costs a real, fee-paying position), this costs the drained borrower one lock transaction per cycle and no capital, so the Treasury imdUSD held behind BadDebtFirst (Treasury.withdraw, payStream) for that position's record can be kept there indefinitely by a borrower who re-locks after each bite; totalBadDebt also keeps growing with fees meanwhile (internal audit info 8).

Griefing only: no funds move to the attacker. Not reachable while a mark is live (a one-wei bite sweeps it at once), so the cadence is one lock per grace+tail (~7 h).

Smallest fix: let cover sweep any collateral whose value at price is below some floor that is dust in economic terms (e.g. below 1e-6 of the position's debt, or below the seizure for debt / 1e6 wei), or allow cover on a marked position once its grace has elapsed.

Q5/Q7. verify() reads back every wiring link between contracts this script deploys, but not the two reads that decide whether the Treasury ever pays for an update:

1. OracleAsker.price() = IIntake(INTAKE).priceOf(ORACLE_ACTION, IMD). If the swarm's Intake does not list IMD for 'oracle.request@oracle-1', or lists it above ASK_MAX_PRICE (1 IMD), every ask() reverts NotSold / PriceTooHigh, the NHI keep-alive never fires, NhiFeed goes stale 24 h after its first seed and the vault halts; the preflight checks only INTAKE.code.length. ASK_MAX_PRICE is a constant, so the only recovery is askPaid by hand at whatever price.
2. OracleAsker.poolPrice() != 0: IMD_POOL_ID and the extsload slot (keccak256(poolId, 6)) are pinned constants; a wrong id reads as 'no drift' forever and the Treasury never pays for a fall (I read the slot live on 2026-10-07: sqrtPriceX96 = 1330305773205498520043022607746, i.e. IMD ~0.00355 ETH, so the committed constants are right today, but nothing in the script proves it at deploy time). Other values not read back: Parameters.gap (50), parameters.workOracle() == 0, usdPriceFeed.maxAge() == 1 hour, triggerBps(feed) == (500, 0). Smallest fix: in verify(), require asker.price() != 0 && asker.price() <= ASK_MAX_PRICE, require asker.poolPrice() != 0, require vault.gap() == 50 and parameters.workOracle() == address(0).