The Scoop (SCOOP) token project is complete, verified, and committed on main.

What was built

• src/ScoopToken.sol is a self-contained, fixed-supply ERC-20. The constructor takes no arguments and mints 1,000,000,000 SCOOP with 18 decimals once to the deployer, which is the launch factory at launch. There is no owner, minter, pause, fee, blocklist, burn, proxy or external call, so the supply can never grow and every launch flow moves exactly what it says.
• test/ScoopToken.t.sol holds 32 tests covering success paths, failure paths with specific custom errors, fuzzed supply conservation and allowance handling, deployment through a CREATE2 factory probe, and mirrors of the protected floor's checks. The mirrored checks include the admin and freeze selector sweeps and the runtime opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT.
• script/DeployScoop.s.sol offers a manual deploy helper whose deploy() function the tests call directly. It reads no environment variables.
• foundry.toml pins solc 0.8.26 by version, sets bytecode_hash = "none", disables ffi and filesystem access. forge-std v1.14.0 is vendored under lib/ as 31 plain files with no nested git metadata or submodule.
• README.md documents behaviour, assumptions, the launch's deployment parameters for the manifest step, manual deployment, operational responsibilities, and the security checklist review.

Verification results

Check	Result
forge build	passes
forge test	32 passed, 0 failed
forge fmt --check	passes
Offline build and test with empty environment	passes
Built runtime contains CBOR metadata	no
Nested .git, submodule, launch.json, .env in tree	none

Notes for the next steps

• No launch.json was written, by design. The README lists the values the manifest step needs.
• The protected floor test itself could not be executed here because it depends on the harness's own v4-core and LaunchLiquidity sources, which were not provided. The tests mirror its token-facing assertions instead.
• Only Foundry's compiler and tests ran. Slither and Mythril were not available, which the README records as an open item.

I found no math, precision or boundary defects in src/ScoopToken.sol that put value at risk. The one thing I report is an informational quirk, and the results are in .imd-findings.json.

Finding 1 (info): anyone can call transferFrom(address(0), to, 0) and it succeeds. The sender is never checked for the zero address (the check sits at src/ScoopToken.sol:116 and only covers the recipient). At amount 0 the allowance and balance checks both pass, so the call emits Transfer(0x0, to, 0). That is the standard mint signal, so an off-chain supply tracker could log mints on a token documented as minting only once. Balances and supply don't change. OpenZeppelin's ERC-20 reverts in this case; the fix is one line adding a zero-address check on the sender in _transfer.

What I checked against the three guides:

• The two unchecked blocks:
  • The balance subtraction in _transfer is safe because it only runs after the balance check.
  • The recipient's balance can't overflow because all balances add up to the fixed supply of 1e27.
  • The allowance subtraction in _spendAllowance is safe for the same reason as the balance subtraction.
• Allowance edges: an unlimited allowance (type(uint256).max) is not reduced when spent, which is intended. Raising it by 1 reverts, and lowering it by 1 makes it an ordinary finite allowance.
• Off-by-one: spending one more than the balance or the allowance reverts. Zero-amount transfers work.
• Self-transfer: the balance stays the same.
• Supply constant: 1_000_000_000 * 10 ** 18 is exactly 1e27 and fits easily. Aderyn's "large numeric literal" warning on line 25 is only about style.

I wrote a throwaway Foundry test covering these cases, including two fuzz tests that check tokens are conserved across transfers. All 5 tests passed, and the project's own 32 tests still pass (37 in the full run). I then deleted the scratch test, so no repository file is changed apart from .imd-findings.json.

Coverage: all five entry points have a row. approve, increaseAllowance, decreaseAllowance and transfer hold; transferFrom points to finding 1. There is also a row for the invariant that the supply is fixed and never grows. The token has no owner, fees or mint path, so the rest of the math checklist (fees, rounding, price math) has nothing to apply to. There is no launch.json in the tree yet, so I did not review a manifest.

Done. I wrote launch.json describing the accepted Scoop launch, and it is the only changed file.

What the manifest says

• Kind custom_token, token contract ScoopToken, name Scoop, symbol SCOOP, 18 decimals.
• Constructor arguments are an empty list. The compiled ABI confirms the constructor takes no inputs, and it mints the whole supply to msg.sender once.
• Total supply is 1000000000000000000000000000 minor units, matching the INITIAL_SUPPLY constant in the source.
• No application contracts. The tree holds only the token, a manual deploy script and tests.
• Pool and economics are copied exactly from the launch terms: IMD pair at the given address, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's economics object verbatim.
• Notes explain the token's behavior and why it takes no launch placeholders, at 1473 characters.

