No report was written.The judge did not finish. The specialists' own reports, if any, are under Work.

1. Posted5 minto the first attempt
2. Audit mathAgent #1637refused

   Refused by Codex's safety filter

   This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. If you’re doing authorized security work that requires more cyber permissive safeguards, apply for Daybreak access via https://platform.openai.com/settings/organization/status-and-access before retrying.

   ran oncodex · gpt-6-astra · 3 turns · 4m 9s

   submissione97142722bc7153ef9d6fbc286ddd80e5b2923d86a95627c98f72fe9cb6f3d7c

   device2fd706f443118bf0ec74d58539102663ef5ba0319f6bd0fbdc6ff01a60e80e81

   started fromd624407521951dcafa6aeb77a372e69226bb07fe

   bundlenone
3. Onchain1 receipton Ethereum mainnet

   receipt

   work accepted · transaction · record

   scores

   written, with no entries recorded on it · block 26,139,978 · transaction

4. Audit permissionsAgent #820refused

   Refused by Codex's safety filter

   This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. If you’re doing authorized security work that requires more cyber permissive safeguards, apply for Daybreak access via https://platform.openai.com/settings/organization/status-and-access before retrying.

   ran oncodex · gpt-6-astra · 5 turns · 7m 48s

   submissionc8dad064d3fe1e4c3db8631bd0d38374601917682b51ba6eaee88047b4540eee

   device2c985fa233fefc9e88c14fca4cbe6142cb51170deea5256c29ae23fd49264741

   started fromd624407521951dcafa6aeb77a372e69226bb07fe

   bundlenone
5. Audit flowAgent #1345found 1 medium, 1 low

   Wrote two findings to .imd-findings.json:

   • Medium: Transfer activity revives already-expired rewards.
   • Low: Low-gas claims can still fail when conversions become due.

   All 41 repository tests and the live fork test passed. The additional gas regression check failed as reported. GME’s live round limit was approximately 3.361 IMD.

   Confirmed decimal scaling, stale-feed handling, zero-limit fallback, and the 97% oracle floor. No additional substantiated defects emerged in solvency, flash-borrow protection, minimum holdings, or scanner-related paths. Contract and configuration files remain unchanged.

   ran oncodex · gpt-6-astra · 7 turns · 14m 58s · 159.2K in · 12.5K out · 2M cached

   submission62fb2cfef0e0f7cc67d73ec2af948356c5652182140acd631ede95fdc703d967

   device1d142f9c9d30c62a2cea1d9e5177d21391a8041bc974dc1f6e3cc971a5876b20

   started fromd624407521951dcafa6aeb77a372e69226bb07fe

   bundlenone

   • mediumTransfer activity revives rewards that have already expiredcontracts/src/CompanyToken.sol:373

     The transfer path refreshes lastActive without settling the expiry calculated from the previous timestamp. Once it does so, expiredRewardsOf returns zero for every asset, and claim no longer reserves the previously expired amount for feeRecipient. This contradicts the strict expiry implemented in claim and lets already-expired rewards become payable to the holder again.

     The same issue applies when the recipient initiates transferFrom. Preserve accrued expiry before changing activity or earning weight, using internal accounting so transfers do not depend on successful external reward-token transfers. This is separate from the documented approximation of recent rewards following a gift.

     Concrete local state: at timestamp 1800000000, one ordinary holder has 100000e18 COMPANY, eligibleSupply is 100000e18, and lastActive equals that timestamp.

     Distributing 2e18 IMD credits 1e18 IMD nominally and reserves 0.2e18 for each stock; withdrawableRewardOf(holder,0) is 999999999999999999 after rounding.

     With no intervening activity or distributions, at timestamp 1800691200 (eight days later), expiredRewardsOf(holder,0) equals that full withdrawable amount.

     For a nonzero transfer with this holder as sender, line 373 changes lastActive to 1800691200 without modifying withdrawnRewards, owed, or the old entitlement.

     Expected: the 999999999999999999 already expired IMD wei remains attributable to feeRecipient.

     Actual: expiredRewardsOf immediately becomes zero under line 512, while the full old amount remains withdrawable.

     A later claim therefore treats it as unexpired.

     The same transition affects each stock with an old unpaid entitlement.

     This finding is substantiated by the source control flow; no new exploit test was executed.

     whole reproduction

   • lowLow-gas claims still fail when conversion becomes due because the gas guard runs after pool and feed readscontracts/src/CompanyToken.sol:598

     The low-gas guard protects the convertStock self-call but is reached only after stockRoundLimit and two oracle reads for each due stock. Those operations are outside the isolated call and consume the gas needed to pay an ordinary claim. Consequently, a claim estimated while stocks are not due can still run out of gas when included after CONVERT_INTERVAL, even though every stock purchase should be skipped.

     This leaves re-check finding 3 partially unresolved. Move the insufficient-gas exit ahead of optional pool/oracle work and retain sufficient gas for expiry accounting and reward payouts. The website's explicit 8000000 gas limit mitigates its own claim flow, but direct callers and integrations using estimation remain affected.

     Using the existing local fixture in contracts/test/scratch/ControlFlowReview.t.sol: timestamp 1800000000, fresh $1 feeds, healthy 1:1 conversion pools, and sequential 1000e18 IMD purchases by Alice and Bob.

     Alice then has 29999999999999999999 IMD wei withdrawable; each stock has 6e18 IMD reserved and lastConvert is 1800000000.

     A call to claim with 145000 gas succeeds at that timestamp.

     Restore the identical pre-claim state and change only the timestamp to 1800000060.

     The same 145000-gas call runs out of gas during the fourth stock's preflight pool/feed work, before payouts, despite its budget being far below the conversion threshold.

     Expected: skip stock processing, pay the existing IMD reward, and preserve all stock reserves.

     Actual: the entire claim reverts.

     Verified with forge test --offline --match-contract ControlFlowReview --match-test test_scanGasBudget -vv; the existing test fails with previously successful gas budget: 145000.

     The verbose trace confirms the successful first claim and OutOfGas in the due-round claim without any convertStock call.

     whole reproduction
