{"assessments":[],"deployments":[],"fuzz":[],"identity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"interpretation":"Records acceptance and evidence. Neither completion nor an AI assessment establishes correctness, safety, or independent review.","jobId":"9755203f-4263-447d-b876-007724cd321b","kind":"audit","nodes":[{"acceptedSubmissionHash":"90587ad88bb169acb3a2f7fb49e620197eaea816db23c168424a1a46c3d4e570","dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","tools":[]},"key":"audit_economics","kind":"code","role":"review","skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","state":"accepted"},{"acceptedSubmissionHash":"7b4ebafb16a95daf5a1cb31cdcec92a10ceca8fbdcce9000f864f64b0ebb4009","dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","tools":[]},"key":"audit_flow","kind":"code","role":"review","skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","state":"accepted"},{"acceptedSubmissionHash":"a289264e76180c4657d1b1752c9231a4533127cd46c3abaf1445bb8d52355015","dependsOn":["audit_math","audit_permissions","audit_economics","audit_flow"],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"af3aa01159bbf354f621cafa5c0006f6169e0938a8b015be508b7377dbf165bc","skillId":"audit-judge","tools":[]},"key":"audit_judge","kind":"code","role":"review","skillHash":"af3aa01159bbf354f621cafa5c0006f6169e0938a8b015be508b7377dbf165bc","skillId":"audit-judge","state":"accepted"},{"acceptedSubmissionHash":"6c18f1e1b645565b7e6592f1a1b1c91f54b9f08abb974fea6b57f92b3ce03f34","dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","tools":[]},"key":"audit_math","kind":"code","role":"review","skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","state":"accepted"},{"acceptedSubmissionHash":"d80608422b18fb90f7b090b50b32b61b47f649f920243b85385ed3a6719ad9bd","dependsOn":[],"execution":{"network":false,"profile":"foundry","requires":[],"skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","tools":[]},"key":"audit_permissions","kind":"code","role":"review","skillHash":"e5ac2cb1fd91a56aa40b16487fc230c48de0d317c8266140331dd3219bb40a85","skillId":"audit-specialist","state":"accepted"}],"objective":"TokenDrops: the treasure hunt for Courier World on Robinhood Chain (4663). The treasury (owner) funds drops of a launchpad token (CourierPad 0x90c3aaae34cf4681701452379D3819D6Bc8Fe8CC) or $STAMP: tokens per coin, coins out per day, a per-wallet daily cap, a daily cap across everyone, and a number of days. Players with an open post office (PostOffice 0x26D80804D0FA2F4598369E0062bFC9536d115D82) claim coins they found, for that day or the next, with EIP-712 vouchers Finds(player, drop, day, coins, deadline) signed by the game server’s key; claimMany pays several drops at once. Owner: topUp, endDrop (after today), withdraw (once claims have closed, or while paused), setSigner, setPaused; no renounce.\n\nPlease check: that no drop can pay more than its own tokens or its caps allow, that drops’ tokens never mix, voucher replay across drops, days and wallets, the claim windows and day edges, re-entry, the owner’s powers, and the withdraw rules.\n\nSource: contracts/src/TokenDrops.sol; tests in contracts/test/TokenDrops.t.sol. Commit 30ade10.","parentJobId":null,"planHash":"4dc7993798460032e573cd4039591b9d69da0aeaa1fc076dbc38c7222a10ded2","previousHash":"0000000000000000000000000000000000000000000000000000000000000000","projectId":"9755203f-4263-447d-b876-007724cd321b","publication":{"commit":null,"deliveredAt":null,"repoUrl":null},"receiptIdentity":{"adapter":"0xde152afb7db5373f34876e1499fbd893a82dd336","chainId":1,"collection":"0x0000ec93127baa929e58e97dd0095a2bfb38ec1d","registry":"0x8004a169fb4a3325136eb29fa0ceb6d2e539a432"},"registry":"0xb6d0a187b050fa5bb0b87033a203f37becf4a775","research":[],"schema":"identitymd-work-v1","signals":[{"agentId":"52606","feedbackHash":"9fd7efccd0880fa06cbf90fa727dab43c82697619400597a9a618c54db69942e","nodeKey":"audit_economics","submissionHash":"90587ad88bb169acb3a2f7fb49e620197eaea816db23c168424a1a46c3d4e570","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"51315","feedbackHash":"aa4b147507e3c743340b19809083692758d765a626f426e0eda86dc7aca08232","nodeKey":"audit_flow","submissionHash":"7b4ebafb16a95daf5a1cb31cdcec92a10ceca8fbdcce9000f864f64b0ebb4009","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52680","feedbackHash":"6ecf618314ef1719e08adf513108ca9befa0cb1df5acbd471d650b43685f42f9","nodeKey":"audit_judge","submissionHash":"a289264e76180c4657d1b1752c9231a4533127cd46c3abaf1445bb8d52355015","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52603","feedbackHash":"f7f164a019df069abf5e3712398ddb1e573d78c966ebb16b11627ca7e9d0de7d","nodeKey":"audit_math","submissionHash":"6c18f1e1b645565b7e6592f1a1b1c91f54b9f08abb974fea6b57f92b3ce03f34","tag1":"review:submission","tag2":"acceptance-v2","value":1},{"agentId":"52255","feedbackHash":"132cf88bc11c40ebcd9355e55b48d196ab59cb388fe8e6892b2646d83482c23b","nodeKey":"audit_permissions","submissionHash":"d80608422b18fb90f7b090b50b32b61b47f649f920243b85385ed3a6719ad9bd","tag1":"review:submission","tag2":"acceptance-v2","value":1}],"site":null,"snapshotHash":"50c03a639f5645442fefe8cf8cdc03f5179ca5a86c408acaf802304de5d48e08","state":"completed","submissions":[{"artifacts":[],"attempt":1,"bundleHash":null,"device":"7e64d4917fa814e6","findings":[{"citation":"resolved","description":"The brief lists four limits per drop: tokens per coin, coins out per day (spots, 24 golden stamps for $STAMP), a per-wallet daily cap (maxPerWallet) and a daily cap across everyone (dailyCoins). Only the last two are applied in claimable(). `spots` is validated at createDrop (1..MAX_SPOTS, maxPerWallet <= spots) and stored, but claimable() never reads it: the day's payout is bounded by `dailyCoins` only when it is non-zero, and the documented default (0, 'only the pool limits it') leaves the per-day bound at N wallets x maxPerWallet. Since the game only lays out `spots` coins a day, any day that pays more than `spots` coins is by definition paying for coins that do not exist; the contract relies entirely on the server key for that bound. If the key leaks (the scenario setPaused is written for) or the server double-counts, an attacker with a few post offices drains an entire drop in a single day, before the owner can pause, instead of being held to spots x perCoin per day. Math/boundary seam: the invariant 'paidCoins[id][day] <= spots' holds in the game model but is unenforced on chain, and the zero-input fast path (dailyCoins == 0) skips the only daily check. Expected: a day never pays more than spots coins (24 for a $STAMP drop). Actual: 50 coins paid on a day with 10 out; 72 golden stamps paid on a day with 24 out. Fix (a defence-in-depth addition that keeps the agreed design): in claimable(), when `d.dailyCoins == 0` use `d.spots` as the day's cap (`dayCap = d.dailyCoins == 0 ? d.spots : d.dailyCoins`), or at createDrop require `dailyCoins != 0 && dailyCoins <= spots`. Either changes the meaning of dailyCoins = 0, so it needs a scope decision by the owner; if 'no daily limit' is wanted on purpose, document that spots is informational and that the signer key is the only per-day bound.","line":169,"path":"contracts/src/TokenDrops.sol","reproduction":"createDrop(coin, perCoin = 1000e18, spots = 10, maxPerWallet = 10, dailyCoins = 0, startDay = today, days = 7, amount = 1_000_000e18). Five wallets with open post offices each present a voucher Finds(wallet, id, today, 10, deadline) and call claim(). Expected: at most 10 coins (10_000e18 tokens) paid for today. Actual: paidCoins(id, today) == 50 and 50_000e18 tokens leave the drop; drop(id).spots == 10. $STAMP variant: createDrop(stamp, 10e18, 24, 24, 0, today, 7, 100_000e18); three wallets claim 24 each: paidCoins == 72 against GOLDEN_SPOTS == 24. Scratch tests test_SpotsDoNotBoundADaysPayout and test_GoldenStampsDoNotBoundPayout in test/scratch/TokenDropsAudit.t.sol show exactly this and pass on the current code.","severity":"low","snippet":" if (d.dailyCoins != 0) {\n uint256 dayLeft = d.dailyCoins > paidCoins[id][day] ? d.dailyCoins - paidCoins[id][day] : 0;\n if (dayLeft < room) room = dayLeft;\n }","title":"spots (coins out per day) never bounds a day's payout; with dailyCoins = 0 a drop can pay many times the coins that exist in one day"},{"citation":"resolved","description":"The docstring on claimMany says 'any that would pay nothing are skipped', and the Claimed-nothing case (claimable() returns 0) is indeed skipped. But every other reason an entry pays nothing reverts inside _claim() and aborts the whole call: Expired (line 212), FutureDay (214), TooLate (215), NotRunning (217), BadSignature (219), UnknownDrop (211). The realistic trigger is the day edge: the game lets a day's finds be claimed that day and the next, so a player naturally batches yesterday's and today's vouchers. A batch assembled in the last seconds of day D+1 and mined after 00:00:00 UTC of D+2 has its D voucher fail TooLate and the D+1 entries, which are still perfectly valid, are not paid either. The player has to notice, drop the stale entry and resubmit; a front end that retries the same calldata keeps failing. No funds are at risk, but the behaviour contradicts the documented contract and makes the two-day window fragile around midnight for exactly the batched case claimMany exists for. Fix: in claimMany, evaluate the time-window checks (deadline, FutureDay, TooLate, NotRunning) per entry and `continue` instead of reverting, keeping the revert for BadSignature/UnknownDrop if preferred; or change the docstring to state that any invalid entry reverts the batch.","line":196,"path":"contracts/src/TokenDrops.sol","reproduction":"Drop id = createDrop(coin, 1000e18, 10, 10, 0, D, 7, 1_000_000e18). Warp to (D+2)*86400 - 1 (last second of day D+1). Alice (open office) holds vouchers Finds(alice, id, D+1, 3, deadline) and Finds(alice, id, D, 2, deadline) with deadline = now + 1h, both validly signed. The transaction claimMany([{id, D+1, 3}, {id, D, 2}]) is mined one second later at (D+2)*86400. Expected per the docstring: entry 0 pays 3000e18, entry 1 is skipped. Actual: the call reverts with TooLate() and nothing is paid; the same entry 0 submitted alone via claim() then pays 3000e18. Scratch test test_ClaimManyRevertsWholeBatchAtDayEdge in test/scratch/TokenDropsAudit.t.sol demonstrates it.","severity":"low","snippet":" total += _claim(c.drop, c.day, c.coins, c.deadline, c.signature);","title":"claimMany is atomic: one entry that reverts (TooLate at the day edge, Expired, NotRunning, BadSignature) loses the whole batch, contrary to its doc that non-paying entries are skipped"},{"citation":"resolved","description":"claimable() is the public quote the front end (and the project's fuzz test) uses to decide whether a claim is worth sending. It applies the per-wallet cap, the pool and the daily cap, but not startDay/endDay, FutureDay, TooLate or paused, which _claim() enforces at lines 212-217 and _checkClaimer() at 202. The view therefore returns a non-zero (n, amount) for a day the drop was not running, for a future day, for a day whose two-day window has closed, and while paused. Within _claim() this is harmless because the window checks run first; the gap is only in what integrators are told. Expected: claimable(id, player, day, coins) == 0 whenever claim(id, day, coins, ...) would revert for a time or pause reason. Actual: it quotes the full amount. Fix: at the top of claimable() return (0, 0) when `paused || day < d.startDay || day > d.endDay || day > today() || today() >= day + CLAIM_DAYS`, and have _claim() keep its explicit reverts for error reporting.","line":160,"path":"contracts/src/TokenDrops.sol","reproduction":"createDrop(coin, 1000e18, 10, 10, 0, D, 1, 1_000_000e18) (a one-day drop). claimable(id, alice, D+5, 3) returns (3, 3000e18) although claim(id, D+5, 3, deadline, sig) reverts FutureDay(); claimable(id, alice, D-3, 3) returns (3, 3000e18) although claim() reverts TooLate()/NotRunning(). Scratch test test_ClaimableQuotesDaysThatCannotBeClaimed in test/scratch/TokenDropsAudit.t.sol.","severity":"info","snippet":" function claimable(uint256 id, address player, uint32 day, uint16 coins) public view returns (uint16 n, uint256 amount) {","title":"claimable() ignores the claim window, the drop's days and pause, so it quotes payouts for days claim() rejects"},{"citation":"resolved","description":"These are the powers the brief asks for and they are implemented as specified; this entry documents them so the requester can weigh them, not as a defect. (1) setPaused(true) followed by withdraw(id, to) moves a running drop's entire remaining pool to any address at any time, including payouts for finds made today and yesterday that are still inside their two-day claim window; after setPaused(false) those vouchers return NothingToClaim (the project's test_PauseStopsClaimsAndFreesTheTokens shows this). (2) setSigner lets the owner install a key it controls and sign vouchers for any wallet with an open office, i.e. pay itself from any drop (only its own deposits, so no third-party loss). (3) endDrop can be called around midnight: an endDrop meant to end day D that is mined after 00:00 UTC of D+1 ends on D+1 instead (last = today()), so one extra day of coins is paid; the transaction cannot express the intended day. (4) Ownership is Ownable2Step with renounceOwnership disabled, so there is always an owner; transferOwnership(address(0)) only clears the pending owner. None of these is a permission bypass. If the requester wants to narrow (1), withdraw-while-paused could be restricted to drops whose endDay + CLAIM_DAYS has passed unless an explicit 'emergency' flag is set in the same call; if (3) matters, endDrop could take the intended last day as a parameter and revert when today() is already past it.","line":300,"path":"contracts/src/TokenDrops.sol","reproduction":"State: a 30-day drop with 500_000e18 tokens, alice holds a valid voucher for 1 coin today. Owner calls setPaused(true); withdraw(id, treasury) succeeds while today() < endDay + 2 (the StillRunning check at line 300 is skipped because paused). Owner calls setPaused(false); alice's claim(id, today, 1, ...) reverts NothingToClaim because left == 0. For (3): drop endDay = D+29; owner sends endDrop(id) at 23:59:59 of day D, mined at 00:00:01 of D+1: drop(id).endDay == D+1, not D.","severity":"info","snippet":" if (!paused && !cancelled && today() < d.endDay + CLAIM_DAYS) revert StillRunning();","title":"Owner powers (trust assumptions): pause + withdraw can take tokens players have found but not yet claimed; setSigner lets the owner mint vouchers"},{"citation":"resolved","description":"setUp warps to exactly 30 days and every later warp adds whole days, so every claim, endDrop and withdraw in the suite runs at the first second of a day. The day-edge rules (now_ >= day + CLAIM_DAYS at line 215; today() < endDay + CLAIM_DAYS at line 300) are therefore never tested at 23:59:59 vs 00:00:00, which is where claimMany's atomicity bites (finding 2) and where the owner's endDrop timing matters. Other untested edges: more wallets than spots claiming on one day (the only on-chain per-day bound with dailyCoins = 0, finding 1; testFuzz_NeverOverpays uses two wallets with maxPerWallet 8 against spots 10, so it can never cross spots); claimMany with an entry that reverts; claimable() for a day outside the drop or the window; two drops of the same token where one is drained and the other withdrawn (the per-drop `left` isolation is asserted only indirectly); a deadline exactly equal to block.timestamp; topUp/endDrop on a cancelled or finished drop; a $STAMP drop claimed against GOLDEN_SPOTS. I ran each of these in test/scratch/TokenDropsAudit.t.sol: the isolation, exact-second day-edge and replay checks pass (the design holds), the others surface findings 1-3. Suggested additions: assert paidCoins[id][day] <= spots across N wallets; warp to (day+2)*86400 - 1 and (day+2)*86400 around claim and withdraw; a claimMany with one stale entry; a two-drop same-token withdraw test.","line":80,"path":"contracts/test/TokenDrops.t.sol","reproduction":"Observed from the test source: setUp() sets block.timestamp = 30 days (line 80) and all subsequent warps are vm.warp(vm.getBlockTimestamp() + N days), so block.timestamp % 86400 == 0 in every test. grep for '86400 - 1' or 'hours' in warps finds none. The seven scratch tests listed above compile and pass against the current code and document the uncovered behaviour.","severity":"info","snippet":" vm.warp(30 days);","title":"Test suite only exercises timestamps at exactly 00:00:00 UTC and never the many-wallets-per-day, failing-batch, or same-token-isolation cases"}],"hash":"6c18f1e1b645565b7e6592f1a1b1c91f54b9f08abb974fea6b57f92b3ce03f34","nodeId":"1c4fb176-8f5e-4e96-9f1e-aec49becec94","outcome":"completed","summary":"Review complete. The findings file is written at the repository root, every quoted snippet matches the tree line for line, and no file outside `test/scratch/` was changed.\n\n**Outcome: no critical or high defects.** The accounting the brief asked me to check holds up under code reading and under the scratch tests I ran against it:\n\n- **Per-drop tokens never mix.** Each drop keeps its own `left`, measured by balance difference on deposit, and both claim and withdraw move only that drop's token by that drop's amount. Two drops of one token, one drained and the other withdrawn, leave the contract at exactly zero.\n- **No overpayment of the pool or the two enforced caps.** The payout is capped by `left / perCoin`, by `maxPerWallet - claimed`, and by `dailyCoins - paidCoins`; the uint16 cast and the multiply back cannot overflow or underflow given those bounds.\n- **Vouchers cannot replay across drops, days, wallets or chains.** The digest binds player, drop, day, cumulative coins and deadline under an EIP-712 domain, and the cumulative design makes a replayed voucher pay zero. OZ 5.4 ECDSA rejects malleable and zero-address signatures.\n- **Claim window and withdraw rule abut exactly.** Claims are allowed through the last second of day+1 and refused at the first second of day+2, which is the first second withdraw is allowed.\n- **Re-entry is closed.** State is updated before the transfer, every value-moving function is nonReentrant, and the remaining unguarded functions are owner-only.\n\n**What I did report** (two low, three info):\n\n1. **Low.** `spots`, the coins-out-per-day figure, is stored but never bounds payouts. With the documented default of `dailyCoins = 0`, five offices each claiming 10 coins pay 50 coins on a day with 10 out; 72 golden stamps against the constant 24. The signer key is the only per-day bound, which matters exactly in the key-leak scenario pausing exists for.\n2. **Low.** `claimMany` reverts the whole batch when one entry fails a time check, contrary to its docstring. A batch of yesterday's and today's vouchers built at 23:59:59 and mined after midnight pays nothing.\n3. **Info.** `claimable()` quotes payouts for days the drop was not running, future days, closed windows and while paused.\n4. **Info.** Owner powers as trust assumptions: pause plus withdraw takes finds still inside their claim window; `endDrop` around midnight ends a day later than intended.\n5. **Info.** The test suite runs every action at exactly 00:00:00 UTC and never crosses `spots`, fails a batch entry, or tests same-token drop isolation directly.\n\nProof files were not attached since nothing reached high or critical. The scratch tests in `contracts/test/scratch/TokenDropsAudit.t.sol` reproduce findings 1 to 3 and confirm the isolation, day-edge and replay properties.","treeHash":null,"usage":{"cachedInputTokens":621901,"inputTokens":290,"model":"claude-fable-5-1","outputTokens":28428,"runtime":"claude","turns":15,"wallClockMs":436045}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"e3a598aae0640402","findings":[{"citation":"resolved","description":"claimMany (line 192) is documented as 'any that would pay nothing are skipped', and the web client sends every voucher the server returns in one claimMany call (web/office.js:537 -> web/chain.js claimAll). The server always signs for both yesterday and today (multiplayer/src/index.js:446, `for (const d of [day - 1, day])`) with a one hour deadline. But inside _claim the window checks revert instead of returning 0: FutureDay (line 214), TooLate (line 215), NotRunning (line 217) and Expired (line 212). So a batch assembled a few seconds before 00:00 UTC that is mined a few seconds after it carries a yesterday voucher that is now TooLate, and the entire transaction reverts, including today's perfectly valid vouchers. Every player with finds on both days who signs the wallet prompt across midnight pays gas for a revert and has to notice and retry. The same happens if the server's clock is a few seconds ahead of the chain's block.timestamp at the day edge: its 'today' voucher is FutureDay on chain and blocks the batch. The single-voucher claim() path correctly reverts (there is nothing else to pay), but the batch path contradicts its own contract. Fix: in claimMany, treat a claim that fails the time window (day > today, today >= day + CLAIM_DAYS, deadline passed, day outside the drop's days) as paying 0 and skip it, keeping UnknownDrop and BadSignature as reverts, or add a view that lets the client drop stale vouchers before sending. Either preserves the single-claim behaviour.","line":215,"path":"contracts/src/TokenDrops.sol","proof":"// SPDX-License-Identifier: MIT\npragma solidity ^0.8.26;\n\nimport {Test} from \"forge-std/Test.sol\";\nimport {ERC20} from \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nimport {TokenDrops, IDropsPad, IDropsPostOffice} from \"src/TokenDrops.sol\";\n\ncontract StalePad {\n function launches(address) external pure returns (address, address, uint64, uint64, bool) {\n return (address(0), address(0), 1, 1, false);\n }\n}\n\ncontract StaleOffice {\n mapping(address => bool) public isOpen;\n\n function open(address who) external {\n isOpen[who] = true;\n }\n\n function offices(address who) external view returns (bool, uint8, uint8, uint16, uint64, address, uint256, uint256, uint256) {\n return (isOpen[who], 0, 0, 0, 0, address(0), 0, 0, 0);\n }\n}\n\ncontract StaleCoin is ERC20 {\n constructor(address to) ERC20(\"Coin\", \"COIN\") {\n _mint(to, 1_000_000e18);\n }\n}\n\n/// claimMany is documented as skipping claims that pay nothing, but a voucher for a day whose claim window has\n/// just closed reverts the whole batch, so the still-valid vouchers in it are not paid.\ncontract DropsBatchStaleTest is Test {\n TokenDrops drops;\n StaleOffice office;\n StaleCoin coin;\n StaleCoin stamp;\n address treasury = makeAddr(\"treasury\");\n address alice = makeAddr(\"alice\");\n uint256 signerKey = 0x5160;\n\n function setUp() public {\n vm.warp(30 days);\n office = new StaleOffice();\n office.open(alice);\n coin = new StaleCoin(treasury);\n stamp = new StaleCoin(treasury);\n drops = new TokenDrops(stamp, IDropsPad(address(new StalePad())), IDropsPostOffice(address(office)), vm.addr(signerKey), treasury);\n vm.startPrank(treasury);\n coin.approve(address(drops), type(uint256).max);\n drops.createDrop(address(coin), 1e18, 10, 10, 0, drops.today(), 7, 100e18);\n vm.stopPrank();\n }\n\n function _voucher(uint256 id, uint32 day, uint16 coins, uint64 deadline) internal view returns (bytes memory) {\n bytes32 structHash = keccak256(abi.encode(drops.FINDS_TYPEHASH(), alice, id, day, coins, deadline));\n bytes32 domain = keccak256(\n abi.encode(\n keccak256(\"EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)\"),\n keccak256(\"Courier World Drops\"),\n keccak256(\"1\"),\n block.chainid,\n address(drops)\n )\n );\n (uint8 v, bytes32 r, bytes32 s) = vm.sign(signerKey, keccak256(abi.encodePacked(\"\\x19\\x01\", domain, structHash)));\n return abi.encodePacked(r, s, v);\n }\n\n /// Vouchers for yesterday (D-1) and today (D) are fetched at 23:59:30 on day D with a one hour deadline, as the\n /// server issues them. The transaction lands at 00:00:10 on D+1. The D-1 voucher is now outside its claim\n /// window (\"would pay nothing\"); the day-D voucher is still valid and should be paid.\n function test_StaleYesterdayVoucherShouldNotBlockTodays() public {\n uint32 day = drops.today() + 1; // D\n vm.warp(uint256(day + 1) * 1 days - 30); // 23:59:30 on day D\n uint64 deadline = uint64(block.timestamp + 1 hours);\n TokenDrops.Claim[] memory cs = new TokenDrops.Claim[](2);\n cs[0] = TokenDrops.Claim(0, day - 1, 3, deadline, _voucher(0, day - 1, 3, deadline));\n cs[1] = TokenDrops.Claim(0, day, 2, deadline, _voucher(0, day, 2, deadline));\n\n vm.warp(uint256(day + 1) * 1 days + 10); // 00:00:10 on day D+1: still inside the deadline\n vm.prank(alice);\n uint256 total = drops.claimMany(cs);\n assertEq(total, 2e18, \"today's finds are paid even though yesterday's window has closed\");\n assertEq(coin.balanceOf(alice), 2e18);\n }\n}","reproduction":"Drop 0: coin, perCoin 1e18, 10 spots, maxPerWallet 10, dailyCoins 0, from day D-1 for 7 days, 100e18 in. Alice has an open office. At 23:59:30 UTC on day D (block.timestamp = (D+1)*86400 - 30) the server signs Finds(alice, 0, D-1, 3, deadline = now + 3600) and Finds(alice, 0, D, 2, same deadline). Alice calls claimMany([those two]) at 00:00:10 on day D+1 (block.timestamp = (D+1)*86400 + 10, inside the deadline). Expected (per the claimMany natspec): the D-1 voucher pays nothing and is skipped, the D voucher pays 2e18, total 2e18. Actual: the call reverts with TooLate() and Alice receives nothing. test/scratch/DropsBatchStale.t.sol reproduces it (fails with TooLate on this code).","severity":"low","snippet":" if (now_ >= day + CLAIM_DAYS) revert TooLate();","title":"claimMany is all-or-nothing: one voucher whose claim window just closed reverts the whole batch, so the still-valid vouchers in it are not paid"},{"citation":"resolved","description":"The number of coins actually out each day (`spots`, 1 to 48) is only used to bound maxPerWallet (line 255); it never bounds the day's total payout. The only cross-wallet daily bound is `dailyCoins`, and 0 (the default the admin UI sends when the field is left empty, web/office.js dropCreate `BigInt(f.dailyCoins || \"0\")`) means no bound at all. That is the documented design (every player can find every coin), but AUDIT.md section 13 states the key-leak exposure as 'a leaked key could claim up to each drop's daily limits ... until the owner pauses', which is not true for dailyCoins = 0: the exposure is the whole of `left`, reachable in one day by signing maxPerWallet coins for as many office wallets as the attacker controls, and the claim window gives two days per find-day. The owner's only reaction is setPaused/setSigner after the fact. Not a code defect; report so the treasury sets dailyCoins deliberately (for example spots x expected players) and the trust note is corrected. A code-level mitigation that keeps the design would be to require dailyCoins != 0 or to default it to a multiple of spots, which is a product decision.","line":169,"path":"contracts/src/TokenDrops.sol","reproduction":"createDrop(coin, perCoin 1e18, spots 10, maxPerWallet 10, dailyCoins 0, startDay today, 7 days, 30e18): 30 coins' worth with 10 coins out a day. The signer key signs Finds(w, id, today, 10, deadline) for three office wallets alice, bob, carol; each claims. Expected under the AUDIT.md statement: at most the day's limit (10 coins' worth). Actual: 30e18 paid in a single day, left == 0, three times the coins that exist that day. Reproduced in test/scratch/DropsEdges.t.sol::test_NoDailyCapMeansPoolIsTheOnlyLimit (passes, documenting the behaviour).","severity":"info","snippet":" if (d.dailyCoins != 0) {","title":"Trust assumption: with dailyCoins = 0 the drop's pool is the only daily bound, so a leaked signer key can drain a drop far past the coins actually out, contrary to AUDIT.md's 'up to each drop's daily "},{"citation":"resolved","description":"Owner powers are intentional and the tokens in a drop are the treasury's own, so this is documentation, not a bypass. AUDIT.md section 13 says the owner can only withdraw a running drop by pausing first, which players can see. In fact the owner can call setSigner(ownerKeyAddress), sign Finds(anyOfficeWallet, id, today, maxPerWallet, deadline) itself and claim, bounded only by maxPerWallet and dailyCoins per wallet per day (unbounded across wallets when dailyCoins is 0), with no paused state for players to notice; only the SignerSet event shows it. Also, while paused the owner may withdraw a drop whose current day and previous day still have unclaimed valid finds (line 300), which is the documented emergency path. Suggested: state both in the trust section; optionally emit the old signer in SignerSet so a rotation is auditable.","line":308,"path":"contracts/src/TokenDrops.sol","reproduction":"Owner (treasury) holds key K with address A. Drop 0 running, left 100e18, maxPerWallet 10, perCoin 1e18, dailyCoins 0. Owner calls setSigner(A) (allowed: A != 0), signs Finds(W, 0, today, 10, now+3600) for its own office wallet W with K, and W calls claim(0, today, 10, ...). Expected per AUDIT.md: a running drop's tokens leave only through a visible pause. Actual: 10e18 moves to W with paused == false and nothing but a SignerSet event; repeated across wallets and days it empties the drop.","severity":"info","snippet":" function setSigner(address signer_) external onlyOwner {","title":"Trust assumption: the owner can take a running drop's tokens without pausing by pointing setSigner at its own key, so AUDIT.md's 'only by pausing first, which stops all claims, so players see it happe"},{"citation":"resolved","description":"Drop isolation is correctly done through per-drop `left` (verified: two drops of the same token keep their balances apart through claims and a paused withdraw of one of them). The flip side is that any token balance that is not a drop's `left` has no owner: a treasury transfer made directly instead of through topUp, or a launchpad token airdropped to the address, can never be recovered. Low impact (self-inflicted by the funder) but worth a sweep for the surplus: balanceOf(token) minus the sum of that token's `left` (tracked per token in a mapping updated by createDrop/topUp/claim/withdraw), owner only.","line":301,"path":"contracts/src/TokenDrops.sol","reproduction":"Drop 0 of coin with 10e18. Treasury calls coin.transfer(drops, 5e18) directly. Owner pauses and withdraws drop 0. Expected: the treasury can recover everything it put in. Actual: coin.balanceOf(drops) == 5e18 with drop(0).left == 0 and no function that moves it. Reproduced in test/scratch/DropsEdges.t.sol::test_DirectTransferIsStuck.","severity":"info","snippet":" uint256 amount = d.left;","title":"Tokens sent straight to the contract (or any balance above the drops' `left`) are stranded: withdraw only moves a drop's own `left` and there is no sweep"},{"citation":"resolved","description":"setUp warps to 30 days exactly and every later warp adds whole days, so all claims and withdraws happen at the first second of a day. Untested on this code: (1) a claimMany batch that straddles midnight (the finding above fails there); (2) the last second of day D+1 paying day D and the first second of D+2 refusing it while the same instant first allows withdraw; (3) the dailyCoins cap of a find-day being charged when claimed the next day; (4) two drops of the same token staying apart across a paused withdraw of one; (5) the identical voucher replayed on the next day; (6) a drop ended with endDrop being withdrawable exactly at endDay + 2; (7) dailyCoins = 0 letting several wallets exceed `spots` in one day. Cases 2 to 7 were run by the reviewer in test/scratch/DropsEdges.t.sol and all hold; they are listed so the suite can keep them holding.","line":80,"path":"contracts/test/TokenDrops.t.sol","reproduction":"Run the shipped suite: every block.timestamp seen by TokenDrops is a multiple of 86400. Add vm.warp(uint256(day + 2) * 1 days - 1) before a claim for `day` and vm.warp(uint256(day + 2) * 1 days) before the next: the suite has no assertion at either instant. Expected: window edges asserted one second either side; actual: none.","severity":"info","snippet":" vm.warp(30 days);","title":"Test suite pins every timestamp to exactly 00:00 UTC, so no day-edge is exercised inside a day; the batch-at-midnight case and several isolation edges are untested"}],"hash":"7b4ebafb16a95daf5a1cb31cdcec92a10ceca8fbdcce9000f864f64b0ebb4009","nodeId":"7202976f-5f57-45cc-8387-1d03afb7b5d5","outcome":"completed","summary":"The findings file is in place at the repository root (excluded from git by the harness's own exclude rule, which is expected), and only my scratch tests are new in the tree. No source or config file was changed.\n\n## Review of TokenDrops at commit 30ade10\n\n**Outcome: no critical, high or medium defect.** The contract holds every property the brief asked me to check. One low finding and four informational notes are recorded in `.imd-findings.json`.\n\n**What I verified and found sound**\n\n- A drop never pays past its own tokens or caps. The view `claimable` bounds the payout by the per-wallet cap, the find-day's cross-wallet cap, and the drop's remaining `left`, and `_claim` writes all three counters before transferring. The shipped fuzz plus my own checks confirm it.\n- Drops' tokens never mix. Two drops of the same token keep separate `left` balances through claims and through a paused withdraw of one of them. Nothing can move one drop's tokens to another.\n- Voucher replay is closed. The digest binds player, drop, day, coins, deadline, chain id and contract address. The coins field is a running total, so an identical voucher pays nothing the second time, including on the next day. The vendored OpenZeppelin 5.4 ECDSA rejects malleable and invalid signatures.\n- Claim windows and day edges are consistent. The last second of day D+1 pays day D, the first second of D+2 refuses it, and that same instant is the first moment withdraw is allowed. The daily cap is charged to the find-day whichever day the claim lands on.\n- Re-entry is guarded on every value-moving path and state is settled before transfer. Owner powers match the brief. Interfaces match the real PostOffice and CourierPad layouts.\n\n**Findings**\n\n1. **Low: claimMany is all-or-nothing at midnight.** The batch path is documented as skipping claims that pay nothing, but a yesterday voucher whose window just closed reverts with TooLate and takes today's valid vouchers down with it. The client always sends both days' vouchers in one call, so players who confirm their wallet prompt across 00:00 UTC pay gas for a revert. The proof test fails on this code and passes on a copy where the window checks return zero inside the batch.\n2. **Info: dailyCoins = 0 means the pool is the only daily bound.** With a leaked signer key, three office wallets drained a 30-coin drop with 10 coins out in one day. AUDIT.md's \"up to each drop's daily limits\" overstates the protection in that configuration.\n3. **Info: the owner can drain a running drop without pausing** by pointing setSigner at its own key, so the \"only by pausing first\" trust note is not accurate.\n4. **Info: tokens sent directly to the contract are stranded.** Withdraw only moves a drop's `left` and there is no sweep.\n5. **Info: the test suite pins every timestamp to exactly 00:00 UTC**, so none of the in-day edges above are exercised.\n\n**Scope limits**: review was manual with Foundry only. No static analyzer ran. The game server and web client were read only to establish how vouchers are issued and batched.","treeHash":null,"usage":{"cachedInputTokens":1478793,"inputTokens":514,"model":"claude-fable-5-1","outputTokens":36845,"runtime":"claude","turns":36,"wallClockMs":633534}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"829d84438fb3fdc8","findings":[{"citation":"resolved","description":"Each drop lays out `spots` coins a day (1-48, 24 golden stamps for $STAMP), so at most `spots` coins of a drop can legitimately be found on any day. `claimable` caps a claim only by `maxPerWallet`, by `dailyCoins` (when non-zero) and by `left`; `spots` is stored but never read on the claim path. `dailyCoins` is not bounded by `spots` at creation either: the admin form (web/office.js) defaults to spots=10, maxPerWallet=5, dailyCoins=100, i.e. ten times the coins that exist, and 0 (\"no limit\") is the documented default. AUDIT.md states the signer-key-leak blast radius is \"up to each drop's daily limits ... until the owner pauses\"; with dailyCoins=0 that limit is the entire pool, and with dailyCoins=100 it is 10x the coins actually out. The contract already holds the information needed to bound a day to the coins it put out, so a server bug or leaked key (the stated threat) could be contained to `spots*perCoin` per day instead of `left`. Fix: in `claimable`, also limit `room` to `spots - paidCoins[id][day]`, and (optionally) reject `dailyCoins > spots` in createDrop or treat dailyCoins as min(dailyCoins, spots).","line":168,"path":"contracts/src/TokenDrops.sol","proof":"// SPDX-License-Identifier: MIT\npragma solidity ^0.8.26;\n\nimport {Test} from \"forge-std/Test.sol\";\nimport {TokenDrops, IDropsPad, IDropsPostOffice} from \"src/TokenDrops.sol\";\nimport {IERC20} from \"@openzeppelin/contracts/token/ERC20/IERC20.sol\";\n\ncontract PlainCoin {\n string public name = \"Coin\";\n string public symbol = \"COIN\";\n uint8 public decimals = 18;\n uint256 public totalSupply;\n mapping(address => uint256) public balanceOf;\n mapping(address => mapping(address => uint256)) public allowance;\n\n constructor(address to, uint256 amount) {\n balanceOf[to] = amount;\n totalSupply = amount;\n }\n\n function approve(address s, uint256 a) external returns (bool) {\n allowance[msg.sender][s] = a;\n return true;\n }\n\n function transfer(address to, uint256 a) external returns (bool) {\n balanceOf[msg.sender] -= a;\n balanceOf[to] += a;\n return true;\n }\n\n function transferFrom(address f, address to, uint256 a) external returns (bool) {\n allowance[f][msg.sender] -= a;\n balanceOf[f] -= a;\n balanceOf[to] += a;\n return true;\n }\n}\n\ncontract StubPad {\n mapping(address => uint64) public created;\n\n function add(address t) external {\n created[t] = uint64(block.timestamp);\n }\n\n function launches(address t) external view returns (address, address, uint64, uint64, bool) {\n return (address(0), address(0), created[t], 0, false);\n }\n}\n\ncontract StubOffice {\n mapping(address => bool) public isOpen;\n\n function open(address w) external {\n isOpen[w] = true;\n }\n\n function offices(address w) external view returns (bool, uint8, uint8, uint16, uint64, address, uint256, uint256, uint256) {\n return (isOpen[w], 0, 0, 0, 0, address(0), 0, 0, 0);\n }\n}\n\n/// A drop puts `spots` coins out per day, yet with dailyCoins = 0 (the \"no limit\" default) the contract pays\n/// any number of coins for one day: here 20 coins are paid on a day that had 10 out.\ncontract DropsSpotsCapTest is Test {\n TokenDrops drops;\n PlainCoin coin;\n PlainCoin stamp;\n StubPad pad;\n StubOffice office;\n address treasury = makeAddr(\"treasury\");\n address alice = makeAddr(\"alice\");\n address bob = makeAddr(\"bob\");\n uint256 signerKey = 0x5160;\n uint256 constant PER = 1_000e18;\n\n function setUp() public {\n vm.warp(30 days);\n stamp = new PlainCoin(treasury, 1e24);\n coin = new PlainCoin(treasury, 1e27);\n pad = new StubPad();\n pad.add(address(coin));\n office = new StubOffice();\n office.open(alice);\n office.open(bob);\n drops = new TokenDrops(\n IERC20(address(stamp)), IDropsPad(address(pad)), IDropsPostOffice(address(office)), vm.addr(signerKey), treasury\n );\n vm.prank(treasury);\n coin.approve(address(drops), type(uint256).max);\n }\n\n function _voucher(address player, uint256 id, uint32 day, uint16 coins, uint64 deadline) internal view returns (bytes memory) {\n bytes32 structHash = keccak256(abi.encode(drops.FINDS_TYPEHASH(), player, id, day, coins, deadline));\n bytes32 domain = keccak256(\n abi.encode(\n keccak256(\"EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)\"),\n keccak256(\"Courier World Drops\"),\n keccak256(\"1\"),\n block.chainid,\n address(drops)\n )\n );\n (uint8 v, bytes32 r, bytes32 s) = vm.sign(signerKey, keccak256(abi.encodePacked(\"\\x19\\x01\", domain, structHash)));\n return abi.encodePacked(r, s, v);\n }\n\n function claimAs(address who, uint256 id, uint32 day, uint16 coins) external returns (uint256) {\n uint64 deadline = uint64(block.timestamp + 1 hours);\n bytes memory sig = _voucher(who, id, day, coins, deadline);\n vm.prank(who);\n return drops.claim(id, day, coins, deadline, sig);\n }\n\n function test_ADayNeverPaysMoreCoinsThanItHasOut() public {\n uint32 day = drops.today();\n vm.prank(treasury);\n // 10 coins out a day, a wallet may be paid all 10, no cap across everyone (the \"0: no limit\" default).\n uint256 id = drops.createDrop(address(coin), PER, 10, 10, 0, day, 7, 100_000e18);\n\n this.claimAs(alice, id, day, 10);\n // Bob's voucher also says 10 found: with 10 coins out, only 0 can be left for him.\n try this.claimAs(bob, id, day, 10) {} catch {}\n\n assertLe(drops.paidCoins(id, day), drops.drop(id).spots, \"a day paid more coins than were out\");\n assertLe(coin.balanceOf(alice) + coin.balanceOf(bob), 10 * PER, \"a day paid more tokens than its coins are worth\");\n }\n}","reproduction":"createDrop(coin, 1000e18, spots=10, maxPerWallet=10, dailyCoins=0, today, 7, 100_000e18). Alice (office open) claims a voucher Finds(alice, id, today, 10): paid 10 coins. Bob claims Finds(bob, id, today, 10): paid another 10 coins. paidCoins[id][today] == 20 on a day with 10 coins out; expected the second claim to pay 0 (or at most spots - 10). With 20 office wallets and dailyCoins=100 (UI default) a single day pays 100 coins = 100_000e18, the whole pool, instead of 10 coins.","severity":"medium","snippet":" // As many as the drop's tokens, and the day's coins, can cover; the rest stays claimable if they grow.\n uint256 room = d.left / d.perCoin;\n if (d.dailyCoins != 0) {\n uint256 dayLeft = d.dailyCoins > paidCoins[id][day] ? d.dailyCoins - paidCoins[id][day] : 0;\n if (dayLeft < room) room = dayLeft;\n }\n if (want > room) want = room;","title":"A day can pay more coins than the drop has out: `spots` is never enforced, and dailyCoins defaults past it"},{"citation":"resolved","description":"The docstring promises \"any that would pay nothing are skipped\" and AUDIT.md says claimMany \"skips claims that would pay nothing and reverts only if all do\". That is true only for the zero-amount case in `claimable`; `_claim` still reverts the batch for Expired, FutureDay, TooLate, NotRunning, UnknownDrop and BadSignature. The server hands out yesterday's and today's vouchers together (multiplayer/src/index.js `vouchers`: days day-1 and day, one-hour deadline) and the client submits them as one claimMany. A batch signed before midnight UTC and mined after it contains a voucher for a day that is now two days old, so the whole transaction reverts with TooLate and today's finds are not paid either; the player loses gas and must fetch fresh vouchers. The same happens for a voucher whose deadline passed in the mempool, or a drop that the owner ended. Fix: in claimMany skip (continue) claims whose deadline/day window/drop range fails, keeping the revert only for `claim`.","line":196,"path":"contracts/src/TokenDrops.sol","proof":"// SPDX-License-Identifier: MIT\npragma solidity ^0.8.26;\n\nimport {Test} from \"forge-std/Test.sol\";\nimport {TokenDrops, IDropsPad, IDropsPostOffice} from \"src/TokenDrops.sol\";\nimport {IERC20} from \"@openzeppelin/contracts/token/ERC20/IERC20.sol\";\n\ncontract PlainCoin {\n string public name = \"Coin\";\n string public symbol = \"COIN\";\n uint8 public decimals = 18;\n uint256 public totalSupply;\n mapping(address => uint256) public balanceOf;\n mapping(address => mapping(address => uint256)) public allowance;\n\n constructor(address to, uint256 amount) {\n balanceOf[to] = amount;\n totalSupply = amount;\n }\n\n function approve(address s, uint256 a) external returns (bool) {\n allowance[msg.sender][s] = a;\n return true;\n }\n\n function transfer(address to, uint256 a) external returns (bool) {\n balanceOf[msg.sender] -= a;\n balanceOf[to] += a;\n return true;\n }\n\n function transferFrom(address f, address to, uint256 a) external returns (bool) {\n allowance[f][msg.sender] -= a;\n balanceOf[f] -= a;\n balanceOf[to] += a;\n return true;\n }\n}\n\ncontract StubPad {\n mapping(address => uint64) public created;\n\n function add(address t) external {\n created[t] = uint64(block.timestamp);\n }\n\n function launches(address t) external view returns (address, address, uint64, uint64, bool) {\n return (address(0), address(0), created[t], 0, false);\n }\n}\n\ncontract StubOffice {\n mapping(address => bool) public isOpen;\n\n function open(address w) external {\n isOpen[w] = true;\n }\n\n function offices(address w) external view returns (bool, uint8, uint8, uint16, uint64, address, uint256, uint256, uint256) {\n return (isOpen[w], 0, 0, 0, 0, address(0), 0, 0, 0);\n }\n}\n\n/// The server hands out yesterday's and today's vouchers together for claimMany. Sent at 23:59 and mined after\n/// midnight, yesterday's voucher is two days old: instead of being skipped (\"any that would pay nothing are\n/// skipped\") it reverts the whole batch, so today's finds are not paid either.\ncontract DropsClaimManyLateTest is Test {\n TokenDrops drops;\n PlainCoin coin;\n PlainCoin stamp;\n StubPad pad;\n StubOffice office;\n address treasury = makeAddr(\"treasury\");\n address alice = makeAddr(\"alice\");\n uint256 signerKey = 0x5160;\n uint256 constant PER = 1_000e18;\n\n function setUp() public {\n vm.warp(30 days);\n stamp = new PlainCoin(treasury, 1e24);\n coin = new PlainCoin(treasury, 1e27);\n pad = new StubPad();\n pad.add(address(coin));\n office = new StubOffice();\n office.open(alice);\n drops = new TokenDrops(\n IERC20(address(stamp)), IDropsPad(address(pad)), IDropsPostOffice(address(office)), vm.addr(signerKey), treasury\n );\n vm.prank(treasury);\n coin.approve(address(drops), type(uint256).max);\n }\n\n function _voucher(address player, uint256 id, uint32 day, uint16 coins, uint64 deadline) internal view returns (bytes memory) {\n bytes32 structHash = keccak256(abi.encode(drops.FINDS_TYPEHASH(), player, id, day, coins, deadline));\n bytes32 domain = keccak256(\n abi.encode(\n keccak256(\"EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)\"),\n keccak256(\"Courier World Drops\"),\n keccak256(\"1\"),\n block.chainid,\n address(drops)\n )\n );\n (uint8 v, bytes32 r, bytes32 s) = vm.sign(signerKey, keccak256(abi.encodePacked(\"\\x19\\x01\", domain, structHash)));\n return abi.encodePacked(r, s, v);\n }\n\n function test_ClaimManySkipsAVoucherThatIsTooLateAndPaysTheRest() public {\n uint32 day = drops.today();\n vm.prank(treasury);\n uint256 id = drops.createDrop(address(coin), PER, 10, 10, 0, day, 7, 100_000e18);\n\n // Two days later, at 23:59:30: the server signs yesterday's (day + 1) and today's (day + 2) finds,\n // with an hour's deadline.\n vm.warp((uint256(day) + 3) * 1 days - 30);\n uint64 deadline = uint64(block.timestamp + 1 hours);\n TokenDrops.Claim[] memory cs = new TokenDrops.Claim[](2);\n cs[0] = TokenDrops.Claim(id, day + 1, 3, deadline, _voucher(alice, id, day + 1, 3, deadline));\n cs[1] = TokenDrops.Claim(id, day + 2, 4, deadline, _voucher(alice, id, day + 2, 4, deadline));\n\n // The transaction is mined 40 seconds later, just after midnight: day + 1 is now two days old.\n vm.warp(block.timestamp + 40);\n vm.prank(alice);\n drops.claimMany(cs);\n\n assertEq(coin.balanceOf(alice), 4 * PER, \"today's finds were paid\");\n assertEq(drops.claimed(id, day + 2, alice), 4);\n }\n}","reproduction":"Drop running from day D. At (D+3)*86400 - 30 the server signs Finds(alice, id, D+1, 3) and Finds(alice, id, D+2, 4) with deadline +1h. Alice sends claimMany([both]) and it is mined 40 s later (now day D+3). Expected: 4 coins paid for D+2, D+1 skipped. Actual: revert TooLate(), nothing paid.","severity":"low","snippet":" for (uint256 i; i < claims.length; i++) {\n Claim calldata c = claims[i];\n total += _claim(c.drop, c.day, c.coins, c.deadline, c.signature);\n }\n if (total == 0) revert NothingToClaim();","title":"claimMany reverts the whole batch on one late or expired voucher instead of skipping it"},{"citation":"resolved","description":"`withdraw` zeroes `left` but does not touch `startDay`/`endDay`. For a running drop taken back while paused (the documented emergency path), `activeDrops(day)` still lists it after unpausing, so the room (`dropsOn` in multiplayer/src/index.js) keeps laying its coins out and signing vouchers for them, and the UI shows a live drop with left == 0. Players spend effort finding coins whose `claim` reverts NothingToClaim; in a claimMany batch the drop is silently skipped. The owner must remember a separate endDrop (which still keeps today's coins out). Fix: have withdraw end the drop as endDrop does (endDay = min(endDay, startDay-1 if not started, else today)), or require it ended/cancelled before withdrawing while paused.","line":302,"path":"contracts/src/TokenDrops.sol","proof":"// SPDX-License-Identifier: MIT\npragma solidity ^0.8.26;\n\nimport {Test} from \"forge-std/Test.sol\";\nimport {TokenDrops, IDropsPad, IDropsPostOffice} from \"src/TokenDrops.sol\";\nimport {IERC20} from \"@openzeppelin/contracts/token/ERC20/IERC20.sol\";\n\ncontract PlainCoin {\n string public name = \"Coin\";\n string public symbol = \"COIN\";\n uint8 public decimals = 18;\n uint256 public totalSupply;\n mapping(address => uint256) public balanceOf;\n mapping(address => mapping(address => uint256)) public allowance;\n\n constructor(address to, uint256 amount) {\n balanceOf[to] = amount;\n totalSupply = amount;\n }\n\n function approve(address s, uint256 a) external returns (bool) {\n allowance[msg.sender][s] = a;\n return true;\n }\n\n function transfer(address to, uint256 a) external returns (bool) {\n balanceOf[msg.sender] -= a;\n balanceOf[to] += a;\n return true;\n }\n\n function transferFrom(address f, address to, uint256 a) external returns (bool) {\n allowance[f][msg.sender] -= a;\n balanceOf[f] -= a;\n balanceOf[to] += a;\n return true;\n }\n}\n\ncontract StubPad {\n mapping(address => uint64) public created;\n\n function add(address t) external {\n created[t] = uint64(block.timestamp);\n }\n\n function launches(address t) external view returns (address, address, uint64, uint64, bool) {\n return (address(0), address(0), created[t], 0, false);\n }\n}\n\ncontract StubOffice {\n function offices(address) external pure returns (bool, uint8, uint8, uint16, uint64, address, uint256, uint256, uint256) {\n return (true, 0, 0, 0, 0, address(0), 0, 0, 0);\n }\n}\n\n/// Withdrawing a running drop while paused empties it but leaves it running: once unpaused, activeDrops still\n/// lists it, so the game server keeps laying its coins out and signing vouchers that pay nothing.\ncontract DropsWithdrawLeavesActiveTest is Test {\n TokenDrops drops;\n PlainCoin coin;\n PlainCoin stamp;\n StubPad pad;\n address treasury = makeAddr(\"treasury\");\n uint256 constant PER = 1_000e18;\n\n function setUp() public {\n vm.warp(30 days);\n stamp = new PlainCoin(treasury, 1e24);\n coin = new PlainCoin(treasury, 1e27);\n pad = new StubPad();\n pad.add(address(coin));\n drops = new TokenDrops(\n IERC20(address(stamp)), IDropsPad(address(pad)), IDropsPostOffice(address(new StubOffice())), vm.addr(1), treasury\n );\n vm.prank(treasury);\n coin.approve(address(drops), type(uint256).max);\n }\n\n function test_AWithdrawnDropIsNotStillOut() public {\n uint32 day = drops.today();\n vm.startPrank(treasury);\n uint256 id = drops.createDrop(address(coin), PER, 10, 5, 0, day, 30, 100_000e18);\n drops.setPaused(true);\n drops.withdraw(id, treasury);\n drops.setPaused(false);\n vm.stopPrank();\n\n assertEq(drops.drop(id).left, 0);\n // Tomorrow the server reads the running drops to lay coins out: an empty drop must not be among them.\n vm.warp(block.timestamp + 1 days);\n assertEq(drops.activeDrops(day + 1).length, 0, \"an emptied drop is still laid out\");\n }\n}","reproduction":"createDrop(coin, 1000e18, 10, 5, 0, today, 30, 100_000e18); setPaused(true); withdraw(id, treasury); setPaused(false). drop(id).left == 0 yet activeDrops(today+1) == [id] for the next 29 days; claim(id, day, n, ...) reverts NothingToClaim for every player.","severity":"low","snippet":" uint256 amount = d.left;\n d.left = 0;\n IERC20(d.token).safeTransfer(to, amount);","title":"withdraw while paused empties a running drop but leaves it active: the game keeps laying out coins that pay nothing"},{"citation":"resolved","description":"Not a bypass: these are the designed powers, recorded so the trust model is explicit. (1) AUDIT.md says the owner can take a running drop back only by pausing, \"which stops all claims, so players see it happen\". setPaused(true), withdraw(id, to), setPaused(false) can be three calls in one block (or one multicall from a contract owner), so players get no window to react; they only see the Withdrawn event afterwards. Players with outstanding vouchers for yesterday/today lose them. (2) setSigner(ownerKey) lets the owner sign arbitrary Finds for any wallet with an office, draining drops to themselves; it is their own deposit, so no third-party loss, but it means the signer role adds no independent check on the owner. (3) endDrop/withdraw ordering is safe: claims need now < endDay+2 and withdraw needs now >= endDay+2 (or cancelled/paused), so there is no state in which both a claim and an unpaused withdraw are possible. No fix required; a timelock on withdraw-while-paused or a requirement that the drop be ended first would make the published statement true.","line":300,"path":"contracts/src/TokenDrops.sol","reproduction":"Running drop id with left = 100_000e18, alice holding a valid voucher for today. Owner in one block: setPaused(true); withdraw(id, treasury); setPaused(false). Alice's claim now reverts NothingToClaim; treasury holds the 100_000e18. All three calls succeed as coded.","severity":"info","snippet":" if (!paused && !cancelled && today() < d.endDay + CLAIM_DAYS) revert StillRunning();","title":"Owner powers (trust assumptions): pause+withdraw+unpause can be atomic, and setSigner lets the owner author vouchers"}],"hash":"90587ad88bb169acb3a2f7fb49e620197eaea816db23c168424a1a46c3d4e570","nodeId":"13cd2ee1-9d12-496f-ac4e-7faeef64da30","outcome":"completed","summary":"Review complete. The findings file holds four entries, three with Foundry proofs that fail on the current code and pass under a minimal fix (verified by patching temporarily and restoring the tree; the existing 23 tests still pass under those fixes).\n\n**What held up under the checklist**\n\n- Per-drop accounting is sound: `left` is set from balance deltas, only decremented by exactly what is transferred, and drops of the same token never mix.\n- Voucher replay is blocked across drops, days and wallets by the EIP-712 struct (player, drop, day, cumulative coins, deadline) plus chain id and contract address. Re-submitting a voucher pays only the unpaid difference.\n- Claim windows and withdraw rules are disjoint: a day's claims close exactly when `today >= endDay + 2`, which is when withdraw opens. Cancel, end-today and start-day edges all behave.\n- Re-entry is covered by `nonReentrant` and checks-effects-interactions. The deployed PostOffice and CourierPad struct layouts match the interfaces the contract decodes.\n\n**Findings written to `.imd-findings.json`**\n\n1. **Medium.** The per-day coin count `spots` is never enforced on the claim path, and `dailyCoins` is not bounded by it. With `dailyCoins = 0` (the documented default) or the admin UI default of 100 against 10 spots, one day can pay the whole pool. This contradicts the AUDIT.md statement that a leaked signer key is bounded by daily limits. Proof: two wallets claim 10 coins each on a 10-spot day, paying 20 coins.\n2. **Low.** `claimMany` reverts the whole batch on a single late or expired voucher despite the docstring saying such claims are skipped. The server bundles yesterday's and today's vouchers, so a batch mined just after midnight UTC pays nothing. Proof included.\n3. **Low.** `withdraw` while paused empties a running drop but leaves it active, so the game server keeps laying out coins that pay nothing after unpausing. Proof included.\n4. **Info.** Owner trust assumptions: pause, withdraw and unpause can be atomic, so players cannot react as the docs imply, and `setSigner` lets the owner author vouchers. Documented, not a bypass.\n\nNo source files were changed. The scratch tests live under `contracts/test/scratch/` as the assignment allows.","treeHash":null,"usage":{"cachedInputTokens":922687,"inputTokens":418,"model":"claude-fable-5-1","outputTokens":30459,"runtime":"claude","turns":21,"wallClockMs":474202}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"d7e6877fd9e388bb","findings":[{"citation":"resolved","description":"The brief lists four per-drop limits: tokens per coin, coins out per day (`spots`), a per-wallet daily cap (`maxPerWallet`) and a daily cap across everyone (`dailyCoins`). claimable() (lines 160-175) applies only the last two and the pool: `spots` is validated at createDrop (1..MAX_SPOTS, maxPerWallet <= spots) and stored, but never read on the claim path, and createDrop accepts any `dailyCoins`, including 0 ('only the pool limits it', the value the admin form sends for an empty field) and values far above `spots` (the admin form's default is dailyCoins = 100 with spots = 10). Since the game lays out exactly `spots` coins of a drop per day, any day on which paidCoins[id][day] exceeds `spots` is paying for coins that do not exist. With an honest server this cannot happen, but the contract's own threat model (setPaused NatSpec: 'if the server key leaks') is the case where it does: whoever holds the key signs Finds(wallet, id, day, maxPerWallet, deadline) for as many wallets with an open office as they control (an office costs 0.005 ETH and is permanent), for today and yesterday, and with dailyCoins = 0 takes the entire `left` of every drop before the owner can react. AUDIT.md section 13 states the exposure as 'up to each drop's daily limits ... until the owner pauses'; for dailyCoins = 0 there is no daily limit, so that statement is not true of the code. Merged from four specialists (audit_math, audit_permissions, audit_economics, audit_flow), all reproduced. Fix (defence in depth, keeps the design): in claimable() also bound the day's room by `d.spots - paidCoins[id][day]` (or use `d.spots` as the day cap when `d.dailyCoins == 0`), and in createDrop reject `dailyCoins > spots` or clamp it. Either changes what dailyCoins = 0 means, so it is a product decision for the treasury; if 'no daily limit' is wanted on purpose, AUDIT.md must say the pool is the only per-day bound and `spots` is informational.","line":169,"path":"contracts/src/TokenDrops.sol","proof":"// SPDX-License-Identifier: MIT\npragma solidity ^0.8.26;\n\nimport {Test} from \"forge-std/Test.sol\";\nimport {TokenDrops, IDropsPad, IDropsPostOffice} from \"src/TokenDrops.sol\";\nimport {IERC20} from \"@openzeppelin/contracts/token/ERC20/IERC20.sol\";\n\ncontract PlainCoin {\n string public name = \"Coin\";\n string public symbol = \"COIN\";\n uint8 public decimals = 18;\n uint256 public totalSupply;\n mapping(address => uint256) public balanceOf;\n mapping(address => mapping(address => uint256)) public allowance;\n\n constructor(address to, uint256 amount) {\n balanceOf[to] = amount;\n totalSupply = amount;\n }\n\n function approve(address s, uint256 a) external returns (bool) {\n allowance[msg.sender][s] = a;\n return true;\n }\n\n function transfer(address to, uint256 a) external returns (bool) {\n balanceOf[msg.sender] -= a;\n balanceOf[to] += a;\n return true;\n }\n\n function transferFrom(address f, address to, uint256 a) external returns (bool) {\n allowance[f][msg.sender] -= a;\n balanceOf[f] -= a;\n balanceOf[to] += a;\n return true;\n }\n}\n\ncontract StubPad {\n mapping(address => uint64) public created;\n\n function add(address t) external {\n created[t] = uint64(block.timestamp);\n }\n\n function launches(address t) external view returns (address, address, uint64, uint64, bool) {\n return (address(0), address(0), created[t], 0, false);\n }\n}\n\ncontract StubOffice {\n mapping(address => bool) public isOpen;\n\n function open(address w) external {\n isOpen[w] = true;\n }\n\n function offices(address w) external view returns (bool, uint8, uint8, uint16, uint64, address, uint256, uint256, uint256) {\n return (isOpen[w], 0, 0, 0, 0, address(0), 0, 0, 0);\n }\n}\n\n/// A drop puts `spots` coins out per day, yet with dailyCoins = 0 (the \"no limit\" default) the contract pays\n/// any number of coins for one day: here 20 coins are paid on a day that had 10 out.\ncontract DropsSpotsCapTest is Test {\n TokenDrops drops;\n PlainCoin coin;\n PlainCoin stamp;\n StubPad pad;\n StubOffice office;\n address treasury = makeAddr(\"treasury\");\n address alice = makeAddr(\"alice\");\n address bob = makeAddr(\"bob\");\n uint256 signerKey = 0x5160;\n uint256 constant PER = 1_000e18;\n\n function setUp() public {\n vm.warp(30 days);\n stamp = new PlainCoin(treasury, 1e24);\n coin = new PlainCoin(treasury, 1e27);\n pad = new StubPad();\n pad.add(address(coin));\n office = new StubOffice();\n office.open(alice);\n office.open(bob);\n drops = new TokenDrops(\n IERC20(address(stamp)), IDropsPad(address(pad)), IDropsPostOffice(address(office)), vm.addr(signerKey), treasury\n );\n vm.prank(treasury);\n coin.approve(address(drops), type(uint256).max);\n }\n\n function _voucher(address player, uint256 id, uint32 day, uint16 coins, uint64 deadline) internal view returns (bytes memory) {\n bytes32 structHash = keccak256(abi.encode(drops.FINDS_TYPEHASH(), player, id, day, coins, deadline));\n bytes32 domain = keccak256(\n abi.encode(\n keccak256(\"EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)\"),\n keccak256(\"Courier World Drops\"),\n keccak256(\"1\"),\n block.chainid,\n address(drops)\n )\n );\n (uint8 v, bytes32 r, bytes32 s) = vm.sign(signerKey, keccak256(abi.encodePacked(\"\\x19\\x01\", domain, structHash)));\n return abi.encodePacked(r, s, v);\n }\n\n function claimAs(address who, uint256 id, uint32 day, uint16 coins) external returns (uint256) {\n uint64 deadline = uint64(block.timestamp + 1 hours);\n bytes memory sig = _voucher(who, id, day, coins, deadline);\n vm.prank(who);\n return drops.claim(id, day, coins, deadline, sig);\n }\n\n function test_ADayNeverPaysMoreCoinsThanItHasOut() public {\n uint32 day = drops.today();\n vm.prank(treasury);\n // 10 coins out a day, a wallet may be paid all 10, no cap across everyone (the \"0: no limit\" default).\n uint256 id = drops.createDrop(address(coin), PER, 10, 10, 0, day, 7, 100_000e18);\n\n this.claimAs(alice, id, day, 10);\n // Bob's voucher also says 10 found: with 10 coins out, only 0 can be left for him.\n try this.claimAs(bob, id, day, 10) {} catch {}\n\n assertLe(drops.paidCoins(id, day), drops.drop(id).spots, \"a day paid more coins than were out\");\n assertLe(coin.balanceOf(alice) + coin.balanceOf(bob), 10 * PER, \"a day paid more tokens than its coins are worth\");\n }\n}","reproduction":"createDrop(coin, perCoin = 1000e18, spots = 10, maxPerWallet = 10, dailyCoins = 0, startDay = today, days = 7, amount = 100_000e18). Alice (office open) claims a signer voucher Finds(alice, id, today, 10, deadline): 10 coins paid. Bob (office open) claims Finds(bob, id, today, 10, deadline). Expected: at most 10 coins paid for a day with 10 out, so bob gets 0 (NothingToClaim). Actual: bob is paid 10 more coins; paidCoins(id, today) == 20 while drop(id).spots == 10 and 20_000e18 tokens have left the drop. With three wallets paidCoins == 30; with dailyCoins = 1000 createDrop is accepted (test_DailyAboveSpots in test/scratch/JudgeProbe.t.sol). The attached proof fails on this code with 'a day paid more coins than were out: 20 > 10'.","severity":"medium","snippet":" if (d.dailyCoins != 0) {","title":"A day's payout is never bounded by `spots`: with dailyCoins = 0 (the default) or dailyCoins > spots a drop pays more coins than it put out, so a leaked signer key or server bug drains the whole pool i"},{"citation":"resolved","description":"claimMany's doc (line 191) and AUDIT.md section 13 say 'any that would pay nothing are skipped' / 'skips claims that would pay nothing and reverts only if all do'. That is true only when claimable() returns 0 (line 223). Every time-window failure inside _claim reverts instead: Expired (212), FutureDay (214), TooLate (215), NotRunning (217), plus UnknownDrop (211) and BadSignature (219), and claimMany has no per-entry skip. The integration relies on the documented semantics: the room signs vouchers for both day-1 and day with a 3600 s deadline (multiplayer/src/index.js lines 444-446) and the client submits all of them in one claimMany (web/chain.js claimAll, web/office.js line 537). A batch fetched shortly before 00:00 UTC and mined after it carries a day-1 voucher that is now two days old, so the whole transaction reverts with TooLate and the still-valid vouchers for the other day are not paid; the player loses the gas and must re-fetch and retry. A voucher whose one-hour deadline lapses in the mempool, or a server clock a few seconds ahead of the chain at the day edge (FutureDay), has the same effect. No funds are at risk. Merged from four specialists, all reproduced. Fix: in claimMany evaluate the window conditions (deadline, day > today, today >= day + CLAIM_DAYS, day outside the drop's days) per entry and `continue` on failure, keeping BadSignature/UnknownDrop as reverts and the final `total == 0` revert; or change the NatSpec and AUDIT.md and have the client drop stale vouchers before sending.","line":196,"path":"contracts/src/TokenDrops.sol","proof":"// SPDX-License-Identifier: MIT\npragma solidity ^0.8.26;\n\nimport {Test} from \"forge-std/Test.sol\";\nimport {ERC20} from \"@openzeppelin/contracts/token/ERC20/ERC20.sol\";\nimport {TokenDrops, IDropsPad, IDropsPostOffice} from \"src/TokenDrops.sol\";\n\ncontract StalePad {\n function launches(address) external pure returns (address, address, uint64, uint64, bool) {\n return (address(0), address(0), 1, 1, false);\n }\n}\n\ncontract StaleOffice {\n mapping(address => bool) public isOpen;\n\n function open(address who) external {\n isOpen[who] = true;\n }\n\n function offices(address who) external view returns (bool, uint8, uint8, uint16, uint64, address, uint256, uint256, uint256) {\n return (isOpen[who], 0, 0, 0, 0, address(0), 0, 0, 0);\n }\n}\n\ncontract StaleCoin is ERC20 {\n constructor(address to) ERC20(\"Coin\", \"COIN\") {\n _mint(to, 1_000_000e18);\n }\n}\n\n/// claimMany is documented as skipping claims that pay nothing, but a voucher for a day whose claim window has\n/// just closed reverts the whole batch, so the still-valid vouchers in it are not paid.\ncontract DropsBatchStaleTest is Test {\n TokenDrops drops;\n StaleOffice office;\n StaleCoin coin;\n StaleCoin stamp;\n address treasury = makeAddr(\"treasury\");\n address alice = makeAddr(\"alice\");\n uint256 signerKey = 0x5160;\n\n function setUp() public {\n vm.warp(30 days);\n office = new StaleOffice();\n office.open(alice);\n coin = new StaleCoin(treasury);\n stamp = new StaleCoin(treasury);\n drops = new TokenDrops(stamp, IDropsPad(address(new StalePad())), IDropsPostOffice(address(office)), vm.addr(signerKey), treasury);\n vm.startPrank(treasury);\n coin.approve(address(drops), type(uint256).max);\n drops.createDrop(address(coin), 1e18, 10, 10, 0, drops.today(), 7, 100e18);\n vm.stopPrank();\n }\n\n function _voucher(uint256 id, uint32 day, uint16 coins, uint64 deadline) internal view returns (bytes memory) {\n bytes32 structHash = keccak256(abi.encode(drops.FINDS_TYPEHASH(), alice, id, day, coins, deadline));\n bytes32 domain = keccak256(\n abi.encode(\n keccak256(\"EIP712Domain(string name,string version,uint256 chainId,address verifyingContract)\"),\n keccak256(\"Courier World Drops\"),\n keccak256(\"1\"),\n block.chainid,\n address(drops)\n )\n );\n (uint8 v, bytes32 r, bytes32 s) = vm.sign(signerKey, keccak256(abi.encodePacked(\"\\x19\\x01\", domain, structHash)));\n return abi.encodePacked(r, s, v);\n }\n\n /// Vouchers for yesterday (D-1) and today (D) are fetched at 23:59:30 on day D with a one hour deadline, as the\n /// server issues them. The transaction lands at 00:00:10 on D+1. The D-1 voucher is now outside its claim\n /// window (\"would pay nothing\"); the day-D voucher is still valid and should be paid.\n function test_StaleYesterdayVoucherShouldNotBlockTodays() public {\n uint32 day = drops.today() + 1; // D\n vm.warp(uint256(day + 1) * 1 days - 30); // 23:59:30 on day D\n uint64 deadline = uint64(block.timestamp + 1 hours);\n TokenDrops.Claim[] memory cs = new TokenDrops.Claim[](2);\n cs[0] = TokenDrops.Claim(0, day - 1, 3, deadline, _voucher(0, day - 1, 3, deadline));\n cs[1] = TokenDrops.Claim(0, day, 2, deadline, _voucher(0, day, 2, deadline));\n\n vm.warp(uint256(day + 1) * 1 days + 10); // 00:00:10 on day D+1: still inside the deadline\n vm.prank(alice);\n uint256 total = drops.claimMany(cs);\n assertEq(total, 2e18, \"today's finds are paid even though yesterday's window has closed\");\n assertEq(coin.balanceOf(alice), 2e18);\n }\n}","reproduction":"Drop 0: coin, perCoin 1e18, spots 10, maxPerWallet 10, dailyCoins 0, from day D-1 for 7 days, 100e18 in. Alice has an open office. At block.timestamp = (D+1)*86400 - 30 (23:59:30 on day D) the signer signs Finds(alice, 0, D-1, 3, deadline = now + 3600) and Finds(alice, 0, D, 2, same deadline). Alice calls claimMany([both]) at block.timestamp = (D+1)*86400 + 10 (00:00:10 on D+1, inside the deadline). Expected per the NatSpec: the D-1 entry pays nothing and is skipped, the D entry pays 2e18, total 2e18. Actual: the call reverts with TooLate() and nothing is paid; claim() with the D entry alone pays 2e18. The attached proof fails on this code with TooLate().","severity":"low","snippet":" total += _claim(c.drop, c.day, c.coins, c.deadline, c.signature);","title":"claimMany is all-or-nothing: one voucher that is TooLate, Expired, FutureDay or NotRunning reverts the whole batch, contrary to its NatSpec, and the server's yesterday+today batches hit this at midnig"},{"citation":"resolved","description":"withdraw zeroes `left` but never touches startDay/endDay. For a running drop taken back under pause (the documented emergency path) activeDrops(day) still lists it for every remaining day after unpausing, so the room (multiplayer/src/index.js dropsOn/layDrops) keeps placing its `spots` coins and signing vouchers for finds, the UI shows a live drop with left == 0, and every claim(id, day, n, ...) reverts NothingToClaim (inside claimMany the entry is silently skipped). The web copy for IsPaused ('Your finds stay claimable until the day after') is not true once the owner has withdrawn. The owner has to remember a separate endDrop, which still leaves today's coins out. The same state arises when a drop with dailyCoins = 0 simply runs dry. Within the owner's documented powers and not a loss of funds; reported because the on-chain list the server trusts is wrong. Merged from audit_permissions and audit_economics, reproduced. Fix: have withdraw end the drop the way endDrop does (endDay = startDay - 1 if not started, else min(endDay, today())) unless it is already over, or require endDrop first when paused; alternatively have the server skip drops whose `left` is below `perCoin`.","line":302,"path":"contracts/src/TokenDrops.sol","proof":"// SPDX-License-Identifier: MIT\npragma solidity ^0.8.26;\n\nimport {Test} from \"forge-std/Test.sol\";\nimport {TokenDrops, IDropsPad, IDropsPostOffice} from \"src/TokenDrops.sol\";\nimport {IERC20} from \"@openzeppelin/contracts/token/ERC20/IERC20.sol\";\n\ncontract PlainCoin {\n string public name = \"Coin\";\n string public symbol = \"COIN\";\n uint8 public decimals = 18;\n uint256 public totalSupply;\n mapping(address => uint256) public balanceOf;\n mapping(address => mapping(address => uint256)) public allowance;\n\n constructor(address to, uint256 amount) {\n balanceOf[to] = amount;\n totalSupply = amount;\n }\n\n function approve(address s, uint256 a) external returns (bool) {\n allowance[msg.sender][s] = a;\n return true;\n }\n\n function transfer(address to, uint256 a) external returns (bool) {\n balanceOf[msg.sender] -= a;\n balanceOf[to] += a;\n return true;\n }\n\n function transferFrom(address f, address to, uint256 a) external returns (bool) {\n allowance[f][msg.sender] -= a;\n balanceOf[f] -= a;\n balanceOf[to] += a;\n return true;\n }\n}\n\ncontract StubPad {\n mapping(address => uint64) public created;\n\n function add(address t) external {\n created[t] = uint64(block.timestamp);\n }\n\n function launches(address t) external view returns (address, address, uint64, uint64, bool) {\n return (address(0), address(0), created[t], 0, false);\n }\n}\n\ncontract StubOffice {\n function offices(address) external pure returns (bool, uint8, uint8, uint16, uint64, address, uint256, uint256, uint256) {\n return (true, 0, 0, 0, 0, address(0), 0, 0, 0);\n }\n}\n\n/// Withdrawing a running drop while paused empties it but leaves it running: once unpaused, activeDrops still\n/// lists it, so the game server keeps laying its coins out and signing vouchers that pay nothing.\ncontract DropsWithdrawLeavesActiveTest is Test {\n TokenDrops drops;\n PlainCoin coin;\n PlainCoin stamp;\n StubPad pad;\n address treasury = makeAddr(\"treasury\");\n uint256 constant PER = 1_000e18;\n\n function setUp() public {\n vm.warp(30 days);\n stamp = new PlainCoin(treasury, 1e24);\n coin = new PlainCoin(treasury, 1e27);\n pad = new StubPad();\n pad.add(address(coin));\n drops = new TokenDrops(\n IERC20(address(stamp)), IDropsPad(address(pad)), IDropsPostOffice(address(new StubOffice())), vm.addr(1), treasury\n );\n vm.prank(treasury);\n coin.approve(address(drops), type(uint256).max);\n }\n\n function test_AWithdrawnDropIsNotStillOut() public {\n uint32 day = drops.today();\n vm.startPrank(treasury);\n uint256 id = drops.createDrop(address(coin), PER, 10, 5, 0, day, 30, 100_000e18);\n drops.setPaused(true);\n drops.withdraw(id, treasury);\n drops.setPaused(false);\n vm.stopPrank();\n\n assertEq(drops.drop(id).left, 0);\n // Tomorrow the server reads the running drops to lay coins out: an empty drop must not be among them.\n vm.warp(block.timestamp + 1 days);\n assertEq(drops.activeDrops(day + 1).length, 0, \"an emptied drop is still laid out\");\n }\n}","reproduction":"createDrop(coin, 1000e18, 10, 5, 0, today, 30, 100_000e18) as id; owner: setPaused(true); withdraw(id, treasury); setPaused(false). Expected: the drop is no longer listed as having coins out. Actual: drop(id).left == 0 yet activeDrops(today + 1) == [id] (and so for the next 28 days); a player's claim(id, today + 1, 1, deadline, sig) reverts NothingToClaim. The attached proof fails on this code with 'an emptied drop is still laid out: 1 != 0'.","severity":"low","snippet":" d.left = 0;","title":"withdraw while paused empties a running drop but leaves it in activeDrops, so the game keeps laying out and signing coins that pay nothing"},{"citation":"resolved","description":"claimable() is the public quote the front end reads (web/chain.js claimable) and the project's fuzz test uses to decide whether a claim is worth sending. It applies maxPerWallet, the pool and dailyCoins, but not startDay/endDay, FutureDay, TooLate or paused, which _claim() enforces at lines 212-217 and _checkClaimer() at 202 before calling it. The view therefore returns a non-zero (n, amount) for a future day, a day whose two-day window has closed, a day the drop was not running, and while paused. Harmless inside _claim() because the window checks run first; the gap is only in what integrators are told. Fix: return (0, 0) at the top of claimable() when `paused || day > today() || today() >= day + CLAIM_DAYS || day < d.startDay || day > d.endDay`, keeping the explicit reverts in _claim() for error reporting.","line":160,"path":"contracts/src/TokenDrops.sol","reproduction":"createDrop(coin, 1e18, 10, 10, 0, D, 1, 100e18): a one-day drop. claimable(id, alice, D+5, 3) returns (3, 3e18) although claim(id, D+5, 3, deadline, sig) reverts FutureDay(); claimable(id, alice, D-3, 3) returns (3, 3e18) although claim() reverts TooLate(); after setPaused(true) claimable(id, alice, D, 3) still returns (3, 3e18). Expected (0, 0) in each case. Reproduced in test/scratch/JudgeProbe.t.sol::test_ClaimableIgnoresWindow (passes on this code, documenting the behaviour).","severity":"info","snippet":" function claimable(uint256 id, address player, uint32 day, uint16 coins) public view returns (uint16 n, uint256 amount) {","title":"claimable() ignores the claim window, the drop's days and pause, so it quotes payouts for days and states claim() rejects"},{"citation":"resolved","description":"These are the powers the brief asks for and they are implemented as specified (Ownable2Step, renounce disabled, so there is always an owner); none is a permission bypass. Recorded so the requester can weigh them and correct AUDIT.md section 13 where it overstates the protection. (1) setPaused(true); withdraw(id, to); setPaused(false) succeed as three calls in one block, so the statement that the owner 'can withdraw a running drop only by pausing first, which stops all claims, so players see it happen' gives players no actual window: finds have no on-chain record until claimed, so vouchers for today and yesterday that were still inside their window pay nothing afterwards. (2) setSigner(anyAddress) lets the owner install a key it controls and sign Finds for any wallet with an office, so a running drop's tokens can leave without any paused state, bounded only by maxPerWallet, dailyCoins and the pool (it is the treasury's own deposit, so no third-party loss, but the signer role is no independent check on the owner). (3) endDrop takes no day: an endDrop sent at 23:59:59 on day D and mined at 00:00:01 on D+1 ends on D+1 (`last = today()`), one extra day of coins. (4) The signer is a hot key in the server's environment (DROPS_KEY) and the sole authority for payouts; its blast radius is the subject of the medium finding. Merged from four specialists' trust entries, all reproduced. Optional narrowing that keeps the design: require a drop to be ended (or endDay + CLAIM_DAYS passed) before withdraw-while-paused unless an explicit emergency flag is passed; give endDrop an intended last-day parameter and revert if today() is already past it; emit the previous signer in SignerSet.","line":300,"path":"contracts/src/TokenDrops.sol","reproduction":"(1) createDrop(coin, 1e18, 10, 10, 0, today, 30, 100e18); alice holds a valid voucher for 1 coin today. Owner in one block: setPaused(true); withdraw(id, treasury); setPaused(false). All succeed; alice's claim(id, today, 1, ...) reverts NothingToClaim; treasury holds the 100e18 (test/scratch/JudgeProbe.t.sol::test_PauseWithdrawUnpauseAtomic). (2) Owner calls setSigner(A) where A is its own key, signs Finds(W, id, today, 10, now+3600) for office wallet W and W calls claim: 10e18 moves with paused == false (same mechanism as the shipped test_NewSignerOnly). (3) Drop endDay = D+29; owner's endDrop(id) mined at (D+1)*86400 + 1: drop(id).endDay == D+1, not D (test_EndDropAcrossMidnight).","severity":"info","snippet":" if (!paused && !cancelled && today() < d.endDay + CLAIM_DAYS) revert StillRunning();","title":"Owner powers recorded as trust assumptions: pause+withdraw(+unpause) can be atomic and takes tokens players have found but not claimed; setSigner lets the owner author vouchers; endDrop cannot express"},{"citation":"resolved","description":"Drop isolation is done correctly through per-drop `left` (verified: two drops of the same token keep their balances apart through a drain of one and a paused withdraw of the other, test/scratch/JudgeProbe.t.sol::test_SameTokenIsolation). The flip side is that any balance that is not some drop's `left` has no owner: a treasury transfer made directly instead of through topUp, or a launchpad token airdropped to the address, can never be recovered. Self-inflicted and low impact; a sweep of `balanceOf(token) - sum of that token's left` (tracked per token in createDrop/topUp/_claim/withdraw), owner only, would recover it.","line":301,"path":"contracts/src/TokenDrops.sol","reproduction":"Drop 0 of coin with 10e18. Treasury calls coin.transfer(drops, 5e18) directly. Owner: setPaused(true); withdraw(0, treasury). Expected: the treasury can recover everything it put in. Actual: coin.balanceOf(drops) == 5e18 with drop(0).left == 0 and no function that moves it (test_DirectTransferStuck).","severity":"info","snippet":" uint256 amount = d.left;","title":"Tokens sent straight to the contract, or any balance above the drops' summed `left`, are stranded: withdraw only moves a drop's own `left` and there is no sweep"},{"citation":"resolved","description":"The owner holds every treasury power over the drops (fund, end, pause, withdraw, set signer) and ownership can only move in two steps, never be renounced. The script falls back to msg.sender for the owner and deploy-drops.sh relies on the operator remembering to 'sign with the treasury'. If the broadcast is signed with another deployer key, the drops are owned by it until a transferOwnership/acceptOwnership round and the treasury's createDrop reverts OwnableUnauthorizedAccount. Suggest requiring DROPS_OWNER on chain 4663 (as PAD is required) or asserting owner == the treasury recorded in deployments/robinhood.json before broadcasting.","line":30,"path":"contracts/script/DeployTokenDrops.s.sol","reproduction":"Run `DROPS_SIGNER=0x... ./script/deploy-drops.sh --broadcast --sender ` with DROPS_OWNER unset. Expected: the treasury owns TokenDrops. Actual: owner == (line 30 picks msg.sender); treasury.createDrop(...) reverts OwnableUnauthorizedAccount(treasury) until ownership is transferred and accepted.","severity":"info","snippet":" address owner = vm.envOr(\"DROPS_OWNER\", msg.sender);","title":"Deploy script defaults the drops owner to the broadcasting key when DROPS_OWNER is unset"},{"citation":"resolved","description":"setUp warps to exactly 30 days and every later warp adds whole days, so every claim, endDrop and withdraw in the suite runs at the first second of a day (no '86400 - 1' or 'hours' warp exists). The day-edge rules (line 215 `now_ >= day + CLAIM_DAYS`, line 300 `today() < d.endDay + CLAIM_DAYS`) are never asserted at 23:59:59 against 00:00:00, which is where claimMany's atomicity bites and endDrop's timing matters. Also untested: more wallets than `spots` claiming on one day with dailyCoins = 0 (testFuzz_NeverOverpays uses two wallets with maxPerWallet 8 against spots 10, so it can never cross spots); claimMany with one stale or expired entry; claimable() for a day outside the drop or the window, or while paused; two drops of the same token with one drained and the other withdrawn under pause; a drop whose `left` is 0 still appearing in activeDrops; dailyCoins > spots being accepted; a $STAMP drop claimed against GOLDEN_SPOTS. The exact-second day edge, same-token isolation and replay-after-topUp checks pass in test/scratch/JudgeProbe.t.sol (the design holds there); the others surface the findings above. Merged from three specialists.","line":80,"path":"contracts/test/TokenDrops.t.sol","reproduction":"Observed from the test source: setUp() sets block.timestamp = 30 days (line 80) and every later warp is vm.warp(vm.getBlockTimestamp() + N days), so block.timestamp % 86400 == 0 in every test. Adding vm.warp(uint256(day + 2) * 1 days - 1) before a claim for `day` and vm.warp(uint256(day + 2) * 1 days) before the next claim and a withdraw gives assertions the suite lacks (both hold on this code: test_DayEdgeExactSeconds). A three-wallet claim on a dailyCoins = 0 drop asserting paidCoins <= spots fails on this code.","severity":"info","snippet":" vm.warp(30 days);","title":"Test suite pins every timestamp to 00:00:00 UTC and never exercises many wallets in one day, a failing batch entry, same-token isolation or claimable() outside the window"}],"hash":"a289264e76180c4657d1b1752c9231a4533127cd46c3abaf1445bb8d52355015","nodeId":"1ae9d960-1ebc-4ee9-9562-6343b699dc32","outcome":"completed","summary":"The review is complete and written to `.imd-findings.json` in the repository root, with 8 merged findings. No source files were changed.\n\n**What I verified**\n\n- The shipped suite passes (23 tests). All four specialist proofs fail on the current code for exactly the reason each finding states. I wrote and ran my own probe suite covering exact-second day edges, same-token isolation, voucher replay after a top-up, and the quote view. The core design holds: a day's finds pay on D and D+1 only, withdraw opens exactly when claims close, tokens of two drops never mix, vouchers cannot be replayed across drops, days or wallets, and reentry is blocked.\n- The `IDropsPad` and `IDropsPostOffice` tuples match the real CourierPad and PostOffice struct layouts, and both payable tokens are plain ERC-20s.\n\n**Findings kept, deduplicated from 20 specialist entries**\n\n1. **Medium, proof attached.** A day's payout is never bounded by `spots`, and `dailyCoins` may be 0 or above `spots`. Two wallets were paid 20 coins on a day with 10 out. A leaked signer key, the contract's own stated threat, drains a whole pool in one day, and AUDIT.md's \"up to each drop's daily limits\" is untrue for the default. Merged from four specialists.\n2. **Low, proof attached.** `claimMany` reverts the whole batch on one TooLate, Expired, FutureDay or NotRunning entry, contrary to its NatSpec. The server issues yesterday+today batches with a one hour deadline, so this bites at midnight UTC. Merged from four.\n3. **Low, proof attached.** `withdraw` while paused zeroes `left` but leaves the drop in `activeDrops`, so the room keeps laying out and signing coins that pay nothing. Merged from two.\n4. **Info.** `claimable()` quotes payouts for future days, closed windows, inactive days and while paused.\n5. **Info.** Owner trust assumptions: pause, withdraw and unpause are atomic in one block, `setSigner` lets the owner author vouchers, and `endDrop` across midnight ends a day late. Merged from four.\n6. **Info.** Tokens sent directly to the contract are stranded with no sweep.\n7. **Info.** The deploy script defaults the owner to the broadcasting key when `DROPS_OWNER` is unset.\n8. **Info.** Test suite gaps: every timestamp is 00:00:00 UTC, and the many-wallets, failing-batch, isolation and quote edges are untested. Merged from three.\n\nNothing was dropped as non-reproducing. Every specialist claim reproduced, so the work was merging and ranking. Scratch tests were removed after the run.","treeHash":null,"usage":{"cachedInputTokens":862910,"inputTokens":322,"model":"claude-fable-5-1","outputTokens":20368,"runtime":"claude","turns":20,"wallClockMs":346842}},{"artifacts":[],"attempt":1,"bundleHash":null,"device":"e06554fd2816f9d7","findings":[{"citation":"resolved","description":"claimMany is documented as 'any that would pay nothing are skipped', but _claim reverts (Expired, TooLate, FutureDay, NotRunning, UnknownDrop, BadSignature) before reaching the pays-nothing path, and claimMany has no per-item try/skip. The game's server (multiplayer/src/index.js, 'vouchers') always signs vouchers for day-1 and day together with a 3600 s deadline, and the web client (web/chain.js claimAll) submits them all in one claimMany. A batch fetched shortly before midnight UTC and mined after it carries a day-1 voucher that is now TooLate, so the whole transaction reverts and the still-valid vouchers for day (yesterday, by then) are not paid in that transaction. The player loses the gas and must fetch new vouchers and retry; a voucher whose 1-hour deadline lapsed between fetch and mining has the same effect. No funds are at risk, but the batch semantics contradict the NatSpec and the integration relies on them. Fix: in claimMany, check the window/deadline conditions per item and `continue` on a stale one (or wrap each _claim so only signature failures revert), keeping the final `total == 0` revert.","line":196,"path":"contracts/src/TokenDrops.sol","reproduction":"Drop id 0 (coin, perCoin 1e18, spots 10, maxPerWallet 10, dailyCoins 0, startDay today, 7 days, 1000e18). Player a has an open office. Build claims = [ {drop 0, day today, coins 3, deadline now+1h, valid sig}, {drop 0, day today, coins 3, deadline now+10s, valid sig} ]; warp 11 s; a calls claimMany(claims). Expected (per the function's NatSpec): first item pays 3e18, second is skipped. Actual: the call reverts with Expired() and nothing is paid. Same with the second item being day = today-1 submitted on today+1 (TooLate). Shown by test/scratch/Probe.t.sol::test_ClaimManyRevertsOnOneStale, which passes with vm.expectRevert(TokenDrops.Expired.selector).","severity":"low","snippet":" total += _claim(c.drop, c.day, c.coins, c.deadline, c.signature);","title":"claimMany reverts the whole batch when one voucher is stale, so today's valid finds are not paid"},{"citation":"resolved","description":"createDrop enforces maxPerWallet <= spots but puts no bound on dailyCoins (0 means unlimited, and any value above spots is accepted), and _claim/claimable never compare paidCoins[id][day] with d.spots. 'Coins out in the world each day' is therefore only a hint to the game server; on-chain the only per-day limit across everyone is dailyCoins, which the brief's own defaults leave at 0. With an honest server this is harmless because it only signs for coins it laid out (at most spots per drop per day). But the contract's stated threat (NatSpec on setPaused: 'if the server key leaks') is exactly the case where the server is not honest: whoever holds the key can sign Finds vouchers for any wallets with an open office (an office costs 0.005 ETH and is permanent), each for maxPerWallet coins, for today and yesterday, and so take ceil(left / (maxPerWallet*perCoin)) offices' worth of claims per day per drop until the owner notices and pauses. A per-day ceiling of spots coins (paidCoins[id][day] + n <= spots, or dailyCoins defaulting to spots and validated <= spots) would cap the loss from a leaked key at spots*perCoin per drop per day, which is the amount the game actually puts out, at no cost to honest play. Severity low because it needs the key compromise the design already treats as the emergency case; reported because the brief asks that 'no drop can pay more than its caps allow' and 'coins out per day' is one of the listed caps.","line":255,"path":"contracts/src/TokenDrops.sol","reproduction":"Owner creates drop 0: coin, perCoin 1e18, spots 10, maxPerWallet 10, dailyCoins 0, startDay today, 7 days, amount 1000e18. Three wallets a, b, c with open offices each present a signer voucher Finds(wallet, 0, today, 10, deadline) and call claim. Expected if 'coins out per day' were a cap: at most 10 coins (10e18) paid for today across everyone. Actual: all three claims succeed; paidCoins(0, today) == 30 and 30e18 has left the drop on a day with 10 coins out (test/scratch/Probe.t.sol::test_PaysMoreCoinsThanSpots logs paidCoins 30, spots 10). createDrop(coin, 1e18, 10, 10, 1000, today, 7, 1000e18) is also accepted with dailyCoins 1000 > spots 10 (test_DailyAboveSpots).","severity":"low","snippet":" perCoin == 0 || spots == 0 || spots > MAX_SPOTS || maxPerWallet == 0 || maxPerWallet > spots || days_ == 0","title":"Coins paid per day are not bounded by spots: dailyCoins may exceed spots or be unlimited, so a leaked signer key can drain a drop's whole pool in one day"},{"citation":"resolved","description":"withdraw under pause zeroes d.left but leaves startDay/endDay untouched, so activeDrops(day) still lists the drop. The server (multiplayer/src/index.js dropsOn/layDrops) lays out the drop's `spots` coins from activeDrops and signs vouchers for finds; claim then returns 0 from claimable and claim() reverts NothingToClaim (claimMany silently pays nothing). Players spend effort hunting coins the treasury has already taken back, and the web's IsPaused copy ('Your finds stay claimable until the day after') is not true once the owner has withdrawn. The same state arises when a drop simply runs out of tokens with dailyCoins 0. Not a loss of funds and within the owner's documented powers; suggested: have withdraw also end the drop (set endDay = today() or cancel it) unless the owner intends to top it up, or have the server skip drops whose `left` is below perCoin.","line":302,"path":"contracts/src/TokenDrops.sol","reproduction":"Owner: createDrop(coin, 1e18, 10, 10, 0, today, 30, 500e18); setPaused(true); withdraw(0, treasury); setPaused(false). activeDrops(today) still returns [0] and drop(0).left == 0. Player with voucher Finds(alice, 0, today, 1, dl): claim(0, today, 1, dl, sig) reverts NothingToClaim (the existing test_PauseStopsClaimsAndFreesTheTokens asserts exactly this revert). Expected from the game's point of view: the drop is no longer listed as having coins out.","severity":"info","snippet":" d.left = 0;","title":"A drop emptied by withdraw-while-paused (or run dry) stays active, so the game keeps laying out coins that pay nothing"},{"citation":"resolved","description":"Documented powers, recorded here as the trust model rather than as defects. Owner (planned: the treasury EOA 0x72215670C2266Bc224949A12C514a77D7fD5D566, a single key; Ownable2Step, renounce disabled): createDrop/topUp with its own tokens; endDrop (never earlier than today, so finds already made keep their window); setSigner at will (so the owner can sign itself vouchers for the tokens it funded, which is self-dealing only); setPaused, which blocks all claims and unlocks withdraw(id, to) for any drop mid-run, i.e. the owner can at any moment take back tokens that players have earned vouchers for but not yet claimed (finds have no on-chain record until claimed). Signer: an EOA whose private key lives in the game server's environment (DROPS_KEY); it is the sole authority for what is paid; if leaked, the loss until pause is bounded per drop per day only by maxPerWallet * perCoin * (number of open offices the attacker controls) and dailyCoins (see the related low finding), not by spots. Both keys deserve the usual hardening: a multisig or hardware-backed owner, a signer kept out of general server logs and rotated with setSigner, and an alert on Claimed volume. No code change is required by this entry.","line":300,"path":"contracts/src/TokenDrops.sol","reproduction":"State: drop 0 running, player alice holds a valid voucher for today's 5 coins but has not claimed. Owner calls setPaused(true) then withdraw(0, treasury): drop 0's full `left` moves to the treasury (test_PauseStopsClaimsAndFreesTheTokens shows the same sequence). Alice's subsequent claim pays nothing. Expected per design: allowed (NatSpec of withdraw); listed so the requester records it as an accepted trust assumption.","severity":"info","snippet":" if (!paused && !cancelled && today() < d.endDay + CLAIM_DAYS) revert StillRunning();","title":"Trust assumptions: the owner key can take every drop's tokens at any time via pause, and the signer is a hot key whose compromise is bounded only by caps and pause"},{"citation":"resolved","description":"The owner holds every treasury power over the drops (fund, end, pause, withdraw, set signer) and ownership cannot be renounced, only handed over in two steps. The script falls back to msg.sender for the owner, and deploy-drops.sh relies on the operator remembering to 'sign with the treasury'. If the broadcast is signed with a different deployer key (as the other deploy scripts' --sender flow allows), the drops are owned by that key until a transferOwnership/acceptOwnership round, and the treasury's createDrop calls revert with OwnableUnauthorizedAccount. Suggest requiring DROPS_OWNER on chain 4663 (like PAD) or printing/asserting that owner == the treasury in deployments/robinhood.json before broadcasting.","line":30,"path":"contracts/script/DeployTokenDrops.s.sol","reproduction":"Run `DROPS_SIGNER=0x... ./script/deploy-drops.sh --broadcast --sender ` with DROPS_OWNER unset. Expected: the treasury 0x7221...D566 owns TokenDrops. Actual: owner == ; treasury.createDrop(...) reverts OwnableUnauthorizedAccount(treasury) until ownership is transferred and accepted.","severity":"info","snippet":" address owner = vm.envOr(\"DROPS_OWNER\", msg.sender);","title":"Deploy script defaults the drops owner to the deployer key when DROPS_OWNER is unset"},{"citation":"resolved","description":"The suite is good on the happy paths and on per-drop caps, but several of the edges named in the brief are not exercised: (1) two drops funded with the same token, with one withdrawn under pause and the other still paying (tokens never mix); (2) the exact withdraw boundary, first second of endDay+2, where withdraw must succeed and a claim for endDay must be TooLate in the same block; (3) claimMany containing one stale or expired voucher alongside valid ones (which reverts the batch; see the low finding); (4) replaying a voucher after a pause/withdraw/topUp cycle, confirming claimed[] persists so nothing is double-paid; (5) a claim for a day the drop was active on but with the voucher's `coins` lower than already claimed (non-monotonic server values); (6) dailyCoins larger than spots. Scratch tests for (1), (2), (3) and (6) in test/scratch/Probe.t.sol all pass against the current code and could be moved into the suite.","line":467,"path":"contracts/test/TokenDrops.t.sol","reproduction":"For (1): createDrop(coin,...,100e18) as x and createDrop(coin,...,200e18) as y; setPaused(true); withdraw(x); setPaused(false); claim 10 coins of y pays 10e18 and coin.balanceOf(drops) was 200e18 after the withdraw. For (2): createDrop(..., startDay today, days 1); vm.warp((today+2)*1 days); withdraw(id) succeeds; claim(id, today, 1, ...) reverts TooLate. Both hold today but are untested.","severity":"info","snippet":" /// Whatever wallets claim, in any order, a drop never pays more than it holds or than its limits allow.","title":"Test suite gaps around the edges the brief asks about"}],"hash":"d80608422b18fb90f7b090b50b32b61b47f649f920243b85385ed3a6719ad9bd","nodeId":"fc0541f0-fd38-4440-90b1-5f96e210b3bd","outcome":"completed","summary":"The review is complete. The findings file at the repository root holds six entries, none above low severity, and no tracked file was changed.\n\n**What was checked.** I traced every entry point of `contracts/src/TokenDrops.sol` against the Access Control, Trust Gap and Asymmetry guides and the brief's list: pool and cap enforcement, token separation across drops, voucher replay across drops, days, wallets, contracts and chains, the claim window and day edges, reentry, the owner's powers, and the withdraw rules. I also read the game server's voucher signing and the web client's claim flow, and confirmed on Robinhood Chain that the deployed PostOffice and CourierPad getters decode with the shapes the drops interface expects. Scratch Foundry tests under `contracts/test/scratch/` exercised the edges the suite does not.\n\n**What holds.** Each drop pays only from its own `left`, bounded by its per-wallet and daily caps, with checks before the transfer and a reentrancy guard. Vouchers bind player, drop, day, coins and deadline under an EIP-712 domain with chain id and contract address, and the cumulative `claimed` counter makes any replay pay nothing. The claim window, the ending of a drop and the withdraw rule line up exactly at the day boundaries, including the first second of endDay plus two. Two drops of the same token stay separate across a paused withdraw.\n\n**Findings written.**\n- **Low.** One stale voucher in `claimMany` reverts the whole batch, contrary to its NatSpec. The server always bundles yesterday's and today's vouchers and the web submits them together, so a batch mined just after midnight UTC fails and today's valid finds go unpaid until a retry.\n- **Low.** Coins paid per day are never bounded by `spots`, and `dailyCoins` is unvalidated with zero meaning unlimited. Three wallets were paid thirty coins on a day with ten coins out. With an honest server this is moot, but it sets the blast radius if the signer key leaks.\n- **Info.** A drop withdrawn under pause stays listed as active with nothing left, so the game lays out coins that pay nothing.\n- **Info.** Trust assumptions recorded: the owner key can pause and take back any drop's tokens at any time, and the signer is a single hot key in the server's environment.\n- **Info.** The deploy script defaults the owner to the deployer when `DROPS_OWNER` is unset.\n- **Info.** Test gaps: same-token drops, the exact withdraw boundary, mixed-validity batches, replay after a pause and top-up cycle.\n\nNo critical or high finding exists, so no proof test files were attached. The existing suite of 23 tests passes on this commit.","treeHash":null,"usage":{"cachedInputTokens":1625835,"inputTokens":450,"model":"claude-fable-5-1","outputTokens":32979,"runtime":"claude","turns":29,"wallClockMs":476310}}],"verification":[]}