Implemented Agent Duel (AD): 1 billion tokens, 18 decimals, minted once to the deployer. No further minting or admin powers.

Dependencies are vendored; deployment parameters and responsibilities are documented.

Verified with Solidity 0.8.26:

• forge build passed.
• All 32 tests passed using the requested seed.
• forge fmt --check passed.

Protected launch integration checks remain for the verifier’s separate harness.

Done. The manifest is written and verified, and nothing else in the tree changed.

What I wrote in launch.json:

• kind is custom_token, with the token contract named AgentDuel, name Agent Duel, symbol AD, 18 decimals.
• constructorArgs is empty, matching the accepted constructor at src/AgentDuel.sol:13, which takes no parameters and mints once to msg.sender.
• totalSupply is the exact minted amount in minor units, 1000000000000000000000000000.
• contracts is empty. The accepted tree contains only the token, so no application contracts are described.
• pool and economics are copied exactly from the launch reference: IMD pair address, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's verbatim economics object.
• notes describe the token's fixed supply, absence of privileged functions, and that the pool price is derived by the deployer.

Verification results:

Check	Result
Scratch schema check (keys, types, lowercase addresses, verbatim economics, notes length)	passed
forge build	successful
forge test with the pinned fuzz seed	32 passed, 0 failed
git status	only launch.json added

The protected tests themselves depend on the launch system's harness and environment variables, so they run on the verifier's side, not here.

The review is complete and .imd-findings.json is written with two findings and eight coverage rows. The working tree is clean apart from that file, and the scratch tests were removed.

Outcome

The token is a bare OpenZeppelin v5.0.2 ERC-20 with a constructor mint of the full supply to the deploying caller. I found no defect in the token's permission model. The only substantiated defect is in the repository's dependency integrity record, reported as low.

What I checked in the Access Control, Trust Gap and Asymmetry areas

• Permission map. The compiled ABI exposes only the constructor, the supply constant, the metadata getters, and the three ERC-20 state changers. There is no owner, role, initializer, mint, burn, pause, blacklist, receive or fallback path. A scratch test confirmed that an ETH send, empty calldata and unknown selectors all revert.
• Guard consistency. Balances are written only by the inherited transfer path, allowances only by the caller's own approve and by transferFrom's allowance spend. The deployer has no privilege after construction.
• Asymmetry pairs. approve versus transferFrom, transfer versus transferFrom, and finite versus unlimited allowance all behave as the README documents. The allowance replacement race is inherent to standard ERC-20, is documented in the README, and is recorded as an info item rather than a defect.
• Trust Gap seams. With no privileged actor, no access-times-economics or access-times-asymmetry seam is reachable.
• Launch floor. The constructor takes no arguments, mints exactly one billion tokens at 18 decimals to msg.sender, and transfers carry no tax or exemption, so the factory, distributor and pool flows move exact amounts.

Findings

1. Low. Seven vendored forge-std files fail the committed checksum file, while the README states checksum verification passed and DEPENDENCIES.md says files were copied without edits. The recorded hashes match upstream v1.9.7 exactly. The local copies differ only in whitespace, so the deployed bytecode is unaffected. The fix is to restore the files or regenerate the checksum record and correct the statements.
2. Info. Standard ERC-20 allowance replacement race, already documented in the README as a holder responsibility.

Verification run

The existing suite passed with the README seed. The vendored OpenZeppelin files are byte-identical to upstream v5.0.2. The format check passed.

The review is complete and the findings file is written and valid. Nothing further is needed; the working tree is unchanged apart from the required findings file.

Outcome: the Agent Duel token itself holds under all three assigned guides. I found one low-severity defect, in the vendored test dependencies, and recorded it in .imd-findings.json with full coverage rows.

What I checked

• Execution Trace. Traced approve, transfer and transferFrom through the vendored OpenZeppelin v5.0.2 ERC20 to final state. Every guard sits before the state write, failed paths roll back the allowance, and no fee, hook, callback or external call exists. The launch flows the protected floor exercises move exactly the stated amounts.
• Periphery. Diffed every vendored library file against the upstream archives named in DEPENDENCIES.md. All five OpenZeppelin files, the only library code compiled into the token, are byte-identical to v5.0.2.
• First Principles. The constructor mints exactly 10^27 minor units once to msg.sender with no arguments or ETH. The compiled ABI exposes nothing beyond the three listed entry points, views and the constructor. Supply cannot grow, no privileged call exists, and the runtime has no forbidden opcodes.
• Tooling. forge build, the full suite with the documented seed, Slither and Aderyn all ran. Results below.

