requestJudging(week) writes requestOf[week] and pendingDay[requestId] and draws 0.5 IMD from the week's thesis pool. The only thing that ever sets judgedSet[week] is a successful onOracleResult. Per the IdentityMD Intake's documented behaviour, a refused body (status 1), a panel that does not agree (status 2), or a callback that reverts or runs out of its 200,000 gas is never retried and never calls back again.

MarginaliaJudge's callback also reverts on its own for answers it is bound to receive sometimes: every ranked id filtered out (kept == 0 -> BadAnswer), agreed < quorum, or an attestation delivered after expiresAt (validForSeconds 86400).

In all those cases requestOf[week] stays set, so requestJudging(week) reverts AlreadyRequested for ever, payJudged(week) reverts NotJudged for ever, and hook.payJudged is judge-only, so the week's thesis pool (30% of every accrual that week) can never be paid or rolled forward. The oracle-consumer reference requires a deadline after which a pending request can be cleared, and that a 'no' answer is stored rather than reverted.

This contracts-only launch deploys MarginaliaRouter, MarginaliaJudge and MarginaliaTreasury as the implementations, and the deployment handoff publishes their addresses under those names. Each has a public one-shot init that the implementation never calls itself or disables, and its only guard is 'not yet initialised', not the caller. The first caller configures the published contract with any hook.

The launch policy forbids initializers and configuration after deployment (medium).

Concretely: (a) MarginaliaTreasury.init(attackerHook). Any IMD later sent to the published treasury address then drips 2% a day to the attacker, because drip approves and calls attackerHook.fundPot, which pulls the amount. If nobody calls init, IMD sent there is stuck for ever, because drip() reverts on hook = 0.

(b) MarginaliaRouter.init(PoolManager, attackerHook). A user or frontend that uses the published router address swaps its IMD into the attacker's pool (getPoolKey/imd/token are the attacker's). (c) MarginaliaJudge.init sets an arbitrary oracle signer.

The same pattern is at src/MarginaliaRouter.sol:90 and src/MarginaliaJudge.sol:61.

_priceInImd hands the note's venue straight to PriceAdapters.priceInQuote. For VenueKind.UniV3 and UniV2 the adapter calls slot0() / getReserves() on address(uint160(uint256(v.ref))) (src/PriceAdapters.sol:38, 42), and for UniV4 it reads any pool id, so the 'market price' of X at posting and at every observe() is whatever a contract the author deployed returns.

Nothing checks the venue against the canonical factories the way the router now checks an X trade leg (finding 2961f6c1 fixed only the router). X itself only needs code and a totalSupply, so the author also picks the market-cap tier. The score is then log2(targetBps) * sqrt(30/horizon) * tier with targetBps up to 2^32-1, horizon 1 and tier 3: about 3.07e6 against 1375 for an honest +10%/30-day call.

A positive weekScore entitles the wallet to the week's leaderboard pool pro rata, capped at 10% per wallet; the cap is per address, so ten sybil wallets take the whole pool. The pool is 50% of every accrual: other authors' stamps, every sell fee, converted forfeits and the treasury's daily drip. Cost to the attacker: the 0.1 IMD stamp per note (itself refundable up to one stamp from the day's refund pool) and gas; the deposit comes back fee-free on RIGHT.

Fix options that keep the design: at _postNote require a UniV3/UniV2 venue to be the pool/pair the canonical factory returns for (X, quote) and a UniV4 pool id to belong to a pool whose currencies are (X, quote), and store the venue only after that check; or refuse UniV3/UniV2 venues entirely in v1 and price only through PoolManager pools.

Self-made canonical pools remain gameable, so the economic review should also weigh capping scores by a liquidity floor; this finding covers the unverified venue.

The refund sweep (kind 0) and the thesis sweep (kind 2) zero the swept pool, but the leaderboard sweep (kind 1) only records leaderboardSwept[epoch] = leaderboardPool[epoch] and adds the remainder to the current week. claimLeaderboard(w) (line 776: uint256 amount = leaderboardShare(w, msg.sender);) computes the share from the untouched leaderboardPool[w] and never reads leaderboardSwept, so every wallet with a positive weekScore[w] that had not claimed before the sweep is still paid in full afterwards.

