_average samples only the first buy of a block, whatever its size, and returns for every later one. The size weighting (w = min(imdIn, FULL_BUY)) stops dust from steering the average, but not from occupying the block's single sample.

Anyone can send dust ETH to the frens (receive()) and call buyFloorWithEth(1e12, 0) at the top of each block (the ETH route has its own one-a-block gate, so this also takes that block's fee-ETH buy): the average moves by w/(64*FULL_BUY) of nothing, and the mint's or arb bot's full 50 $IMD buy that follows in the block does not move it at all.

Repeated each block for gas only, the average never converges: a swapper whose seed was accepted within 2x at the launch (PlaceModules._soundSwapper) stays 2x off, and after a market move the floor keeps being valued at a stale rate (floorRate = min(spot, average)) for as long as the griefer pays gas.

Fix candidate (FrenSwapper only): sample the largest buy of the block (keep the block's sampled weight and let a bigger buy replace the sample), or weight by the block's cumulative $IMD volume.

The audit's Low fix (_spent(nonce)) reads Permit2's bitmap, which only knows nonces already consumed. A nonce approved for request A and not yet taken is still unspent there, so approveJob(B, sameNonce, sameDeadline) is accepted: both requests write the same permit digest to approvedDigest and the allowance to Permit2 grows to 1.0 $IMD.

Permit2 can take one payment (nonce spent); the other request's approval then reads as spent too (r.jobApproved && _spent(r.jobNonce)), so neither _reclaimLapsed nor releaseLapsedJob ever undoes it: its 0.50 stays approved to Permit2 forever, _unswept books it as a payment Permit2 may take, and it never reaches the floor (the same stranding the spent-nonce fix was for). The shared digest also stays approved (isValidSignature) after both requests reveal.

The README's keeper discipline ('never reuse a nonce already assigned to another pending job') is the only guard, as the earlier fix relied on the keeper before.

Fix candidate: keep a mapping of nonces in use (set in approveJob, cleared in _unapprove) and refuse them alongside _spent(nonce).

setModules documents address(0) as a valid 'none' for the swapper, and the README's manual recovery and PlaceModules' replacement path both have the governor re-wiring it. In that state _floorValue returns 0, so quote() counts only floorImd and the unswept $IMD: the IMD6900 reserve, the bulk of a floor once fees have been bought in, is priced at zero. requestMintFor still runs (the floor buy just returns false), and recycle() still pays reserve / out in IMD6900.

Any unprivileged minter in the window between unwiring and re-wiring (or if the governor leaves it unset while the mint is open) takes a reserve share for the curve's price. The precondition is a governor action, so this is a guard gap rather than an open drain, but nothing in the contract refuses it.

Fix candidate: in quote(), revert (or price the reserve at the last known rate) when swapper == address(0) && reserve != 0, or have setModules refuse address(0) while reserve != 0 and mintOpen.

The audit-fix commit re-mined the salts (src/FrensPlan.sol, script/placement/addresses.json, README): the collection now lands at 0x6900d042460d6bdbe68CE994F4dE36706797CCd4, the swapper at 0x69002297DD7980af0d24249f6a44E7046B1Cb1fb, the minter at 0x46B50a3061Ea692e075231c13bc653FdD1Bedd29 and the gate at 0xF83807Ec2E27e1771Fb2594139c1F6925Cfd9B8E (test_ProtectedFactoryDeploysBothLaunchesInOrder asserts these). launch.json's notes, ADAPTATION.md's address table (lines 25-28) and test/test_collection_manifest.py (lines 17-20, which asserts the stale strings are present and therefore passes) still carry the previous plan's addresses.

The manifest notes are not deployment authority, but they are what the adapter, the reviewer and the operator read for the timelock batch targets and the swapper exemption; a batch queued against 0x6900453d... would exempt nothing. The contracts list itself (PlaceFrens, PlaceModules $contract:PlaceFrens) is correct.

Recorded for the adapter, not as defects (the brief requires the team wallet's setup() and the prior round dispositioned them, ADAPTATION.md item 8): (1) the collection is configured after deployment, not in a constructor: setRenderer, setModules, setTraitRules/addPairRule/sealTraits, setMintOpen, gate.setWlRoot; (2) the governor can stop minting at any time (setMintOpen(false)), pause the floor's buys (setParams(_, 0, 0)), change the swapper that spends the floor's $IMD (setModules; a malicious swapper takes every buy's imdIn), change keeper/relayer/payee (setRoles) and tiers/caps; setGovernor is one-step; (3) the owner or the governor can block every peer transfer by setTransferValidator (a rejecting validator freezes the collection on marketplaces and OTC; recycle and buyTreasury bypass it); (4) the relayer alone decides which combos each request reveals as, within the rules; the keeper alone approves job payments; (5) IMD6900 sent to the collection outside buyFloor/buyFloorWithEth/buyTreasury is never booked (no sweep like _unswept for $IMD) and no function can move it; (6) the tier is a balance snapshot at the mint, so $IMD borrowed outside Uniswap v4 (another lender, or a friend's same-transaction transfer) reaches a tier; (7) the IMD6900 distributor status and the pair hook's fee exemption are external timelock-controlled switches: losing distributor status would make every recycle and treasury buy revert.

No DELEGATECALL, CALLCODE or SELFDESTRUCT: both launch contracts' runtimes scan clean (PlaceFrens 193 bytes, PlaceModules 358 bytes) and the fresh-chain trace test asserts none in the nested creations.

The NatSpec at src/frens/IMD6900Frens.sol:800 promises 'recycle pays exactly this, revealed or not', but recycle() (line 902) and buyTreasury() (line 921) call _sweep() before reading floorPerFren(), which books the unswept $IMD (balance minus floorImd, jobBudget and the Permit2 allowance) into floorImd. The public view does not.

Unswept $IMD exists routinely: IMD refunds half of every 0.50 job payment straight to the contract (README, fork test test_RefundsJoinTheFloor), and while floor buys are paused (setup() sets maxImdPerBuy = 0) nothing else sweeps it, since buyFloor() reverts Cap when imdIn == 0 and undoes its own sweep.

Consequences: (1) buyTreasury() price = 2 x (view + extra/out), so a buyer who sets maxImd from the view gets a Cap revert after every job refund; (2) any integration (site, marketplace floor display, quote() of the minter) reading floorPerFren() under-reports what a recycle pays by extra/out. No funds are lost: the write path always pays more than the view says.

This is the view/write divergence the Invariant guide lists; the fix that keeps the design is to add the unswept extra to imdPart in the view (it already is counted in quote() via _unswept()).

quote() charges a mint exactly its share of the floor (count * value / out, line 500) whenever that exceeds the curve. Of that payment JOB_PRICE goes to the job budget and only paid - JOB_PRICE joins the floor (line 553). After the mint the per-fren floor is (value + paid - 0.5) / (out + count) = value/out - 0.5/(out+count): every fren, the new ones and the existing ones alike, loses 0.5/(out+count).

The minter therefore bears only count/(out+count) of the job price and the existing holders bear out/(out+count) of it. With 100 frens out a mint-plus-recycle costs the caller about 0.005 $IMD (plus gas) while draining about 0.495 $IMD from the other holders, and it commissions a 0.50 $IMD five-agent job each time (IMD refunds 0.25 of it to the floor later).

The README acknowledges the minter only loses 'their share of the job', so this is the design, not a bug: the caller cannot profit, and the per-cycle drain is bounded by 0.5 $IMD. Recorded so the requester can decide whether the job price should instead be charged on top of the floor share in the floor-bound regime (quote = atFloor + JOB_PRICE when atFloor > price), which would make every mint pay its own job without touching the curve.

Asymmetry (economics x asymmetry seam) between the three prices of one share of the floor. quote() (line 498-500) values a share as (unswept + floorImd + reserve at floorRate + pendingImd) / out, and buyTreasury() (line 922-926) charges 2 x (reserve/out, floorImd/out + _floorValue(0)/out), both counting the ETH and WETH sitting in the contract at POOL4's price. recycle() pays only floorPerFren() = (reserve/out, floorImd/out) after _sweep(): the ETH/WETH part is left out entirely.

The ea109756 fix (dc3bd30d) put the pending ETH into the mint and treasury prices so nobody can buy under it and sell over it once it is bought in; it did not mirror that into the sale price, so the asymmetry now runs the other way: whoever recycles while ETH waits gives their whole share of it to the remaining holders.

The holder can only avoid it by first calling buyFloorWithEth, which is capped at maxEthPerBuy (0.25 ETH) per buyDelayBlocks, reverts outright while buys are paused (setParams(_,0,0), the whole bootstrap phase) and is not wrapped in try/catch, so it also reverts while the ETH route fails (before the collection is an IMD6900 distributor).

Impact: a bounded loss to an identifiable party (the recycler) under common state (royalties/hook fees pending), in favour of the other holders; no attacker profit path was found beyond passively holding, so severity is low rather than medium.

Fix options that keep the design: pay the recycler its ETH share in ETH (address(this).balance / out, and the WETH likewise) alongside the two in-kind parts, or sweep the pending ETH into the reserve before pricing the sale the way _sweep() does for $IMD and refuse the recycle while it cannot be swept.

Access x asymmetry seam. requestMintFor(minter, count, maxPay) has no restriction on who may name minter after the opening (only the closed-mint branch is governor-only), and the gate's spend() trusts whatever minter the collection passes (FrenWorkerGate.sol line 121-129 checks only msg.sender == frens).

So during the workers' window a stranger can pick any wallet holding credits, pay the curve price (0.69 $IMD plus the 0.50 job inside it) and burn that wallet's credits at a moment of the stranger's choosing.

The victim does receive the frens (minted to minter, at the tier of its bag at that moment), so there is no loss of funds and the attacker pays for the gift; what the worker loses is control over when its credits are used (the tier snapshot, which for a WL wallet depends on what it holds at that instant) and over batching (one 0.50 job per request).

Identity.md holders are tier 3 through identityTier regardless, so for the window's main audience the only effect is the forced timing. Recorded as information for the requester: if the credit is meant to be the worker's to spend, spend() could require msg.sender-of-the-mint to be the minter or an approved payer (FrenMinter passes msg.sender), e.g. by having requestMintFor forward the payer and the gate accept payer == minter || payer == trusted minter contract.

FrenMinter.quoteFloor(imdIn) and quoteFloorEth(ethIn) are documented as 'what buyFloor would get' and 'what buyFloorWithEth would get' (lines 99, 104). They run the pair swap with an unbounded price limit (line 149) and the POOL4 leg likewise (line 138). The real buys go through FrenSwapper, which stops each leg at a price limit: the pair pool at pairMoveBips() = fee()/2 = 345 bips (the live hook's fee() returns 690) and POOL4 at 50 bips (FrenSwapper.sol:212, 249, 262).

With the pair pool's current liquidity (4.706e22, about 113 $IMD / 19.5M IMD6900 virtual reserves) a buy stops after about 1.93 $IMD, so the view and the write diverge by more than an order of magnitude (numerical gap: queryX omits the term doX applies). Any caller that uses the quote as minOut makes the buy fail: in _buyFloor the swapper's Short() is caught and buyFloor reverts Cap(); buyFloorWithEth reverts with the swapper's Short().

The site's and the keeper's numbers are wrong by the same factor.

The swap's price limit is derived from an external, mutable value with no lower bound.

For fee() in {0, 1}, moveBips = 0 and _limit computes f = Math.sqrt(1e36) = 1e18 exactly, so the limit equals slot0's sqrtPrice; Uniswap v4's Pool.swap rejects a limit equal to the current price (PriceLimitAlreadyExceeded) in both directions. imdToImd6900 then reverts inside _buyFloor's try/catch, which returns false: mints keep going (quote still books floorImd at face), buyFloor reverts Cap() for everyone, and buyFloorWithEth reverts with the pool's error; fee ETH and floor $IMD stop being bought in until the governor wires a different swapper (pairMoveBips is not configurable).

The same reading also carries the sandwich bound: the comment's 'half the fee' argument holds only while the hook's fee stays at least twice the configured move, which is true today (690 bips vs 345) but is the hook owner's to change. POOL4_MOVE_BIPS (50) is hard-coded against POOL4's current 1% fee for the same reason. Boundary of an external dependency; the hook is IMD's, not this collection's, so no unprivileged trigger: recorded as info.

Execution trace, across transactions. buyFloorWithEth calls _buyGate() first (line 869), which writes lastEthBuyBlock = block.number before any size check; the only lower bound on ethIn is ethIn == 0. A 1 wei buy passes every check (on the live pools 1 wei of ETH still yields a nonzero IMD6900 amount through both hops, so _credit's got == 0 check does not stop it), and the honest buy of the same block (the arb bot's 0.25 ETH) then reverts TooSoon.

Repeated at the top of every block the griefer pays only gas and the frens contract's ETH (hook fee slice, marketplace royalties, unwrapped WETH) is never bought into the reserve. The $IMD path was protected against exactly this (test_DustEthBuyCannotTakeTheMintsTurn: a dust ETH buy cannot take the mints' $IMD turn, because the two paces are separate), but the ETH pace itself has no dust protection.

Consequence while the ETH stays pending: quote() and buyTreasury() charge minters and treasury buyers for the pending ETH (at POOL4 spot, the retained MEDIUM a99c13...), while recycle() pays only reserve/out and floorImd/out (floorPerFren, line 805), so every holder who recycles during the griefing forfeits their share of the pending ETH to the holders who remain (a holder-griefer collects it when they stop), and the spot-valued pending balance that the retained MEDIUM depends on is kept large instead of being drained at 0.25 ETH a block.

No direct theft; a griefing race that costs the griefer gas and 1 wei a block. Fix (changes src/frens, so by the requester's rule record only): require ethIn >= a dust floor (e.g. maxEthPerBuy / 100, or min(address(this).balance, maxEthPerBuy) so a buy must take all that is affordable), or let a buy below the threshold through without consuming the block turn.

Periphery: view/write divergence in a helper the site and keeper are told to use (natspec lines 99 and 104: 'what buyFloor would get', 'what buyFloorWithEth would get'). The quote path in unlockCallback swaps the whole input with the extreme sqrtPriceLimit (line 138 for the POOL4 leg, line 149 for the pair leg) and ignores maxImdPerBuy / maxEthPerBuy.

The real buys go through FrenSwapper, whose swaps stop at _limit(key, dir, pairMoveBips()) (half the pair hook's fee; fee() is 690 bips live, so 345 bips) and _limit(pool4, true, POOL4_MOVE_BIPS) (50 bips), returning the unspent input to the frens contract (FrenSwapper.sol lines 212, 231-234, 249, 272-273). On the live pools the limits bind at a small fraction of a default-size buy, so the quote is not a conservative estimate but far above what the buy can ever return.

Impact: anyone using the quote as minOut for buyFloor / buyFloorWithEth (the bot the README says runs them) has every buy fail (buyFloor: the swapper's Short is caught and surfaces as Cap; buyFloorWithEth: Short); dashboards that use it to show the floor's expected growth are wrong by an order of magnitude. No loss of funds.

Fix (src change, record only): run the quote with the same price limits as FrenSwapper (pairMoveBips(), POOL4_MOVE_BIPS) and return the input actually spent, or document that the quotes are unlimited and must not be used as minOut.

Execution trace, mid-operation config mutation. approveJob stores only the nonce and deadline of the approved payment; the permit digest is a function of (nonce, deadline, imd, JOB_PRICE, x402Proxy, imdPayTo). _permit2Digest re-reads imdPayTo (line 760) at clearing time.

If the governor changes the payee with setRoles while a payment is in flight and that payment then lapses, _reclaimLapsed -> _unapprove computes the digest for the new payee and writes false to a key that was never true; approvedDigest[oldDigest] stays true for ever while the allowance is reduced and the job money is re-used.

No funds can move: the digest binds the deadline and Permit2 refuses an expired permit, and the allowance was taken back, so isValidSignature answering the ERC-1271 magic for an expired permit is inert.

Residue only: the contract's statement 'ERC-1271: valid only for the payments approveJob approved' is no longer exact after a payee change. Fix (src change, record only): store the permit digest (or the payee) in the Request at approval and clear that stored digest in _unapprove.