Checks run

• A scratch script confirmed the manifest has only the schema's top-level keys, strings for uint256 and address fields, numbers for fee, tickSpacing and decimals, lowercase addresses, and the verbatim economics.
• forge build succeeded and forge test passed all 32 tests.
• git status shows launch.json as the only new or changed path.

The findings file is in place at the repository root, the scratch tests are removed, and the tracked tree is unchanged.

Result: no defects found in the Economic Security, Invariant and Flow Gap areas. The findings list is empty and the coverage record answers all five entry points as holds, plus six invariant and flow rows.

What I checked

• Economic Security. The token has no external dependencies, no oracle, no callbacks and no fee, tax, reflection, pause, blocklist or exemption list. Every ERC-20 function returns a well-formed true, which is what the Uniswap v4 currency library expects from its low-level call. A scratch probe that settles the way the PoolManager does, by balance difference, credited exactly the amount sent in both directions.
• Invariant. The sum of balances equals the fixed supply of 1,000,000,000e18. Only one private function writes balances and it subtracts and adds the same amount. A Foundry invariant run of 256 sequences and 128,000 random transfer and transferFrom calls over five actors never broke it. The supply is an immutable, the ABI exposes no mint, burn, owner, initializer, receive or fallback, and transfer to the zero address reverts, so no path grows or shrinks it. Self-transfer through both paths keeps the balance; the allowance underflow and overflow boundaries revert.
• Flow Gap. The factory to distributor to claimant flow moves 10 percent whole and drains the distributor to exactly zero. The pool seed and swaps see no shortfall. The whole supply, 1e27, fits the int128 deltas the PoolManager uses. Constructor takes no arguments, so CREATE2 with empty constructorArgs deploys it unchanged and all supply lands on the factory.
• Static analysis leads. The single aderyn low on the large numeric literal at line 25 is a style note; the literal equals the manifest supply exactly and is not a defect.

Trust assumptions. None in the code. The only custodial point is whoever controls the remainder address, which is launch policy rather than token code.

Not covered. The deployer's liquidity math and the opening price derivation are outside the token and I did not evaluate them.

The review is complete. The source tree is unchanged, and the findings file is in place.

Outcome. The Scoop token has no privileged surface at all, so the Access Control and Trust Gap guides produce no findings. One low-severity Asymmetry defect is substantiated and recorded in .imd-findings.json, with a Foundry proof under test/scratch/ that fails on the current code and passes with the one-line fix.

Finding 1 (low), src/ScoopToken.sol:115. The internal transfer helper rejects a zero recipient but never checks the sender. Any account can call transferFrom(address(0), anyone, 0) with no allowance, and the token emits an Approval and a Transfer from the zero address. That is the same event shape the constructor uses for the one real mint, so explorers and indexers label it a mint. No balance or supply changes, since the zero address can never hold tokens and a non-zero amount reverts. Impact is limited to off-chain log integrity. OpenZeppelin v5 rejects this case. The fix is to add the mirrored zero-sender check at the top of the helper. I verified the fix makes the proof pass while the existing 32-test suite still passes.

What I covered in depth.

• Access Control: enumerated all five state-changing entry points plus constructor, receive and fallback. No owner, modifier, initializer, proxy, pause, blocklist, fee or exemption list exists. The constructor hands out only the supply to the deployer. The admin-style selectors the launch floor probes all revert for stranger and deployer alike.
• Trust Gap: no privileged actor exists, so no access-times-economics or access-times-asymmetry seam is reachable. The launch flows (factory to distributor, claims, pool seed, swaps) move exact amounts with no exemption logic, matching the protected test's expectations and the empty constructor arguments.
• Asymmetry: diffed transfer against transferFrom, approve against increase and decrease allowance, and both zero-address checks. Verified self-transfer, infinite allowance, max-minus-one allowance, and three-party conservation under fuzzing.

Coverage record. All five listed entry points have rows: four hold, transferFrom carries finding 1. Three additional invariant rows are included.

Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal line is the supply constant and is not a defect.

Not reached. The manifest does not exist yet, so no manifest review was possible. Nothing else in scope was left unexamined.

The review is complete and recorded in .imd-findings.json at the repository root. No source file was changed and the scratch test was removed.

Outcome: the Scoop token is sound in the assigned area. I found no defect that moves funds, grows supply, or breaks a launch flow. One informational item is reported.

What I covered

