Failed on the agent's machine.

• lowSimdAirdrop: a remainder below TOTAL_WEIGHT strands every token in the airdrop forever (no claim, no burn)src/SimdAirdrop.sol:54

  bind() is the only function that sets token and claimEnd and it requires the airdrop to already hold at least TOTAL_WEIGHT (633,028,988.0235e18 raw units) of the launched token (line 54). claim() (line 67) and burnUnclaimed() (line 80) both revert NotBound while token == address(0).

  The factory sends the launch remainder exactly once at launch time (LaunchFactory: if (remainder > 0) IERC20(token).safeTransfer(params.remainderTo ...)), so if that remainder is even one unit short, or remainderTo names another address, the tokens already in the airdrop have no exit at any time, including after the 30-day window the brief describes.

  SIMDVault.bindLaunch swallows the failed bind in try/catch (src/SIMDVault.sol:79-83) and bindAirdrop() keeps reverting InsufficientRemainder, so the vault, staking and jobs run while the remainder is stuck. The >= TOTAL_WEIGHT precondition is what the brief asks for; the defect is that the shortfall case is unrecoverable. Merged from audit_economics.

  Fix needs a scope decision: let burnUnclaimed() run while unbound after a fixed deadline, or let bind() accept any nonzero balance and keep TOTAL_WEIGHT only as the pro-rata denominator.

  whole finding

  Offline with the project's mocks (test/helpers/VaultTestBase): launchedToken.mint(address(drop), drop.TOTAL_WEIGHT() - 1); vm.prank(DEV); vault.bindLaunch(NUMBER, token).

  Expected: the airdrop's tokens can eventually be claimed or burned.

  Actual: vault.token() == token, drop.token() == address(0); vault.bindAirdrop() reverts SimdAirdrop.InsufficientRemainder; after vm.warp(+3650 days) drop.burnUnclaimed() reverts NotBound and drop.claim(1, []) reverts NotBound; launchedToken.balanceOf(drop) is still TOTAL_WEIGHT - 1 with no function able to move it.

  Reproduced in test/scratch/Judge.scratch.t.sol::test_F1_airdropShortRemainderStrandedForever (passes, i.e. the lock is real).

  whole reproduction

• lowSIMDVault: the one launch flag is consumed by the on-chain payment, so IMD and ETH held before a successful bindLaunch have no exit if the launch is never boundsrc/SIMDVault.sol:65

  launch() sets launched = true before the Intake call (line 65) and the Intake forwards the price to the treasury in the same call with no refund or callback. If the plane later refuses or fails the launch body, or the dev wallet never binds, no factory position will ever name the vault as requester, so bindLaunch() always reverts LaunchPool.WrongRequester and distribute() always reverts NotBound (line 94).

  Every IMD unit in the vault beyond the exact price (overfunding, a price decrease, direct transfers) and any ETH accepted by receive() is then permanently stuck: the vault has no other transfer path by design, and launch() cannot be retried (AlreadyLaunched). The only recovery is an outside launch whose requester is handed to the vault with LaunchFactory.setRequester.

  This is the brief's 'only once' rule, so it is the requested behaviour; it is reported because the loss path is permanent and the dev must validate the body off-chain before paying. Merged from audit_economics (pre-bind funds stuck) and audit_permissions (launch flag consumed by an accepted payment). Fix needs a scope decision: tie launched to a successful bindLaunch with a deadline, or let distribute() split IMD before binding (skipping claimFees and the burn).

  whole finding

  Offline with the project's mocks: imd.mint(address(vault), PRICE + 1 ether); vm.deal(address(vault), 1 ether); vm.prank(DEV); vault.launch('{}') succeeds and the Intake takes PRICE, launched() == true.

  Expected: the remaining 1 IMD and 1 ETH can eventually be distributed or the launch retried.

  Actual: vault.distribute() reverts NotBound; vm.prank(DEV); vault.bindLaunch(9999, token) reverts LaunchPool.WrongRequester because no position names the vault; vm.prank(DEV); vault.launch('{}') reverts AlreadyLaunched; imd.balanceOf(vault) stays 1 ether and address(vault).balance stays 1 ether with no function able to move either.

  Reproduced in test/scratch/Judge.scratch.t.sol::test_F2_prebindFundsStuckAfterLaunchFlagConsumed.

  whole reproduction