That IMD was already booked to leaderboardPool[currentWeek] and will be claimed there too. Both payments burn the hook's ERC-6909 IMD claims, which back every pool: after the double payment the hook holds less IMD than the sum of its live pools, and the shortfall lands on whoever claims last (claimLeaderboard, claimRefund, payJudged or drawForJudging reverts in poolManager.burn with insufficient balance).

The sweep is permissionless, so any wallet that scored in a week and waits 28 days can collect its share twice over time (once directly, once through the rolled-forward week it also scores in).

Fix: zero leaderboardPool[epoch] in the kind-1 branch (claimLeaderboard then returns 0 -> NothingToClaim, and leaderboardSwept becomes unnecessary), or make leaderboardShare return 0 when leaderboardSwept[w] == leaderboardPool[w] after a sweep.

The thesis sweep only checks the clock: 28 days after the week ends anyone may move thesisPool[epoch] into the current week. It does not ask the judge whether the week has a pending request (judge.requestOf(epoch) != 0 and not yet judged) or a stored ranking that has not been paid (judge.judgedSet(epoch) && !judgedPaid[epoch]).

MarginaliaJudge.requestJudging has no deadline of its own, so a week can be requested on day 27 after it ends; the Intake answers minutes to hours later; once the sweep window opens, a front-run sweep(2, w) before judge.payJudged(w) zeroes the pool, hook.payJudged then pays shares of 0 and marks judgedPaid[w], and the 0.5 IMD drawn from the pool for the oracle bought nothing.

The ranked authors lose the prize they were judged to have won; the IMD is not lost to the system but to the wrong week's claimants.

Fix: in the kind-2 branch revert when judge.requestOf(epoch) != bytes32(0) && !judgedPaid[epoch] (a pending or judged-but-unpaid week), or have MarginaliaJudge.requestJudging refuse a week once its sweep window is within REQUEST_TTL.

Clones.clone (OpenZeppelin 5.0.2) only checks that CREATE returned a non-zero address; it does not check that the implementation has code. The clone is a 45-byte EIP-1167 proxy, so Solidity's extcodesize check on t.init / r.init / j.init passes, the proxy delegatecalls to an address without code, the EVM returns success with empty return data, and because init returns nothing the call is treated as a success.

The constructor therefore completes, the factory initializes the pool and beforeInitialize binds it, and the hook is live with three companions that revert on every call (router.note: the clone returns no data to decode; treasury.drip, judge.requestJudging likewise). No note can ever be posted, no drip or judging can happen, and with no owner or upgrade the only remedy is a new launch, while the pool and its liquidity keep trading under the hook.

This is exactly the state of the tree today: src/MarginaliaImpls.sol holds rehearsal placeholders 0x...a0001/2/3, and ADAPTATION.md itself notes 'a clone of a codeless address accepts init silently'. The hook launch's protected rehearsal (Hook.protected.t.sol) deploys the hook on a chain where those addresses are empty, so it passes with or without the real addresses and cannot catch the mistake.

Fix: require MarginaliaImpls.ROUTER_IMPL.code.length > 0 (and the other two) in the constructor, and/or have each init return a value (for example its own address) that the constructor checks, so a codeless delegatecall's empty return data makes the constructor revert. The hook's constructor already requires code at poolManager_ and token_, so this adds no new rehearsal constraint.

_postNote copies p.venue into the note with no check that it is a Uniswap pool, that it trades p.x, or that it is quoted in what it says. _priceInImd (src/MarginaliaHook.sol:469-479) and PriceAdapters.priceInQuote (src/PriceAdapters.sol:32-47) then read the post price and every observation price from whatever venue.ref names: for VenueKind.UniV3 and UniV2 that is a bare slot0() / getReserves() call on an address the author chose (any contract answering those selectors), and for UniV4 any pool id, including a pool the author created and is the only LP of.

The settlement in settle (settlePrice * 10_000 >= n.postPrice * n.targetBps), the hold rule and the difficulty tier (postPrice * totalSupply) therefore all run on numbers the author sets. A note with a self-reported price is Right whenever the author wants, books +difficulty into weekScore, returns its deposit through claimDeposit, and claimLeaderboard pays the author leaderboardPool[w] * score / weekTotal[w] capped at 10% per wallet.

