Everything is done and verified. The project builds, all tests pass with an empty environment, and the formatter check is clean.

What was delivered (Foundry project at the repository root):

• src/AmbidexToken.sol: contract AmbidexToken, a plain fixed-supply ERC-20 on OpenZeppelin v5.4.0. Name AMBIDEX, symbol AMBI, 18 decimals, one billion tokens minted once in the constructor to the deployer. No constructor arguments, no owner, no mint, pause, blacklist, freeze, tax or proxy.
• test/AmbidexToken.t.sol: 27 tests covering metadata, supply, CREATE2 deployment from a factory-like contract, exact transfers including the factory to distributor to claimant chain, a 256-run fuzz for balance conservation, every ERC-6093 failure path, allowance behaviour, absence of all privileged selectors the launch floor probes, and a bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT.
• script/DeployAmbidexToken.s.sol: a reviewable deploy helper that reads no environment, with a deploy() function tests call directly.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", disables CBOR metadata, keeps ffi off and grants no filesystem permissions.
• lib/forge-std v1.9.7 and lib/openzeppelin-contracts v5.4.0 vendored as ordinary files. Nested git metadata was removed, so nothing becomes a submodule.
• README.md documents the token, deployment parameters for the manifest step, assumptions, an "After launch" section (nothing to configure) and operational responsibilities.

Check results

Check	Result
forge build	success, 28 files, solc 0.8.26
forge test	27 passed, 0 failed
forge fmt --check	clean

Notes for the reviewer

• Since the token has no transfer rules, it takes none of the factory, PoolManager or launchNumber exemption arguments. The manifest's constructor argument list is empty and the supply field is 1000000000000000000000000000.
• Slither and Mythril were not available here and did not run. Explorer verification is left to the launch deployer, as the README states.
• I did not create a git commit, since the rules forbid touching the git directory. All files are in the working tree, ready for the submission step to commit.

I found no defects, so .imd-findings.json has an empty findings list and five coverage rows, all marked holds.

What I reviewed: src/AmbidexToken.sol, the OpenZeppelin 5.4.0 ERC20 code it builds on in lib/, the deploy script, and the protected launch test. The token is a plain ERC-20 that changes no transfer behaviour. It only fixes decimals() at 18 and mints 1,000,000,000 × 10^18 once, to msg.sender, in its constructor (no arguments). The project's own 27 tests pass. I did not run the protected launch test.

Execution Trace guide:

• transfer and transferFrom come straight from OpenZeppelin. They move exactly the amount asked, revert on a short balance, a zero sender or a zero receiver, and reverting leaves no partial changes.
• transferFrom spends the allowance before moving tokens. An unlimited allowance is not reduced.
• approve rejects a zero spender.
• No calls out: nothing in the token calls another contract or passes control to one, so there is nowhere for reentrancy to start.

Periphery guide: There is no fee, burn or exemption logic. So the factory's transfers to the distributor, the pool seed through the PoolManager, and trades all arrive whole. The token has no receive or fallback, and no DELEGATECALL, CALLCODE or SELFDESTRUCT. The deploy script only creates the token.

First Principles guide:

• Supply cannot grow: the constructor is the only place tokens are minted.
• No privileged power: there is no owner or admin role, so no call can move or freeze a holder's balance.
• Decimals are 18, matching the brief.

Static analysis: aderyn's one note (a large number at src/AmbidexToken.sol:30) is the supply constant, and its value is correct, so it is not a defect.

Not covered: launch.json doesn't exist yet, so I had no manifest to check.

The review is complete and the findings file is written. No defects were found in the economics area.

Result: .imd-findings.json holds an empty findings list and eight coverage rows, one for each of the three state-changing entry points plus the invariants and flows I checked. The working tree has no modified tracked files, and the scratch test directory was removed.

What I verified