• lowJobsVault.setToken makes bindLaunch depend on the launched token's optional decimals(); a token without it can never be bound and every claimed fee is stuck in the vaultsrc/JobsVault.sol:44

  SIMDVault.bindLaunch (src/SIMDVault.sol:76-77) calls stakeRewards.setToken and jobsVault.setToken outside any try/catch, and JobsVault.setToken makes an unguarded call to decimals() (line 44), an optional ERC-20 function that LaunchPool.tokenOf (src/libraries/LaunchPool.sol:16) does not check (it only requires code). The live factory deploys whatever tokenCreationCode the plane supplies, so a launched token without decimals() is representable.

  For such a token every bindLaunch attempt reverts, token stays address(0), distribute() reverts NotBound forever, and because the vault is the position's requester, every IMD fee that factory.claimFees pays it (anyone can trigger that) is stuck with no exit. StakeRewards.setToken and SimdAirdrop.bind accept any token with code; JobsVault.setToken silently adds a stricter requirement.

  Reading decimals in setToken is what the brief asks for ('times 10^decimals, set in setToken'), so this is a trust assumption on the plane's LaunchToken being ERC20Metadata. Merged from audit_permissions. Minimal fix preserving the design: read decimals() with a try/catch and fall back to 18, or let bindLaunch tolerate a failed JobsVault.setToken the way it tolerates a failed airdrop bind.

  whole finding

  State: factory.positionOf(N) = (currency0 = IMD, currency1 = T, requester = vault) where T is an ERC-20 with code but no decimals() selector.

  Call vault.bindLaunch(N, T) from DEV.

  Expected (spec): bind succeeds and StakeRewards and JobsVault get the token.

  Actual: the call reverts inside JobsVault.setToken (decimals() reverts), vault.token() stays address(0).

  Then mint 100 IMD to the vault (as factory.claimFees would) and call vault.distribute(): reverts NotBound, IMD permanently stuck.

  Reproduced in test/scratch/Judge.scratch.t.sol::test_F3_tokenWithoutDecimalsBlocksBindAndStrandsFees with a minimal ERC-20 lacking decimals().

  whole reproduction

• lowSIMDVault.bindLaunch accepts a launch number the airdrop can never bind (<= 3187), fixing the vault to that launch for good while the remainder is strandedsrc/SIMDVault.sol:73

  bindLaunch validates requester, pair, code and non-IMD token (line 73) but not the airdrop's own precondition number > MIN_LAUNCH_EXCLUSIVE (src/SimdAirdrop.sol:51 if (number <= MIN_LAUNCH_EXCLUSIVE) revert OldLaunch();). The airdrop bind runs inside try/catch, so a launch numbered <= 3187 whose requester is the vault binds the vault, StakeRewards and JobsVault for good while SimdAirdrop.bind reverts OldLaunch on every later bindAirdrop() retry.

  Because burnUnclaimed() and claim() both require a bound airdrop, any launched token already held by the airdrop has no exit, and the one-time vault binding cannot be redone (AlreadyBound). Reachable only through the dev wallet (an old launch's requester would have to hand the position to the vault with the factory's setRequester), and the token is a valueless test token, so impact is low; the failure is permanent and signalled only by AirdropBindAttempt(false).

  Merged from audit_flow.

  Fix: check number > airdrop.MIN_LAUNCH_EXCLUSIVE() in bindLaunch up front so the dev can bind the right launch.

  whole finding

  State: factory.positionOf(3187) returns a pool pairing IMD with token T and requester == vault; SimdAirdrop holds >= TOTAL_WEIGHT of T.

  (1) DEV calls vault.bindLaunch(3187, T): succeeds, vault.token() == T, event AirdropBindAttempt(false), drop.token() == address(0).

  (2) anyone calls vault.bindAirdrop(): reverts SimdAirdrop.OldLaunch.

  (3) after 31 days drop.burnUnclaimed(): reverts SimdAirdrop.NotBound.

  (4) DEV calls vault.bindLaunch(3200, T): reverts AlreadyBound.

  (5) vault.distribute() still runs, bound to the old launch.

  Expected: bindLaunch rejects number <= 3187 up front, or the remainder has a recovery path.

  Reproduced in test/scratch/Judge.scratch.t.sol::test_F4_oldLaunchNumberBindsVaultButNeverAirdrop.

  whole reproduction

• infoStakeRewards: carried IMD (zero-staker time and rate remainder) is released only by a later nonzero deposit; if fee income stops, up to a full week's share stays reserved but unreachablesrc/StakeRewards.sol:95

  notifyDeposit follows the specified algorithm: when the vault has nothing new (received == 0, line 95) it returns before restarting the stream, so carryScaled, which already holds every scaled unit streamed while totalStaked was 0 plus the rate-division remainder, is never paid to stakers until a later deposit with received > 0 arrives.

  The first distribute() is permissionless and allowed immediately after bindLaunch, typically before anyone has staked, so the entire first 40% share is carried. The IMD is counted in reserved (balance >= reserved holds) but no staker can claim it. Any party can release it by transferring >= 1 wei IMD to StakeRewards before the next distribute().

  This matches the brief's 'if 0 return', so it is a design consequence, not a code deviation. Merged from audit_permissions.

  After bindLaunch: mint 1000 IMD to the vault, call distribute() with nobody staked (StakeRewards receives 400 IMD, carried over the week).

  Warp 7 days, alice stakes 1 token, warp 7 days, call distribute() with the vault at 0 IMD, warp 7 days, alice.claim().

  Expected by a staker: some of the 400 IMD.

  Actual: alice receives 0, rewards.reserved() == 400e18, rewards.carryScaled() == 400e18 * 1e36.

  Then mint 1 wei IMD to StakeRewards and call distribute() again: after 7 days alice claims > 399 IMD.

  Reproduced in test/scratch/Judge.scratch.t.sol::test_F5_carryReleasedOnlyByNonZeroDeposit.

  whole reproduction