Ten wallets, each posting one note with targetBps = type(uint32).max (difficulty 32e4 x 54772 / 1e4 x 3 = 5,258,112, which dwarfs any honest score), take 100% of a week's leaderboard pool, i.e. half of every stamp, sell fee, forfeit and treasury drip accrued that week, for ten stamps (1 IMD) plus gas.

The prior fix of the router's trade venue (factory lookup in _tradeV3/_tradeV2) does not cover this: the note's price venue is a different field (NoteParams.venue) and is never compared with anything.

Fix: validate the venue at posting, i.e. for v3/v2 require factory.getPool/getPair to return venue.ref and that p.x and venue.quote are its two tokens with xIsToken0 matching; for v4 take the PoolKey (not the id) in the venue, require key.toId() == venue.ref, the currencies to be p.x and venue.quote, and ideally a liquidity floor, since any wallet can open a v4 pool at any price.

sweep(1, epoch) (src/MarginaliaHook.sol:816-820) moves leaderboardPool[epoch] - leaderboardSwept[epoch] into leaderboardPool[_week()] and sets leaderboardSwept[epoch] = leaderboardPool[epoch], but leaves leaderboardPool[epoch] and every weekScore[epoch][*] untouched because leaderboardShare needs them. claimLeaderboard(w) checks only w < _week(), leaderboardClaimed[w][msg.sender] and amount > 0; it never looks at leaderboardSwept[w].

So after the sweep every wallet with a positive score in week w can still claim its full share, computed on the pre-sweep pool, and _unlock(ACT_PAY, ...) burns IMD claims that the sweep has already re-promised to the current week's pool.

The conservation invariant hook ERC-6909 IMD balance >= sum of live pools breaks by the claimed amount; the shortfall is borne by whichever later claim (a refund, a leaderboard share, a judged prize, the judge's draw) finds the hook short, where poolManager.burn reverts. A second sweep(1, w) after such a claim reverts with an arithmetic underflow (leaderboardSwept > leaderboardPool).

The refund pool (kind 0) and thesis pool (kind 2) do not have this gap because they are zeroed.

Fix: make claimLeaderboard revert once leaderboardSwept[w] >= leaderboardPool[w] (the week is swept), or have the sweep only roll forward what no wallet can still claim (pool minus the sum of unclaimed capped shares) and mark the week closed.

The sweep's own comment restricts kind 2 to 'a week with no thesis, under the judge threshold, or never judged', but the code checks only the clock: 28 days after the week ends anyone may zero thesisPool[epoch] and roll it into the current week.

Nothing in the hook records that the judge has drawn the oracle price for that week (drawForJudging), that a request is pending, or that onOracleResult already stored a ranking; judgedPaid[w] is set only by payJudged, which is a separate permissionless call with no deadline and no reward. payJudged then computes shares = [pool*50/100, pool*30/100, pool*20/100] on thesisPool[w] == 0, pays three zero transfers, sets judgedPaid[w], and the week can never be paid again.

The same happens when requestJudging is called late (there is no deadline on it either) and the Intake's answer lands after the sweep: the 0.5 IMD oracle price is spent and the winners get nothing. The money is not destroyed (it moved into the current week's thesis pool) but it is paid to the wrong week's winners, and the oracle fee is wasted.

Fix: have sweep(2, w) refuse a week the judge has drawn for (track drawnForJudging[w] in drawForJudging, cleared by payJudged), or have payJudged carry its own roll-forward and the sweep skip judged weeks; alternatively have the judge's onOracleResult call hook.payJudged directly when the callback gas allows.

Asymmetry between the three sweep kinds and their claim counterparts. sweep(0, day) zeroes refundPool[day] and claimRefund then computes 0 and reverts; sweep(2, week) zeroes thesisPool[week]. sweep(1, week) cannot zero leaderboardPool[week] because leaderboardShare() needs it as the pro-rata base, so it moves the unclaimed remainder (leaderboardPool - leaderboardSwept) into the current week and sets leaderboardSwept[week] = leaderboardPool[week].