• The token is OpenZeppelin v5.4.0 ERC20 plus constants and one constructor mint. The five vendored OpenZeppelin files hash identically to upstream v5.4.0, and neither library is a git submodule.
• The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions. There is no mint, burn, owner, pause, blacklist, initializer, receive or fallback, and the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Conservation law: a stateful invariant run of 6400 random transfer, approve and transferFrom calls across eight actors kept the sum of balances equal to the total supply of 1e27, with no balance at the zero address.
• Launch flows: a simulated 10/88/2 split through distributor, pool manager (both push and pull) and remainder address, then a claim and a round-trip trade, moved exactly the amounts requested with the supply unchanged. There is no tax or exemption logic that could short a hop.
• Boundaries: 1 wei, whole supply, max uint, self-transfer, self-approval and transfers from the zero address all behave as the standard dictates.
• The existing 27 project tests pass and forge fmt --check is clean.

Not covered: the protected launch harness itself cannot run here, since it imports Uniswap v4 and launch helper contracts that are not in this tree. Static analysis reported nothing above a benign large-literal note. The only trust note recorded is the standard ERC-20 allowance race, which is a property of the interface the brief asked for rather than a defect.

The findings file is in place at the repository root and is excluded from git by the harness's own exclude rule, which is expected for a review task. The scratch directory has been removed and the working tree is unchanged.

Review outcome: the token's math holds. No defect in the contract itself survived verification.

What I checked, in my area:

• Math Precision. The supply constant is a compile-time expression equal to exactly 1e27, far below the uint256 limit. The aderyn "large numeric literal" line is style only. There is no division, variable multiplication, scale conversion, or narrowing cast anywhere in the token or on the OpenZeppelin paths it reaches.
• Boundary. The vendored OpenZeppelin ERC20 and Context are byte-identical to upstream v5.4.0. Transfers of the maximum uint and of supply plus one revert with the exact ERC-6093 error and no state change. The infinite-allowance sentinel is left untouched while max-minus-one decrements by exactly the spent value. Self-transfer, zero-amount, from-equals-spender and zero-address cases all behave as the standard requires. The token makes no external calls, has no payable path, and decodes no bytes.
• Numerical Gap. Balance conservation holds over fuzzed eight-hop transfer sequences among three holders. The launch split of ten, eighty-eight and two percent of 1e27 divides with zero remainder, so the protected harness flows arrive whole.

The one finding is informational and sits in the test suite, not the contract. The test that claims to pin the manifest's constructor arguments to an empty list only asserts the creation code is non-empty. I reproduced that it passes unchanged on a mutant token with a constructor parameter. The author can strengthen it by asserting the ABI constructor has no inputs or by comparing the creation code tail against the runtime code.

Coverage: all three listed entry points are marked holds, with seven additional rows for the supply and balance invariants, the launch split, the constructor, decimals, and the two guide sweeps that found nothing to exercise. Nothing in my area was left unreached.

The review is complete. The findings file is valid, the snippet matches line 97 exactly, and the working tree is unchanged apart from the gitignored scratch tests and the findings file.

Outcome: no access-control, trust-gap or asymmetry defect found. The token is a thin wrapper over OpenZeppelin v5.4.0 with three public entry points and no roles, and every path I traced behaves as the brief intends.

What I checked in the assigned area:

• Permission map. No owner, role, initializer, receive or fallback exists. The constructor mints the full supply to msg.sender and hands out no roles. Mint and burn are unreachable after deployment.
• Entry points. approve writes only the caller's own allowance slot. transfer debits only the caller. transferFrom requires an allowance from the holder, and a stranger always reverts. The creator has no special pull path.
• Trust gap in the dependency. The five library files that compile into the token are byte-identical to the upstream v5.4.0 tag. The other differences in the vendored library are the project's formatter settings applied to files the token never uses. No git submodules.
• Asymmetry. approve and the allowance decrement mirror each other. transfer and transferFrom share the same internal path, validation and events. No admin variant of any user function exists.
• Dynamic check. A scratch invariant run of 128,000 random approve, transfer and transferFrom calls held supply constant, kept balances summing to supply, and produced no unconsented balance loss.

