On a feed whose data chain is not the consumer chain and is not reported by block.number (the attestationChainId != block.chainid / attestationChainId != blockClockChainId path, i.e. every consumer chain except the data chain itself and the Robinhood-style parent-block chain), _requireQuestion applies only _tickClock. _tickClock bounds a window from BELOW (toBlock + maxAge/12 >= projectedHead(issuedAt)) and never from above, and _tickClock stores clockBlock = max(toBlock, projected) and lastToBlock = toBlock.

A signed attestation with an arbitrarily large toBlock (a window that could not have existed when it was signed) is therefore accepted; it moves clockBlock to that value and lastToBlock past every real block, after which every honest window reverts WindowNotAdvancing (or WindowBehindClock) forever. The header at lines 80-87 states the premise ('the window existed when it was signed, so toBlock <= head(issuedAt)') but the code never verifies it.

The impact is a permanent halt of the feed (no borrowing, no liquidation at a price) from one attestation, which is outside the stated trust model for a swarm feed ('a compromised attester can move those feeds within the cap per epoch'); it also contradicts the monotonic-clock design's claim that a run of windows 'cannot walk it into the past'.

Reachability with BetaConfig: NOT on the beta's mainnet deployment (all mainnet feeds have attestationChainId == block.chainid, so the local branch enforces toBlock <= block.number); reachable on any other consumer of the mainnet questions (a chain like Base/Sepolia; Robinhood Chain is protected because its block.number reports Ethereum's head and takes the block-clock branch), and only with a valid signature over a future window, i.e. an attester/plane fault or compromise.

The smallest fix: in _requireQuestion's remote branch, once clockAt != 0, reject a.toBlock > projectedHead(a.issuedAt) + PARENT_SLACK with WindowInFuture, before _tickClock (the first value still sets the clock).

The contract's own NatSpec states the property that makes the reading push-proof: 'So a price push before a sample does not change the reading: only positions do' (lines 32-33), and it tells deployments 'Wire attested/Chainlink feeds (for IMD: the attested IMD median x Chainlink ETH/USD), never a LivePoolPrice' (lines 36-37).

The beta's every sampler violates both: beta config wires feed1 = F_IMD_USD_LIVE = ProductFeed(LivePoolPrice(IMD/ETH, this pool), Chainlink ETH/USD) (script/DeployConfig.sol:399 with :452-453 and :375-376). The reference therefore re-anchors on the pushed price, so the 400-tick maxDeviationTicks guard sees ~0 deviation for any push, and a push moves the +/-15% band onto a different part of the liquidity distribution and changes the reading.

The proof (below) shows a -25% swap changing the reading from 16,686.04e18 to 0 (x token0) and from 10,278.12e18 to 5,199.96e18 (x token1) with the beta's reference and maxDeviationTicks = 400; the existing test test_pricePushDoesNotChangeReading only passes because its reference is a fixed MockFeed, not the shipped one.

A second claim on line 41, 'A push now needs real capital held across separate transactions', is also false: the guard only reads v4's transient lock during the unlock callback, so a contract can call pm.unlock(swap to push), let the callback return and settle, then call sample()/measure() in the same transaction (the pool price persists after the lock clears), then unlock a swap back; the proof's push is a router swap (an unlock) followed by measure() after it returns.

A liquidity pull needs no capital at all. The README lists 'Depth griefing' as a known accepted risk with measured costs, and this finding does not change those economics: it is the NatSpec/guard claim that is wrong, not the accepted risk.

Reachable with BetaConfig: yes (all three samplers).

Smallest fix: wire the attested IMD median x Chainlink ETH/USD as the reference as the NatSpec requires (or, if the live reference is kept for liveness, amend the NatSpec and the README to state that a same-transaction push is sampled and the 400-tick guard is not a push guard); no on-chain check can make a pool-derived reference push-proof.

The header at line 31 states 'FAIL CLOSED AND NEVER REVERTS ... Readers ... therefore never revert through this contract'. attested() multiplies the leg's value by the ETH/USD price with a plain uint256 multiply. The leg is a SwarmFeed, whose FIRST accepted value has no on-chain magnitude bound (and later values are only bounded relative to it), so an oversized value makes the product overflow and depth() revert.

The only protocol consumer, Parameters.depthIMD(), wraps imdDepth.depth() in try/catch and reads 0, so the depth-gated line still fails closed; the false part is the claim about direct readers (keeper, Safe, integrators), which revert. Reachable only with an attester-signed oversized first value (or a leg set by governance whose first value is not checked); the beta leaves the depth leg unset at genesis, so this is a robustness/claim defect, not a beta-reachable attack.

Smallest fix: reject or clamp an absurd leg value before multiplying (e.g. return 0 when usdPerEth != 0 && wei_ > type(uint256).max / usdPerEth); Math.mulDiv alone still reverts when the 256-bit result overflows.

The header at lines 9-11 states 'a feed that reverts or answers malformed data reads as zero and stale'. latestValue only checks the returndata length and then abi.decodes two uint80 fields; Solidity validates narrow integer encodings and reverts when the upper 176 bits of either word are non-zero (the same is true of the address decoded in _clamped).

