Implemented Keelpad (KEEL): 18 decimals, exactly 1,000,000,000 tokens minted once to the deployer.

• forge build, forge test, and forge fmt --check pass.
• All 31 tests pass with the specified seed, including fuzz and invariant tests.
• Offline build and tests pass; dependencies are vendored.
• Deployment assumptions and operational responsibilities are documented.

The external protected launch suite remains for the independent verifier.

I found no defects in Keelpad (KEEL), and I've written an empty findings list with full coverage to .imd-findings.json.

What the code is: src/Keelpad.sol is a plain OpenZeppelin v5.0.2 ERC20. Its constructor makes one _mint(msg.sender, INITIAL_SUPPLY) call, where INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18, which is 1e27 and matches the brief. It changes no inherited behaviour, has no owner, mint, burn, pause or other privileged functions, and contains no assembly.

What I checked:

• Library integrity: the SHA-256 hashes of the vendored ERC20.sol, Context.sol, IERC20.sol, IERC20Metadata.sol and draft-IERC6093.sol all match dependencies.lock.json, so the inherited code is unmodified upstream.
• Execution trace:
  • transfer and transferFrom go through _transfer to _update. They revert on a zero sender or receiver and on insufficient balance or allowance, and otherwise move exactly the amount requested.
  • An allowance of type(uint256).max is never decreased; any other allowance is checked and then decremented.
  • approve rejects a zero spender and emits Approval.
• Launch flows (periphery): there is no fee, burn or exemption logic. So the factory's transfer to the distributor, claims, the pool seed and swaps through the PoolManager all move exact amounts. Nothing calls back into other contracts, so there is no reentrancy surface.
• First principles:
  • The supply is fixed after the constructor and goes to the factory.
  • No account can move or freeze another holder's balance.
  • There is no DELEGATECALL, CALLCODE or SELFDESTRUCT.
  • decimals is 18.
• Static-analysis lead: aderyn's large-numeric-literal at src/Keelpad.sol:10 is a style note. The value is correct, so I didn't report it.

The coverage record marks approve, transfer and transferFrom as holds, and adds rows for the fixed-supply invariant and the no-forbidden-opcodes invariant. The project's existing suite passes (31 tests). I didn't run the protected floor tests, because they need the launch environment variables the harness supplies.

Created launch.json matching Keelpad’s constructor, exact supply, pool settings, and required economics. No other deliverable files changed.

Validation passed: manifest and constructor ABI checks, forge build, and all 31 tests using the supplied fuzz seed.

The review is complete. No defects were found in the math, boundary or numerical-gap area, and the findings file records that with full coverage.

Outcome: .imd-findings.json holds an empty findings list and nine coverage rows, one for each of the three listed entry points and six for the invariants and checklist areas I traced. The scratch test and temporary download were removed, so the tree is unchanged apart from the findings file.

What was checked

• Supply constant. The literal flagged by aderyn evaluates at compile time to exactly 10^27, matching the brief's one billion tokens at 18 decimals. The constructor mints it once to the deployer with checked arithmetic, and no burn path is reachable, so the supply can neither grow nor shrink.
• Transfer and transferFrom arithmetic. The vendored OpenZeppelin ERC20 is byte-identical to the v5.0.2 tag on GitHub. Its balance check precedes the unchecked subtraction, the receiver add cannot exceed the fixed supply, and the allowance sentinel of max uint is never decremented. I exercised 1 wei, the full supply, supply plus one, max uint, zero value, self-transfers, exact-allowance consumption and the zero-address paths in a scratch test, and all behaved as the ERC-20 contract and README describe.
• Boundaries. The token makes no external calls, has no payable, receive or fallback function, decodes no bytes and performs no division, scaling or narrowing cast, so the Math Precision and Numerical Gap failure modes have no site in this code.
• Deployment. The constructor takes no arguments and calls nothing, and the existing CREATE2 factory test shows the factory alone receives the whole supply and that swarm, pool and remainder transfers arrive exact.

Not covered: the protected launch harness itself was not executed here, since it needs the network's Uniswap v4 vendoring and environment variables that this review does not carry. The project's own 31 tests, including the invariant suite, pass.

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

Result: no defects found. Keelpad is a 15-line contract that inherits OpenZeppelin ERC-20 v5.0.2 unchanged and mints exactly 10^27 units to its deployer once in the constructor. Nothing in the Economic Security, Invariant or Flow Gap checklists applies in a way that produces a failing input.

What I verified:

• Vendored dependency is genuine. All five OpenZeppelin files diff byte-identical against the upstream v5.0.2 release, and match the SHA-256 values in the lock file.
• Launch flows are exact. A scratch test drove the real 10/80/10 split through a CREATE2 factory stand-in, a PoolManager-style sync/transfer/settle balance delta, distributor claims and a trader buy and sell. Every leg moved exactly the stated amount, including a fuzz over every pool share from 0 to 90 percent.
• Supply invariant holds. Only the constructor touches total supply. The compiled ABI exposes just the standard ERC-20 surface, with no mint, burn, owner, pause, blacklist, upgrade or initializer. The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Failure paths revert atomically. Overdraw, insufficient allowance and zero-address receiver all revert with allowances and balances untouched. The infinite allowance is preserved and finite allowances are consumed exactly.
• Static-analysis lead. The aderyn large-numeric-literal line is the supply constant, which evaluates to exactly 10^27 as specified. Not a defect.

