Q6. The doc (and the identical NatSpec at src/SwarmFeed.sol:43, 'a 3x walk takes five hours of sustained, visible manipulation') restates the ramp-and-hold walk under the per-epoch bound as 40% per hour taking five hours to reach 3.48x. The arithmetic does not follow from the committed constants.

An epoch lasts exactly maxAge from the block its first value is RELAYED in (SwarmFeed._anchorAt, line 442), and a value is stale one second after maxAge from its signed issuedAt (_tooOld, line 456). The allowance of the next epoch is _allowanceNow() at the block it opens (line 389), and nothing in _checkValue/_accept carries _epochFirst or any freshness requirement across an epoch boundary.

So an attacker who relays each step one hour and one second after the previous one always opens on a STALE anchor and gets STALE_DEVIATION_MULTIPLE x cap = 40% at every step, never the fresh 20%: the value compounds at 1.4 per hour, 1.96x at 1h+1s, 2.744x at 2h+2s, 3.84x at 3h+3s, and 3.48x is passed by the fourth attestation about three hours after the first.

'Five hours' is the 1.4 x 1.2^5 = 3.484 chain of the OLD last-value bound, which assumed every later step is measured against a still-fresh value; under the epoch bound the attacker chooses the timing and the fresh 20% step never has to happen. Two further things the figure omits. (1) The first step's allowance is whatever the silence bought (_allowanceNow: 4000 + 250 x whole hours past the lifetime).

Price feeds are not keep-alive, a rise never arms (DRIFT_RISE_TRIGGER_OF_CAP_BPS = 0) and wideOpen needs 60%, so for eight hours and fifty-nine minutes of silence nothing refreshes them and the attacker takes 57.5%: 1.575 x 1.4 = 2.2x at 1h+1s, 3.09x at 2h+2s.

An attacker who instead waits for wideOpen (9h) can front-run the Treasury's honest delivery with their own 60% value, which _epochFirst then protects for the hour (the honest 1.0A is refused, ExcessDeviation, Treasury back-off 2h): 1.6 x 1.4^3 = 4.39x at 3h+3s.

(2) The window rules do not slow it: steps are 300 blocks apart, the primary's 600-block window has 7 of its 13 samples in its newer half, so a pool held at each rung for one hour gives every window its median at the rung and the spot (last block) the same figure, within SKEW_BPS of each other, from ONE ramp-and-hold round trip.

Cost and earnings at the committed constants (LINE $1M, mat 170 at NHI >= 0.85; pool 841 ETH / 207,881 IMD at IMD $10.92, ETH $2,699, 1% fee, the doc's own inputs): pushing a constant-product price by M needs 841 x (sqrt(M) - 1) ETH in and the same out, so 3.48x: 728 ETH ($1.97M), ~$39k round trip; 3.84x: 807 ETH, ~$44k; 4.39x: 921 ETH, ~$50k.

The vault lends $1M against collateral worth $1.7M / M at market: $489k at 3.48x (gain $511k), $443k at 3.84x ($557k), $387k at 4.39x ($613k). Net roughly $470k-$560k for about three hours (two with a 57.5% start) of holding a $2.3M-a-side pool pumped, the attacker's exposure to holders selling into it being the only remaining cost. The revisit rule in the same section says the epoch bound 'keeps the answer five hours in the open'; the constants make it about three.

The paragraph also re-costs only the borrowing direction: for the liquidation direction (docs/AUDIT-INTERNAL-2026-10-06.md finding 1) the grace is already six hours at NHI >= 0.85, so a 40%-per-hour bound adds no delay there at all (0.6A at bark, 0.6 x 0.6^k an hour later each step, bounded only by the IMD the attacker can sell, with honest attestations refused for 11+ hours afterwards because the allowance back UP to market grows only 2.5%/h).

Not a code defect: the constants are a deliberate choice, but the stated safety condition for proposeLine is wrong by nearly a factor of two in time, and no committed test exercises more than one epoch (test_chainedAttestationsCannotWalkPastTheEpochBound).

Smallest fix: restate as 40% per hour compounding (1.4^n: 3.84x in three hours, 3.48x on the fourth attestation), first step up to 57.5% (60% racing the Treasury)

5(b), the fix in 8dd0847. wideOpen requires the feed's value to be STALE and reads the allowance from SwarmFeed.epoch(), which during a live epoch is the STORED bound of that epoch. Staleness is measured from the attestation's signed issuedAt (SwarmFeed._updatedAt = issuedAt, _tooOld), but the epoch is measured from the block the attestation was RELAYED in (_anchorAt = block.timestamp).

Inside the wide epoch an honest refresh opens, the value therefore goes stale at issuedAt + maxAge, BEFORE the epoch expires at relayedAt + maxAge, and for that gap wideOpen is true again: isStale() true, epoch() still reporting the >= 6000 bound the refresh opened. Anyone calls ask(feed, body) and the Treasury pays 0.5 IMD for a second refresh of a feed refreshed less than an hour ago (ASK_MIN_INTERVAL long passed).

The gap equals the delivery latency of the Intake's callback (panel signature to writer callback, minutes), and up to a whole lifetime for an answer bought off chain and relayed by hand (SwarmFeed accepts issuedAt up to maxAge old and the window up to 300 blocks old). The NatSpec at lines 298-302 claims the property the code does not have: 'Once a value has landed it is fresh, and the feed is not wide open again until it has been silent long enough to be.'

Bounded: one extra Treasury purchase per wide refresh (the second delivery lands within first +- 20%, is accepted, and the value is fresh again), about 1.3 extra IMD a day for two price feeds in a dead market, inside the 15 IMD budget; the adversarial variant costs the attacker 0.5 IMD per 0.5 IMD of Treasury spend plus the off-chain purchase.

So a leak, not a drain, but it is the exact behaviour 8dd0847 set out to close and the regression test (test_aDeliveredRefreshClosesWideOpen) only checks the block of delivery with issuedAt == block.timestamp. Reachable with the constants as committed.

Smallest fix: also require that no epoch is live, which is what 'silent long enough' means: (, uint64 openedAt, uint256 allowance) = SwarmFeed(feed).epoch(); return SwarmFeed(feed).isStale() && openedAt == block.timestamp && allowance >= WIDE_ALLOWANCE_BPS; (epoch() reports openedAt == block.timestamp exactly when the stored epoch has run its maxAge; unseeded feeds on mainnet still read wide open, so DeployMainnet.verify line 323 still passes).

Q1 ('make a delivery revert so a paid request never lands'). When a request has been in flight for ASK_TIMEOUT (2 hours) and anyone asks again for the same feed (ask or askPaid), _request deletes feedOf[f.inFlight] before recording the new one. If the Intake then delivers the OLD request, onOracleResult hits if (feed == address(0)) revert UnknownRequest(requestId) at line 258 and reverts.

The Intake records a failed callback for a request the Treasury or an askPaid caller paid 0.5 IMD for, and the attestation is never relayed by the asker, contrary to the function's own contract (lines 265-268: the callback 'never reverts' on a delivery it cannot land, 'clears the feed's in-flight slot either way and reports whether it relayed'; 'An answer it could not deliver stays public, and anyone can relay it by hand' presumes the Intake exposes it after a reverted callback).