Check	Result
forge test (seeded)	32 passed, 0 failed
Slither	0 results
Aderyn	1 low, style only
sha256sum -c vendor-checksums.sha256	7 FAILED

The finding (low). Seven forge-std files under lib/ differ from the pinned v1.9.7 archive. The diffs are whitespace-only line re-wrapping consistent with forge fmt having been run over lib/. The recorded hashes are the correct upstream hashes, so the shipped integrity record fails. README line 129 and DEPENDENCIES.md state that this check passed and that files were copied without edits. The token's bytecode is unaffected, but the deliverable's own integrity attestation is false. The fix is either to restore those seven files to upstream bytes or to regenerate the record and amend the documentation.

Not reported. The Aderyn large-literal note is style with no behavioural effect. The standard ERC-20 approve replacement race is inherent to the specification and already documented in the README.

No critical or high finding exists, so no proof test was written under test/scratch/.

The findings file is in place and the scratch directory is removed. Nothing else is needed.

Result: no math, boundary or numerical-gap defect in the token. The findings file at .imd-findings.json holds one info-level finding and nine coverage rows, all three listed entry points marked holds.

What I checked in my area

• Supply constant. The literal on line 10 of src/AgentDuel.sol evaluates at compile time to exactly 10^27. It is far below the uint256 limit and also below 2^96, so downstream uint128 and int128 Uniswap v4 deltas cannot truncate it. The single checked mint cannot overflow. The aderyn large-literal lead is style only.
• Inherited arithmetic. The vendored OpenZeppelin v5.0.2 _update and _spendAllowance do their unchecked subtractions only after an explicit less-than check, and the unchecked additions are bounded by the sum-of-balances invariant. I verified transfer and transferFrom at zero, exact balance, balance plus one, max uint, self-transfer, finite allowance at max minus one, infinite allowance over balance, and zero-address sender. All behave as the standard specifies.
• Boundary surface. The token makes no external calls, has no payable, receive or fallback, and decodes no bytes. ETH sent to it reverts. The only sentinel branches are the zero-address mint and burn paths, which _transfer blocks from outside.
• Launch split. Ten percent and eighty percent of 10^27 divide with zero remainder, so no dust is stranded at the factory and the protected test's basis-point arithmetic stays well inside uint256.
• Suites. The project's 32 tests pass with the documented seed, including the invariant run with zero handler reverts. My scratch boundary tests passed and were deleted afterwards.

The one finding (info, outside my area). The committed vendor-checksums.sha256 does not match seven committed forge-std files, so the README's statement that dependency checksum verification passed is false for this tree. All five OpenZeppelin files verify, so the production dependency is intact. Reproduction is the project's own command:

sha256sum -c vendor-checksums.sha256

It exits 1 with seven FAILED lines on a clean checkout.

Not reached. Nothing within the assigned area was left unexamined. I did not run the protected Uniswap v4 seed-and-swap suite, since its harness contracts are not in this repository, but the token has no transfer hooks that could affect it.

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

Outcome: the Agent Duel token holds in the assigned area. It is a bare OpenZeppelin v5.0.2 ERC-20 whose constructor mints 10^27 base units once to msg.sender, with no fee, burn, exemption list, hook, owner or external call anywhere in a transfer path. I found no economic, invariant or flow-gap defect in the token itself.

What I checked

• Supply conservation and single mint: only one _mint, in the constructor, credited to the deploying factory under CREATE2. The project's invariant suite and a scratch fuzz confirm totalSupply never changes and balances always sum to it.
• Launch flows: the 10% swarm share, 80% pool seed, 10% remainder to the requester, distributor claims, and buy and sell legs all move exactly their stated amounts, so none of the protected floor's flow checks can come up short. I could not execute the protected suite itself since it needs v4-core and the harness environment.
• Entry points: approve, transfer and transferFrom traced through the vendored OZ code, which is byte-identical to upstream v5.0.2. No privileged surface, no DELEGATECALL, CALLCODE or SELFDESTRUCT in runtime code, decimals 18.
• Project tests: all 32 pass with the README's seed, and forge fmt --check passes.

One low finding reported

• The README says dependency checksum verification passed, and DEPENDENCIES.md tells readers to run sha256sum -c vendor-checksums.sha256. On the committed tree that command fails for seven forge-std files. The recorded hashes are the true upstream v1.9.7 hashes, and the committed files are identical to upstream once whitespace is ignored, so the code is a forge fmt reflow, not tampering. Impact is documentation only, since forge-std is never deployed, but the shipped integrity artefact does not describe the tree.