• infoStakeRewards: per-token and per-account floor dust stays in `reserved` forever and is never re-streamed (unlike rate-division dust)src/StakeRewards.sol:138

  The specified algorithm carries only the rate-division remainder (total % DURATION) into carryScaled. Two other floors are not carried: streamed / totalStaked in _update (line 138) and Math.mulDiv(stakeOf, delta, SCALE) in earned (line 89). What those floors drop stays counted in reserved (reserved only decreases by paid claims), so it is never claimable and never re-streamed, and there is no other exit for IMD.

  Magnitude is bounded by totalStaked / 1e36 raw IMD per update plus < 1 raw unit per account update: wei-level dust for realistic stakes. It only becomes the whole deposit when received * 1e36 < totalStaked, which is unreachable with real amounts. The algorithm is exactly the one the brief specifies.

  Merged from audit_math.

  Mock IMD at the fixed address, StakeRewards with token set. alice stakes 1e18, bob stakes 1e18 (totalStaked = 2e18).

  Mint 1 raw IMD to StakeRewards, vault calls notifyDeposit(): rewardRate = 1e36/604800, carryScaled = 1e36 % 604800 = 92800.

  Warp 7 days, both claim: rewardPerTokenStored = (1e36 - 92800)/2e18 floored, earned(each) = 0, both receive 0, reserved stays 1.

  Then mint 604800e18 and notifyDeposit() again, warp 7 days, both claim: 604800e18 paid in total and reserved is still 1 (exact arithmetic: 604800e18 + 1 paid, reserved 0).

  Reproduced in test/scratch/Judge.scratch.t.sol::test_F6_floorDustStrandedInReserved.

  whole reproduction

• infoJobsVault: the 25.72% budget is permanently locked if the Intake stops selling job.open@job-1 (trust assumption; no withdraw by design)src/libraries/IntakePayment.sol:17

  requestJob() is the only path that moves IMD out of JobsVault, and it spends through IntakePayment.request, which reverts ActionNotSold when priceOf(action, IMD) returns 0 (line 17) and reverts when Intake.request itself rejects. The Intake is an external, IMD-operated contract; if it retires the action, changes the asset or pauses, every requestJob reverts and the jobs budget (25.72% of every weekly distribution, accumulated forever) is stuck with no admin, sweep or fallback.

  This is the brief's explicit design ('No withdraw'), recorded as a dependency trust assumption. The same single Intake price also bounds how fast a Sybil of 1,000,000-token wallets can spend the budget (one job of priceOf per wallet per 24 h), which the brief accepts. Merged from audit_economics.

  State: JobsVault holds 100 IMD; alice has 1,000,000e18 staked; mock Intake configured with price 0 (intake.configure(0, false, false)). vm.prank(alice); jobs.requestJob('{}').

  Expected per the brief: a job is paid.

  Actual: revert IntakePayment.ActionNotSold; imd.balanceOf(jobs) stays 100 IMD and no function on JobsVault can move it.

  Reproduced in test/scratch/Judge.scratch.t.sol::test_F7_jobsBudgetLockedWhenActionNotSold.

• infoSimdAirdrop: the pro-rata payout divides by the constant TOTAL_WEIGHT, which the contract cannot check against the committed list; a leaf sum above it makes late claimants failsrc/SimdAirdrop.sol:63

  amountOf divides by the constant TOTAL_WEIGHT (line 63), not by the actual sum of the leaves under MERKLE_ROOT. The 457 wallet/weight records are not in this tree (test/README.md says so), so neither the tests nor this review can check that the leaves sum to exactly 633028988023500000000000000 or that no address appears twice (claimed[] is per address, so a duplicated address could claim only one of its leaves).

  If the real sum exceeds TOTAL_WEIGHT, the sum of amountOf over all leaves exceeds startBalance and the last claimants' safeTransfer reverts ERC20InsufficientBalance; if it is below, the difference is burned at claimEnd. A Merkle commitment cannot enforce this on chain; it is a precondition the list publisher must prove before claims open. Merged from audit_economics.

  With a synthetic root (the production list cannot be exercised without the records): leaves (alice, TOTAL_WEIGHT) and (bob, 1e18); fund the airdrop with exactly TOTAL_WEIGHT and bind. alice.claim(TOTAL_WEIGHT, proof) transfers the whole startBalance. bob.claim(1e18, proof) with a valid proof: expected a share, actual revert ERC20InsufficientBalance (balance 0 < amountOf(1e18) = 1e18).

  Arithmetic: amountOf(w) = startBalance * w / TOTAL_WEIGHT, so sum over leaves = startBalance * sum(w) / TOTAL_WEIGHT > startBalance whenever sum(w) > TOTAL_WEIGHT.

  The real list's sum is the unverified input.

  whole reproduction