But claimLeaderboard(week) (src/MarginaliaHook.sol:773-782) never reads leaderboardSwept: after the sweep it still computes the wallet's full share from the untouched leaderboardPool[week], marks leaderboardClaimed, adds to leaderboardSwept and burns IMD claims for it. The IMD that was already credited to the current week's pool is paid out a second time.

The hook holds a single pool of ERC-6909 IMD claims for every pool, so the sum of all live pools now exceeds the claims that back them; whichever claimant (leaderboard, thesis winner via payJudged, writer refund) is last loses that amount when poolManager.burn reverts. Any wallet with a positive score in a swept week triggers it, with no cost beyond gas, and the weekly 10% cap means one wallet can take up to 10% of the week's pool per swept week.

Trust gap, access x economics. MarginaliaHook.sellPotMarg (src/MarginaliaHook.sol:718-725) is restricted to the judge 'so the timing is predictable', and the sale runs in unlockCallback ACT_SELL with sqrtPriceLimit MIN_SQRT_PRICE + 1 and no minimum IMD out.

MarginaliaJudge.convertForfeits is a permissionless, unconditional pass-through to it (any caller, any time, the entire potMarg in one swap), so the access guard is correct in isolation and the swap is a standard pool swap, yet the combination hands the timing and the size of a bounded-less market sale of shared funds to whoever wants to sandwich it.

The attacker sells MARG into the hook's pool, calls convertForfeits so the pot dumps at the depressed price, and buys back in the same transaction; no mempool race is needed because the attacker makes the call. Victims are every leaderboard, thesis and refund claimant, whose pools receive less IMD for the pot's MARG.

The 3% quiet sell fee limits the attacker's own margin but does not protect the pot: in the reproduction the pools receive 5% less (and 18% less at a 200 MARG sandwich, which only the attacker's margin makes unattractive), and an attacker who is also an LP captures the LP side too.

The NatSpec says kind 2 is for 'a week with no thesis, under the judge threshold, or never judged', but the branch checks only the 28-day clock. It does not consult judge.judgedSet(week) / judgedPaid[week] or an open oracle request.

Once a week's ranking has been bought (0.5 IMD drawn from the same pool) and delivered, the prize is still only paid when someone calls MarginaliaJudge.payJudged(week); if that has not happened 28 days after the week ends, anyone calls sweep(2, week), thesisPool[week] becomes 0 and is added to the current week, and the later payJudged pays 50/30/20 of zero while still marking judgedPaid and judgedWins.

The ranked authors lose the prize the oracle awarded them; it goes to the current week's winners instead, which the sweeper can be. The same happens when a request is pending at day 28 (requested late or re-requested after REQUEST_TTL) and the answer lands after the sweep. Asymmetric with the leaderboard side, where the claimant's entitlement survives the sweep (finding 1), and with the judge, which refuses to re-request a judged week.

A note's price venue is whatever p.venue names: for UniV2/UniV3 kinds PriceAdapters.priceInQuote calls getReserves()/slot0() on the raw address in venue.ref, and for UniV4 any pool id, with no factory check, no liquidity floor and no TWAP (the router authenticates trade venues against the canonical factories, the hook authenticates price venues against nothing). _postNote only requires p.x to have code. observe() re-reads the same venue and settle() scores _difficulty() from the author's own targetBps (uint32, up to 4.29e9 = 429,496x), horizon and IERC20(x).totalSupply() (attacker-minted, so tier 3).

An author therefore deploys a token X and a 20-line contract returning reserves of their choosing, posts a BUY call '400,000x in 1 day' for ~1 IMD (0.1 IMD stamp, 0.5 IMD of MARG deposit that comes back on RIGHT), sets the reserves a day later, observes three times and settles RIGHT with a week score of 3,050,115 against ~20,700 for an honest 2x-in-7-days call. leaderboardShare caps a wallet at 10% of the week's pool, so ten such wallets take 100%.

The leaderboard is half of every stamp, sell fee, forfeit and treasury drip, so this is the protocol's main payout being paid to whoever games it, at ~1 IMD per 10% of the pool.

sweep(1, epoch) moves leaderboardPool[epoch] - leaderboardSwept[epoch] into the current week's pool and sets leaderboardSwept[epoch] = leaderboardPool[epoch], but neither leaderboardPool[epoch] nor the per-wallet eligibility changes. claimLeaderboard(w) only checks w < _week() and leaderboardClaimed[w][msg.sender], then computes the share from leaderboardPool[w] and burns that many IMD claims (_unlock(ACT_PAY, ...)).