The repository's own 31 tests, including the fuzz and invariant suites, pass with the documented seed.

Coverage record: all three entry points are marked holds, plus four invariant rows. The one thing I could not reach is the protected floor test against a real Uniswap v4 PoolManager, since v4-core is not vendored. Because the token makes no external calls and has no transfer hooks, a swap reduces to the plain transfer paths exercised here. I also noted that the README names Ethereum mainnet as the launch chain, which the later manifest step must reconcile with the job's actual chain.

The review is complete and found no defects in the assigned area. The findings file is written with an empty findings list and seven coverage rows, and the scratch test directory has been removed so the tree is unchanged apart from the required output file.

What was reviewed

• The token in src/Keelpad.sol is a 15-line contract: it inherits OpenZeppelin's ERC-20 and mints the whole supply once to the constructor's caller. The three listed entry points are the unmodified library functions.
• The vendored OpenZeppelin files were diffed against the upstream v5.0.2 release and are byte-identical. They also match the SHA-256 values in the lock file.
• The compiled ABI exposes no state-changing function beyond approve, transfer and transferFrom. There is no receive or fallback, and the runtime has no delegatecall, callcode or selfdestruct.

Access Control, Trust Gap and Asymmetry results

• The permission model is empty by design. There are no roles, modifiers, initializers or admin variants, so the guide's failure modes about inconsistent guards, escalation chains and unprotected initialization have nothing to attach to.
• The deployer's only distinction is holding the initial balance. A scratch Foundry test confirmed the factory cannot pull from a holder without an allowance, and 14 common privileged selectors revert from both the deployer and a stranger.
• The approve and transferFrom pair was traced for sentinel asymmetries. A zero sender cannot mint, a zero recipient cannot burn and the allowance is restored on revert, and a zero spender is rejected.
• Every sender class runs the identical transfer path, so the launch flows to the distributor, claimants and the pool manager arrive exactly. The scratch harness deployed via CREATE2 from a factory contract and confirmed the supply is credited to the factory rather than the transaction origin.

Not reached

The real Uniswap v4 seed and swap harness could not be run because v4-core is not vendored in this repository. Only the token-side transfer semantics were verified, which is all the token contributes to that flow. The aderyn large-numeric-literal note on line 10 is stylistic: the expression evaluates at compile time to exactly 1e27, as the existing tests assert.

Implemented only under test/: 17 new edge/fuzz tests and stronger balance, allowance, and supply invariants.

Validation passed offline:

• forge build
• Full forge test with the required seed: 48 passed, 0 failed.
• 32,768 invariant calls, no unexpected reverts.

No implementation defects found.

I found no defects in the Keelpad (KEEL) token, so .imd-findings.json has an empty findings list and a coverage row for each entry point.

Specialist findings: all four specialists and the test writer reported nothing, so there was nothing to reproduce or merge.

What the code is: src/Keelpad.sol is a plain OpenZeppelin v5.0.0 ERC20 with nothing changed. Its constructor takes no arguments and mints 1_000_000_000 * 10**18 once, to msg.sender. There is no other way to mint or burn, no owner or pause, and no fee or burn on transfer. That means the factory, distributor and pool flows each move exactly what they say.

Coverage (all holds):

• approve(address,uint256): rejects a zero owner or spender, sets the allowance and emits Approval.
• transfer(address,uint256): rejects zero addresses, reverts if the balance is too low, and moves the exact amount.
• transferFrom(address,address,uint256): reverts if the allowance is too low, leaves an unlimited (max) allowance unchanged and reduces any other, then transfers like transfer.
• Fixed supply: launch.json matches the code. It has a totalSupply of 1000000000000000000000000000, decimals 18, empty constructorArgs for the no-argument constructor, a valid contract name and a lowercase pairedCurrency.
• Deployability: the contract is 2,636 bytes of creation code and 1,752 bytes deployed, far under the limits. Its constructor needs no arguments and no particular address bits.

Checks: the project's own 48 tests pass under forge test. The one static-analysis lead (aderyn's "large numeric literal" at line 10) is the supply constant itself and isn't a defect. I didn't add a finding for the standard ERC-20 approve front-running race, because it's ordinary behaviour, not something wrong in this code. I didn't run the protected tests, because they import harness files that aren't in this tree.

Stray files: git status shows untracked dotfiles in the repository root that I didn't create: .bashrc, .profile, .zshrc, .gitconfig, .mcp.json, .claude/, .vscode, .idea and others. I left them alone. Remove them before anything is packaged from this tree, since a submission that touches configuration files is rejected.