Whether the paid answer is lost for good depends on the Intake's handling of a reverting callback, which this repository cannot see; from the asker's side it is refused. The delete is also unnecessary: the if (f.inFlight == requestId) guard at line 261 already keeps a superseded delivery from touching the live slot, so a late answer could be relayed harmlessly (SwarmFeed refuses it itself if its window no longer advances).

Reachable with the constants as committed whenever the swarm takes more than two hours to answer (an undelivered request is exactly the case ASK_TIMEOUT exists for), and anyone can be the second asker. No funds at risk beyond the price of the request.

Smallest fix: remove the delete feedOf[f.inFlight] from _request; onOracleResult already deletes feedOf[requestId] on delivery and only clears the slot when the id matches.

5(c), the fix in cc4103f for the final review's low finding. _coverDust (line 577) sweeps collateral below the seizure for max(debt / COVER_DUST_DIVISOR, 1 wei), so a borrower who re-locks exactly that many raw units plus a rounding margin is above the floor and cover reverts NoRealizedBadDebt at this line. That collateral is worth 1.2e-6 of the position's debt: $0.0012 on a $1,000 bad debt, $1.20 on $1M, and in sIMD raw units (24 decimals) a number anyone holds.

Nothing then reaches it except bite, which needs a NEW mark (the drain's mark has expired, that is when the griefer acts), the full grace (lull(): six hours at NHI >= 0.85) and a liquidator who sizes debtToRepay to the exact raw amount (a one-wei bite leaves a remainder that is not below _oneWeiSeizure and so is not swept; an oversized bite reverts InsufficientCollateral). The borrower then re-locks for the next cycle.

So the griefing the finding described remains with its cost raised from ~1e-20 sIMD to 1.2 millionths of the debt plus one lock transaction per ~7 hours: still gas-dominated, still free in capital.

Harm as before: the Treasury's imdUSD equal to the record stays locked behind BadDebtFirst (Treasury.withdraw, payStream) and totalBadDebt keeps growing with fees while the record cannot be retired. No funds move to the borrower; griefing only. Reachable with the constants as committed.

The NatSpec at lines 572-576 ('Collateral worth under a millionth of the debt is dust in every economic sense') is true but the closure it implies ('could re-lock for free') does not hold one unit above the floor.

Smallest fix, either: let bite skip mark-and-grace for a position whose _recordedBadDebt is nonzero (it has already been drained once, and the grace exists to let a borrower who could recover react), or raise the floor to the larger of a millionth of the debt and an absolute value (one imdUSD of collateral at price), so that re-locking enough to block cover costs real money.

5(e). On day one the keeper is NHI's only buyer: Treasury.fundOracle pays only from sIMD the Treasury holds (none until the first liquidation cut), and the runbook has the keeper buy 'NHI near stale first' with its own IMD inside ASK_PAID_IMD_PER_DAY (2 IMD, i.e. four purchases). The state in which neither keeps NHI alive: the figure api.imd.fun/swarm now reports lies outside the feed's allowance.

NhiFeed carries the same 2,000 bps cap as the price feeds, bounded per one-day epoch against the anchor, and the NHI question is a live API read with no intermediate values (SwarmFeed._checkValue, _allowanceNow).

A genuine move of more than 20% in a day (one core service down is -10 points on a 1.0 index, agentsOnline halving is -20, a batch of blocked jobs moves r) is refused with ExcessDeviation by EVERY purchase until the stored value is a day stale: allowance 2000 until 24h, 4000 at 24h+1s, 4250 at 25h, 5000 at 28h. A refused answer still costs the full Intake price (OracleAsker.askPaid pulls it before the request; the back-off in onOracleResult applies only to the Treasury's ask).

A keeper that follows the runbook and retries its refused NHI purchases spends its 2 IMD on four refusals between the 18-hour near-stale mark and 24 hours, and has nothing left at 24h+1s when the first purchase that WOULD be accepted becomes possible; the Treasury has no sIMD to help, and its own ask path would back off two hours per refusal anyway.

NhiFeed.isStale() turns true at 24h and ParameterizedVault._pricingStale() then refuses draw, free with debt, bark, bite, cash and cover's dust path for the rest of the keeper's UTC day (or until someone else pays 0.5 IMD with the allowance open). The runbook tells the keeper neither to read SwarmFeed.epoch() before buying (the allowance is public exactly so a buyer can see 'how far the feed will follow') nor to keep budget for the accepting attempt.

Reachable with the constants as committed; it needs a real NHI move, which is what the feed exists to report.

Smallest fix: a sentence in 7.4 that the keeper reads epoch() and the live API figure and does not buy an NHI answer the feed will refuse, holding its last purchase for the first second the allowance covers the gap; and seed the asker with IMD at deploy (the earlier finding's fix) so the Treasury path is not dead on day one.

Q2. proposeWorkOracle (NatSpec lines 239-243) requires, once vault.totalEarned() != 0, that the successor 'name the current oracle as its predecessor'. IWorkOracleSuccessor.predecessor() is a typed call; SwarmWorkOracle, the only attested work oracle in the repository and the one WORK_ORACLE_FACTORY creates, exposes no such function, so the call reverts and the proposal is refused for every SwarmWorkOracle, including one deployed fresh against this vault.

The documented path to 'integrating minting from work upstream never forces a new vault' therefore requires a contract that does not exist yet, and the fallback of proposing address(0) is also refused once minted.

Not exploitable and not a bypass: wage == 0 is checked at proposal and application, a single Governed slot means a wage and an oracle change cannot be pending together, WorkOracleFactory.create can only return an oracle whose vault is its caller, and the sentinel path reverts rather than downgrading.

The ordering of wage and oracle proposals cannot bypass wage == 0; rights claimed but never consumed in the old oracle are stranded when it is replaced (they are re-claimable in a successor with an empty creditedTasks only while totalEarned is zero), which is a governance choice visible for 48 hours.

Smallest fix: add address public immutable predecessor (zero for a created oracle) to SwarmWorkOracle and a constructor argument on the factory's second path, or document in Parameters that the successor must be a new contract type.

5(d). The new check proves the slot keccak256(IMD_POOL_ID, 6) holds a nonzero sqrtPriceX96, i.e. that IMD_POOL_ID is SOME initialised pool on POOL_MANAGER. The bodies (and the feeds' pinned questions) name pool 0xb07d...fbf3 in text; OracleAsker.driftBps compares the feeds' value against whatever IMD_POOL_ID reads.

With IMD_POOL_ID pointing at any other initialised pool the script prints 'Deployed and verified' and the Treasury's fall trigger compares IMD against an unrelated price forever: it pays for falls that did not happen (bounded by the budget and the arming rule) or never pays for ones that did (collateral over-valued for up to an hour each time).

Other reads still not made by verify: the work oracle's expectedQuestionHash(1,2) != 0 and its attestationChainId/answerType (checked for the three feeds, not for the fourth SwarmFeed); and the Chainlink leg, which _refuseUnlessReady checks before a broadcast but verify does not, so --sig verify(...) against an existing deployment does not notice a dead ETH/USD aggregator (UsdPriceFeed.isStale() true, every price action StaleFeed).

The asker-balance / Treasury-sIMD day-one check the earlier finding asked for is also absent (the runbook moved it to the keeper).

Smallest fix: require(vm.contains(string(p.priceBody), vm.toString(IMD_POOL_ID)) && vm.contains(string(p.spotBody), vm.toString(IMD_POOL_ID))), require(work.expectedQuestionHash(1, 2) != bytes32(0)), and call _preflightPriceLeg() from verify.