So after the sweep every wallet with a positive score in week w can still claim its full share, while the same IMD has already been credited to the current week's pool. The hook's ERC-6909 IMD balance then falls short of SUM(pools): whoever claims last from any pool (a thesis winner via payJudged, a leaderboard or refund claimant) hits burn with insufficient balance and is never paid.

The kind-0 and kind-2 sweeps zero their pool so late claimants get nothing; kind 1 is the asymmetric one.

questionBody puts only the first MAX_JUDGED (200) ids of hook.thesesOfWeek(week) into guards.allow, and the hook records at most MAX_DAY_NOTES (256) thesis ids per week (weekTheses[_week()].push), in posting order. There is no per-author limit and a thesis costs one note (0.1 IMD stamp + 0.5 IMD of MARG deposit, min ~0.61 IMD).

Right after a week starts an attacker posts 200 one-character theses (measured: 122 IMD and 98M gas), including one or three actually argued ones; every thesis anyone else posts that week is absent from the allow list, so the panel can only rank the attacker's. The week's thesis pool (30% of all stamps, sell fees, forfeits and treasury drips: 4,200 IMD/week with a 100,000 IMD treasury) is then paid 50/30/20 to the attacker's own wallets by payJudged.

30% of the forfeited junk deposits also flow back into the same pool. The exclusion alone (honest theses unjudgeable for 122 IMD) is the griefing form.

