I built the IMDPot (IMDPOT) token as a Foundry project at the repository root and committed it as 4345c76. forge build, forge test (17 of 17 pass, fuzz tests run with the verifier's seed) and forge fmt --check all pass.

The token (src/IMDPotToken.sol, contract name IMDPotToken):

• It is named IMDPot, with symbol IMDPOT and 18 decimals.
• The constructor takes no arguments and mints the full 1,000,000,000 tokens (1e27 in minor units) once to whoever deploys it. On the launch, that's IMD's factory.
• It's a plain ERC-20: no fees, burns, mint, pause, blacklist or owner. Every transfer moves exactly the amount it says, which the factory, distributor, pool seed and swaps need. Nobody can ever increase the supply.
• It makes no calls to other contracts and uses no libraries.

Tests (test/IMDPotToken.t.sol):

• Success cases: the token's details, minting the full supply to the deployer, transfers, approvals and spending them, and unlimited approvals.
• Failure cases: spending more than the balance or the approval, sending to the zero address, and approving the zero address.
• No admin calls: common admin calls like mint, pause and transferOwnership fail and leave the supply unchanged.
• Fuzz tests: the total supply never changes, and spending can't exceed an approval.

I couldn't run the two protected launch checks here. They rely on files and settings that only the verifier supplies. The token is built to meet what they check.

Other files:

• foundry.toml pins solc 0.8.26 with bytecode_hash = "none".
• forge-std is copied into lib/forge-std as ordinary files. I removed its own .github folder because .github/ paths are off limits.
• script/Deploy.s.sol is a deploy script for local testing only; the tests call it directly.
• README.md covers the token's behaviour, assumptions, deployment, and who runs what. Its "After launch" section says there is nothing to configure.

I did not write a launch.json, because the later manifest step creates it. Git had no author identity on this machine, so I set your email and the name "bkenny1123" for this one commit only. As the README says, passing tests are not a security audit.

Created launch.json with the accepted token, empty constructor arguments, exact supply, pool settings, and economics.

Verified manifest fields against the compiled ABI. forge build succeeded; all 17 tests passed with the supplied fuzz seed. Only launch.json is changed for submission.

The review is complete. The findings file is written and validated, the snippet matches the tree at the cited lines, and the scratch tests are removed so the only change in the tree is .imd-findings.json.

Outcome: one low-severity finding, no critical, high or medium defects. The token is a minimal fixed-supply ERC-20 with no external calls, no admin surface and no fee logic, and it holds up under the Execution Trace, Periphery and First Principles guides.

What I found

• Low: missing zero-sender guard in _transfer at src/IMDPotToken.sol:62. The contract adopts ERC-6093 errors but omits ERC20InvalidSender. Calling transferFrom(address(0), to, 0) from any address succeeds and emits Transfer(address(0), to, 0), a mint-shaped event. No balance or supply changes, so it is a forged log and a spec deviation, not a loss. Reproduced with a Foundry test on the current code. The fix is a one-line from == address(0) revert at the top of the private transfer helper.

What I verified as holding

• approve, transfer and the constructor trace cleanly: receiver and balance checks guard the unchecked math, self-transfers preserve balances, and supply is conserved under fuzzing of transfer and transferFrom chains.
• The compiled runtime passes the protected floor's opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT. The only trailer is the solc CBOR tag.
• No privileged powers exist, so launch flows to the distributor, pool seed and swaps move exact amounts.
• The deploy script is local-only periphery with nothing reachable on chain.

Leads rejected

• Aderyn's large-numeric-literal note on line 14 is correct arithmetic, confirmed by the existing metadata test.
• Zero-value transferFrom without allowance from a real holder matches OpenZeppelin v5 and is not reported.

Coverage rows are recorded for all three listed entry points plus the constructor, the supply invariant, the no-privilege invariant, the opcode invariant, the launch flows and the deploy script. Nothing in the assigned area was left unreached.

The review is complete and the findings file is written at the repository root. No source files were changed.

Result: no economic, invariant, or flow-gap defect found. IMDPot is a minimal fixed-supply ERC-20 with no owner, no mint or burn path, no fees, no hooks, and no external calls. Every failure mode in the three assigned guides that depends on an external dependency, a token misbehaviour, a cached pre-call value, or a capped value with a second write path is structurally absent.

What I checked

• Supply conservation. A fuzzed probe ran sixteen-step random transfer and transferFrom sequences across six actors. The sum of balances always equalled the immutable total supply of one billion tokens.
• Launch flows. The swarm share, the pool seed, the remainder to the requester, a claim, and a buy and sell round trip all moved exactly the named amount.
• Allowance semantics. The unlimited-allowance sentinel is exact at the max value and decrements normally one below it. A reverted transferFrom leaves the allowance untouched.
• Boundaries. Self-transfer through both paths keeps the balance. Zero receiver reverts. Unchecked addition cannot overflow because the total is fixed.
• Bytecode. The runtime has no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL or CREATE opcodes.
• Existing suite. All seventeen project tests pass.

One informational finding. The internal transfer helper rejects a zero receiver but not a zero sender. Any account can call transferFrom with address zero as the sender and a zero value. No balance or supply changes, but the contract emits a Transfer event from address zero, which explorers read as a mint. The reproduction and a one-line fix are in the findings file. This does not affect holders, the pool, or any launch flow.

Coverage. All three listed entry points have rows: approve and transfer hold, transferFrom carries the info finding. Three invariant rows and the constructor are also recorded as holding. The aderyn large-literal lead is a style note with no behavioural effect and was left out.

The scratch probe file under test/scratch/ is review material only and is not part of the submission.

The review is complete and the findings file is written and validated.

Outcome: the IMDPot token has no privileged surface, so the Access Control and Trust Gap guides produce no failures. The Asymmetry pass found one low-severity defect, which I confirmed with a failing Foundry test.

Finding (low): src/IMDPotToken.sol:61 checks for a zero receiver but never for a zero sender. Any address can call transferFrom(address(0), B, 0). The allowance check passes because zero is not less than zero, the balance check passes the same way, and the contract emits a Transfer event from the zero address. Explorers and supply indexers read that as a mint, which contradicts the documented invariant that the constructor is the only mint. No balance or supply changes, since the value is forced to zero. The proof test under test/scratch fails on the current code with both assertions and would pass once the sender-zero check is added.

What I verified and found holding:

• approve writes only the caller's own allowance row and rejects a zero spender.
• transfer moves only the caller's balance, and unchecked arithmetic is safe because the balance sum equals the fixed supply.
• transferFrom enforces allowance, keeps the unlimited allowance bounded by balance, and conserves supply under fuzzing.
• No owner, mint, burn, pause, blacklist, initializer, delegatecall or selfdestruct exists, so no trust-gap seam is reachable.
• Every transfer path moves exactly the named amount, so launch flows arrive whole.

Coverage record: all three listed entry points have rows, plus six invariant rows. Only transferFrom carries the finding.

Not reached: the protected launch harness could not be run locally because it needs v4-core and launch environment variables. Its token-side requirements were traced by reading.

The review is complete. The findings file is written and the tree is otherwise untouched.

Result: no defects in the Math Precision, Boundary or Numerical Gap areas. The findings file holds an empty list and eight coverage rows, one per entry point plus the invariants checked.

What the token contains. src/IMDPotToken.sol is a fixed-supply ERC-20 with no division, multiplication, scaling, casts, external calls, payable paths or bytes decoding. The only arithmetic is two guarded unchecked subtractions and one unchecked addition.

What I verified, with concrete inputs:

• The unchecked balance and allowance subtractions each sit behind a strict less-than guard, so a transfer of the full balance plus one and an allowance consumed exactly then overdrawn by one both revert with the exact error arguments.
• The unchecked addition to the recipient cannot overflow because the sum of balances is pinned to the constructor's mint. A stateful fuzz over random transfer, approve and transferFrom sequences kept the sum at exactly 1e27 across all runs.
• Edges: value zero proceeds, value max reverts on balance rather than wrapping, self-transfer and self-transferFrom leave the balance unchanged, allowance of max minus one is decreased while exactly max is not, and transfers to the zero address revert even for zero value.
• The supply literal flagged by aderyn evaluates to exactly 1,000,000,000 times 10^18, matching the brief and README.
• The runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT. A first scan flagged a byte 0xff, but it was the immediate of a PUSH1 for the uint8 mask, and the floor test's loop counts that correctly.

Test outcome. The project's 17 tests plus 14 scratch tests all passed. The scratch tests were removed afterwards since nothing under test/scratch/ is kept.

Not reached. The protected launch floor test could not be run locally because it imports Uniswap v4 core, which is not vendored here. Its checks on this token were traced by reading rather than executed. The standard ERC-20 approve front-running property is noted in the approve coverage row as inherent to the interface, not reported as a defect.

Added failure-path, edge-case, fuzz, and stateful invariant tests under test/.

Validation passed offline with the required seed:

• forge build
• forge test: 37 reported tests passed
• 32,768 invariant handler calls

No defects found. Only two new test files were added.

The review is finished: I kept one low-severity finding and found nothing more serious. The results are in .imd-findings.json, and no files in the tree were changed.

Finding 1 (low), src/IMDPotToken.sol:62. All three specialists who reported something (permissions, flow and economics) found the same flaw, so I merged their reports into one. _transfer rejects a zero receiver but never a zero sender. As a result, anyone can call transferFrom(address(0), B, 0). The allowance check (0 < 0 is false) and the balance check both pass, so the call succeeds and logs Transfer(address(0), B, 0). Explorers and indexers read that as a mint, which the README says never happens. No balances or supply change, so the only harm is a misleading log; that is why it is low. The same call with value 1 is refused for lack of allowance.

• Reproduction: I ran the specialist's proof test under test/scratch/, then deleted the copy. Both of its tests fail on the current code for the reason the finding gives.
• Fix: add an ERC20InvalidSender error and revert at the top of _transfer when from == address(0). This matches OpenZeppelin v5.

Coverage:

• approve: holds. It rejects a zero spender and sets the allowance exactly.
• transfer: holds. It moves exactly the named amount, including a transfer to yourself, and can't overflow because the supply is fixed.
• transferFrom: finding 1. The allowance handling itself is correct: the maximum value is treated as unlimited, otherwise the allowance is reduced, and a short allowance is refused.
• Two invariants: hold. The supply is fixed and minted only once, in the constructor. launch.json matches the code: no constructor arguments, the same name, symbol, 18 decimals and total supply, and no keys outside the schema.

On the static analysis: Slither reported nothing. Aderyn's large-number note on line 14 is the supply constant, 1_000_000_000 * 10 ** 18, which is correct. Neither is a defect.