Coverage record: all three ABI entry points marked holds, plus five invariant and trust rows, one of which points at the finding above. The aderyn large-literal lead is a compile-time constant equal to 10^27 and is not a defect.

Done. The delivered suite now has 56 tests across four files, all passing with the verifier's seed, and only files under test/ were added.

What I found. The token at src/AgentDuel.sol is a bare OpenZeppelin v5 ERC-20 that mints one billion 18-decimal tokens to the constructor caller. I read it adversarially and found no defect, so there is no findings file to write. To make sure the passing suite means something, I ran the new handler against two deliberately broken variants in scratch: a one-percent fee-on-transfer and a deployer that can spend any holder's balance without approval. The first version of my handler missed the second mutant, because nothing ever acted as the deployer. I added that action, and both mutants now fail the invariants.

What I added, building on the earlier contributors' unit and model-based invariant files without rewriting them:

• test/AgentDuel.failures.invariant.t.sol: a second invariant harness whose handler deliberately overspends, sends to the zero address, spends without approval, approves the zero spender, self-spends, and lets the deployer and an outsider try to move others' funds. Each rejected call is caught, its exact ERC-6093 error compared, and balances, allowances and supply checked unchanged. Six actors at very different scales, a never-acting deployer, and a never-funded outsider. Five invariants: constant supply, every token accounted for including what is stuck in the token contract, balances and allowances matching ghost accounting, and the idle holder untouchable. An afterInvariant hook asserts each run exercised both succeeding and rejected paths, so the run cannot be vacuous.
• test/AgentDuel.edges.t.sol: the launch handoff done inside one constructor, so deployment and all three distribution flows happen in a single transaction as the factory does it. Error precedence when more than one rejection applies: zero receiver beats insufficient balance, insufficient allowance beats both. Allowance edges such as max-minus-one being finite, a holder not being its own spender, exact consumption to zero, and overwrite rather than accumulate. Tokens sent to the token contract are stuck and unrecoverable. Fuzzed properties use bound rather than discarding runs, including one that calls any selector with any arguments from any stranger and checks the supply cannot grow, the stranger cannot gain, and a holder cannot lose or be frozen.

Run counts are set inline in each file, so foundry.toml is untouched. The scratch mutation harness lives in test/scratch/ and is not part of the deliverable.

The review found one real defect, rated low: the repository's own dependency checksum check fails. Nothing blocks the token. The results are in .imd-findings.json: one finding plus a coverage row for each entry point.

The finding (low): the checksum check fails although the docs say it passed. All four specialists reported this; it is one cause, so it is one finding.

• What fails: running sha256sum -c vendor-checksums.sha256 reports 7 failed files under lib/forge-std/src/ and exits with 1. That contradicts README.md:129 ("dependency checksum verification passed") and DEPENDENCIES.md:12-13 ("copied without edits").
• How I checked it: I downloaded the upstream forge-std v1.9.7 archive into an empty directory. For all 7 files, the hash in the record equals the upstream hash. With whitespace removed, each copy in the repo is identical to upstream. So the files were only reformatted, which fits forge fmt having been run over lib/.
• Impact: forge-std is only used by tests, and all 11 OpenZeppelin entries pass, so the deployed contract is unaffected. The harm is that anyone running the documented check can't tell a harmless reformat from a tampered test library without comparing against upstream themselves.
• Fix: either restore the 7 files exactly from v1.9.7, or regenerate the record and correct the two docs. Either way it touches lib/, so the author has to decide.

Dropped: the approve front-running race. One specialist reported it as info. It is standard ERC-20 behaviour, already documented in README.md:117-119, and not a defect in this code.

My own pass. src/AgentDuel.sol is unmodified OpenZeppelin v5.0.2 ERC20. Its constructor mints 1e27 once to the deployer, and it has:

• no owner, mint, burn or pause function;
• no fee or hook on transfers;
• no external calls.

Transfers move exactly the amount stated, so the launch's transfers to the distributor, the pool and the requester arrive in full. The constructor takes no arguments, matching the empty constructorArgs in launch.json, and the manifest supply matches the mint. The contract is far under the size limits (2,637 bytes creation code, 1,752 bytes deployed), so there is no deployment blocker. forge build passes, and all 56 tests pass.

Coverage: approve, transfer and transferFrom are all marked "holds", plus one row for the fixed-supply rule.

Limits:

• I couldn't run the protected launch tests. They need the Uniswap v4 code and the network's own test contracts, and neither is in this tree.
• None of the findings needed a Foundry proof file.