6. Audit economicsAgent #544found 1 medium, 2 low, 1 info2 attempts

   #165CodexrefusedRefused by Codex's safety filter

   Refused by Codex's safety filter

   This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. If you’re doing authorized security work that requires more cyber permissive safeguards, apply for Daybreak access via https://platform.openai.com/settings/organization/status-and-access before retrying.

   ran oncodex · gpt-6-astra · 3 turns · 5m 3s

   submission2a43fd4c4c742c1165731da490aeab7eeb995cef8a489f43c39b1bbfd73927ab

   device8d210756eb9ac4d7a88179dbd4f598adddce273a0df43bd8fc7548cc1f6e2eae

   started fromd624407521951dcafa6aeb77a372e69226bb07fe

   bundlenone

   #544Claudefound 1 medium, 2 low, 1 info

   The review is complete. The findings file is at the repository root, no tracked file was changed, and the only untracked content is my scratch tests under contracts/test/scratch/.

   Outcome. The four changes since the re-check do what the request says, and none of the guarantees broke. I found one medium and two low defects, all in the same place: the new "hold" paths in _convertAll have no bound and no fallback in a contract with no admin.

   Confirmed, with evidence

   • Oracle check and decimals: live reads on Robinhood Chain show USDG at 6 decimals, the five stocks at 18, all six feeds at 8 decimals and under 21 hours old. The minStockOut formula is dimensionally right. The fork test bought all five stocks and GME cleared the 97% floor with about 1.1% to spare.
   • GME: the live round limit reads 3.36 IMD and the token symbol and feed description match.
   • Zero stockRoundLimit pays the round as IMD; too little gas skips instead of reverting. Both hold in the existing tests and in my extended fuzz.
   • Solvency of all six assets, eligible supply equal to the sum of weights, and withdrawable within owed held across 256 fuzz runs that mix trades, claims, expiry, stale and off-oracle feeds, zero liquidity, a blocked stock, low-gas claims and spot pushes. The flash-borrow guard and the 100,000 minimum are unchanged by this round.

   Findings

   • Medium: a feed that stops updating permanently (feed deprecation) freezes that stock's 10% of every future holder fee forever. The USDG feed would freeze 50%. The IMD is tracked, so it is never redistributed, and no call can release it. Proof test fails on current code and asserts only the bounded-hold property.
   • Low: PriceOff is also an unbounded hold. On a 1%-fee pool at the live GME scale, one buy of 8 USDG (attacker's loss about 0.25 USDG) kept the GME reserve untouched through 336 claims over a week. Fee, price impact and feed deviation already use about 2% of the 3% tolerance on such a pool.
   • Low: zero active liquidity in the IMD/USDG pool holds all five stock shares, while the same condition on a stock pool falls back to IMD.
   • Info: stock and USDG decimals are immutable snapshots while the stock tokens share an upgradeable beacon. Live values are correct today.

   The common fix is to bound the holds: after a long staleness or a run of skipped rounds, credit the round as IMD the way the zero-liquidity path already does. That keeps the short-term oracle protection the re-check asked for.

   ran onclaude · claude-fable-5-1 · 42 turns · 24m 1s · 578 in · 66.1K out · 2.8M cached

   submission6de467627eab71877c03e74080e0c7e8f38d27a53509b70c0d41d26bdef66fde

   device56b13350bba65fd7364389b27d67466554527325042c06b1f0b0d55d090d9407

   started fromd624407521951dcafa6aeb77a372e69226bb07fe

   bundlenone

   • mediumA Chainlink feed that stops updating for good freezes that stock's share of every holder fee forever: the stale-feed hold has no bound, no fallback and no admincontracts/src/CompanyToken.sol:598

     _convertAll() holds a stock while its /USD feed (or the shared USDG/USD feed) is older than MAX_ORACLE_AGE: the loop continues, lastConvert is untouched, pendingConvert keeps growing with every flush, and nothing is ever credited to holders, not as stock and not as IMD.

     That is the right response to a weekend or a holiday, but the hold is unbounded, the feed addresses are fixed at deployment (priceFeeds[], usdFeed are never written again), the token has no owner, and no function can release a reserve other than a successful purchase or _fallBackToImd(), which this path never reaches.

     Chainlink feeds are routinely deprecated (the aggregator simply stops posting; latestRoundData keeps returning the last round, so _readFeed() reports stale forever). If that happens to one stock feed, 10% of every holder fee from then on is reserved and locked in the token contract permanently; if it happens to the USDG/USD feed (0x61B7e565...) all five stock shares, 50% of every holder fee, are locked.

     The IMD is counted in distribute()'s tracked so it is never redistributed either. This is a new consequence of the re-check fix: before it, any failed purchase fell back to IMD. By contrast a stock pool with no liquidity (stockRoundLimit == 0) and a stock token that refuses the contract both fall back at once, so the system already accepts 'pay the round as IMD' as the response to a stock that cannot be bought.

     Suggested minimal fix that keeps the design: bound the hold. For example, record when a feed was last seen fresh (or count consecutive held rounds) and, once a feed has been stale for longer than a window no market closure can reach (e.g. 30 days), treat the round like the zero-liquidity case and credit imdIn to holders as IMD without swapping, one capped round at a time. Short staleness (weekends, holidays, the 4-day window) keeps holding exactly as now.

     whole finding

     State: alice and bob each buy 1,000 IMD through CompanyRouter, so 6 IMD is reserved per stock.

     The NVDA feed (priceFeeds[1]) posts one more round and then never updates again; every other feed keeps a fresh updatedAt.

     Warp 5 days (feed older than MAX_ORACLE_AGE = 4 days).

     Then for 90 days: each day bob buys 1,000 IMD (3 IMD more reserved for NVDA), alice claims, bob claims; at the end call convert() directly.

     Expected (what a bounded hold would give): NVDA's reserve is released at some point over three months, either as NVDA once the feed recovers or as IMD when it does not, so pendingConvert(1) < 6e18 + 90*3e18.

     Actual: pendingConvert(1) == 276e18 exactly (every wei reserved since the hold began), totalDistributed(1) == 0, lastConvert(1) unchanged, and the 276 IMD cannot be moved by any call; GOOGL/AAPL/GME/MSTR kept converting every day.

     Observed in test/scratch/DeadFeed.t.sol: 276000000000000000000 >= 276000000000000000000.

     whole reproduction

   • lowThe PriceOff skip is unbounded: one small buy that lifts a thin stock pool's spot about 2% over Chainlink withholds that stock's share for as long as the nudge lasts, at a cost of centscontracts/src/CompanyToken.sol:606

     On PriceOff the stock is skipped with no fallback and no counter, so the hold lasts exactly as long as the pool's spot stays above the oracle by more than the tolerance leaves. For a 1%-fee pool like the live GME/USDG pool the 3% tolerance is mostly consumed by honest costs: 1% pool fee + about 0.5% price impact of a round sized at half the fee times depth + the feed's 0.5% deviation threshold, leaving about 1% for spot drift.

     A thin 1%-fee pool naturally sits anywhere inside its +/-1% arbitrage band, so GME rounds will fail the check in normal operation some of the time, and an attacker can make it fail every time: buying about 1% of the pool's virtual USDG depth moves spot about 2.4% and the round then receives about 96.5% of fair, below the 97% floor.

     At the live pool's scale (stockRoundLimit about 3.4 IMD, so virtual depth about 3,000 USDG on the USDG side) that is a buy of roughly 8-40 USDG and the attacker's only loss is the fee plus the premium on what they bought (about 3% of the buy, i.e. 0.25-1 USDG), which they can also recover later by selling back into a recovered spot.

     Arbitrageurs only sell GME into the pool once spot exceeds fair by more than the 1% fee, so they bring it back to about +1%, where the check passes with about 0.5% margin, and the attacker simply nudges again (cost per nudge is the same cents).

     Who loses: current holders, whose 10% GME share is neither bought nor paid as IMD while the hold lasts; when it finally converts it is credited to whoever holds at that time (accepted finding 6), so earners who leave in the meantime lose it. The attacker gains nothing directly, so this is griefing, not extraction; it is reported because the request asked whether a caller can force PriceOff, and the answer is yes, cheaply, with an unbounded effect.

     Fix options that keep the oracle guard: bound the hold (after N consecutive PriceOff rounds, or after the reserve has waited longer than X, credit that round as IMD as the zero-liquidity path does); and/or size the tolerance per pool (fee + expected impact + feed deviation + a drift margin) so a 1% pool is not already at 2% of its 3% budget at fair price.

     whole finding

     State (test/scratch/Probe.t.sol, test_probe_priceOffHoldCost): mock GME/USDG pool with fee 1% and spacing 200 like the live pool, liquidity thinned so stockRoundLimit(4) = 3.43 IMD (live reading on the fork: 3.36 IMD); all feeds at $1 and fresh; alice and bob hold.

     A fair-priced round first converts normally (3.318 GME for 3.4 IMD, 97.6% of fair).

     Attacker then buys GME with 8 USDG (about 1.2% of virtual depth): spends 8 USDG, receives 7.753 GME, mark-to-oracle loss 0.247 USDG.

     Then 336 claims (one every hour for 7 days, feeds refreshed each hour).

     Expected: GME's reserve is bought once the price is fair or, failing that, handed to holders as IMD like any other purchase that cannot complete.

     Actual: pendingConvert(4) is 2.5919 IMD before and after the week, lastConvert(4) is untouched (1800000060 while now is 1800604860), no GME bought, no IMD credited, while NVDA/GOOGL/AAPL/MSTR drained their reserves to zero.

     whole reproduction

   • lowNo active liquidity at the IMD/USDG pool's current tick holds all five stock shares with no fallback, unlike a zero stockRoundLimit which pays the round as IMDcontracts/src/CompanyToken.sol:588

     maxConvert() returns 0 when the IMD/USDG pool has no liquidity at its current tick (getLiquidity(id) == 0), so cap == 0, every stock's imdIn is clamped to 0 and the loop continues before the zero-limit fallback at line 592 can run. The re-check finding 2 fix made the equivalent condition on the stock hop (stockRoundLimit == 0) credit the round as IMD without a swap; the first hop was left as an unbounded hold.

     The IMD/USDG pool belongs to third-party LPs (it is fixed at deployment and hookless), and its active liquidity reaches zero whenever concentrated positions go out of range after a large IMD move (IMD was $9.80 in the deploy note of 2026-10-07 and about $4.45 on the fork at block 82415782 of the same week) or when LPs leave.

     While it is zero, 50% of every holder fee accumulates in pendingConvert with nothing credited, for as long as the state lasts, and nobody connected to the protocol can change it. Not swapping is correct (a swap would cross to whatever position sits next, the concern of re-check finding 2); holding instead of paying as IMD is the gap.

     Fix: treat maxConvert() == 0 like stockRoundLimit == 0, i.e. hand each due stock min(pendingConvert, MAX_ROUND_IMD/5) to holders as IMD without a swap, or apply the same bounded hold as the stale-feed case.

     whole finding

     State (test/scratch/Probe.t.sol, test_probe_imdUsdNoActiveLiquidity_holdsAllStocks): alice and bob buy 1,000 IMD each (6 IMD reserved per stock); the IMD/USDG mock pool's only position (10,000 liquidity, full range) is removed so maxConvert() == 0; feeds fresh.

     Call convert() once a day for 30 days.

     Expected: as with a stock pool that has no liquidity, the rounds are credited to holders as IMD one capped round at a time (pendingConvert falls, owed(0) rises).

     Actual: pendingConvert(s) == 6e18 for all five stocks after 30 days, lastConvert(s) still the deployment timestamp, owed(0) unchanged.

     Contrast in the same test: restoring the IMD/USDG liquidity and removing the NVDA pool's instead makes the next round fall back at once (pendingConvert(1) 6e18 -> 2e18 as IMD).

     whole reproduction

   • infoStock and USDG decimals for minStockOut are read once at deployment, while the stock tokens are upgradeable beacon proxies; live values verified (USDG 6, stocks 18, feeds 8)contracts/src/CompanyToken.sol:266

     Verified on Robinhood Chain at block 82415782: USDG (0x5fc5...1d168) decimals 6; NVDA, GOOGL, AAPL, GME (0x1b0E...153E, symbol GME) and MSTR decimals 18; all six feeds decimals 8 with descriptions 'USDG / USD', 'RHNVDA / USD', 'Robinhood GOOGL / USD', 'Robinhood AAPL / USD', 'Robinhood GME / USD', 'Robinhood MSTR / USD', all updated within the last 21 hours. minStockOut's formula fair = usdIn * usdgUsd * 10^stockDec / (stockUsd * 10^usdDec) is dimensionally right, and the fork claim passed the 97% floor on every stock (GME received about 98.1% of what the feeds imply).

     The only caveat: _unit[] and _usdUnit are immutable snapshots. The five stock tokens share one Robinhood beacon, so an upgrade that changed decimals() would silently shift minStockOut by 10^k: every round would then either revert PriceOff forever (hold, see the medium finding) or pass at any price. This is a trust assumption on the token issuer rather than a defect, recorded here because the request asked whether reading decimals at deployment is right.

     Reading decimals() in minStockOut instead costs one staticcall per round.

     whole finding

     Not a failing state today: cast call 'decimals()' on each of the six tokens returns 6/18/18/18/18/18 and the fork test converts all five stocks. The failing state would be a beacon upgrade that changes a stock's decimals from 18 to e.g. 6: minStockOut would demand 10^12 times more stock than the pool can return, so every round reverts PriceOff and the stock is held with no bound.

7. Audit judge

   waits onAudit math, Audit permissions, Audit economics, Audit flow
8. Published