An aggregator that returns 160 bytes with a dirty roundId/answeredInRound word therefore makes the view revert instead of returning (0,0), and the revert propagates to Pricer.quote and every action that prices that collateral. Reachable only with a broken or non-Chainlink aggregator (the beta's aggregators are real Chainlink proxies, immutable), so this is a claim/robustness defect.

Smallest fix: decode those fields as uint256 and return (0,0) when they exceed type(uint80).max (and range-check the address in _clamped), so malformed returndata fails closed as documented.

DepthSampler's NatSpec (lines 43-52) rests the anti-inflation argument on two claims: 'an attacker who adds liquidity only around his own samples cannot raise a bucket, because the keeper's honest sample in the same hour sets it' and 'to inflate the figure he must keep the liquidity in the pool whenever anyone may sample, all day: and liquidity held all day IS depth'. Both assume the keeper's sample time is unobservable. It is not: sample() is a public transaction in the mempool. An LP front-runs every keeper sample with a one-sided position on the X-sell side of the band (for IMD/ETH: an ETH-only range above the current tick, so no IMD is needed and the position is out of the money) and removes it in the next transaction of the same block. No honest sample lands in that hour, so the hour's bucket is the inflated reading, bounded only by MAX_RISE (2x the current depth per sample). After one day the 4th-lowest bucket is 2x the honest depth; the next day 4x, and ImdDepth's 7-day low follows after a week. The pool holds the attacker's liquidity only inside the keeper's transaction.

Call sequence (external): [attacker] Router.addLiquidity(one-sided range in band) ; [keeper] DepthSampler.sample() ; [attacker] Router.modifyLiquidity(-L) ; same block, repeated each hour. Bundling this around a public tx is routine for builders; a sample sent from a random minute does not help.

Concrete state: 24 honest hourly samples read depth D (proof: 10,301,648,335,867,592 USD-1e18 in the harness). 24 further hours in which each keeper sample is sandwiched by +1e17/-1e17 liquidity. Expected (the NatSpec's property): depth() <= D, since outside the sandwiches measure() still reads D (asserted). Actual: depth() = 2D = 20,603,296,671,735,184 (MAX_RISE binds; without it the bucket would be ~100x).

Reachable with script/DeployConfig.sol BetaConfig: yes. All three samplers are listed at genesis, sampling is permissionless and the keeper samples hourly from a public account. The inflation is capped by the posted ceiling depthIMD (80,100e18, MainnetConfig.DEPTH_IMD) which the README calls 'only a ceiling': at the README's measured depth (61,954) the rule admits a 21,636 sIMD line; at the ceiling it admits 33,733 (README, 'At $80.1k that is 33,733'). So the attack converts the posted ceiling from a safety cap into the effective depth: +12,097 imdUSD of sIMD line backed by no real depth.

Cost at README depths: the one-sided ETH position is not spent (out of the money, exposed for one block), so the cost is gas: 2 transactions per hour x >=21 hours x 7 days ~ 300 transactions, roughly $1.5k-3k at 2026 mainnet gas; no pool fee is paid. It pays for a borrower who wants the extra 12k of sIMD line (or wants the rule's depth premise broken before a liquidation), and it falsifies the README invariant 6 premise that depthIMD is measured.

Smallest fix: make a sample require the liquidity across at least one full block: prime() stores measure() and the block; sample() records min(stored, measure()) only when block.number > primedBlock (and clears the prime), so a JIT position must sit through a block where anyone can trade against it; sample through a private relay as an operational measure; and size the posted ceiling as the binding bound (it already is the only real one). Alternatively weight each hour by the minimum of several samples the keeper sends from unlinkable accounts.

The contract's header (lines 27-37) states the measurement is 'ANCHORED ON THE FEEDS, NOT ON THE POOL'S PRICE', that 'a price push before a sample does not change the reading: only positions do', that a sample is refused when the pool tick is more than maxDeviationTicks from the reference tick, and (line 41) that 'a push now needs real capital held across separate transactions'. LivePoolPrice.sol line 12-13 states it is 'THE REDEMPTION PAYOUT LEG ONLY ... never used to measure a borrower'. BetaConfig (MainnetConfig._sampler, script/DeployConfig.sol:386-405) wires every sampler's feed1 to F_IMD_USD_LIVE = ProductFeed(LivePoolPrice(IMD/ETH pool), ETH/USD). For the two samplers on IMD/ETH pools the reference is then the sampled pool's own price: _sqrtRef(p0, p1) = sqrt(ETHUSD / (live x ETHUSD)) = the pool's sqrtP up to rounding, the reference tick equals the pool tick, the 400-tick guard can never fire, and the band moves with any push. The third sampler (Treasury imdUSD/IMD pool) is referenced from the IMD/ETH pool's price, so only there is the guard live.

The 'separate transactions' claim is also false: sample() only checks the v4 unlock slot, which is cleared when a router's unlock returns, so push, sample and push-back are three CALLS inside one transaction, atomic, with no capital held across blocks and no arbitrage exposure. Cost in the real pool is the 1% fee each way on the push notional (fee 10000); the harness pool is fee-free so the round trip is free.

README 'Known issues ... Measured depth: Depth griefing' accepts lowering through 'separate-call sandwiches' and measures it ($9,998 for a 25% push, $22,403 for 50%). This finding is reported because (a) the in-scope NatSpec of DepthSampler and LivePoolPrice claims properties the deployed configuration does not have, (b) the extreme is a recorded bucket of exactly 0 when the push leaves the band with no liquidity (a pool with only concentrated ranges), and (c) with the atomic form the attacker pays only the fee, not the README's IMD-at-risk figure. It can only lower the line (plus, see finding 1, the live reference also lets a price push raise the ETH paid per IMD-move, but the 4th-lowest rule makes that a held-price attack and MAX_RISE bounds it).

Call sequence: in one tx: Router.swap(sell X to tick-3000) ; DepthSampler.sample() ; Router.swap(back to the original sqrtP). Concrete: honest measure 10,301,648,335,867,592; after a 3,000-tick push sample() does not revert PoolOffReference (expected per NatSpec) and records bucket 0 (actual); the pool is restored in the same transaction.

Reachable with BetaConfig: yes (feed1 = F_IMD_USD_LIVE on all three samplers, maxDeviationTicks 400 inert on two). Cost at README depths: a 25% push of the ~$1.9M IMD/ETH pool is ~ $110k notional, 2 x 1% = ~$2.2k; emptying the band needs pushing past every in-range position (against full-range liquidity the reading only shrinks ~ 1/sqrt(price ratio)). Pays nothing directly; it lowers the sIMD line (griefing).

Smallest fix: keep the live reference only as a staleness fallback and anchor the band on the attested IMD median x ETH/USD when that is fresh (the config comment's objection is that attested legs are stale most hours: then take the reference as the TWAP-style median of the pool price over the last N blocks read from the previous sample, or at minimum compare the live reference against the last accepted attested value within maxDeviationTicks); and correct the three NatSpec claims (lines 27-37, 41; LivePoolPrice 12-13) to describe the shipped wiring.

DepthSampler.depth() returns 0 while fewer than MIN_BUCKETS (20) of its 24 slots are inside the 26-hour window: 6 missed hours are tolerated, a 7th makes it 0, and because the slots alias by hour%24 the count stays at 17-19 until the gap leaves the window, so the sampler reads 0 for about 20 hours after a 7-hour gap even though sampling has resumed (verified in the proof: sampler.depth() is back to full only after the gap ages out). ImdDepth.poke() (line 119) folds sampled() into the UTC hour's reading without distinguishing 'measured 0' from 'not enough buckets'. Four pokes in four of those hours (the keeper's own hourly chore does it; anyone may poke, so an attacker can do it for ~4 x 100k gas) make the day's ROBUST_RANK-th lowest hour 0, and depth() is the minimum over 7 day figures, so the sIMD line is 0 for the following 7 days, while the pool, the sampler and the pokes are healthy again within a day. Nothing in the NatSpec states this amplification (it states a fresh deployment reads 0 for 6 days and that a week of silence must not read as depth).

Causes of a 7-hour sampling gap in the beta: the keeper's sampler down for 7 hours and nobody else sampling (the README's trust model relies on the keeper), or ETH/USD (ChainlinkFeed, maxAge 70 minutes) stale for 7 hours so measure() reverts StaleFeed (not attacker-triggerable; WalkTooLong is unreachable on the beta pools, <~330 steps on the spacing-10 pool, and PoolOffReference is inert on the live-referenced pools, see finding 2). So an attacker cannot cause the gap on the main pools; the finding is a liveness amplification plus a permissionless four-poke trigger during any natural gap.

Call sequence: 8 days of hourly sample()+poke() ; 7 hours of poke() only ; 48 hours of sample()+poke(). Expected: depth() returns to the full reading once the sampler does. Actual: depth() = 0 (day -1 and day -2 figures are 0) and stays 0 until those days leave the 7-day window.

Reachable with BetaConfig: yes (ImdDepth listed at genesis with the three samplers; the keeper pokes hourly). Cost: nothing beyond the gas of four pokes; it pays only as griefing (no new sIMD debt for a week; repayment unaffected).

Smallest fix: in poke(), do not record a reading when sampled() is 0 (if (v == 0) return _figure(l); before the fold; a listed exit pool with literally no liquidity in the band is not a case the rule needs to remember, and depth() still fails closed live while sampled() is 0). Better: have DepthSampler expose hasWindow() (filledBuckets() >= MIN_BUCKETS) and skip the record while any listed sampler lacks a window.

NATSPEC CLAIMS NOT HELD BY THE CODE OR THE SHIPPED WIRING: (1) LivePoolPrice.sol:12-13 'THE REDEMPTION PAYOUT LEG ONLY ... never used to measure a borrower': BetaConfig wires it (as F_IMD_USD_LIVE) as the band reference of all three DepthSamplers, which size the sIMD line. (2) DepthSampler.sol:27-37 'ANCHORED ON THE FEEDS, NOT ON THE POOL'S PRICE' / 'a price push before a sample does not change the reading' / the 400-tick refusal: inert on the two live-referenced pools (finding 2). (3) DepthSampler.sol:41 'needs real capital held across separate transactions': separate calls suffice (finding 2). (4) DepthSampler.sol:48-51 'the keeper's honest sample in the same hour sets it' / 'liquidity held all day IS depth': defeated by sandwiching the keeper's sample (finding 1). (5) SwarmFeed.sol:157-159 MAX_ALLOWANCE_BPS 'The allowance never exceeds this': the constant is never referenced; the bound holds only through the constructor's maxDeviationBps <= 10_000 and STALE_DEVIATION_MULTIPLE = 2 (true, but not enforced where stated). (6) SwarmFeed.sol:534-537 on _epoch: 'Public so a buyer can see' on a private function (the public one is epoch()). (7) ChainlinkFeed.sol:56 '(or the int192 maximum) is none': no int192 check exists; harmless because a real answer is below it. (8) ImdDepth.sol:28-29 states only the fresh-deployment 6-day zero, not the 7-hour-gap-to-a-week amplification (finding 3).

Q1 ATTESTATION ACCEPTANCE: holds. The EIP-712 domain ('IdentityMD Oracle', '2', block.chainid, address(this)) binds consumer chain and leaf, so an attestation for another leaf (price vs spot vs seat vs depth), another consumer chain or another feed address fails _recover != attester; the signed chainId must equal the pinned data chain (1); questionHash is recomputed from the pinned prefix plus the signed fromBlock/toBlock, so another question is refused; requestId is consumed before the question check and a second submission reverts ReplayedAttestation; s > n/2 and v not in {27,28} are refused and ecrecover's 0 never equals the non-zero attester; floors 100 panel and 67 (price, spot) / 51 (NHI, seats, depth) agreed with agreed <= panelSize; expiresAt >= now >= issuedAt, issuedAt within maxAge and not before the last accepted issuedAt (equal allowed: README known); window span within [min,max], toBlock > lastToBlock, toBlock <= block.number and within maxAge/12 blocks (the remote block/time clock branch is unreached in the beta: attestationChainId == block.chainid == 1). quorum is unchecked by design. Not found: accepting for another leaf, question, chain, or twice. Note (not a defect): a relayer holding the newest valid window refuses older honest windows (WindowNotAdvancing), bounded by the epoch cap.

Q2 EPOCH CAP: holds as documented. _fitsEpoch measures from the epoch's anchor (the value held when the epoch opened), bound cap (2,000 bps) on a fresh base and 2x only after maxAge + 1h of relay silence (since = max(acceptedAt, updatedAt)); a wide epoch is closed to the cap around its first value (_epochFirst); _returnAnchor admits only levels the expired epoch already allowed, for 2*maxAge + 1h; _openEpoch anchors a new epoch at the value being replaced. The maximum walk is the documented (1+cap)^2-1 once across a boundary and cap per lifetime after; from a two-hour-silent feed 1.4 then 1.2 per hour. Halting: not found; a push relayed at the end of an epoch leaves the honest level reachable through the way back for 2 lifetimes + 1h, and an honest relay once per 2 hours keeps it. The first value is unbounded (documented, checked off chain by DeployMainnet.verifySeeded).

Q3 FRESHNESS: holds. SwarmFeed stamps the signed issuedAt (future refused; delayed relay cannot extend life); isStale = !hasValue || now - updatedAt > maxAge. ChainlinkFeed: updatedAt == 0 or > now reads unpriced, isStale uses the aggregator stamp. ProductFeed: older stamp, stale if either leg. RateFeed: underlying's stamp, stale if the rate reads 0. LivePoo

The header (lines 43-52) rests the anti-inflation argument on the keeper: 'an attacker who adds liquidity only around his own samples cannot raise a bucket, because the keeper's honest sample in the same hour sets it. To inflate the figure he must keep the liquidity in the pool whenever anyone may sample, all day'. That is false when the attacker wraps THE KEEPER's sample() in a same-block add/remove of liquidity (a public-mempool sandwich, or any builder bundle).

The hour's only honest sample then reads the JIT liquidity, the first sample of the hour sets the bucket (line 220-221), nothing lowers it, and sample() only refuses calls made INSIDE an unlock callback (line 210), not calls made between two unlocks in the same block. After 24 sandwiched hours every bucket is MAX_RISE x the resting depth, so depth() = 2x; the next day 4x, until the Parameters depth ceiling (BetaConfig DEPTH_IMD $80.1k) or the attested leg binds.

ImdDepth's 7-day low needs the sandwich sustained 7 days (168 keeper samples).

Cost: gas for 2 modifyLiquidity calls per hour ($1-15 each at mainnet prices), capital exposed for zero blocks; the JIT position must be about as large as the resting in-band liquidity (~$60-120k of ETH+IMD for the 0xb07d pool per README depth figures), which the attacker keeps.

Reachable with BetaConfig: samplers listed at genesis, keeper sampling hourly in the public mempool, sIMD line = min(50k target, what k x depth admits): README measures depth $61,954 -> line 21,636; inflating to the $80.1k ceiling admits 33.7k, i.e. +$12k of sIMD borrowing against a market that cannot absorb it at liquidation (edge sleeve loss). The ceiling bounds the damage in the beta, which is why this is medium and not high.

Smallest fix: make a reading depend on liquidity that survives across blocks, e.g. sample() stores (measure, block.number) as a pending reading and a second call in a LATER block records min(pending, measure now); operationally, the keeper should submit through a private relay. Also correct the header's claim.

The way back accepts any value within the cap of the expired epoch's LEVEL, regardless of where the feed's last accepted value is. When an epoch anchored at A ended with an honest move to the cap edge (0.8A, a real 20% market fall), the moment it expires an attestation of 1.2A is accepted: it fails _fitsEpoch (anchor 0.8A, fresh allowance 20% admits at most 0.96A) but passes _returnAnchor (within 20% of A).

The feed jumps +50% from its last value, and the new epoch is anchored at A with the plain cap, so it stays up to 1.2A for a lifetime. The README trust model states 'a value moves at most a fixed cap per epoch, widened at most 2x after an hour of staleness' and the known-issue text says 'up to 40% after a silence and 20% per epoch'; here a fresh feed moves 50% in one accepted attestation.

The NatSpec (line 520) is accurate that no level outside the expired epoch is reached, so the harm is bounded: the attacker (who must buy a pushed-pool attestation) gets 2.5x the per-epoch cap in the direction opposite to a genuine move, without waiting an hour of silence, and the pushed level persists until an honest relay (honest values within 20% of A are accepted at once). Reachable with BetaConfig (1h lifetime, 2,000 bps).

Smallest fix: in _returnAnchor also require the value to lie between the last accepted value and level (a return TOWARD the level is what the way back exists for), e.g. if (value > Math.max(level, _value) || value < Math.min(level, _value)) return 0;.

Lines 27-37 claim the band is 'ANCHORED ON THE FEEDS, NOT ON THE POOL'S PRICE', that 'a price push before a sample does not change the reading: only positions do', that samples are refused when the pool is >maxDeviationTicks from the reference, and 'Wire attested/Chainlink feeds ... never a LivePoolPrice'. script/DeployConfig.sol line 399 sets every sampler's feed1 to F_IMD_USD_LIVE = ProductFeed(LivePoolPrice(0xb07d pool), ETH/USD), and feed0 to F_ETH.

For the two ETH/IMD samplers the reference p0/p1 = ETH_USD / (live_IMD_ETH x ETH_USD) is the pool's own price, so refTick == tick always, PoolOffReference can never fire, and the band [ref, ref x 1.1765] follows any push.

The README accepts the lowering case (depth griefing, 'It can only lower the sIMD line'), but the raising case exists too: with liquidity L constant, out0 = L x (1/sqrtRef - 1/sqrtUp) is proportional to 1/sqrtRef, so buying IMD with ETH before a sample (IMD price in ETH up by x) raises the reading by sqrt(1+x) (e.g. +21% price -> +10% reading), and a push into a denser tick range raises it more.

Cost at README depths: the round-trip 1% fee on a swap large enough to move the 0xb07d pool 21% (order of $100-200k -> $2-4k per sandwiched keeper sample, 24 per day) against a line gain of at most +$12k under the $80.1k ceiling: it does not pay, so low. For the third sampler (v1 imdUSD/IMD pool) the reference is the OTHER pool's live price, so a 4%+ divergence between the two pools makes that sampler revert PoolOffReference (it then contributes 0, ~0.5% of depth).

Fix: either wire the attested IMD median (and accept that samples pause while it is stale) or rewrite the header to state what the live reference gives up, and remove 'It can only lower' from the README.

rate() takes a fall at once (by design, 'a loss must never be hidden'), and poke() is permissionless and writes rate() as the new checkpoint. If a source's rate dips transiently (within one block or a few) and anyone pokes during the dip, the ceiling is re-based at the dip and the true rate is only re-approached at maxGrowthPerSecond (BetaConfig CAP = 0.1%/day): a 1% dip under-prices the collateral for 10 days, a 5% dip for 50.

The under-priced borrow/liquidation price can mark positions near mat (sUSDS/Steakhouse at 108%) liquidatable. Whether this is reachable depends on the source: wstETH.stEthPerToken falls only on a real negative rebase; sUSDS convertToAssets follows a monotonic chi; MetaMorpho Steakhouse USDC falls only on realised bad debt; sIMD's convertToAssets could not be checked here (external token).

Reported as informational: no beta source with a transient dip was identified. Smallest fix if one is ever wired: poke() should refuse to lower the checkpoint below the live rate read in a later block (two-step), or cap the FALL the checkpoint may take per poke the way the rise is capped.

The port kept v1's comments.

Properties they claim that this tree does not have: (1) lines 300-302 and 477-478: 'DeployMainnet.verifySeeded refuses a price or spot anchor more than a quarter of the cap from the pool' and the feed is deployed 'from a salt no one else knows' - no verifySeeded exists in script/ (grep: the name occurs only in this comment), and DeployConfig says swarm feeds are 'Deployed EMPTY (priced 0 until the first relay)' with a permissionless relayer, so the FIRST value of every price, spot, NHI, seat and depth leaf is unbounded on chain and whoever relays first sets the anchor; (2) line 553-554: 'the Treasury does, through OracleAsker, once the allowance reaches WIDE_ALLOWANCE_BPS' - no such contract or constant exists; (3) lines 255-256 and 591-592 name PriceFeed, NhiFeed, SpotFeed and SwarmWorkOracle as the shipped leaves; the leaves here are SwarmPriceFeed, SwarmSpotFeed, SwarmNhiFeed, SwarmSeatMedianFeed, SwarmSeatSpotFeed and SwarmImdDepthFeed (the first-value and _accept statements hold for them); (4) line 63 cites test/SwarmFeed.t.sol, which is test/unit/SwarmFeed.t.sol here.

Also DepthSampler.sol line 19 says depth is 'read as the minimum over the last day' where the code reads the 4th-lowest bucket over a 26-hour window. Item (1) matters operationally: the deployment runbook, not the code, is what stops a raced first relay on each empty leaf.

The sampler's only defence against a same-transaction price push is sample() reverting while the v4 PoolManager is UNLOCKED (DepthSampler.sol:210, exttload of Lock.IS_UNLOCKED_SLOT). The NatSpec (lines 39-41) concludes that "a push now needs real capital held across separate transactions". It does not: the lock is released at the end of every unlock() call, so a single transaction can (1) unlock, swap the pool 20-25% and settle, (2) call sample() with the manager locked (ManagerUnlocked does not fire), (3) unlock again and swap back. The capital is returned inside the same transaction, so it can be flash-borrowed; what the attacker pays is the pool fee twice (1% each way on the 0xb07d pool) plus gas.

With the beta wiring (script/DeployConfig.sol:371-405: feed1 = F_IMD_USD_LIVE, a ProductFeed over LivePoolPrice of the very pool being sampled) the reference price moves WITH the push, so the deviation guard (maxDeviationTicks 400) never fires for the 0xb07d sampler and the band is measured around the pushed price, where the pool is thin. The NatSpec claims at lines 27-31 ("ANCHORED ON THE FEEDS, NOT ON THE POOL'S PRICE ... a price push before a sample does not change the reading: only positions do") and 34-37 ("Wire attested/Chainlink feeds ..., never a LivePoolPrice") are therefore not properties of the deployed system.

Relation to README 'Known issues' (Measured depth, depth griefing): the README accepts that four sandwiches lower the depth and quotes a cost of "about $9,998 of IMD" for a 25% push. That figure is the notional sold; the attacker recovers it in the unwind. The actual cost is about 2% of it ($200) plus gas, and no capital has to be held across transactions or blocks, so the attack is roughly 50x cheaper and carries no arbitrage risk. It can only LOWER the sIMD line (the README is right about that), so the impact is a denial of new sIMD credit: at the README's figures, 4 sandwiches ($920 incl. gas) cut the sIMD line from 21,636 to 10,500 for about 8 days; a 50% push (~$450 each, ~$1,800 total) cuts it to 4,765.

Reachable with BetaConfig: yes (all three samplers use F_IMD_USD_LIVE as the IMD reference; sampler 0 is the pool whose price is the reference).

Call sequence (one transaction from any EOA via a helper contract): PoolManager.unlock -> swap(IMD->ETH or ETH->IMD, ~20-25%) -> settle; DepthSampler.sample(); PoolManager.unlock -> swap back -> settle. Repeat in 4 different UTC hours of one day, then (or let the keeper) ImdDepth.poke().

Smallest fix: make a same-transaction push detectable without an attested reference: store the pool tick seen by the last sample taken in an EARLIER block ((lastTick, lastBlock)) and, when block.number != lastBlock, refuse a sample whose current tick is more than maxDeviationTicks from lastTick (PoolOffReference). A pushed price then has to be held across at least two blocks with a sample in each, which exposes the push to arbitrage, restoring the capital-at-risk the NatSpec describes. Also correct the NatSpec at lines 27-41 or wire a non-live reference.

The NatSpec (lines 43-52) argues that JIT liquidity cannot raise a bucket because the keeper's honest sample at a random minute of the hour sets the bucket's minimum, so an inflater "must keep the liquidity in the pool whenever anyone may sample, all day". The keeper's sample() is an ordinary public transaction. An attacker who front-runs it with modifyLiquidity(+L) and back-runs it with modifyLiquidity(-L) (three transactions in one block, or one bundle) has his liquidity in the pool at every sample of the hour, including the keeper's, while holding it for a single block (zero price risk in a bundle). Nothing in sample() can tell such liquidity from liquidity held all day. The same sandwich applied to every sample for 21 of 24 hours raises depth() (the 4th-lowest bucket) by MAX_RISE (2x) per day; applied for 7 days it raises ImdDepth's 7-day low and therefore the sIMD line.

Bounds (which make this low): MAX_RISE 2x per day; ImdDepth's 7-day low; and Parameters.depthCap (BetaConfig DEPTH_IMD = 80,100e18) caps the depth the rule uses. At the README's measured depth (61,954) the most an inflater gains is the line moving from ~21,636 to ~33,733 (the posted cap binds), i.e. 12k of extra sIMD borrowing room, for about 500 gas-only transactions ($1.5-5k of gas at 10-30 gwei) and no capital at risk beyond one block. No funds are extracted; the harm is that the depth rule's protection (liquidation capacity to -15%) is overstated by up to the cap/measured ratio.

Reachable with BetaConfig: yes (permissionless sampling, public keeper transactions, no liquidity-age requirement in v4).

Call sequence: block N: attacker.modifyLiquidity(+L in [ref-2400, ref+2400]); keeper.sample(); attacker.modifyLiquidity(-L). Every hour for 7 days; ImdDepth.poke() hourly (the keeper's own).

Smallest fix: on-chain, v4 exposes no position age, so the sampler cannot filter one-block liquidity; the practical fixes are operational and should be stated in the NatSpec: (a) the keeper submits sample() through a private relay so it cannot be sandwiched, and (b) the Safe watches Sampled events whose sell1 exceeds the median of the day and lowers depthCap (instant). Alternatively count a bucket only when two samples at least one block apart agree within a tolerance (an attacker then has to hold the liquidity across blocks, with price risk). Correct lines 43-52.

rate() = min(live, checkpointRate x (1 + maxGrowthPerSecond x dt)) and poke() (permissionless) sets checkpointRate = rate(). A fall is taken in full at once (intended: "a loss must never be hidden"), but the cap then also governs the RETURN to a level the feed had already read. If the source's rate reads lower for one block (a vault that momentarily reports a loss, a reverting/rounding glitch, a bad-debt realisation that is later repaid, or any misreport) and anyone pokes in that block, the checkpoint is the dipped value and the feed reads min(live, dipped x (1 + cap x dt)) afterwards: with BetaConfig CAP = 0.001e18 / 1 days, a 10% dip is read for ~111 days after the source has recovered.

Impact: every position on the type is valued at the dipped rate for months. For sIMD (three RateFeed legs on the same source: F_SIMD_MEDIAN, F_SIMD_SPOT, F_SIMD_LIVE), wstETH (stEthPerToken), sUSDS and Steakhouse USDC, low falls by the dip, so positions that are healthy at market become liquidatable (sIMD at mat 170%, chop 20%: a position at CR 185% reads 166.5% and is bitten by the standing bid), and borrowing room shrinks. It is also one-directional griefing: the poker needs no capital, only a block in which the source reads low.

Reachability with BetaConfig: the mechanism is deterministic, but I could not identify a beta source whose rate an attacker can dip on demand: wstETH.stEthPerToken() and sUSDS move only by governance/accrual; ERC-4626 deposits and withdrawals round in the vault's favour (no dip); a Metamorpho or sIMD dip needs a realised loss or a misreport. Severity is therefore low (not attacker-triggerable on the shipped sources as far as I can tell), but the consequence when it does happen is a months-long mispricing that nothing on chain can correct (no admin, no re-anchor), which the design did not intend.

Call sequence: [source rate reads 0.9x for one block] -> anyone: RateFeed.poke() -> source back to 1.0x -> RateFeed.rate()/latestValue() read 0.9x growing at 0.1%/day.

Smallest fix: keep a high-water mark of accepted rates (uint192 highRate, set in the constructor and raised in poke when rate() exceeds it) and let the ceiling be max(checkpoint grown at the cap, highRate): a return to a level the feed has already accepted is not new value, while a donation above the high-water mark is still capped. Alternatively require two pokes a configurable interval apart before a FALL moves the checkpoint (a fall is still read live through rate() at once, so no loss is hidden).

Lines 27-37 state: the band is measured from the feeds' reference, "a price push before a sample does not change the reading: only positions do", a sample is refused when the pool is more than maxDeviationTicks from the reference, and "Wire attested/Chainlink feeds (for IMD: the attested IMD median x Chainlink ETH/USD), never a LivePoolPrice." script/DeployConfig.sol:371-405 (_depthSamplers, _sampler) wires feed1 = F_IMD_USD_LIVE = ProductFeed(LivePoolPrice(0xb07d), ETH/USD) for all three IMD samplers, with the reason given there (an attested leg is stale most hours and would stop sampling).

Consequences the NatSpec denies: for the 0xb07d sampler the reference IS the pool price (ratio p0/p1 = 1 / live), so PoolOffReference can never fire and the band follows any push; for POOL4 and the v1 imdUSD/IMD pool the reference is another pool's live price. README 'Known issues' (Measured depth) records the choice; the contract's own documentation does not, and a future reader of DepthSampler would take the deviation guard as live.

Not a code defect by itself (see the two low findings for what it enables); report as a documentation claim the deployed code does not have.

Fix: amend lines 27-37 to describe the live-reference wiring and its consequences, or wire a reference that does not move inside the sampler's transaction.

ChainlinkFeed.isStale() is block.timestamp - at > maxAge. MainnetConfig (inherited by BetaConfig) sets _cl(CL_USDC_USD, 6, 1 days) and _cl(CL_USDS_USD, 18, 1 days), while _cl(CL_USDT_USD, 6, 1 days + 1 hours) and pegQuoteFeedMaxAge = 1 days + 1 hours allow for the update transaction landing after the heartbeat.

Chainlink's heartbeat is the trigger for a new round; the round lands some seconds to minutes later, so in quiet markets (deviation below 0.25%) these two feeds read stale for a short window around every 24h mark. During that window the USDC (held), S-USDC-STEAKHOUSE, S-USDS and PEG (quote leg) types read priced = false: no borrowing or withdrawal, and no liquidation or redemption against them, and the blue sleeve's standing bid on S-USDS/S-USDC stands aside.

Minor and self-healing (minutes), but inconsistent with the other stablecoin feeds' allowance; Chainlink's own guidance is heartbeat plus a margin.

Fix: 1 days + 1 hours for both. Out of scope strictly (script/), reached through ChainlinkFeed.isStale.

SCOPE READ: SwarmFeed, SwarmFeeds, ChainlinkFeed, RateFeed, ProductFeed, LivePoolPrice, DepthSampler, ImdDepth, plus Pricer, ParametersBase.depthRule/depthLine/depthIMD, IFeed, v4 Lock/TickBitmap/Pool.swap semantics and script/DeployConfig.sol (BetaConfig). Passes: Math Precision, Boundary, Numerical Gap (the assigned area), then the entry-point inventory and the cross-protocol (v4 callback, flash accounting) checks. Tests run: the panel glob (114 pass) and three scratch proofs (fail as intended), deleted afterwards.

Q1 ATTESTATION ACCEPTANCE: holds. Domain = (IdentityMD Oracle, 2, block.chainid, address(this)); a leaf accepts only a digest over its own domain, so an attestation signed for another leaf or another chain recovers to a different address and reverts InvalidSignature (the relay forwards the same bytes; the signature cannot be re-targeted). Same attestation twice: usedRequests[requestId] -> ReplayedAttestation; a second request over the same window: toBlock <= lastToBlock -> WindowNotAdvancing. questionHash is recomputed from the pinned prefix and the SIGNED fromBlock/toBlock, so another question (another leaf's prefix, a different span) is WrongQuestion; spans are bounded per leaf (300-1200 price, 150-1200 spot/NHI, 45k-55k seat median, 6.5k-8k seat spot and depth). s <= half order, v in {27,28}, ecrecover(0) != attester. Floors: panelSize >= 100, agreed >= 67 (price/spot) or 51 (NHI, seats, depth), agreed <= panelSize; quorum is unchecked by design. Time: block.timestamp <= expiresAt, issuedAt <= block.timestamp, issuedAt <= expiresAt, issuedAt not older than maxAge, issuedAt >= _updatedAt (equality allowed: README known issue). Mainnet window: toBlock <= block.number and block.number - toBlock <= maxAge/12. The remote-chain clock (_tickClock, PARENT_SLACK) is unreached on mainnet (attestationChainId == chainid). Nothing found.

Q2 EPOCH CAP: holds as documented; nothing beyond the README's 'wrong pair' item. Checked: _fitsEpoch measures against the epoch ANCHOR (the value the feed held when the epoch opened), so n attestations inside one epoch move at most the allowance once; two steps straddling an epoch boundary give (1+cap)^2-1 = 44% once, then 20% per hour; the stale base (2x cap) needs maxAge + 1h of silence measured from max(acceptedAt, updatedAt), so a held attestation cannot earn it early; a wide epoch stores its first value (uint80: all shipped magnitudes fit) and holds later values within the cap of it; _returnAnchor opens the next epoch with bound = cap at a level the expired epoch already allowed, so it cannot widen the walk, and it is unavailable after 2 maxAge + 1h. Halt: after a 2h silence the FIRST relayer at 1.4A (or 0.6A) locks the honest A out for the epoch and for the way-back window (A is not within 20% of first = 1.4A), i.e. about 3h, for one attestation (0.5 IMD) plus the cost of having the panel attest 1.4A (holding the pool pushed at >= 7 of the 13 median samples over >= 300 blocks, exposed to arbitrage): the README's measured 'wrong pair' case, not worse. A gap larger than 2x the cap halts the feed until the market returns (documented and accepted).

Q3 FRESHNESS: holds. isStale = !hasValue || now - updatedAt > maxAge with updatedAt = the SIGNED issuedAt (never relay time, so a held attestation is fresh only for the remainder of its hour); issuedAt > block.timestamp is refused (no future value). ChainlinkFeed: updatedAt == 0 or in the future -> unpriced; LivePoolPrice is never stale by design (current block); ProductFeed and RateFeed are stale if either leg is and carry the older timestamp. A 'fresh' median may describe a window closing up to 300 blocks ago over up to 1200 blocks: the design's window rule, not a defect.

Q4 CHAINLINK LEGS: holds. answer <= 0, updatedAt == 0 or future, answer > 10^(18+dec) (1e36 per token), answer <= minAnswer or >= maxAnswer of the proxy's CURRENT aggregator -> (0,0) = unpriced and stale. Scaling verified for 8-decimal BTC/USD with tokenDecimals 8 (USD

Merged from audit_math (low), audit_permissions (medium) and audit_economics (medium); reproduced with the economics specialist's proof and my own variant (same block, keeper = a separate EOA, attacker balances unchanged afterwards).

The header (lines 43-52) rests the anti-inflation argument on the keeper: 'an attacker who adds liquidity only around his own samples cannot raise a bucket, because the keeper's honest sample in the same hour sets it. To inflate the figure he must keep the liquidity in the pool whenever anyone may sample, all day'. The keeper's sample() is an ordinary public transaction. An LP who front-runs it with modifyLiquidity(+L) and back-runs it with modifyLiquidity(-L) in the same block (a bundle, or a plain mempool sandwich) has liquidity in the pool at the hour's only honest sample while holding it for one block. sample() only refuses calls made INSIDE an unlock callback (line 210); nothing in it can tell one-block liquidity from liquidity held all day (v4 exposes no position age). The first sample of the hour sets the bucket (lines 220-221) and only lower samples move it, so after 24 sandwiched hours every bucket is MAX_RISE x the resting depth and depth() reads 2x; the next day 4x; after 7 days ImdDepth's 7-day low follows, until Parameters.depthCap (BetaConfig DEPTH_IMD = 80,100e18) binds.

Call sequence (block N, every hour): attacker Router.modifyLiquidity(+L over the band) ; keeper DepthSampler.sample() ; attacker Router.modifyLiquidity(-L). Hourly ImdDepth.poke() is the keeper's own chore.

Reachable with BetaConfig: yes. All three samplers are listed at genesis with permissionless sampling, the keeper samples hourly from a public account, and the IMD position needs only ETH when placed one-sided above the price (the IMD-sell side the samplers report, soldIsToken0 = false).

Impact at the README's figures: measured depth 61,954 admits an sIMD line of 21,636; the ceiling 80,100 admits 33,733 (README 'At $80.1k that is 33,733'). The attack converts the posted ceiling from a safety cap into the effective depth: about +12,100 imdUSD of sIMD line backed by no liquidity a liquidator could sell into, and invariant 6's premise (depthIMD is measured) does not hold. Bounded by the ceiling and by the Safe's instant postLowerDepth, which is why this is medium.

Cost (Q10): two modifyLiquidity transactions per hour for 7 days, about 340 transactions, roughly $1.5k-5k of gas at 10-30 gwei; the position (about the size of the resting in-band liquidity, $60-120k of ETH for the 0xb07d pool) is exposed for one block and no fee is paid. It pays for a borrower who wants the extra line.

NatSpec claims this falsifies: lines 48-51 ('the keeper's honest sample in the same hour sets it', 'liquidity held all day IS depth').

Smallest fix: make a reading depend on liquidity that survives a block: sample() stores (measure(), block.number) as a pending reading and a later-block call records min(pending, measure now) into the bucket (a JIT position must then sit through a block anyone can trade against). Operationally, submit the keeper's sample through a private relay and alert on Sampled events whose sell1 exceeds the day's median; correct lines 43-52.

Merged from audit_math (low + info), audit_permissions (low), audit_economics (low + its NatSpec item) and audit_flow (low): one mechanism, reproduced.

Three claims in scope are not properties of the shipped system. (1) DepthSampler lines 27-37: 'ANCHORED ON THE FEEDS, NOT ON THE POOL'S PRICE ... a price push before a sample does not change the reading: only positions do ... A sample is refused when the pool's tick is more than maxDeviationTicks from the reference tick ... Wire attested/Chainlink feeds, never a LivePoolPrice'. script/DeployConfig.sol:399 wires feed1 = F_IMD_USD_LIVE = ProductFeed(LivePoolPrice(0xb07d pool), ETH/USD) for all three samplers (the reason is given at :371-376 and in the README). For the two ETH/IMD samplers p0/p1 = ETH_USD / (live x ETH_USD) is the pool's own price, so refTick == tick, PoolOffReference can never fire, and the band follows any push; for the third (v1 imdUSD/IMD pool) the reference is the OTHER pool's live price. (2) Line 41: 'A push now needs real capital held across separate transactions'. sample() reads v4's transient unlock slot, which is cleared when unlock() returns, so a contract can unlock+swap+settle, call sample() with the manager locked, then unlock+swap back, all in one transaction: the capital is returned in the same transaction (flash-borrowable), and the attacker pays the LP fee twice (1% each way on 0xb07d) plus gas. (3) LivePoolPrice lines 12-13: 'THE REDEMPTION PAYOUT LEG ONLY ... never used to measure a borrower': it is the band reference of the samplers that size the sIMD line.

Relation to README 'Known issues: Depth griefing': the lowering of the sIMD line is accepted and measured there ('a 25% push costs about $9,998 of IMD'). That figure is the IMD notional sold; in the atomic form the attacker recovers it in the unwind, and the real cost is about 2% of it (~$200 for 25%, ~$450 for 50%) plus gas, with no capital held across blocks and no arbitrage exposure, i.e. about 50x cheaper than written. The impact is unchanged (it can only lower the line: 21,636 -> 10,500 for four sandwiched hours, or -> 4,765 at 50%, for about 8 days). The live reference also lets a push RAISE a reading by sqrt(price ratio) at constant liquidity, but that needs the pool held pushed at the keeper's sample (a sandwich of the keeper, finding 1) and is bounded by MAX_RISE; at the 1% fee it does not pay. Reported as low: a documentation and cost-model defect over an accepted risk, with the reading extreme being a bucket of 0 when the push leaves the band empty.

Call sequence (one transaction from any EOA via a helper): PoolManager.unlock -> swap IMD->ETH to sqrtP x sqrt(1.25) -> settle ; DepthSampler.sample() ; PoolManager.unlock -> swap back to the original sqrtP -> settle. Repeat in 4 UTC hours of one day; the keeper's own ImdDepth.poke() records it. Reachable with BetaConfig: yes (all three samplers use F_IMD_USD_LIVE).

Smallest fix: refuse a sample whose pool tick is more than maxDeviationTicks from the tick seen by the last sample taken in an EARLIER block (store (lastTick, lastBlock)); a push then has to be held across blocks with a sample in each, exposed to arbitrage, which restores the capital-at-risk the NatSpec describes. And rewrite DepthSampler lines 27-41 and LivePoolPrice 12-13 to state the live-reference wiring and what it gives up; correct the README cost figure.

Merged from audit_math (low) and audit_permissions (info); reproduced.

rate() = min(live, checkpoint x (1 + maxGrowthPerSecond x dt)) and the permissionless poke() writes rate() as the new checkpoint (line 73). The NatSpec (lines 11-12) describes poke as moving the checkpoint UP to the capped rate and says a fall is taken in full at once so that a loss is never hidden; but a poke landed in a block where the source reads low also moves the checkpoint DOWN, and from then the ceiling grows from the dipped value: with BetaConfig CAP = 0.001e18 / 1 days, a 10% dip is read for ~111 days after the source has recovered, a 1% dip for 10 days. Every position on the type is valued at the dipped rate meanwhile: for sIMD (three RateFeed legs on the same source) 'low' falls by the dip, so positions healthy at market become liquidatable (mat 170%: CR 185% reads 166.5%), and borrowing room shrinks. Nothing on chain can correct it (no admin, no re-anchor).

Reachability with BetaConfig: the mechanism is deterministic but no shipped source was identified whose rate an attacker can dip on demand: wstETH.stEthPerToken and sUSDS move by accrual/governance, ERC-4626 conversions round in the vault's favour, and a MetaMorpho or sIMD dip needs a realised loss or a misreport that is later reversed. Hence low: not attacker-triggerable as far as I can tell, but when it happens the consequence is a months-long mispricing the design did not intend.

Call sequence: [source reads 0.9x for one block] -> anyone: RateFeed.poke() -> source back at 1.0x -> rate()/latestValue() read 0.9x growing at the cap.

Smallest fix: keep a high-water mark of accepted rates (uint192 highRate, set in the constructor, raised in poke when rate() exceeds it) and let the ceiling be max(checkpoint grown at the cap, highRate): a return to a level already accepted is not new value, while a donation above the high-water mark is still capped. Alternatively refuse to lower the checkpoint unless the live rate reads low in a later block as well (two-step fall).

From audit_economics (low); reproduced with a real DepthSampler and ImdDepth.

DepthSampler.depth() returns 0 while fewer than MIN_BUCKETS (20) of its 24 slots are inside the 26-hour window. Six missed hours are tolerated; a seventh makes it 0, and because slots alias by hour % 24 the count stays at 17-19 for most of a day after sampling resumes (the missed hours' slots refill only when their hour comes round). ImdDepth.poke() (line 119) folds sampled() into the UTC hour's reading without distinguishing 'measured 0' from 'not enough buckets'. Four pokes in four of those hours (the keeper's own hourly chore, or anyone for ~4 x 100k gas) make the day's 4th-lowest hour 0, depth() is the minimum over the last 7 day figures, so the sIMD line is 0 for the following 7 days while the pool, the sampler and the pokes are healthy again within a day. The header (lines 28-29) states only the fresh-deployment 6-day zero and 'a week of silence must not read as depth'; it does not state that 7 hours of silence reads as a week of zero.

Causes of a 7-hour sampling gap in the beta: the keeper's sampler down with nobody else sampling, or ETH/USD (ChainlinkFeed, maxAge 70 min) stale for 7 hours so measure() reverts StaleFeed. Not attacker-triggerable on the beta pools (PoolOffReference is inert on the live-referenced pools, finding 2; WalkTooLong needs ~4,096 steps and the band spans at most ~330 initialised ticks on the spacing-10 pool). So: a liveness amplification plus a permissionless four-poke trigger during any natural gap. Cost: the gas of four pokes; pays only as griefing (no new sIMD debt for a week).

Call sequence: 8 days of hourly sample()+poke() ; 7 hours of poke() only ; sampling resumes with hourly sample()+poke().

Reachable with BetaConfig: yes (ImdDepth listed at genesis with the three samplers).

Smallest fix: in poke(), do not record a reading when sampled() == 0 (depth() still fails closed live while sampled() is 0; a listed pool with literally no liquidity in the band is not a case the day memory needs). Better: expose DepthSampler.hasWindow() (filledBuckets() >= MIN_BUCKETS) and skip the record while any listed sampler lacks a window.

From audit_flow (reported medium); reproduced with its proof. Lowered to low because the beta deploys every feed on the data chain (attestationChainId == block.chainid == 1), where the local branch at line 401 enforces toBlock <= block.number, and because it needs the pinned attester to sign a window that did not exist when it was signed (an attester fault or compromise).

On a feed whose data chain is not the consumer chain and not the block-clock chain (every consumer except Ethereum and Robinhood Chain: Base, Sepolia), _requireQuestion applies only _tickClock. _tickClock refuses a window BEHIND the projected head (line 429) but never one AHEAD of it, then stores clockBlock = max(toBlock, projected) and lastToBlock = toBlock. The header (lines 80-87) states the premise 'the window existed when it was signed, so toBlock <= head(issuedAt)' but the code never checks it. A signed attestation with toBlock = 1e12 is accepted, after which every honest window reverts WindowNotAdvancing (or WindowBehindClock) forever: the feed, and every type pinned to it, is halted (no borrowing, no liquidation at a price), outside the stated trust model 'a compromised attester can move those feeds within the cap per epoch', and contradicting 'a run of laggy windows cannot walk it into the past' (the future is unguarded).

Smallest fix: in the remote branch, once clockAt != 0, revert WindowInFuture when a.toBlock > projectedHead(a.issuedAt) + PARENT_SLACK (the first value still sets the clock).

From audit_permissions (low); reproduced.

The way back accepts any value within the cap of the expired epoch's LEVEL regardless of where the feed's last accepted value is. Epoch anchored at A; at minute 59 an honest 0.8A is accepted (within the cap of the anchor); at minute 60 the epoch has expired and 1.2A is submitted: _fitsEpoch fails (anchor 0.8A, fresh allowance admits at most 0.96A) but _returnAnchor passes (level = _anchorValue = A, |1.2A - A| <= 20%). The feed moves +50% in one accepted attestation while fresh, and the new epoch is anchored at A with the plain cap, so the pushed level persists for a lifetime and the next epoch opens from 1.2A. The NatSpec at line 519 ('reaches no level the expired epoch did not already allow') is true; the README trust model ('a value moves at most a fixed cap per epoch, widened at most 2x after an hour of staleness') and the known issue ('up to 40% after a silence and 20% per epoch') are not. Harm is bounded: 2.5x the per-epoch cap once, in the direction opposite to a genuine move, with the attestation bought at the cost the README's 'wrong pair' item describes (holding the pool pushed for >= 7 of 13 median samples over >= 300 blocks, exposed to arbitrage, plus 0.5 IMD). Reachable with BetaConfig (1h lifetime, 2,000 bps).

Smallest fix: in _returnAnchor also require the value to lie between the last accepted value and level (a return TOWARD the level is what the way back exists for): if (value > max(level, _value) || value < min(level, _value)) return 0;

Merged from audit_permissions and audit_economics (NatSpec items). Verified by grep: 'verifySeeded', 'OracleAsker', 'WIDE_ALLOWANCE_BPS' and 'SwarmWorkOracle' occur nowhere in src/, script/ or test/ except in src/feeds/SwarmFeed.sol.

(1) Lines 300-302 and 476-479: 'DeployMainnet.verifySeeded refuses a price or spot anchor more than a quarter of the cap from the pool ... from a salt no one else knows'. No such check exists; DeployConfig says the swarm feeds are deployed EMPTY and the relay is permissionless, so the FIRST value of every price, spot, NHI, seat and depth leaf is unbounded on chain and whoever relays first anchors it. This matters operationally: the runbook, not the code, stops a raced first relay.

(2) Lines 553-554: 'the Treasury does, through OracleAsker, once the allowance reaches WIDE_ALLOWANCE_BPS': neither exists.

(3) Lines 255-256 and 591-592 name PriceFeed, NhiFeed, SpotFeed, SwarmWorkOracle; the leaves here are SwarmPriceFeed, SwarmSpotFeed, SwarmNhiFeed, SwarmSeatMedianFeed, SwarmSeatSpotFeed, SwarmImdDepthFeed (the stated property, no path to _accept without an attestation, does hold for them).

(4) Lines 157-159: MAX_ALLOWANCE_BPS 'The allowance never exceeds this' is never referenced; the bound holds only through maxDeviationBps <= 10_000 and STALE_DEVIATION_MULTIPLE = 2.

(5) Lines 534-537 describe _epoch as 'Public so a buyer can see' on a private function (the public one is epoch()).

(6) Line 63 cites test/SwarmFeed.t.sol (here test/unit/SwarmFeed.t.sol).

(7) Lines 286-287 say the deterministic chain-read feeds demand two thirds; SwarmImdDepthFeed (also a deterministic read of pool 0xb07d) keeps 51. It can only lower depth, and the leg is unset in the beta.

(8) DepthSampler line 19 'read as the minimum over the last day' vs the code's 4th-lowest bucket over 26 hours.

Fix: amend the comments; for (1) either add the seed check to the deploy script or state that the first relay is the deployer's to win.

SCOPE READ: SwarmFeed, SwarmFeeds, ChainlinkFeed, RateFeed, ProductFeed, LivePoolPrice, DepthSampler, ImdDepth; dependencies Pricer (quote/_applyLive), ParametersBase.depthRule/depthIMD/depthLine, IFeed, v4 Lock/StateLibrary/TickBitmap semantics, script/DeployConfig.sol (BetaConfig/MainnetConfig), README. Specialists' 20 findings were each re-read against the code; 9 mechanisms survive (merged above), none was dropped as non-reproducing, three were lowered in severity (clock: not reachable in the beta; two JIT lows raised to the merged medium). Tests: the panel glob (121 pass) plus my scratch reproductions, deleted afterwards.

Q1 ATTESTATION ACCEPTANCE: holds. Domain (IdentityMD Oracle, 2, block.chainid, address(this)) binds consumer chain and leaf, so a signature for another leaf, feed address or chain recovers to a different address -> InvalidSignature; the signed chainId must equal the pinned data chain (1); questionHash is recomputed from the pinned prefix + signed fromBlock/toBlock, so another question or span -> WrongQuestion; spans bounded per leaf (300-1200 price, 150-1200 spot/NHI, 45k-55k seat median, 6.5k-8k seat spot/depth); requestId consumed before the question check -> ReplayedAttestation on a second submission; WindowNotAdvancing on a second window at or before lastToBlock; s <= n/2, v in {27,28}, ecrecover(0) != attester; floors panel >= 100, agreed >= 67 (price, spot) / 51 (NHI, seats, depth), agreed <= panelSize, quorum unchecked by design; now <= expiresAt, issuedAt <= now, issuedAt <= expiresAt, issuedAt within maxAge and >= last accepted issuedAt (equal allowed: README known issue); mainnet window: toBlock <= block.number and within maxAge/12 blocks. Nothing found on the beta. Off the beta (remote consumer chains) see finding 5.

Q2 EPOCH CAP: holds as documented except finding 6. _fitsEpoch measures from the epoch ANCHOR, so n attestations inside one epoch move at most the allowance once; two steps straddling a boundary give (1+cap)^2-1 = 44% once; the stale base (2x) needs maxAge + 1h of silence from max(acceptedAt, updatedAt), so a held attestation cannot earn it early; a wide epoch stores its first value (uint80: all shipped magnitudes fit) and holds later values within the cap of it; _returnAnchor reaches no level the expired epoch did not allow, but allows a 50% step from the LAST value (finding 6). Halt: after a 2h silence the first relayer at 1.4A (or 0.6A) locks the honest A out for about 3h for one attestation plus the pushed-pool cost (README 'wrong pair', not worse); a single-step gap beyond 2x the cap halts the feed until the market returns (documented).

Q3 FRESHNESS: holds. SwarmFeed stamps the SIGNED issuedAt (future refused, delayed relay cannot extend life); isStale = !hasValue || now - updatedAt > maxAge. ChainlinkFeed: updatedAt 0 or future -> unpriced. ProductFeed: older stamp, stale if either leg. RateFeed: underlying's stamp, stale if rate() == 0. LivePoolPrice: never stale by design (current block). A 'fresh' median may describe a window closing up to 300 blocks ago: the design's window rule.

Q4 CHAINLINK LEGS: holds. answer <= 0, updatedAt 0/future, answer > 10^(18+dec), answer at the current aggregator's minAnswer/maxAnswer -> (0, 0) unpriced and stale; scaling checked for 8-decimal BTC/USD with tokenDecimals 8 and for 18-decimal ratio feeds. Info: a dirty narrow word reverts instead of (0, 0) (finding 9); the 'int192 maximum' remark at line 56 has no corresponding check (harmless).

Q5 RATE AND PRODUCT FEEDS: finding 3 (a poked transient dip is read for months). Ceiling growth: ck x (1 + cap x dt) from the last poke, so headroom accrues while nobody pokes (README known issue); a donation cannot lift the rate above the ceiling whether or not poked (view-side cap). A rate above what the source supports: not found (rate() = min(live, ceiling)). ProductFeed: a x b / 1e18 with checked arithmetic; both legs bounded on the beta (Chainlink 1e36 cap; swarm legs bounded after the first