_accrue sends 20% of every accrual (stamps, sell fees, converted forfeits and the treasury's 2%/day drip via fundPot) into refundPool[today].

The only outflow is claimRefund, capped at one STAMP (0.1 IMD) per non-retracted note, and notesPerDay is capped at 256 by weekTheses/MAX_DAY_NOTES semantics only for theses but in practice bounded by gas and the per-day count, so a day can pay out at most notesPerDay x 0.1 IMD. sweep(0, day) moves the remainder into another day's refund pool, which has the same cap.

Any day whose accruals exceed ~128 IMD (a treasury above ~6,400 IMD drips more than that) adds surplus that no code path can ever pay to anyone: with a 100,000 IMD treasury the first drip alone puts 400 IMD into the day's refund pool against 0.5 IMD payable to that day's 5 notes. Over the treasury's life ~20% of it (minus a few IMD/day) accumulates in refund pools with no exit, contradicting 'everything feeds a pot that pays'.

Merged from audit_flow (2accb7de), audit_economics (17cab1d2) and audit_math (1e1cf71a); reproduced. _postNote stores p.venue from the router's hookData unchecked (line 428) and reads postPrice from it (line 443); observe (line 498) re-reads the same venue. PriceAdapters.priceInQuote (src/PriceAdapters.sol:38, 42) calls slot0() / getReserves() on the bare address in venue.ref for VenueKind.UniV3 / UniV2 and getSlot0 on any pool id for UniV4.

Nothing compares the venue with the canonical factories (the router's 2961f6c1 fix covers only the X trade leg), with p.x, or with a liquidity floor. X only needs code and a totalSupply, so the author also sets the market-cap tier (3). settle then scores _difficulty from the author's own targetBps (uint32, up to 2^32-1), horizon (1 day) and tier: about 3.07e6 against ~1,400 for an honest +10%/30-day call.

A positive weekScore entitles the wallet to leaderboardPool[w] pro rata, capped at 10% per address; ten sybil wallets take the whole pool, which is 50% of every stamp, sell fee, converted forfeit and treasury drip.

Cost: one 0.1 IMD stamp per wallet (the deposit returns on RIGHT, the stamp is itself refundable from the day's refund pool). Residual even after a factory check: a canonical v4/v3/v2 pool the author created and is the only LP of, or a thin pool manipulated in the observation block, gives the same control, so the fix should also require the venue's currencies to be (X, quote) and weigh a liquidity floor or the univ4-spot recipe the SPEC mentions.

Fix that keeps the design: at _postNote require a UniV3/UniV2 venue to equal factory.getPool(x, quote, fee) / getPair(x, quote) with xIsToken0 matching, and a UniV4 venue to be given as a PoolKey whose id equals venue.ref and whose currencies are (x, quote); or refuse UniV3/UniV2 venues in v1.

Merged from audit_flow (ffdf1939), audit_economics (278f4a6e), audit_math (39b0ef44) and audit_permissions (fb597398); reproduced.

The kind-0 and kind-2 sweeps zero the swept pool, but the kind-1 branch (lines 818-820) only sets leaderboardSwept[epoch] = leaderboardPool[epoch] and adds the remainder to leaderboardPool[_week()], because leaderboardShare needs leaderboardPool[w] as its pro-rata base. claimLeaderboard(w) checks only w < _week() and leaderboardClaimed[w][msg.sender], computes the share from the untouched leaderboardPool[w] and never reads leaderboardSwept.

Every wallet with a positive weekScore[w] that had not claimed before the sweep is therefore still paid in full afterwards, while the same IMD is already booked to the current week's pool and will be paid there too. Both payments burn the hook's ERC-6909 IMD claims, which back every pool: after the double payment the sum of live pools exceeds the claims, and whoever claims last (claimLeaderboard, claimRefund, payJudged or drawForJudging) reverts in poolManager.burn.

A second sweep(1, w) after such a claim reverts with an arithmetic underflow (leaderboardSwept > leaderboardPool).

Permissionless and free: any wallet that scored in a week and waits 28 days collects its share after the pool has been rolled forward.

Fix: zero leaderboardPool[epoch] in the kind-1 branch (claimLeaderboard then returns 0 -> NothingToClaim), or make claimLeaderboard revert once leaderboardSwept[w] >= leaderboardPool[w], or roll forward only what no wallet can still claim.

Merged from audit_flow (8458b1a2), audit_economics (e075ec4d), audit_math (dce3ad7b) and audit_permissions (c9c9d71b); reproduced by tracing and by a scratch test against the fixture (thesisPool after the draw 5.53e18; after sweep(2, w) and judge.payJudged(w) the ranked author received 0 and judgedPaid[w] is set).

The NatSpec restricts kind 2 to 'a week with no thesis, under the judge threshold, or never judged', but the branch checks only block.timestamp >= (epoch+1)*7 days + SWEEP_AFTER.

The hook has no view of the judge's requestOf/judgedSet, and judgedPaid[w] is set only by payJudged, a separate permissionless call with no deadline and no reward. MarginaliaJudge.requestJudging has no upper time bound either and the Intake answers asynchronously, so a week can be judged on or after day 28, or judged earlier and simply not paid yet.

In that window anyone calls sweep(2, w): thesisPool[w] becomes 0 and is added to the current week; the later judge.payJudged(w) -> hook.payJudged(w, top) computes shares of 0, pays three zero transfers, sets judgedPaid[w] and paid[w], and the week can never be paid again. The 0.5 IMD drawn for the oracle bought nothing and the prize goes to the current week's winners (which the sweeper can be).

Fix: track drawnForJudging[w] in drawForJudging (cleared by payJudged) and make the kind-2 branch revert for such a week; or have payJudged carry its own roll-forward and the sweep skip weeks the judge has requested.

From audit_flow (c641acdd); reproduced by running its proof. Clones.clone only checks that CREATE returned a non-zero address and never that the implementation has code. The clone is a 45-byte EIP-1167 proxy, so Solidity's extcodesize check on t.init / r.init / j.init passes, the proxy delegatecalls to an address without code, the EVM returns success with empty return data, and because init returns nothing the call is accepted.

The constructor completes, the factory initializes the pool, beforeInitialize binds it, and the hook is live with three companions that revert on every call (router.note, treasury.drip, judge.requestJudging). With no owner or upgrade the only remedy is a new launch, while the pool keeps trading under the hook.

This is the state of the tree today: src/MarginaliaImpls.sol holds rehearsal placeholders 0x...a0001/2/3 that this companions launch must replace, and the hook launch's protected rehearsal deploys on a chain where those addresses are empty, so it passes with or without the real addresses. The constructor already requires code at poolManager_ and token_, so the same check on the three implementations adds no rehearsal constraint.

Fix: require(MarginaliaImpls.ROUTER_IMPL.code.length > 0 && JUDGE_IMPL.code.length > 0 && TREASURY_IMPL.code.length > 0) in the constructor, and/or have each init return a value the constructor checks so a codeless delegatecall's empty return data reverts.

From audit_economics (48d8e7d7); reproduced by tracing. _postNote appends a thesis id to weekTheses[_week()] in posting order up to MAX_DAY_NOTES (256) (src/MarginaliaHook.sol:441), and _allowList puts only the first MAX_JUDGED (200) of them into the request's guards.allow. There is no per-author limit and a thesis costs one note (0.1 IMD stamp plus a 0.5 IMD-equivalent MARG deposit, minimum input about 0.61 IMD).

An attacker who posts 200 theses right after a week starts (about 122 IMD, three of them actually argued) makes every later thesis absent from the allow list, so the panel can only rank the attacker's and onOracleResult can only store the attacker's ids.

The week's thesis pool (30% of all stamps, sell fees, forfeits and treasury drips; with a 100,000 IMD treasury about 4,200 IMD a week) is then paid 50/30/20 to the attacker's wallets by payJudged; 30% of the attacker's own forfeited deposits also flows back into that pool. The exclusion alone (honest theses unjudgeable for 122 IMD) is the griefing form.

Fix options: cap theses per author per week, select the judged set by something other than posting order (for example the 200 with the most resolved children or the largest deposits), or let the Intake body carry all ids in several requests.

From audit_economics (29df5bb3); reproduced by tracing. _accrue sends amount - lb - th (20%) of every accrual, including the treasury's 2%/day drip through fundPot, into refundPool[today]. The only outflow is claimRefund, which pays each non-retracted note of that day at most one STAMP (0.1 IMD), so a day can pay out at most notesPerDay x 0.1 IMD. sweep(0, day) moves the remainder into another day's refund pool, which has the same cap.

Any day whose accruals exceed about 128 IMD (a treasury above about 6,400 IMD drips more than that) adds a surplus no code path can ever pay to anyone: with a 100,000 IMD treasury the first drip alone puts 400 IMD into the day's refund pool against 0.5 IMD payable to that day's five notes. Over the treasury's life about a fifth of it accumulates as hook-owned IMD claims with no exit, which contradicts the brief's 'everything feeds a pot that pays'.

Fix: have sweep(0, day) (or claimRefund) route the part above notesPerDay x STAMP into the current week's leaderboard and thesis pools instead of another refund day.

From audit_economics (5a2740a2); reproduced by tracing v4's swap loop. sellPotMarg (called by judge.convertForfeits() with the entire potMarg) does potMarg -= amount and then _unlock(ACT_SELL, ...), whose callback swaps exact-input -int256(amount) with the price limit at MIN/MAX_SQRT_PRICE and burns uint256(uint128(-margDelta)), the MARG the pool actually consumed (line 876).

When the bound pool runs out of IMD-side liquidity before amount is sold, v4's Pool.swap loop walks the empty tick words to the price limit and returns with amountSpecifiedRemaining != 0: a partial fill, which the hook accepts as long as some IMD came out (line 875 only rejects a zero fill). Fewer MARG claims are burned than potMarg was reduced by; the difference stays as hook-owned ERC-6909 MARG claims that no variable tracks and no function can move.

A single-sided launch pool whose price sits at the bottom of the LP range (at or below launch price, where a MARG-only seeded pool starts) is exactly this state. The same mismatch exists for claimDeposit(id, true): the author's deposit is set to 0 and the unfilled part is silently lost.

Fix: in ACT_SELL compare the consumed MARG with amount and revert PartialFill (or return the unsold part to potMarg / the author's deposit).

Finding d40af08d (self-priced venue) is fixed for its reported vector: _postNote now refuses any call whose x is not MARG or whose venue is not the bound pool (line 442-446), and the supplied Proof_d40af08dafc9 passes. The residual named in that finding, a manipulated venue, is not addressed: the bound pool is read as a spot price (margPriceInImd() = slot0) and observe is permissionless with no restriction on swaps in the same transaction or block.

SPEC.md line 210 lists 'Spot read at settle is flash-manipulable' as mitigated by '>=3 observations >=20 blocks apart, median', but the same caller may make every observation, each one inside its own poolManager.unlock: swap IMD->MARG (price up), call hook.observe(id) for every note it holds, swap the same MARG back, and settle only the net IMD delta. v4 flash accounting means no capital is held across blocks; the only cost is the 1.25% LP fee on each leg plus the hook's 3% quiet sell fee on the way back, about 5.5% of the amount needed to move the price.

The MIN_PRICE_DEPTH floor of 1,000 IMD (line 66) does not bound this: the cost scales with depth but so does nothing on the reward side, and at 100x the floor the attack is still profitable from a single week's funding. All sybil notes share the same three manipulated observations, so the per-wallet 10% cap only sets how many wallets are needed. The leaderboard pool is 50% of every stamp, sell fee, forfeit and treasury drip, paid to whoever games the observation.

Fix that keeps the design: make observe read a price the observer cannot have set in the same block, e.g. record the block-opening price in beforeSwap (when block.number != lastSwapBlock, store blockOpenPrice = margPriceInImd() and lastSwapBlock = block.number) and have observe use blockOpenPrice whenever lastSwapBlock == block.number; then a manipulator must hold a moved price across the 20-block gaps against arbitrage, which is what the SPEC's median assumes.

Alternatively refuse observe in a block where the pool was swapped, or adopt the SPEC's univ4-spot oracle recipe.

Settlement of 392cb896 (flash-manipulated observation).

The fix closes exactly the vector I reported: beforeSwap (lines 316-321) records blockOpenPrice before a block's first swap and observe stores blockPrice() (line 298: return lastSwapBlock == block.number ? blockOpenPrice : margPriceInImd();), so a swap in the same transaction or block as the observe no longer sets it; the author's testRevisionFlashObservationReadsTheBlockOpenPrice and my first-round scenario pass, and the full suite passes (126 tests).

The remedy is the one I suggested, and I was wrong that it forces the manipulator to hold a moved price across the 20-block gaps: it forces a hold across one block boundary. In a block with no swap yet, blockPrice() is the spot, i.e. the price the previous block's last swap left behind.

The same caller therefore buys MARG in block N (the last swap on the pool in that block), and in block N+1 calls observe for every sybil note and sells the MARG back in the same transaction; the observation stores the pumped price. Done three times, 25 blocks apart, every +10% call settles Right.

The cost is identical to the first round: 946.02 IMD of LP and quiet-sell fees against 3,077.77 IMD claimed by three sybils (the 10% per-wallet cap; more wallets take more), with 5,900 IMD of capital at risk for one block. The two defences the author's residual note (ADAPTATION.md lines 102-108) relies on do not hold here.

Competing observers cannot interpose: the first observation is impossible before horizonEnd and each later one before the previous one plus OBS_GAP_BLOCKS, so the manipulator pumps in the block before each earliest eligible block and observes first in it; an honest observe in that same block reads the same block-open price, and one in the pump block is refused (TooEarly or ObservationTooSoon).

Arbitrage cannot interpose either: MARG has one venue, so there is no atomic backrun, and a backrun needs MARG inventory, must land in block N after the pump, and nets only the move minus the 3% quiet fee and 1.25% LP fee; in block N+1 nothing anyone does changes the block-open price. Nothing else about the round's changes is wrong: _postingPrice (lines 303-308) correctly takes the author-unfavourable of block-open and spot for the post price and the noted-sell deposit.

Fix that keeps the design: observe must store a price the manipulator has to hold for the whole gap, not a single boundary.

Keep a cumulative price-time accumulator updated in beforeSwap (priceCumulative += blockOpenPrice * (block.timestamp - lastSwapTs) before the first swap of a block, plus the pending tail at read time), store the cumulative at each observation and use the time-weighted average between consecutive observations as the observed price (with the first observation acting as the checkpoint, or OBS_MIN raised by one); that costs two storage slots and no TickMath, within the 703 bytes left under EIP-170.

Otherwise adopt the SPEC's univ4-spot oracle recipe. In either case the leaderboard pool should stay small relative to the pool's quote depth: the fee cost of moving a thin pool is a few percent of the move, so a depth floor of 1,000 IMD does not protect a pool paying thousands of IMD a week.