One info finding, outside the area. The existing test named "constructor takes no arguments" only asserts the creation code is non-empty, so it cannot detect the manifest listing spurious constructor arguments. I confirmed that creation code with appended arguments still deploys and mints normally. No on-chain impact.

The ERC-20 approve change race is a property of the standard the brief asked for, and the README already assigns it to holders, so I recorded it as a trust note in the coverage rather than a finding. Slither reported nothing and the aderyn large-literal note is the supply constant, which I verified equals 1e27.

The work is complete. forge build and forge test pass offline with 64 tests across three suites, and only files under test/ were added.

What I found in the implementation. src/AmbidexToken.sol is a thin wrapper over OpenZeppelin v5.4.0 ERC20 with a constructor mint of 10^27 minor units to msg.sender, no admin, no hooks, no payable paths. I found no defect, so there is no .imd-findings.json. The one behaviour worth noting is standard ERC-20 semantics rather than a bug: tokens sent to the token's own address are unrecoverable because there is no admin, and a zero-amount transferFrom needs no allowance. Both are pinned as documented tests, not asserted as correct silently.

What I added.

• test/AmbidexToken.invariant.t.sol: a handler with the deployer, five users, the token itself as a sink, and seed-derived strangers. It has a raw layer with unrestricted amounts and addresses, and a clamped layer that derives inputs from state. Every token call is predicted against a model ledger and allowance ledger before it runs, and the exact ERC-6093 error with exact arguments is compared on revert. Random undefined selectors and ether sent with any call are also driven. Eight invariants check fixed supply, balances summing to supply over every touched address, model-ledger agreement, zero address holding nothing, allowance-model agreement, nobody pulling more than cumulatively approved, no ether held, and immutable metadata and code hash. Inline config sets 256 runs by depth 64 with fail-on-revert on, so a harness bug surfaces loudly.
• test/AmbidexToken.edge.t.sol: 36 unit and fuzz tests at 1000 runs covering one wei, the whole supply, the maximum, supply plus one, the same call twice, the zero address as sender and receiver, any non-zero recipient including precompiles, approve overwrite and directionality, exact allowance decrement, infinite allowance semantics, revert precedence in transferFrom, strangers reusing a spender's arguments, ether on every function, undefined selectors, and truncated calldata.

How I grounded the suite. In scratch space I ran the same handler and invariants against a token with a one percent burn-on-transfer and a public mint. The ledger and supply invariants failed within three calls, and the junk-call handler flagged the mint selector. One early failure in my own suite turned out to be the harness dealing ether to the token when it was picked as caller, which I fixed in the handler rather than weakening the property. Scratch files were removed and the final tree runs green.

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

Outcome: the AMBIDEX token has no code defects. It is an unmodified OpenZeppelin v5.4.0 ERC20 with a zero-argument constructor that mints exactly 1,000,000,000e18 to the deployer, no privileged roles, no fee or hook on transfer, and no forbidden opcodes. All 64 project tests pass, and the manifest agrees with the compiled ABI.

Specialist findings: audit_permissions and audit_math each reported the same root cause, so I merged them into one info finding. I reproduced both claims with a scratch test under test/scratch/:

• A mutant with a one-argument constructor passes the identical assertion in test_constructorTakesNoArguments.
• Appending ABI-encoded arguments to the real token's creation code still deploys and mints the full supply, with byte-identical runtime.

The test's comment claims it pins the manifest's constructorArgs, but it only checks that the creation code is non-empty. This is a test-evidence gap, not an on-chain risk, so it stays at info severity with no proof file attached. audit_flow, audit_economics and the independent tester reported nothing, and the static analysis lines did not rise to a finding.

Coverage: all three entry points, approve, transfer and transferFrom, are marked holds with traced checks and failure paths. I added three rows for the supply and constructor invariant, the absence of privileged roles and blocked opcodes, and the launch.json manifest.