Done. The Keelnet (KEEL) token is implemented, tested, documented, and committed on main.

What was built

• src/KeelnetToken.sol is a plain OpenZeppelin v5 ERC-20. The constructor takes no arguments and mints the whole supply to msg.sender, which is the launch factory. There is no owner, mint, burn, pause, blocklist, fallback, or upgrade path, and the runtime has no DELEGATECALL, CALLCODE, or SELFDESTRUCT.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none" and cbor_metadata = false, and keeps ffi off with no fs permissions.
• forge-std v1.11.0 and OpenZeppelin Contracts v5.4.0 are vendored under lib/ as ordinary committed files, with no submodule and no .git directories.
• script/DeployKeelnet.s.sol is a reference deploy script. Its deploy() function takes no config and reads no environment, and the tests call it directly.
• README.md documents the token parameters, assumptions, the launch's fixed economics, that there is nothing to configure after launch, operational responsibilities, and the security checklist items that apply.

Checks run

Check	Result
forge build (clean)	passes
forge test with the verifier's fuzz seed	31 tests pass, 0 fail
forge fmt --check	passes

The test suite covers metadata and supply constants, the single mint event, success and typed-error failure paths for transfer, approve, and transferFrom, the deployer having no power over holders, every common admin selector reverting from both a stranger and the deployer, and three fuzz tests for supply conservation and allowance bounds. A scratch test under test/scratch/ also confirmed the creation code deploys through CREATE2 from a factory-like contract that then holds the whole supply, and that the launch flows move exact amounts. That directory is ignored and not part of the deliverable.

Open items for the launch, not this job

• The manifest step writes launch.json with constructorArgs: [] and totalSupply of 1000000000000000000000000000.
• Explorer source verification is the deployer's step after deployment.

I've written launch.json for the Keelnet (KEEL) launch. It's the only file changed. forge build and forge test pass with the verifier's fuzz seed (31 of 31). The JSON parses, but I checked the schema rules by reading the file, not with a validator.

• Token: the contract is KeelnetToken in src/KeelnetToken.sol, named Keelnet, symbol KEEL, 18 decimals. Its constructor takes no arguments, so constructorArgs is []. It mints 1,000,000,000 × 10^18 to the deployer, so totalSupply is "1000000000000000000000000000".
• Contracts: []. The accepted code contains only the token, with no other contracts to deploy.
• Pool: paired with IMD at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tick spacing 60, and initial price 79228162514264337593543950336, all as the launch gives them.
• Economics: copied exactly as given.
• Notes: a short description of the token. It's a plain fixed-supply ERC-20 with no owner, no later minting, no pause, no fee and no burn, so every launch transfer moves exactly the amount sent.

I didn't run the two task-supplied test files against the manifest. They need a harness and environment variables that aren't in this repo.

I haven't committed launch.json. It's sitting as an untracked file in the working tree.

The review is complete. .imd-findings.json holds an empty findings list and nine coverage rows. The tree is otherwise unchanged.

Result: no defects in the assigned area. The token is a 35-line wrapper over stock OpenZeppelin v5.4.0 ERC20 with a single compile-time constant and no custom arithmetic, so the Math Precision, Boundary and Numerical Gap guides have almost no surface to bite.

What I checked and how:

• Supply constant. SUPPLY_WHOLE_TOKENS * 10 ** uint256(DECIMALS) evaluates to exactly 1e27 since ** binds tighter than *. It matches the manifest figure and fits well under uint128, so no downstream pool cast can truncate it.
• Entry points. All three state-changing functions were traced through the vendored _update, _approve and _spendAllowance. I probed zero, exact balance, balance plus one, max uint, whole-balance self-transfer, zero receiver and spender, and the from-equals-zero-address route into transferFrom. Every path reverts or succeeds as intended, and none can mint.
• Invariants. A fuzzed sequence of transfers among three holders kept the sum of balances equal to totalSupply across 256 runs. The 10 percent, 80 percent and one-in-a-thousand shares the factory and protected test compute divide the supply with no dust.
• Periphery. The five vendored OpenZeppelin files the token depends on hash identically to the upstream v5.4.0 release, so the inherited math is unmodified.
• Static-analysis lead. The aderyn "large numeric literal" line is style only. The literal is the brief's whole-token count and the resulting value was verified.

Coverage: all three listed entry points are marked holds, with additional rows for the constructor constant, three invariants, the vendored library, and the aderyn lead. Nothing in my area was left unreached. The existing 31-test suite passes, and my six scratch probes passed before I deleted them, so nothing outside the findings file was added to the tree.