• All five state-changing entry points were traced from call to final state against the Execution Trace, Periphery and First Principles guides: parameter divergence, sentinel bypass, stale reads, partial updates, approval residuals, boundary values (zero, max, whole balance, self-transfer), and unchecked arithmetic reasoning. Each row in the coverage record carries a reason.
• Invariants checked and recorded as rows: the constructor mints exactly the stated supply once to the deployer, the supply is immutable with no mint or admin selector in the ABI, every transfer path moves exactly the requested amount so the swarm share, pool seed and swaps arrive whole, and the runtime has no dangerous opcodes or fallback.
• Periphery: the deploy script is outside the launch path and only wraps the constructor. Vendored forge-std is test tooling and not linked into the token.
• Existing suite passes (32 tests). A scratch fuzz of balance conservation across two hops also passed.

The one finding (info)

The private transfer routine rejects a zero recipient but never checks the sender. Combined with a zero-amount allowance spend that always passes, any caller with no tokens and no allowance can emit a zero-value Transfer from the zero address, which indexers read as a mint event, and a zero Approval naming any owner. Balances, allowances and total supply are untouched. A non-zero amount from the zero address reverts. The reproduction is two calls on a fresh token, confirmed with event assertions. The suggested fix is a one-line sender check that preserves all intended behaviour.

Leads from static analysis: the only tool line was a low-impact large-literal note on the supply constant. The literal equals the stated supply exactly, so it is not a defect.

Not reached: nothing inside the assigned area. The manifest and launch service checks were not in the tree and were not assessed.

Done. The suite builds with no warnings and forge test passes 86 tests across three files. Only test paths were touched, and nothing was installed.

What I added on top of the accepted unit suite, which I left untouched:

• test/ScoopToken.invariants.t.sol holds a handler and six invariants over random call sequences. The handler drives six actors plus arbitrary fuzzed recipients with bounded inputs and keeps a ghost ledger of balances and allowances. Every failure path is exercised inside the handler through try/catch with the exact custom error asserted, and the run uses fail-on-revert so a missing or half-applied revert fails the test. Invariants: fixed supply, sum of all holder balances equals supply, balances match the ghost ledger, allowances match the ghost ledger, the zero address holds nothing, and every holder can still move its whole balance after any sequence. I grounded the harness with two scratch mutants of the token (sender never debited, allowance check removed) and both were caught.
• test/ScoopToken.edges.t.sol holds 48 edge and failure-path tests: one wei, the whole supply twice, the maximum, zero to the zero address, allowance exactly one below the unlimited sentinel, the order in which transferFrom's two checks fire, the allowance decrement rolling back on a balance revert, the owner needing a self-allowance, no path that mints from the zero address, the deployer having no residual power, and a mirror of the launch flows (10% swarm, 80% pool pull, 10% remainder, seven uneven claims) arriving whole. The fuzz tests use bound only, with 1000 runs set by inline config.

Finding reported in .imd-findings.json, severity info, no proof needed: transferFrom(address(0), to, 0) succeeds for any caller and emits a mint-shaped Transfer(0x0, to, 0) event after construction. Balances and supply are unchanged and any non-zero amount reverts, so there is no exploit. I did not assert that event as correct. The implementation is otherwise sound against everything I threw at it.

Files are left uncommitted in the working tree for the pipeline to pick up, as the earlier contributor's work was.

The review is complete. The findings file is at the repository root, the snippet matches line 116 of the token exactly, and the working tree has no other changes.

Outcome: one low finding, merged from all four specialist reports.

• Zero sender accepted by transferFrom (src/ScoopToken.sol:116). The transfer helper rejects a zero recipient but never checks the sender. With amount zero, every guard passes, so anyone with no balance and no allowance can make the token emit a Transfer from the zero address, the same event shape as the one real constructor mint. Balances, allowances and supply never change, and any non-zero amount reverts, so impact is limited to off-chain log integrity. Severity is low. The specialist proof fails on the current code for the stated reason, so I kept it on the finding. The minimal fix is a matching zero-sender check at the top of the transfer helper.

What I verified myself

• The full repository suite passes, including the opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT.
• A scratch test confirmed the emitted Approval and Transfer events and both revert controls for non-zero amounts.
• All five entry points are covered: four hold, transferFrom carries the finding. I also recorded rows for the constructor's fixed supply, the manifest, and the static-analysis leads.
• The manifest uses only schema keys, has no constructor arguments to match the no-argument constructor, states the supply the constructor mints, and keeps notes under the limit.
• The aderyn large-literal lead is style only. The constant evaluates to exactly one billion times ten to the eighteenth, which a repository test asserts, so I left it out.

Nothing else was found on my own pass. The token has no privileged roles, no external calls, no receive or fallback, and its creation and runtime code are far below the size limits.