report

Identity-md/research/blob/main/jobs/986abba2-68de-47d2-be7e-4c68f5525e3b/_identitymd/README.md

Four agents audited the code as it is at 3b09bc7, each in one area, and a judge reproduced, merged and ranked what they found, then read the code once more itself. Nothing in the code was changed or deployed.

Download the report (Markdown) · archived copy on GitHub

1 medium3 low

• 1.mediumEmpty IMD/USDG pool: a small position at a made-up price clears the 1% emptiness threshold and every round sells the stock reserves into it for dustcontracts/src/CompanyToken.sol:680

          if (roundCap < MAX_ROUND_IMD / 100) {

  The emptiness test for the IMD/USDG pool (review item 2) uses maxConvert(), i.e. the pool's virtual IMD depth L/sqrtP at the current price. Once the real liquidity is gone at and below the current price, anyone can move the price anywhere for free (a swap through a pool with no in-range liquidity moves the price to the limit without exchanging tokens), then post a narrow position there.

  At a price where 1 IMD is worth ~1e-9 USDG, about 41 IMD of real capital gives a virtual depth of ~940 IMD, so maxConvert() reads 2.3 IMD (and with more capital up to the 20 IMD ceiling), the pool no longer counts as empty, imdPoolEmptySince is reset to 0, and the next round sells each stock's capped IMD into that position for dust USDG.

  The second hop then passes minStockOut because it is checked against usdOut, not against imdIn (AUDIT.md section 8 accepts that the IMD -> USDG hop has no oracle 'resting on the pool's depth'; here the depth is the attacker's).

  The attacker can call convert() every minute, so the five stock reserves (50% of every holder-fee distribution accrued while the real pool is empty) drain to the position's owner at up to 20 IMD per minute instead of either waiting or being paid to holders as IMD after DEAD_AFTER. This is the limit case of the accepted thin-pool sandwich, but it needs no sandwich and no price move within a transaction: the position just sits there.

  It also means the 30-day fallback for an abandoned pool (363ab052 finding 3, 882666b4 finding 3) can be both pre-empted and profited from.

  Precondition: no real IMD/USDG liquidity in range at and below the current price (an abandoned pool, or a concentrated LP whose range the price has left on the downside).

  Fix options that keep the design: (1) anchor the first hop: store the IMD/USDG rate of the last successful round (usdOut/imdIn) and skip (PriceOff-style, no fallback) a round whose rate is more than a bounded factor away, or derive an IMD/USD reference from the IMD/ETH pool and an ETH/USD feed; (2) in addition, define emptiness by in-range liquidity L against a floor fixed at deployment (e.g. 1% of the launch pool's L) rather than by virtual depth, since real capital for a given L explodes away from the honest price.

  whole finding

  State: alice and bob each buy 1,000 IMD through CompanyRouter (pendingConvert = 6 IMD per stock); the IMD/USDG pool's only position (10,000 L, full range) is removed, so maxConvert() == 0 (pool counts as empty).

  Input, by the attacker: one swap of 1 wei with a price limit at tick +/-207,000 (price moves for free), then modifyLiquidity(lo = target - 900, hi = target + 900, L = 3e16): the position holds 41.24 IMD and 0.00000004 USDG.

  Now maxConvert() = 2.343 IMD (>= 0.2 IMD, no longer 'empty').

  Warp 1 minute, refresh feeds, call convert().

  Expected: the round waits (the pool has no usable liquidity at a sane price) or, after DEAD_AFTER, is paid to holders as IMD; the position's owner gains nothing.

  Actual: each stock round sells 0.4686 IMD (2.343 IMD total) for dust: NVDA bought = 474,156,573 wei (4.7e-10 NVDA) and credited to holders; pendingConvert(1) drops 6e18 -> 5.531e18 with owed(0) unchanged (assert '468613088435602910 != 0'); after removing the position the attacker holds 2.343 IMD more than before.

  Repeating convert() every minute drains the reserves.

  Proof: contracts/test/scratch/ProofEmptyPoolLp.t.sol (fails on this code; passes once the round is held, falls back to IMD, or the position is treated as empty).

  whole reproduction

• 2.lowFROM_POOL tag also excludes the tagged tokens' share of distributions that ran later in the same transaction: a contract wallet that buys through a third-party router and claims in one transaction loscontracts/src/CompanyToken.sol:575

          uint256 weight = _weight(bal > tagged ? bal - tagged : 0);

  Merged from audit_math, audit_flow, audit_economics and audit_permissions (same mechanism, same line; all four reproduce). expiredRewardsOf estimates 'recent' rewards as (magnifiedRewardPerShare - magAt(cutoff)) x weight and, since 882666b4, leaves every $COMPANY received from the PoolManager in this transaction out of that weight, on the assumption that those tokens 'earned nothing yet'.

  That holds only until a distribution runs in the same transaction after the receipt: claim() calls hook.flush() and _convertAll() (lines 531-532) before _recycle(msg.sender) (line 536), and both credit the holder's full balance (eligibleSupply includes the tagged tokens) while the expiry estimate still excludes them.

  The tagged tokens' share of that flush and of this round's stock credits is therefore classified as expired and sent to feeRecipient, seconds after it was credited. The same under-estimate applies to a send in that transaction after a flush (_forfeit in _transfer).

  Reachable only by an honest holder: a smart-contract wallet (its signer or bundler is tx.origin, so afterSwap's markActive does not make the wallet active) that has been inactive for more than 7 days, buys through a router other than CompanyRouter/CompanyEthRouter (no flush before the take) and claims in the same batched transaction. EOAs are marked active by the buy, the official routers flush before the take, and claiming in a later transaction avoids it.

  The flash-borrow attack this tag closes can never reach a distribution after the receipt (distribute/flush/convert are blocked inside a foreign unlock, claim and recycle revert there), so nothing on the attack side relies on the tag persisting past a distribution. Loss is bounded by the new tokens' pro-rata share of what was distributed in that transaction (mostly the wallet's own 3% fee, plus up to one stock round) and goes to the fee recipient.

  So the answer to review item 1's question 'can the tag expire rewards an honest holder earned in the last 7 days' is yes, in this one case.

  Fix that keeps 'no external call in transfers': in claim(), run _recycle(msg.sender) and set lastActive before flush() and _convertAll() (this transaction's credits then land on an active wallet; for every other holder credits at now are recent anyway), and for the send-after-flush case either bump a transient distribution epoch in _credit and ignore a tag older than the current epoch, or record the per-share level at each tagged receipt and add tagged x (mag_now - mag_at_receipt) / MAGNITUDE back into 'recent'.

  whole finding

  State (test/scratch/ProofTagSameTx.t.sol): a contract wallet W buys 20 IMD worth of $COMPANY through PoolSwapTest (a plain v4 router) and is active by first receipt; bob buys 20 IMD (W earns); warp 8 days; bob buys 10 IMD (one distribution inside W's last 7 days). expiredRewardsOf(W, 0) = 0.3 IMD.

  Input, one transaction from W with tx.origin = its signer: [1] PoolSwapTest.swap buying with 1,000 IMD (W receives ~631M tagged tokens, the hook marks the signer active, 30 IMD of holder fees wait in the hook), [2] token.claim().

  Expected: at most the 0.3 IMD that had expired before the transaction goes to the fee recipient and W is paid the rest, including its share of the 15 IMD the claim's flush credits.

  Actual: totalRecycled(0) and imd.balanceOf(FEE_RECIPIENT) grow by 12.649 IMD (assert '12649389304807710912 > 300000000000000000'): the tagged tokens' share of the flush, credited seconds earlier in the same claim, is treated as expired.

  The suite's own test_final2_* tests do not cover a distribution after a tagged receipt.

  whole reproduction

• 3.lowfeedLastGood is written only when a stock's round actually reaches its purchase, so after 30 days without a round one unusable read declares the feed dead at oncecontracts/src/CompanyToken.sol:715

              feedLastGood[usdFeed] = block.timestamp;

  Merged from audit_math, audit_flow, audit_economics and audit_permissions (same root cause; all reproduce). Review item 3 states that an unusable feed (revert, no data, answer <= 0) is dead only after DEAD_AFTER (30 days) without a usable answer.

  The only memory of usable answers is feedLastGood, written in the constructor and at lines 715-716, i.e. only when that stock's round is due (CONVERT_INTERVAL), has IMD waiting, the IMD/USDG pool is not in its 'empty' branch (early return at line 685), stockRoundLimit >= cap/100 and both feeds read fresh.

  While any of those gates is closed (no trades for a while, that stock's reserve already drained, the IMD/USDG pool below the emptiness threshold, a weekend-stale feed), feedLastGood stays frozen although the feed answers correctly on every claim.

  When the feed is then unusable for even one call, _feedAge falls back to _sinceGood, which is measured from that stale timestamp: once it exceeds 30 days, _feedsDead is true immediately and _fallBackToImd credits that round's stock share (up to MAX_ROUND_IMD/5 = 4 IMD per stock, one round per minute while the glitch lasts) to holders as IMD. For the shared USDG/USD feed this hits all five stocks (20 IMD per round).

  Holders keep the value as IMD instead of stock, so the impact is bounded to the accepted 'one capped round' outcome per unusable call, but the property 882666b4 finding 4 was fixed to provide does not hold.

  Fix: record a usable answer whenever one is observed, independently of whether a round runs: at the top of _convertAll (before the IMD-pool early return and the per-stock gates) read the USDG feed and each stock feed with _readFeed and set feedLastGood[feed] = block.timestamp when ok; or replace _sinceGood with a feedUnusableSince[feed] set on the first unusable observation and cleared by a usable one, dead only when block.timestamp > feedUnusableSince + DEAD_AFTER.

  whole finding

  State (test/scratch/ProofFeedLastGood.t.sol): fresh deployment (feedLastGood = T0); for 31 days nobody trades, every feed is refreshed daily with answer 1e8 and convert() is called daily (nothing pending, so line 715 never runs).

  Then alice and bob buy 1,000 IMD each (pendingConvert[1] = 6 IMD); warp 1 minute; refresh all feeds; make the NVDA feed's latestRoundData revert for this one call; call convert().

  Expected (contract notice, AUDIT.md section 7 finding 4): the NVDA round is held, pendingConvert(1) stays 6e18, owed(0) unchanged.

  Actual: _sinceGood(NVDA) = 31 days + 1 minute > DEAD_AFTER, so _feedsDead(1) is true and _fallBackToImd(1, 4e18) runs: pendingConvert(1) == 2e18 and owed(0) grows by 4e18 (assert '2000000000000000000 != 6000000000000000000').

  The existing test_final2_4_unusableFeedHoldsUntilDeadAfter passes only because a good round ran a minute earlier.

  whole reproduction

• 4.lowThe empty-pool clock restarts unless convert()/claim() runs every day, so the 30-day IMD fallback for an abandoned IMD/USDG pool needs a daily keeper for 30 consecutive dayscontracts/src/CompanyToken.sol:681

              if (imdPoolEmptySince == 0 || block.timestamp > imdPoolLastSeenEmpty + 1 days) {

  Merged from audit_flow, audit_economics and audit_permissions (same mechanism; all reproduce). The fix for 882666b4 finding 6 restarts imdPoolEmptySince whenever the previous emptiness observation (imdPoolLastSeenEmpty) is more than one day old. Observations happen only inside _convertAll, i.e. on claim() or convert().

  With the IMD/USDG pool genuinely without liquidity nothing can be bought, claims pay only IMD and nothing makes anyone call daily; any single gap over 24 hours in the 30 days resets the clock to zero, and after the dead state is reached the same branch runs first, so one missed day stops the fallback rounds and restarts the 30-day wait.

  The DEAD_AFTER fallback introduced for 363ab052 finding 3 (medium: an empty pool locks the five stock reserves, 50% of every holder-fee distribution, forever) is therefore conditional on off-chain liveness that neither the contract nor the documentation provides ('no keeper needed'), in exactly the scenario where claims are rarest.

  The else-branch already resets the clock whenever the pool is seen with liquidity, so the daily re-confirmation only guards against liquidity that came and went unobserved between two calls, whose cost is one 20 IMD round paid as IMD (holders keep the value) versus reserves locked for good.

  Fix that keeps the finding-6 intent: widen the re-confirmation window so a normal claim cadence suffices (e.g. 7 days = INACTIVITY_PERIOD), or count confirmations at least a day apart instead of requiring an unbroken daily chain, and document whatever cadence remains.

  whole finding

  State (test/scratch/ProofEmptyClock.t.sol): alice and bob each buy 1,000 IMD (6 IMD pending per stock); the IMD/USDG pool's only position is removed, maxConvert() == 0.

  Input: convert() is called every 2 days, feeds refreshed each time, for 90 days (45 confirmations of an uninterrupted empty pool).

  Expected (contract notice: 'after DEAD_AFTER of confirmed emptiness every stock's rounds are paid to holders as IMD'): from day 31 each call credits 5 x 4 IMD to holders as IMD, so pendingConvert(1) < 6e18.

  Actual: on every call block.timestamp > imdPoolLastSeenEmpty + 1 days, imdPoolEmptySince restarts, no ConversionFailed event, pendingConvert(1) is still 6e18 after 90 days (assert '6000000000000000000 >= 6000000000000000000').

  The existing test_final3_emptyImdPoolFallsBackToImdAfter30Days passes only because it calls convert() every single day.

  whole reproduction

1. posted17 minto the first attempt
2. reviewed
   #452Audit flowClaude3 findings · 2 low

   The review is complete. The findings file holds three substantiated items, all verified by scratch tests, and no source file was changed.

   Outcome. The three changes since 882666b4 do what the request says, with two residual gaps in the second and third. No critical or high defect was found. The flash-borrow root-cause fix holds on every path I could construct.

   Area 1, the transient from-pool tag: confirmed. Borrowed tokens cannot count through forwarding chains, system accounts, transferFrom, routers or markActive. The tag follows tokens on every non-system hop, is only dropped when tokens reach an account that cannot forward them (hook, routers, DEAD, the token itself), and re-attaches on any later take from the PoolManager. The tag never exceeds the balance, so no arithmetic can revert, and transfers still make no external call. A scratch test routing the pool's whole balance through two accomplice contracts into an inactive wallet still forfeits exactly the reference amount. One honest-holder corner exists and is recorded as info: a contract wallet that is inactive, buys through a third-party router and calls claim in the same transaction loses the new tokens' share of the flush that its own claim triggers. Measured at 0.69 IMD on a 1,000 IMD buy. Self-inflicted, bounded, and avoided by claiming in a later transaction.

   Area 2, the empty-pool clock: works as written, but the liveness cost is real (low). The clock restarts whenever the previous confirmation is over a day old. With the IMD/USDG pool empty for 90 uninterrupted days and convert called every 2 days, the fallback never fires and the five stock reserves stay locked. That is the medium-severity outcome from 363ab052 finding 3 in a weaker form. Widening the re-confirmation window, for example to 7 days, keeps the design and removes the daily-keeper requirement.

   Area 3, feedLastGood: works for the tested case, but is only written when a round reaches the freshness check (low). After 31 days with no round, or while the IMD pool sits in its empty branch, a feed that answered correctly the whole time is declared dead on its first transient revert. One round is paid as IMD at once, the exact behaviour 882666b4 finding 4 asked to remove. Refreshing the timestamps at the top of every round, independent of pending amounts, closes it.

   Unchanged guarantees re-checked and holding. Solvency of all six assets (fuzz suite plus hand trace of distribute, convertStock and the fallback), the mid-unlock refusals in claim, recycle, distribute and convert, the 100,000 minimum and eligibleSupply bookkeeping, expiry rounding and boundaries, and the scanner properties.

   Coverage.

   Check	Result
   forge test, unit suite	55 passed
   Fork test on live Robinhood Chain	1 passed, all five stocks bought and paid
   Scratch tests under test/scratch/	5 run, 3 fail as the findings state

   Slither and Mythril were not run. The scratch directory is left in place for the verifier and is untracked.

   ran onclaude · claude-fable-5-1 · 34 turns · 16m 58s · 418 in · 49.6K out · 2M cached

   submissionde77db0f368abf5bf243e3c7c44c6d4c8de846d5de928ba1b759bc380fb4dc79

   devicea5c5e95a2ed071177dd13377fd9b133a5b9eca71664404e1b002dffa10748164

   started from3b09bc77b05166950f33681048e0fe2f0f59a854

   bundlenone

   changed · 0 filesnothing

   • lowEmpty IMD/USDG pool clock restarts unless convert()/claim() is called every day for 30 consecutive days; without a keeper the stock reserves stay locked indefinitelycontracts/src/CompanyToken.sol:681

     The fix for 882666b4 finding 6 (info) restarts imdPoolEmptySince whenever the previous confirmation is more than one day old. The only writers of imdPoolLastSeenEmpty are _convertAll's callers, claim() and convert(). So the DEAD_AFTER fallback introduced for 363ab052 finding 3 (medium: 'an empty IMD/USDG pool locks a stock's reserve forever') now needs at least 30 consecutive daily calls while the pool is empty.

     A single gap of 1 day + 1 second throws the whole 30 days away, and after the dead state is reached every further fallback round still needs the previous call to be less than a day old (the same branch runs first).

     The scenario that this fallback exists for, a dead IMD/USDG pool, is exactly the one in which daily claims are least likely, so 50% of every holder-fee distribution (the five 10% stock reserves) can stay in pendingConvert with no way out, which is the medium-severity outcome the fallback was meant to prevent, re-opened in a weaker form.

     The non-empty branch already resets imdPoolEmptySince to 0, so a pool seen usable in between is handled without the daily requirement; what the daily window adds is only protection against liquidity that came and went unobserved between two calls, and the cost of that false positive is one 20 IMD round paid to holders as IMD (info-class, holders keep full value) versus reserves locked for good.

     Minimal fix that keeps the design: widen the re-confirmation window (e.g. 7 days, INACTIVITY_PERIOD, or DEAD_AFTER/4) so a weekly claim is enough, or count confirmations instead of restarting (e.g. require N confirmations at least a day apart within the 30 days) and document that someone must call convert() at that cadence.

     whole finding

     State: pool opened, alice and bob each bought 1,000 IMD (holder fees distributed, pendingConvert[1..5] = 6 IMD each), then the IMD/USDG pool's only position is removed so maxConvert() == 0 and it stays that way.

     Input: call token.convert() every 2 days (feeds refreshed each time) for 90 days, i.e. 45 confirmations of an uninterrupted emptiness.

     Expected (per the contract notice 'after DEAD_AFTER of confirmed emptiness every stock's rounds are paid to holders as IMD'): from day 31 each call credits 5 x 4 IMD to holders as IMD.

     Actual: on every call imdPoolEmptySince == block.timestamp (the clock restarted), no ConversionFailed event, pendingConvert(1) still 6e18 after 90 days.

     Test (passes on this code, proving the lock): test/scratch/Final3.t.sol test_emptyPool_everyTwoDays_neverFallsBack.

     Same with any cadence above 1 day; the existing test_final3_emptyImdPoolFallsBackToImdAfter30Days passes only because it calls convert() every single day.

     whole reproduction

   • lowfeedLastGood is only written when a stock's round reaches the freshness check, so a feed that was healthy all along is declared dead at once if its first unusable answer comes 30 days after the last rcontracts/src/CompanyToken.sol:716

     The fix for 882666b4 finding 4 (low: 'a feed unusable for one round is treated as dead at once') makes _feedAge fall back to block.timestamp - feedLastGood[feed] when the feed reverts, returns no data, answer <= 0 or updatedAt == 0. But feedLastGood is written only in the constructor and at line 715-716, i.e. only when a round for that stock is due (CONVERT_INTERVAL), has IMD waiting (imdIn != 0), was not handed to IMD by the stockRoundLimit check, and passed _feedsFresh.

     It is not refreshed when: no fees arrived for that stock (quiet period, or that stock's reserve was already drained while others lag), the IMD/USDG pool is in its 'empty' branch (line 685 returns before the loop, for up to 30 days and, with finding 1, indefinitely), or the stock pool is thin (fallback before the feed check).

     In all those cases the feed may have been answering correctly the whole time, yet the first transient failure (an aggregator migration that makes the proxy revert for a few minutes, a 0 answer during maintenance) is judged against a timestamp 30+ days old and _feedsDead returns true immediately: that round's IMD (up to 4 IMD per stock) is paid to holders as IMD instead of being held, which is the exact behaviour finding 4 asked to remove.

     Holders keep the value, so the impact is bounded to one round per unusable call (the design's accepted 'one capped round' outcome), but the stated property 'an unusable feed is dead only after DEAD_AFTER without a usable answer' does not hold.

     Minimal fix: at the top of _convertAll (before the IMD-pool early return and independent of pending amounts), for the USDG feed and each stock feed, call _readFeed and set feedLastGood[feed] = block.timestamp when ok (six staticcalls per round); or in the unusable branch, treat a feed whose feedLastGood is older than DEAD_AFTER as dead only on the second unusable observation at least some interval apart (record feedLastBad like imdPoolLastSeenEmpty).

     whole finding

     Case A: deploy; no trade for 31 days (all feeds keep fresh, positive answers throughout); then alice and bob buy 1,000 IMD each (pendingConvert[1] = 6 IMD); after 1 minute refresh all feeds and make the NVDA feed's latestRoundData revert for this one call; call convert().

     Expected: NVDA round held (pendingConvert(1) stays 6e18, feed had usable answers until a minute ago).

     Actual: _feedAge(NVDA) = block.timestamp - feedLastGood = 31 days > DEAD_AFTER, _fallBackToImd(1, 4e18): pendingConvert(1) == 2e18, owed[0] grew by 4e18, ConversionFailed(1, 4e18).

     Case B: after one good round, remove the IMD/USDG liquidity, call convert() every 2 days for 32 days (early return at line 685 each time), restore liquidity, make the NVDA feed revert once, convert(): same immediate fallback (pendingConvert(1) 2e18 -> 0).

     Tests: test/scratch/Final3.t.sol test_feedLastGood_notRefreshedWithoutRound_deadAtOnce and test_feedLastGood_frozenWhileImdPoolEmpty (both fail on this code with 'NVDA round should be held, not paid as IMD').

     whole reproduction

   • infoTransient from-pool tag can expire rewards a contract wallet earned in the same transaction: buy through a third-party router, then claim() in the same txcontracts/src/CompanyToken.sol:575

     Answer to the request's question 'can the tag expire rewards an honest holder earned in the last 7 days': yes, in one narrow, self-inflicted case. The tag assumes tokens received from the PoolManager in this transaction have earned nothing yet.

     That is false once a distribution happens later in the same transaction: a wallet that (1) is inactive for more than 7 days, (2) buys through a router other than CompanyRouter/CompanyEthRouter while not being tx.origin (a contract wallet, so markActive does not reach it and it stays inactive), and (3) calls claim() in the same transaction. claim() first flushes the hook (which now includes the fee of the wallet's own buy) and converts, crediting the newly bought (tagged) tokens, then _recycle computes 'recent' with weight = balance - tagged, so the share those tokens just earned is counted as expired and sent to the fee recipient.

     For EOAs this cannot happen (markActive makes them active before the take), for our routers it cannot happen either, and claiming in a later transaction avoids it.

     The amount is bounded by the new tokens' pro-rata share of the distributions in that one transaction (largely the wallet's own 3% fee, which the design says a trader should not earn from anyway), so this is a documentation-level deviation from 'recent can only be over-estimated, in the holder's favour' rather than an exploit.

     If wanted, it can be closed by clearing an address's tag at the start of claim() when the PoolManager is not unlocked (the tokens are no longer borrowable at that point and the claim is the holder's own act), or by noting the limitation next to the contract-wallet note in the README.

     whole finding

     State: contract wallet W holds half of alice's 1,000 IMD buy (first receipt makes it active), bob buys 1,000 IMD (W earns), 8 days pass (W inactive, 15 IMD backlog).

     Input: in one transaction W swaps 1,000 IMD for $COMPANY through PoolSwapTest (W is msg.sender, not tx.origin) and then calls token.claim().

     Expected: the same amount expires as when the claim is sent in the next transaction (14.999999999999999999 IMD, the old backlog).

     Actual: 15.687586906397248853 IMD expire; the extra 0.6876 IMD is the just-bought tokens' share of the 30 IMD flushed by the claim (the hook's holder fees from W's own trade), earned in that transaction and sent to the fee recipient.

     Test: test/scratch/Final3.t.sol test_tag_contractWalletBuyThenClaimSameTx_losesRecentShare (fails on this code with 'same-tx claim expires more').

     whole reproduction
3. reviewed
   #1708Audit permissionsClaude3 findings · 3 low

   Review complete. The findings file holds three substantiated low-severity findings, each with a failing Foundry proof under contracts/test/scratch/, and the source tree is untouched.

   Verification run

   Check	Result
   forge test (unit, attack, fuzz)	55 passed
   forge test --mc CompanyForkTest on live Robinhood Chain	passed (all five stocks bought and paid)
   Scratch proofs on current code	3 fail as stated; all pass with minimal fixes applied locally, with the main suite still green

   The three focus items

   1. FROM_POOL tag. The borrow-proof weight holds. I traced every forwarding path: tokens leaving the PoolManager are tagged on receipt, the tag follows forwarded tokens up to the amount sent, and it is dropped only when tokens go to a system account, none of which can forward (the hook moves tokens only in the one-time openPool, routers never transfer from themselves, the token never sends itself, nobody holds DEAD or the zero address). The invariant tag ≤ balance holds, so the tag cannot revert a transfer. transferFrom, pulls, routers and markActive all forfeit with the tagged weight before any balance change. The one gap is the reverse direction: tokens received from the pool and then credited by a distribution inside the same transaction are excluded from "recent", so an inactive contract wallet that buys via a third-party router and claims in one batch loses the new tokens' share of that claim's distribution. Reported as low with a proof.
   2. Empty-pool clock. The 0.2 IMD threshold and the one-day re-confirmation work as described. The cost is that the 30-day fallback now requires a convert or claim every 24 hours for 30 consecutive days, which nothing on-chain or in the docs provides. Reported as low with a proof.
   3. feedLastGood. Correct when a stock converts regularly, but the timestamp is only written after a stock passes every gate in _convertAll. After a quiet month for a stock, the first unusable answer is treated as dead at once, the same symptom as the original finding 4. Reported as low with a proof.

   Unchanged guarantees I re-checked and found intact: solvency of all six assets (tracked = owed + pending + recycledHeld on every path), the mid-unlock refusals on claim, recycle, distribute, distributeStock and _convertAll, eligibleSupply equals the sum of weights across the 100,000 threshold, recycle never exceeds expiredRewardsOf, and _transfer makes no external call (the forfeit path is storage and transient reads only).

   Observation, not a finding: the 80 IMD of virtual depth that keeps the IMD/USDG pool "non-empty" can be met by a single narrow position holding about one IMD of real tokens. If the real liquidity ever leaves, that LP both prevents the fallback and converts rounds at their own price. This is the accepted no-oracle IMD to USDG hop from AUDIT.md section 8, so I left it out of the findings.

   Coverage limits: passes done were access control, trust gap, asymmetry, execution trace, invariants and boundaries by manual review plus the test runs. No Slither or extended fuzzing ran. A clean result on the three focus items is not proof of absence.

   ran onclaude · claude-fable-5-1 · 47 turns · 18m 57s · 418 in · 67.1K out · 2.4M cached

   submission4849c62f33c4d31df0b2eb4fc014060ba69958880b86dec825bbca8c45659adf

   deviced63429bf439b43f1963f518fde62ae84390582006e4d6fb04781d25bf98b4fce

   started from3b09bc77b05166950f33681048e0fe2f0f59a854

   bundlenone

   changed · 0 filesnothing

   • lowfeedLastGood is refreshed only when a stock actually converts, so after a quiet month a momentarily unusable feed is still 'dead' at oncecontracts/src/CompanyToken.sol:715

     The fix for audit 882666b4 finding 4 says an unusable feed (revert, answer <= 0) is dead only after DEAD_AFTER without a usable answer. But feedLastGood is written only in _convertAll after the stock passed every earlier gate (interval due, imdIn != 0, pool limit >= cap/100, feeds fresh).

     While a stock has nothing waiting (no trades for a while, or its reserve was fully converted), or while its pool is below the dust threshold, feedLastGood is never refreshed although the feed answers correctly on every claim. _feedAge then falls back to _sinceGood for an unusable feed, which is measured from that stale timestamp, so once more than 30 days have passed since the stock's last round, the first revert or zero answer of the feed turns that round into IMD immediately (_fallBackToImd), exactly the behaviour finding 4 was meant to remove.

     Holders still receive the value, but as IMD instead of the stock, and the decision is driven by a bookkeeping gap rather than by 30 days of unusable answers.

     Fix: record a usable answer whenever one is observed, independently of whether the stock converts, e.g. at the top of each loop iteration (if (_feedsFresh(a)) { feedLastGood[usdFeed] = feedLastGood[priceFeeds[a]] = block.timestamp; }) before the interval and imdIn checks, or refresh all feeds once per _convertAll. With that change the attached test passes and the existing suite still passes.

     whole finding

     State: alice and bob each buy 1,000 IMD worth (6 IMD waiting per stock). convert() twice, one minute apart: every reserve is now 0 and feedLastGood[NVDA feed] = now.

     Then 31 days pass with no trades; feeds are updated daily and alice claims daily (claim runs _convertAll, which converts nothing and never touches feedLastGood).

     Trading resumes (bob buys 1,000 IMD: 3 IMD waiting for NVDA).

     One minute later the NVDA feed reverts on latestRoundData at the moment convert() runs.

     Expected (contract notice and AUDIT.md section 7 finding 4): NVDA is held, pendingConvert(1) stays 3e18, owed(0) unchanged.

     Actual: _feedsDead(1) is true because _sinceGood = 31 days + 2 minutes > DEAD_AFTER, so _fallBackToImd runs: pendingConvert(1) = 0 and owed(0) grows by 3e18 (ConversionFailed emitted).

     Test: forge test --match-path test/scratch/FinalCheck3FeedLastGood.t.sol fails with 'NVDA held, not paid as IMD: 0 != 3000000000000000000'.

     whole reproduction

   • lowAn inactive holder that receives pool tokens and claims in the same transaction loses the part of that transaction's distribution the new tokens earnedcontracts/src/CompanyToken.sol:574

     expiredRewardsOf estimates the 'recent' (non-expiring) rewards as (mag now - mag at the cutoff) x weight, where the weight now excludes every token the holder received from the PoolManager in this transaction (FROM_POOL tag). The comment says those tokens 'earned nothing yet'.

     That is only true if no distribution happens between the receipt and the expiry computation inside the same transaction. claim() itself distributes: it calls hook.flush (which credits pending holder fees to current holders, including the tag-tagged tokens) and _convertAll (which can credit stock and IMD fallbacks) before _recycle(msg.sender).

     So a holder who is inactive for more than 7 days, buys through a third-party router in a way that does not markActive it (a contract wallet, where tx.origin is the relayer or bundler), and claims in the same batched transaction, has the share of that distribution earned by the just-bought tokens counted as expired and sent to the fee recipient, although it was earned seconds ago. The same under-estimate applies to a send or pull after a same-transaction distribution.

     The loss is bounded by (new tokens / eligible supply) x (amount distributed in that transaction), typically the holder's own 3% fee share, so this is low severity, but it answers the request's question: the tag can expire rewards an honest holder earned inside the 7-day window.

     Fix: the tag is only needed where borrowed tokens can be present, i.e. in _forfeit paths that may run mid-unlock (transfer, markActive). claim() and recycle() refuse to run while the PoolManager is unlocked, so every token the holder has at that point is real; _recycle can use the untagged weight (e.g. an internal _expired(holder, asset, bool useTag) with expiredRewardsOf = _expired(.., true) and _recycle using false).

     That keeps the flash-borrow fixes intact (the attached test and the whole existing suite pass with that change). Alternatively, apply the tag only to per-share growth recorded before the receipt.

     whole finding

     State: a contract wallet W buys 1,000 IMD worth of $COMPANY through a plain v4 swap router (PoolSwapTest), so it holds tokens and is active (first receipt).

     Bob buys 1,000 IMD: 15 IMD are credited and W, the only holder, earns all 15.

     8 days pass with no activity; expiredRewardsOf(W, 0) = 15e18 (nothing recent).

     In one transaction W buys another 1,000 IMD through the third-party router (its 30 IMD holder fee waits in the hook; W receives X tokens tagged FROM_POOL; markActive goes to tx.origin, not W) and then calls claim(). claim() flushes: 15 IMD are credited while W holds B + X, so W earns 15 x (B+X)/eligible.

     Then _recycle(W): recent = (mag growth of this flush) x _weight(B), which is smaller than what W just earned by 15 x X/eligible.

     Expected: exactly the 15e18 that had expired before the transaction goes to the fee recipient.

     Actual: totalRecycled(0) grows by 15.687e18, i.e. 0.687 IMD of the fee W paid seconds earlier is taken as 'expired'.

     Test: forge test --match-path test/scratch/FinalCheck3TagSameTx.t.sol fails with 'only the backlog that had expired before the tx goes to the protocol: 15687586906397248854 != 15000000000000000000'.

     whole reproduction

   • lowThe 30-day empty-pool fallback only ever fires if convert()/claim() is called at least once a day for 30 consecutive dayscontracts/src/CompanyToken.sol:681

     The fix for audit 882666b4 finding 6 restarts imdPoolEmptySince unless emptiness was re-confirmed within one day. Confirmation happens only inside _convertAll, i.e. on a claim() or convert() call. The contract notice promises that an empty IMD/USDG pool is waited for 'but not forever' and that after DEAD_AFTER the stock rounds are paid as IMD; in practice that promise now depends on an external caller hitting the contract every 24 hours for 30 days.

     An abandoned pool is the scenario where claims become rare (half of every fee is stuck in reserves and only the IMD half keeps arriving), so a gap of just over a day anywhere in the 30 days, for example a weekend without a claim, resets the clock to zero and the five stock reserves (50% of all holder fees accrued since the pool emptied) stay locked until someone runs a daily keeper for a full month.

     Nothing is lost, but the stated guarantee is conditional on off-chain liveness that neither the contract nor the documentation provides (the website's claim button is not a keeper).

     Fix options that keep the finding-6 intent: widen the confirmation window to something that tolerates normal claim cadence (e.g. 7 days: a pool that is usable in between still resets the clock through the else-branch whenever anyone converts while it has liquidity), or make the clock a count of distinct-day confirmations rather than a chain of daily ones, or have the website/keeper call convert() daily and document that dependency in AUDIT.md section 8.

     whole finding

     State: alice and bob each buy 1,000 IMD worth (6 IMD waiting per stock); the whole IMD/USDG liquidity is removed, maxConvert() == 0. convert() is then called every 2 days for 90 days with fresh feeds.

     Expected (contract notice: 'Wait, but not forever ... after DEAD_AFTER of confirmed emptiness every stock's rounds are paid to holders as IMD'): after 30 days the rounds start to be paid as IMD, pendingConvert(1) < 6e18.

     Actual: each call sees block.timestamp > imdPoolLastSeenEmpty + 1 days and restarts imdPoolEmptySince, so block.timestamp <= imdPoolEmptySince + DEAD_AFTER on every call; pendingConvert(1) is still 6e18 after 90 days.

     Test: forge test --match-path test/scratch/FinalCheck3EmptyClock.t.sol fails with 'rounds paid as IMD after DEAD_AFTER: 6000000000000000000 >= 6000000000000000000'.

     whole reproduction
4. reviewed
   #1492Audit mathClaude2 findings · 1 medium

   Review complete. The findings file holds two substantiated defects, both with Foundry proofs that fail on this commit and pass against a scratch copy carrying the suggested fix.

   Outcome

   • Medium, contracts/src/CompanyToken.sol:575. The new transient tag correctly keeps PoolManager receipts out of the "recent" weight, but those tokens still earn from any distribution later in the same transaction. In claim(), the flush and conversion run before _recycle, so an inactive contract wallet that buys through a third-party router and claims in one batched transaction has its new tokens' share of that flush treated as expired and sent to the fee recipient. In the proof, 12.95 IMD left the wallet when only 0.6 IMD had actually expired. Fix: recycle and reset the timer before flushing and converting in claim(), and optionally carry the per-share value at receipt alongside the tag to cover the send path too.
   • Low, contracts/src/CompanyToken.sol:880. feedLastGood is only written when a round for that stock actually runs. After 30 quiet days for a stock, the first unusable read (revert or answer 0) is treated as a dead feed at once and a round is paid as IMD, contradicting the finding 4 guarantee. Fix: time unusability from the first unusable observation.

   Confirmed sound after tracing with concrete values: the tag cannot be shed except by returning tokens to the pool or losing them to a system account; it follows forwarding chains and transferFrom; it never exceeds the balance and cannot revert a transfer; both official routers mark the buyer active before the tokens arrive, so ordinary users are unaffected. The empty-pool clock, the 0.2 IMD threshold and the one-day re-confirmation behave as documented. Solvency, the 100,000 minimum, the mid-unlock guards and the no-external-call property of transfers all hold. All 55 unit tests and the live Robinhood Chain fork test pass.

   Worth knowing, not defects: the 30-day empty-pool countdown needs someone to call convert() or claim() at least daily, otherwise it restarts; and GME's live round limit sits at about 3.6 IMD, just under the 4 IMD per-stock cap, so its pool depth is the binding constraint today.

   Scope limits: no Slither or symbolic tools were run, and the stock tokens' sequencer-level restrictions were not modelled. Nothing outside contracts/test/scratch/ and the findings file was created or changed.

   ran onclaude · claude-fable-5-1 · 41 turns · 19m 40s · 642 in · 83.2K out · 4.6M cached

   submission61ad6f04b8c5b9d78e7e0d2bc047ab30bcb69a4ce6a31ae4cd186ac467032466

   device9841ca91054c407d96ed3f6668635c09656c28965664edb80eaa5973259b288b

   started from3b09bc77b05166950f33681048e0fe2f0f59a854

   bundlenone

   changed · 0 filesnothing

   • mediumTagged same-transaction pool receipts earn from the claim's own flush, but that share is counted as expired and sent to the fee recipientcontracts/src/CompanyToken.sol:575

     The root-cause fix for audit 882666b4 findings 1 and 2 removes tokens received from the PoolManager in the current transaction (FROM_POOL_SEED tag) from the weight used to estimate "recent" rewards in expiredRewardsOf.

     That is correct for the past 7 days (those tokens earned nothing before they arrived), but once they sit in the holder's balance they are a full part of weightOf() and earn from every distribution that happens later in the same transaction (_credit at CompanyToken.sol:489-498 uses eligibleSupply, which includes them). claim() runs ICompanyHook(hook).flush() and _convertAll() (lines 531-532) before _recycle(msg.sender) (line 536): the flush credits the claimer's whole balance, tagged tokens included, and then _recycle computes expired = withdrawable - recent with recent built on bal - tagged, so the tagged tokens' share of that flush (and of this round's stock credits) is treated as expired and transferred to feeRecipient instead of being paid.

     The same happens in _transfer's _forfeit(from) if a flush ran between the tagged receipt and the send.

     The flash-borrow case this guards against never reaches a distribution (distribute() returns 0 mid-unlock and claim/recycle revert there), so the only holder that hits it is an honest one: a contract wallet (tx.origin is its signer, so the hook's markActive does not make the wallet active) that has been inactive for more than 7 days, buys through a router other than CompanyRouter/CompanyEthRouter (no flush before it receives the tokens; the 3% holder fee waits in the hook) and claims in the same batched transaction.

     It loses the tagged tokens' pro-rata share of 1.5% of its own buy in IMD and of this round's stock credits (up to 4 IMD per stock) to the fee recipient: for a wallet that holds most of the eligible supply after the buy, about 1.2% of the buy in IMD plus the stock round.

     Bounded and non-compounding, but a permanent loss of rewards the design says the holder keeps ("except what it earned during those last 7 days"), and the request asked whether the tag can expire rewards an honest holder earned in the last 7 days: it can.

     Suggested fix: in claim(), run _recycle(msg.sender) and set lastActive[msg.sender] before flush() and _convertAll(), so this claim's distributions are credited to an active wallet and never enter the expiry estimate (same result for every other holder, since credits at now are recent anyway).

     To also cover a send after a third-party flush in the same transaction, record with each tagged receipt the magnifiedRewardPerShare at arrival (a transient correction, like _corrections) and add tagged x (mag_now - mag_at_receipt) / MAGNITUDE to recent.

     whole finding

     Setup as test/Company.t.sol.

     A contract wallet W (multicall; its owner EOA is tx.origin) buys 20 IMD of $COMPANY through CompanyRouter at T0 (W is the recorded buyer, lastActive[W] = T0); bob buys 20 IMD, so W earns.

     Warp 8 days; bob buys 10 IMD (one distribution inside W's last 7 days).

     Now expiredRewardsOf(W, 0) = 0.6 IMD (the first distribution) and the rest is recent.

     In ONE transaction W executes: (1) PoolSwapTest.swap buying with 1,000 IMD (W receives the tokens from the PoolManager: tagged; the hook marks tx.origin, not W; 30 IMD of holder fee wait in the hook), then (2) token.claim().

     Expected: the fee recipient receives exactly the 0.6 IMD that had expired and W is paid everything else, including its share of the 15 IMD the claim's flush distributes.

     Actual: imd.balanceOf(FEE_RECIPIENT) grows by 12.949 IMD (assert '12949389304807710911 != 599999999999999999'): the 1,000 IMD worth of tagged tokens are about 82% of eligibleSupply, their 12.35 IMD share of the flush is counted as expired, and the tagged share of this round's NVDA..MSTR credits goes the same way.

     Proof file: contracts/test/scratch/TagSameTxForfeitProof.t.sol.

     whole reproduction

   • lowfeedLastGood is refreshed only by rounds that run, so after 30 quiet days one unusable read is treated as a dead feedcontracts/src/CompanyToken.sol:880

     The fix for audit 882666b4 finding 4 makes an unusable feed (revert, answer <= 0, updatedAt == 0) dead only after DEAD_AFTER (30 days) without a usable answer, measured from feedLastGood. But feedLastGood[feed] is written only at CompanyToken.sol:715-716, inside the per-stock loop of _convertAll, after the stock passed every earlier gate (something pending, 1 minute since lastConvert, IMD/USDG pool not empty, stockRoundLimit >= cap/100, feeds fresh).

     While a stock has nothing pending, or while the IMD/USDG pool counts as empty (early return at line 685), no round reaches that line and feedLastGood keeps its old value even though the feed answers normally on-chain.

     Once that gap exceeds 30 days, the next round that meets an unusable answer computes _sinceGood > DEAD_AFTER, _feedsDead returns true at once and _fallBackToImd credits that round's stock share (up to MAX_ROUND_IMD/5 = 4 IMD per stock, per minute while the glitch lasts) to holders as IMD instead of holding the stock, which is what finding 4 was meant to prevent.

     Holders lose no value, but the stated guarantee (dead only after 30 days without a usable answer) does not hold, and a transient Chainlink glitch after a quiet month turns stock rounds into IMD.

     Suggested fix: measure unusability from the first unusable observation rather than from the last recorded good one, e.g. feedUnusableSince[feed] set on the first unusable read and cleared on a usable one, dead only when block.timestamp > feedUnusableSince + DEAD_AFTER; or at least refresh feedLastGood for every feed that reads usable at the top of each _convertAll.

     whole finding

     Deploy as in test/Company.t.sol setUp (feedLastGood = deployment time T0).

     Make no trade for 31 days.

     At T0 + 31d: alice and bob each buy 1,000 IMD through CompanyRouter (pendingConvert[1] = 6 IMD).

     Warp 1 minute; set every feed fresh except NVDA, which returns answer 0 with updatedAt = now.

     Call convert().

     Expected (AUDIT.md section 7 finding 4): the NVDA round is held, pendingConvert(1) stays 6e18 and owed(0) is unchanged.

     Actual: _feedsDead(1) is true because block.timestamp - feedLastGood[NVDA] = 31 days + 1 minute > DEAD_AFTER, so _fallBackToImd(1, 4e18) runs: pendingConvert(1) becomes 2e18 and owed(0) grows by 4e18 (assert '2000000000000000000 != 6000000000000000000').

     Proof file: contracts/test/scratch/FeedLastGoodProof.t.sol, test_unusableFeedAfterQuietMonth_isHeldNotPaidAsImd.

     whole reproduction
5. reviewed
   #1494Audit economicsClaude3 findings · 3 low

   Review complete. No tracked file changed; the only untracked items are the three proof files under contracts/test/scratch/ and the findings JSON.

   Outcome. The three changes since 882666b4 do what the brief says, and I found no critical or high defect. The full suite passes (54 tests) and the fork test passes against live Robinhood Chain state. I confirmed the flash-borrow guard, solvency, the 100,000 minimum, strict expiry and the no-external-call property of transfers. I filed three low findings, each with a self-contained failing Foundry proof.

   Area 1, the FROM_POOL tag. A borrowed balance cannot count through any path. The tag is conserved under forwarding chains, system-account passes, transferFrom, routers and markActive, and the tag never exceeds the balance, so it cannot revert a transfer. I proved the forwarding-chain case with a probe that passes. The one real gap is a same-transaction under-estimate:

   • Low: expiredRewardsOf applies the tag for the whole transaction, but a distribution that happens after a tagged receipt credits those tokens while "recent" ignores them. A Safe-style wallet, inactive over 7 days, that buys through a third-party router and claims in the same batch loses rewards credited seconds earlier. In the proof 12.95 IMD are recycled against 0.6 IMD actually expired. Since no distribution can run inside a foreign unlock, a transient distribution epoch stored with the tag fixes it without adding an external call to transfers.

   Area 2, the empty IMD/USDG pool. The 0.2 IMD threshold and the reset-when-liquid branch are correct. The daily re-confirmation introduces a liveness dependency:

   • Low: a genuinely empty pool observed every two days for 90 days is never declared dead, so the 30-day fallback from the earlier medium finding can be postponed indefinitely and the five reserves stay locked. The contract promises no keeper, but this path needs one.

   Area 3, feedLastGood. The dead-after-30-days logic is right for readable feeds. For unusable ones the clock measures last use, not last usable answer:

   • Low: feedLastGood is only written when a purchase is actually attempted. After a month with nothing to convert, a feed that reverts or answers zero for one block is dead at once and that stock's round is paid as IMD immediately. Through the shared USDG/USD feed this hits all five stocks in one round.

   Everything else I traced held: solvency of all six assets, the strictness of expiry, the per-stock limits and the oracle check. The proofs are in contracts/test/scratch/Proof1_TagRecent.t.sol, Proof2_FeedLastGood.t.sol and Proof3_EmptyPoolLiveness.t.sol, and the report is at .imd-findings.json in the repository root.

   ran onclaude · claude-fable-5-1 · 49 turns · 20m 6s · 578 in · 80.9K out · 3.8M cached

   submissionc91db0a3642934ecc8f3e888946fcd6e353cfa85abefad6b9ae65cdd4de1edc6

   devicee250de394555c13290d0667bc2fc77a2bfff25e524f16eab251047e16fb1f6bb

   started from3b09bc77b05166950f33681048e0fe2f0f59a854

   bundlenone

   changed · 0 filesnothing

   • lowFROM_POOL tag expires rewards earned in the same transaction after the tagged receipt (contract wallet: third-party buy, then claim)contracts/src/CompanyToken.sol:575

     expiredRewardsOf estimates the holder's last-7-day earnings as (magnifiedRewardPerShare - magAt(cutoff)) x weight, and since 882666b4 the weight leaves out every $COMPANY the holder received from the PoolManager in the current transaction (the transient FROM_POOL tag).

     The tag is applied for the whole transaction, but it is only sound while nothing has been distributed since the receipt: a distribution that happens after the tagged tokens arrived credits them (withdrawableRewardOf counts the full balance through _corrections), while the 'recent' estimate ignores them. The difference, which is seconds old, is classified as expired and sent to feeRecipient.

     The borrowed-token case the tag was written for can never see a distribution after the receipt (distribute/distributeStock/convert/flush are all blocked inside a foreign unlock and PoolManager.unlock cannot nest), so every distribution after a tagged receipt proves the tokens are real and the exclusion is wrong at that point.

     Reachable by an honest holder: a smart-contract wallet (Safe, or any contract) that has been inactive for more than 7 days buys through a third-party router (afterSwap marks tx.origin, the signer, not the wallet) and claims in the same batch. claim() flushes the pending holder fees (including the 3% the wallet just paid) over the wallet's full balance, converts stock rounds, then _recycle(wallet) expires the just-bought tokens' share of all of it.

     The same happens on a self-send or a send in that batch (_forfeit in _transfer) and on recycle(wallet) by anyone in that transaction. Loss is bounded by the holder's share of what was distributed in that transaction; the official routers are not affected because they flush before the take.

     Fix that keeps 'no external call in transfers': bump a transient distribution epoch in _credit and store the epoch with the tag; _fromPool returns 0 (and forwards nothing) when the holder's tag epoch is older than the current one, so the tag only ever excludes tokens that have not been through a distribution. Alternatively keep a per-asset transient correction for tagged tokens (amount x mag at receipt) and add their real earnings since receipt back into 'recent'.

     whole finding

     State: contract wallet W bought 20 IMD worth through PoolSwapTest (a third-party router) 8 days ago and has been inactive since; alice bought 20 IMD; bob bought 10 IMD today (one distribution inside W's last 7 days). expiredRewardsOf(W, 0) = 0.6 IMD.

     Input, one transaction from W (tx.origin = its signer): [1] extRouter.swap buying 1,000 IMD worth of $COMPANY (W's weight goes from 59.0M to 690.5M, the 631.5M new tokens are tagged; the hook marks the signer active, not W), [2] token.claim().

     Expected: the claim recycles 0.6 IMD (what had expired) and pays everything else, including W's share of the 30 IMD flushed by this claim.

     Actual: 12.949 IMD go to feeRecipient; 12.35 IMD of rewards credited seconds earlier in the same claim are treated as expired (plus the tagged share of the five stock rounds converted in that claim).

     Run: forge test --match-path test/scratch/Proof1_TagRecent.t.sol (fails: 'rewards earned seconds ago were expired: 12949389304807710911 > 600000000000000000').

     whole reproduction

   • lowfeedLastGood records the last round that used the feed, not its last usable answer: a feed unused for 30 days is dead the moment it is unusablecontracts/src/CompanyToken.sol:715

     The stated property (882666b4 finding 4) is that an unusable feed (revert, no data, answer <= 0) counts as dead only after DEAD_AFTER without a usable answer. feedLastGood is the only memory of past usable answers and it is written in exactly two places: the constructor, and _convertAll immediately before a purchase is attempted, i.e. only when that stock had IMD pending, CONVERT_INTERVAL had passed, the IMD/USDG pool was not 'empty', its own pool was not 'empty' and both feeds read fresh.

     Any period in which no round consumed the feed (no claims or converts for a month, nothing pending for a month, the IMD/USDG pool below the emptiness threshold, that stock's pool empty, or the feed merely stale over 4 days while the USDG/USD feed only gets refreshed together with a fresh stock feed) leaves feedLastGood frozen even though the feed answered correctly throughout.

     When the feed then becomes unusable for even one block, _feedAge returns _sinceGood = now - feedLastGood > 30 days, _feedsDead is true and the round is paid to holders as IMD at once by _fallBackToImd. For the shared USDG/USD feed this hits all five stocks in the same round (20 IMD). It is the opposite failure from the readable-but-stale case, where _feedAge correctly uses updatedAt.

     Holders get IMD of equal value instead of stock, and the stock reserve keeps draining at one capped round per minute while the outage lasts, so a short aggregator hiccup after a quiet month turns stock rounds into IMD.

     Fix: refresh feedLastGood from every successful _readFeed (e.g. probe all six feeds at the top of _convertAll before any early return/continue, or make _feedAge fall back to the stored updatedAt of the last usable read rather than the time of the last purchase).

     whole finding

     State: fresh deployment; 31 days pass with no trades (every feed keeps answering 1e8 with a current updatedAt, nobody calls convert/claim so feedLastGood stays at the deployment timestamp); then alice and bob buy 1,000 IMD each (pendingConvert = 6 IMD per stock), one minute passes.

     Input: the NVDA/USD aggregator reverts (it answered one second earlier) and anyone calls convert().

     Expected: NVDA is skipped and waits (unusable for one minute, not 30 days); GOOGL/AAPL/GME/MSTR convert.

     Actual: NVDA's 4 IMD round is credited to holders as IMD immediately (owed[0] 30 -> 34 IMD, pendingConvert[1] 6 -> 2 IMD).

     Second input in the same proof: the USDG/USD feed answers 0 instead; expected all five stocks wait, actual all five rounds (20 IMD) are paid as IMD at once (owed[0] 30 -> 50).

     Run: forge test --match-path test/scratch/Proof2_FeedLastGood.t.sol (both tests fail).

     whole reproduction

   • lowEmpty IMD/USDG pool is never declared dead unless someone calls convert/claim at least once a day for 30 consecutive dayscontracts/src/CompanyToken.sol:681

     The fix for 882666b4 finding 6 restarts imdPoolEmptySince whenever the previous emptiness observation is more than one day old. Observations only happen inside _convertAll, i.e. when someone calls claim() or convert().

     With the IMD/USDG pool genuinely without liquidity nothing can be bought, claims pay only IMD, and nothing forces anyone to call daily; a claim every two days (or any gap over 24 hours, once, during the 30 days) resets the clock, so the 30-day fallback of 363ab052 finding 3 ('rounds are paid to holders as IMD after DEAD_AFTER') can be postponed indefinitely and the five stock reserves stay locked, which is the state that finding was rated medium for.

     The same daily requirement applies after the pool has been declared dead: one missed day stops the fallback rounds and restarts the 30-day wait. The contract notice says no keeper is needed; this path needs one.

     A pool seen with liquidity in between already resets the clock explicitly (the else branch), so the daily re-confirmation only guards against liquidity that came and went unobserved; a longer confirmation window (e.g. restart only if the last observation is older than 7 days) or counting distinct confirmed days instead of consecutive ones keeps the intent without the liveness dependency.

     whole finding

     State: alice and bob bought 1,000 IMD each (6 IMD pending per stock); all liquidity is removed from the IMD/USDG pool (maxConvert() == 0, a fully empty pool, not a dust position).

     Input: convert() is called every 2 days for 90 days with fresh feeds.

     Expected (AUDIT.md section 6 finding 3): after 30 days of emptiness each round pays the stocks' IMD to holders as IMD (owed[0] grows by 20 IMD per round).

     Actual: imdPoolEmptySince is restarted at every call because the previous observation is 2 days old; after 90 days owed[0] is still 30 IMD and all five reserves are still locked.

     Run: forge test --match-path test/scratch/Proof3_EmptyPoolLiveness.t.sol (fails: 'no fallback after 90 days of emptiness').

     whole reproduction
6. reviewed
   #467Audit judgeClaude4 findings · 1 medium

   afterAudit math, Audit permissions, Audit economics, Audit flow

   The review is complete. The findings file is in place at the repository root and nothing outside it and test/scratch/ was changed.

   Outcome. Four findings, all reproduced against the code with failing Foundry tests. The eleven specialist findings collapse into three real mechanisms, and I found one new issue on review item 2.

   #	Severity	Finding	Specialists merged
   1	medium	Empty IMD/USDG pool: a small position at a made-up price clears the 1% emptiness threshold and rounds sell the stock reserves into it for dust	new
   2	low	FROM_POOL tag excludes tagged tokens' share of a distribution run later in the same transaction (contract wallet: third-party buy, then claim)	4
   3	low	feedLastGood only refreshed when a round reaches its purchase, so after 30 quiet days one unusable read is "dead" at once	4
   4	low	Empty-pool clock restarts unless convert or claim runs daily for 30 consecutive days	3

   What I checked beyond the specialists' claims.

   • The whole suite passes at HEAD, and the live fork test against Robinhood Chain passes with real feeds and pools.
   • The tag cannot make a transfer revert, and a borrowed balance cannot regain untagged weight through forwarding chains, system accounts or transferFrom. I added a chain-forwarding sanity test and it forfeits correctly. The amount of untagged tokens is conserved across non-system addresses, so only real capital can inflate "recent", which is the accepted gift variant.
   • Solvency, the 100,000 minimum and the no-external-call property of transfers are unchanged by the fix commit.

   On severities. The same-transaction tag loss is self-inflicted and bounded, so I kept it low rather than audit_math's medium. The new finding is medium because it shares the precondition of 363ab052 finding 3 (an abandoned IMD/USDG pool) but produces a worse outcome: with about 41 IMD of capital at a fake price, the reserves drain to the attacker at up to 20 IMD per minute instead of waiting or falling back to IMD.

   Next step for the requester. Each finding carries a self-contained proof under contracts/test/scratch/ that fails now and is written to pass under any of the suggested fixes, so the fix commit can be verified by rerunning those files.

   ran onclaude · claude-fable-5-1 · 33 turns · 16m 38s · 450 in · 43.6K out · 1.9M cached

   submissionffece18c9a8470ff5a4208fd9fbcceef2f126aa1046a23818c76acad116a7880

   devicebdd9b74dce66953d980cc1c0cfe15f99b1c1ffde3719dbe7e0d5dec4e3e7a8eb

   started from3b09bc77b05166950f33681048e0fe2f0f59a854

   bundlenone

   changed · 0 filesnothing

   • mediumEmpty IMD/USDG pool: a small position at a made-up price clears the 1% emptiness threshold and every round sells the stock reserves into it for dustcontracts/src/CompanyToken.sol:680

     The emptiness test for the IMD/USDG pool (review item 2) uses maxConvert(), i.e. the pool's virtual IMD depth L/sqrtP at the current price. Once the real liquidity is gone at and below the current price, anyone can move the price anywhere for free (a swap through a pool with no in-range liquidity moves the price to the limit without exchanging tokens), then post a narrow position there.

     At a price where 1 IMD is worth ~1e-9 USDG, about 41 IMD of real capital gives a virtual depth of ~940 IMD, so maxConvert() reads 2.3 IMD (and with more capital up to the 20 IMD ceiling), the pool no longer counts as empty, imdPoolEmptySince is reset to 0, and the next round sells each stock's capped IMD into that position for dust USDG.

     The second hop then passes minStockOut because it is checked against usdOut, not against imdIn (AUDIT.md section 8 accepts that the IMD -> USDG hop has no oracle 'resting on the pool's depth'; here the depth is the attacker's).

     The attacker can call convert() every minute, so the five stock reserves (50% of every holder-fee distribution accrued while the real pool is empty) drain to the position's owner at up to 20 IMD per minute instead of either waiting or being paid to holders as IMD after DEAD_AFTER. This is the limit case of the accepted thin-pool sandwich, but it needs no sandwich and no price move within a transaction: the position just sits there.

     It also means the 30-day fallback for an abandoned pool (363ab052 finding 3, 882666b4 finding 3) can be both pre-empted and profited from.

     Precondition: no real IMD/USDG liquidity in range at and below the current price (an abandoned pool, or a concentrated LP whose range the price has left on the downside).

     Fix options that keep the design: (1) anchor the first hop: store the IMD/USDG rate of the last successful round (usdOut/imdIn) and skip (PriceOff-style, no fallback) a round whose rate is more than a bounded factor away, or derive an IMD/USD reference from the IMD/ETH pool and an ETH/USD feed; (2) in addition, define emptiness by in-range liquidity L against a floor fixed at deployment (e.g. 1% of the launch pool's L) rather than by virtual depth, since real capital for a given L explodes away from the honest price.

     whole finding

     State: alice and bob each buy 1,000 IMD through CompanyRouter (pendingConvert = 6 IMD per stock); the IMD/USDG pool's only position (10,000 L, full range) is removed, so maxConvert() == 0 (pool counts as empty).

     Input, by the attacker: one swap of 1 wei with a price limit at tick +/-207,000 (price moves for free), then modifyLiquidity(lo = target - 900, hi = target + 900, L = 3e16): the position holds 41.24 IMD and 0.00000004 USDG.

     Now maxConvert() = 2.343 IMD (>= 0.2 IMD, no longer 'empty').

     Warp 1 minute, refresh feeds, call convert().

     Expected: the round waits (the pool has no usable liquidity at a sane price) or, after DEAD_AFTER, is paid to holders as IMD; the position's owner gains nothing.

     Actual: each stock round sells 0.4686 IMD (2.343 IMD total) for dust: NVDA bought = 474,156,573 wei (4.7e-10 NVDA) and credited to holders; pendingConvert(1) drops 6e18 -> 5.531e18 with owed(0) unchanged (assert '468613088435602910 != 0'); after removing the position the attacker holds 2.343 IMD more than before.

     Repeating convert() every minute drains the reserves.

     Proof: contracts/test/scratch/ProofEmptyPoolLp.t.sol (fails on this code; passes once the round is held, falls back to IMD, or the position is treated as empty).

     whole reproduction

   • lowFROM_POOL tag also excludes the tagged tokens' share of distributions that ran later in the same transaction: a contract wallet that buys through a third-party router and claims in one transaction loscontracts/src/CompanyToken.sol:575

     Merged from audit_math, audit_flow, audit_economics and audit_permissions (same mechanism, same line; all four reproduce). expiredRewardsOf estimates 'recent' rewards as (magnifiedRewardPerShare - magAt(cutoff)) x weight and, since 882666b4, leaves every $COMPANY received from the PoolManager in this transaction out of that weight, on the assumption that those tokens 'earned nothing yet'.

     That holds only until a distribution runs in the same transaction after the receipt: claim() calls hook.flush() and _convertAll() (lines 531-532) before _recycle(msg.sender) (line 536), and both credit the holder's full balance (eligibleSupply includes the tagged tokens) while the expiry estimate still excludes them.

     The tagged tokens' share of that flush and of this round's stock credits is therefore classified as expired and sent to feeRecipient, seconds after it was credited. The same under-estimate applies to a send in that transaction after a flush (_forfeit in _transfer).

     Reachable only by an honest holder: a smart-contract wallet (its signer or bundler is tx.origin, so afterSwap's markActive does not make the wallet active) that has been inactive for more than 7 days, buys through a router other than CompanyRouter/CompanyEthRouter (no flush before the take) and claims in the same batched transaction. EOAs are marked active by the buy, the official routers flush before the take, and claiming in a later transaction avoids it.

     The flash-borrow attack this tag closes can never reach a distribution after the receipt (distribute/flush/convert are blocked inside a foreign unlock, claim and recycle revert there), so nothing on the attack side relies on the tag persisting past a distribution. Loss is bounded by the new tokens' pro-rata share of what was distributed in that transaction (mostly the wallet's own 3% fee, plus up to one stock round) and goes to the fee recipient.

     So the answer to review item 1's question 'can the tag expire rewards an honest holder earned in the last 7 days' is yes, in this one case.

     Fix that keeps 'no external call in transfers': in claim(), run _recycle(msg.sender) and set lastActive before flush() and _convertAll() (this transaction's credits then land on an active wallet; for every other holder credits at now are recent anyway), and for the send-after-flush case either bump a transient distribution epoch in _credit and ignore a tag older than the current epoch, or record the per-share level at each tagged receipt and add tagged x (mag_now - mag_at_receipt) / MAGNITUDE back into 'recent'.

     whole finding

     State (test/scratch/ProofTagSameTx.t.sol): a contract wallet W buys 20 IMD worth of $COMPANY through PoolSwapTest (a plain v4 router) and is active by first receipt; bob buys 20 IMD (W earns); warp 8 days; bob buys 10 IMD (one distribution inside W's last 7 days). expiredRewardsOf(W, 0) = 0.3 IMD.

     Input, one transaction from W with tx.origin = its signer: [1] PoolSwapTest.swap buying with 1,000 IMD (W receives ~631M tagged tokens, the hook marks the signer active, 30 IMD of holder fees wait in the hook), [2] token.claim().

     Expected: at most the 0.3 IMD that had expired before the transaction goes to the fee recipient and W is paid the rest, including its share of the 15 IMD the claim's flush credits.

     Actual: totalRecycled(0) and imd.balanceOf(FEE_RECIPIENT) grow by 12.649 IMD (assert '12649389304807710912 > 300000000000000000'): the tagged tokens' share of the flush, credited seconds earlier in the same claim, is treated as expired.

     The suite's own test_final2_* tests do not cover a distribution after a tagged receipt.

     whole reproduction

   • lowfeedLastGood is written only when a stock's round actually reaches its purchase, so after 30 days without a round one unusable read declares the feed dead at oncecontracts/src/CompanyToken.sol:715

     Merged from audit_math, audit_flow, audit_economics and audit_permissions (same root cause; all reproduce). Review item 3 states that an unusable feed (revert, no data, answer <= 0) is dead only after DEAD_AFTER (30 days) without a usable answer.

     The only memory of usable answers is feedLastGood, written in the constructor and at lines 715-716, i.e. only when that stock's round is due (CONVERT_INTERVAL), has IMD waiting, the IMD/USDG pool is not in its 'empty' branch (early return at line 685), stockRoundLimit >= cap/100 and both feeds read fresh.

     While any of those gates is closed (no trades for a while, that stock's reserve already drained, the IMD/USDG pool below the emptiness threshold, a weekend-stale feed), feedLastGood stays frozen although the feed answers correctly on every claim.

     When the feed is then unusable for even one call, _feedAge falls back to _sinceGood, which is measured from that stale timestamp: once it exceeds 30 days, _feedsDead is true immediately and _fallBackToImd credits that round's stock share (up to MAX_ROUND_IMD/5 = 4 IMD per stock, one round per minute while the glitch lasts) to holders as IMD. For the shared USDG/USD feed this hits all five stocks (20 IMD per round).

     Holders keep the value as IMD instead of stock, so the impact is bounded to the accepted 'one capped round' outcome per unusable call, but the property 882666b4 finding 4 was fixed to provide does not hold.

     Fix: record a usable answer whenever one is observed, independently of whether a round runs: at the top of _convertAll (before the IMD-pool early return and the per-stock gates) read the USDG feed and each stock feed with _readFeed and set feedLastGood[feed] = block.timestamp when ok; or replace _sinceGood with a feedUnusableSince[feed] set on the first unusable observation and cleared by a usable one, dead only when block.timestamp > feedUnusableSince + DEAD_AFTER.

     whole finding

     State (test/scratch/ProofFeedLastGood.t.sol): fresh deployment (feedLastGood = T0); for 31 days nobody trades, every feed is refreshed daily with answer 1e8 and convert() is called daily (nothing pending, so line 715 never runs).

     Then alice and bob buy 1,000 IMD each (pendingConvert[1] = 6 IMD); warp 1 minute; refresh all feeds; make the NVDA feed's latestRoundData revert for this one call; call convert().

     Expected (contract notice, AUDIT.md section 7 finding 4): the NVDA round is held, pendingConvert(1) stays 6e18, owed(0) unchanged.

     Actual: _sinceGood(NVDA) = 31 days + 1 minute > DEAD_AFTER, so _feedsDead(1) is true and _fallBackToImd(1, 4e18) runs: pendingConvert(1) == 2e18 and owed(0) grows by 4e18 (assert '2000000000000000000 != 6000000000000000000').

     The existing test_final2_4_unusableFeedHoldsUntilDeadAfter passes only because a good round ran a minute earlier.

     whole reproduction

   • lowThe empty-pool clock restarts unless convert()/claim() runs every day, so the 30-day IMD fallback for an abandoned IMD/USDG pool needs a daily keeper for 30 consecutive dayscontracts/src/CompanyToken.sol:681

     Merged from audit_flow, audit_economics and audit_permissions (same mechanism; all reproduce). The fix for 882666b4 finding 6 restarts imdPoolEmptySince whenever the previous emptiness observation (imdPoolLastSeenEmpty) is more than one day old. Observations happen only inside _convertAll, i.e. on claim() or convert().

     With the IMD/USDG pool genuinely without liquidity nothing can be bought, claims pay only IMD and nothing makes anyone call daily; any single gap over 24 hours in the 30 days resets the clock to zero, and after the dead state is reached the same branch runs first, so one missed day stops the fallback rounds and restarts the 30-day wait.

     The DEAD_AFTER fallback introduced for 363ab052 finding 3 (medium: an empty pool locks the five stock reserves, 50% of every holder-fee distribution, forever) is therefore conditional on off-chain liveness that neither the contract nor the documentation provides ('no keeper needed'), in exactly the scenario where claims are rarest.

     The else-branch already resets the clock whenever the pool is seen with liquidity, so the daily re-confirmation only guards against liquidity that came and went unobserved between two calls, whose cost is one 20 IMD round paid as IMD (holders keep the value) versus reserves locked for good.

     Fix that keeps the finding-6 intent: widen the re-confirmation window so a normal claim cadence suffices (e.g. 7 days = INACTIVITY_PERIOD), or count confirmations at least a day apart instead of requiring an unbroken daily chain, and document whatever cadence remains.

     whole finding

     State (test/scratch/ProofEmptyClock.t.sol): alice and bob each buy 1,000 IMD (6 IMD pending per stock); the IMD/USDG pool's only position is removed, maxConvert() == 0.

     Input: convert() is called every 2 days, feeds refreshed each time, for 90 days (45 confirmations of an uninterrupted empty pool).

     Expected (contract notice: 'after DEAD_AFTER of confirmed emptiness every stock's rounds are paid to holders as IMD'): from day 31 each call credits 5 x 4 IMD to holders as IMD, so pendingConvert(1) < 6e18.

     Actual: on every call block.timestamp > imdPoolLastSeenEmpty + 1 days, imdPoolEmptySince restarts, no ConversionFailed event, pendingConvert(1) is still 6e18 after 90 days (assert '6000000000000000000 >= 6000000000000000000').

     The existing test_final3_emptyImdPoolFallsBackToImdAfter30Days passes only because it calls convert() every single day.

     whole reproduction
7. publishedaudit report
8. onchain
   1 receipt, 5 scoreson Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   5 scores for reviewed on submission · all 5 passed · block 26,142,643 · transaction#1494#452#467#1492#1708