The review is complete. The findings file is written with an empty list and full coverage, and the tree is otherwise untouched.

Result: no defects found in the Access Control, Trust Gap or Asymmetry areas.

What was checked

• Permission model. The token's ABI exposes exactly three state-changing functions, approve, transfer and transferFrom, plus the constructor. There are no modifiers, roles, owner slot, initializer, receive or fallback. The constructor mints the full supply once to msg.sender and hands out no role.
• Dependency integrity. The vendored ERC20.sol, Context.sol, IERC20.sol, IERC20Metadata.sol and draft-IERC6093.sol are sha256-identical to upstream OpenZeppelin v5.4.0, so the inherited logic is stock and _msgSender is plain msg.sender with no forwarder.
• Weakest-guard analysis. Each storage variable has one write path: balances through _update, allowances through _approve. No function lets a caller write another holder's allowance row or move a balance without a matching allowance. The minter retains no residual power.
• Asymmetry pairs. approve sets the exact row that transferFrom decrements. transfer and transferFrom share the same internal path. The burn branch is unreachable and the mint branch runs only in the constructor.
• Trust-gap seams. With no admin setter, fee recipient, oracle or price formula there is no privileged actor and no asymmetric economic primitive to combine.

Verification performed

• The existing 31-test suite passes.
• A scratch test with five inversion cases passed: attacker cannot raise an allowance on a victim's row, self-pull still needs an allowance, the factory has no residual mint or pull power, allowance mirroring holds under fuzzing, and appended-sender calldata is not honoured. The scratch file was removed afterwards.
• The static-analysis lead about the large numeric literal at line 24 is a compile-time constant that evaluates to the correct supply and is not a defect.

Coverage record has seven rows, all holds: the three listed entry points, the constructor, and three invariants covering the absence of privileged roles, trust-gap seams and paired-surface asymmetries.

The review is complete. The findings file is written with an empty findings list and a full coverage record. Nothing in the tracked tree changed.

Result: no defects found in the economics of Keelnet (KEEL).

What I checked, against the Economic Security, Invariant and Flow Gap guides:

• Supply and mint. The constructor mints exactly 1,000,000,000 × 10^18 to msg.sender with no arguments and no external call. The compiled ABI exposes only the three state-changing ERC-20 entry points plus views, so nothing can grow, burn, pause, freeze or seize after deployment. The runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT.
• Conservation. A 256-run fuzz of 40 random transfer and transferFrom steps across eight actors kept the sum of balances equal to totalSupply, and totalSupply equal to the brief's figure.
• Launch flows. A scratch test replayed the launch: 10% to the distributor, 80% pulled by a PoolManager stand-in via transferFrom, 10% to the remainder address, then uneven claims and a buy and sell against the pool. Every leg moved exactly the requested amount.
• Dependency. The five vendored OpenZeppelin files the token compiles are byte-identical to the upstream v5.4.0 tag by sha256.
• Opening economics. The 3,400 IMD cap over the supply gives a tick near ±125,930, inside Uniswap v4's range for either currency order, and the seed amount fits uint128 liquidity math.

Two notes that are not defects, recorded in the coverage rows rather than as findings:

• The DECIMALS constant is not wired into decimals(). They both read 18 today, so there is no failing state, but an edit to one would not follow the other.
• The standard ERC-20 approve race and the fact that tokens sent to the token's own address are stuck are inherent to a plain ERC-20 and already documented in the README.

Coverage: all three listed entry points are marked holds, with five extra rows for the invariants, the dependency check and the opening economics. The aderyn large-numeric-literal lead on line 24 is a style note on a correct constant and was not promoted. Static analysis from slither reported nothing.

The review is complete. The findings file at the repository root holds an empty findings list and ten coverage rows, and my scratch test directory has been removed so the tree is otherwise unchanged.

Result: no defects found in the Keelnet token. The contract is a 34-line wrapper over an unmodified OpenZeppelin v5.4.0 ERC-20 with a no-argument constructor that mints the full supply once to the deployer.

What I checked in my area:

• Execution trace. Traced approve, transfer and transferFrom from entry to final storage write through the inherited OpenZeppelin code. Every revert path is a typed ERC-6093 error, the allowance is spent before the balance moves, infinite allowance is preserved while max-minus-one is decremented, and self-transfers and zero-value transfers leave balances intact. No external calls exist, so there is no reentrancy or callback surface.
• Periphery. Diffed the vendored OpenZeppelin and forge-std trees against their upstream v5.4.0 and v1.11.0 release tarballs. Both are byte-identical. Context returns msg.sender directly, so no forwarder path exists.
• First principles. The constructor takes no arguments and calls no contract, so a CREATE2 deployment from a factory probe leaves all of the 1e27 supply with the factory. The ABI has only three state-changing functions, no receive or fallback, and the runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, CREATE or transient-storage opcodes.
• Launch flows. A scratch test moved the ten percent swarm share, eighty percent pool share and remainder, then a distributor claim and a pool-manager pull-back. Every transfer delivered the exact amount and the supply stayed constant. The project's own 31 tests also pass under the verifier's fuzz seed.

Leads I examined and did not report: the approve front-running property of ERC-20, tokens sent to the contract's own address being stuck, the missing Approval event on transferFrom, and aderyn's large-numeric-literal note. Each is standard, documented ERC-20 behaviour or style, with no failing input that contradicts the brief.

One limitation: I could not run the protected launch test itself, since it depends on Uniswap v4 core, the LaunchLiquidity helper and launch environment variables that are not in this tree. The launch flow was reproduced with a simplified factory probe instead, and that is noted in the coverage record.

Done. The suite grew from 31 to 64 tests, all passing under the verifier's seed and unseeded, and no defects were found in the token.

What I found

The implementation is a plain OpenZeppelin v5 ERC-20 with the whole supply minted to msg.sender and no admin surface. I read it adversarially (zero address as sender, self-pulls, the allowance one below infinity, tokens sent to the contract, repeated calls, unknown selectors, CREATE2 deployment, the one-call launch flow) and every behaviour matched the brief and the launch floor. No .imd-findings.json was written because there is nothing to report.

What I added (the existing test/KeelnetToken.t.sol is untouched)

• test/KeelnetToken.invariant.t.sol: a handler with six actors and the token's own address as a sink, bounded inputs, ghost balances and allowances, and deliberate failure paths that check the exact ERC-6093 error (over-balance, over-allowance, zero receiver, zero spender, unknown selectors). Six invariants run with fail-on-revert = true over 256 runs of depth 64: constant supply, sum of balances equals supply, balances and allowances match the ghost model, no balance above supply, zero address empty, metadata and code hash unchanged. A second contract fuzzes the token's ABI directly with random senders and reverts allowed.
• test/KeelnetToken.edges.t.sol: 23 unit tests and 7 fuzz tests at 1000 runs, including a helper that deploys and pays out swarm, pool and remainder shares in one call as the factory does, for any pool share from 0 to 90 percent.

Verification

• Both files were run against mutant tokens in scratch: a 1 percent burn-on-transfer was caught by the ghost model on the first sequence, and a hidden public mint was caught by the open-fuzz supply invariant. The harness is not vacuous.
• forge build passes, forge fmt --check passes on the new files, nothing outside test/ was touched, no submodules, nothing installed.

The two new files are untracked in git. I did not commit, since the pipeline makes its own commit for the job.

I found no defects in Keelnet (KEEL). I wrote .imd-findings.json with an empty findings list and a coverage row for each of the three entry points, all marked holds. I changed no other files.

What's in the code: src/KeelnetToken.sol is a plain OpenZeppelin v5 ERC-20 that changes none of the library's behaviour. Its constructor takes no arguments and mints 1e27 minor units (1,000,000,000 × 10^18) once to msg.sender. It has no owner, no way to mint more, and no fee, burn, pause or blocklist. There is no DELEGATECALL or SELFDESTRUCT.

Entry points: approve, transfer and transferFrom are the library's own code. I read them in the vendored ERC20.sol: they move exactly the amount asked, and they revert when the balance or allowance is too small or an address is zero. So the launch flows (factory to distributor, distributor claims, pool seed and swaps) all arrive in full.

Deployment: The token can be deployed through the factory. Its deployed code is 2,203 bytes and its creation code 3,368 bytes, well under the limits.

Manifest: launch.json fits the code. Its empty constructorArgs matches the constructor with no arguments, and its totalSupply, decimals, name and symbol match the contract.

Tests: All 64 of the repository's tests pass.

Specialist reports and tool output:

• None of the four specialists or the test writer reported anything, so there was nothing to reproduce or merge.
• Slither reported nothing.
• Aderyn's one note flags the 1_000_000_000 literal on line 24 as a large number. That is a style note, not a defect, so I left it out.

I didn't run the protected floor tests. They import helper files that aren't in this tree, so I only read them.