The deliverable is complete and verified. Nothing further is needed from the requester.

What was built

• src/MADToken.sol: a fixed-supply ERC-20 on OpenZeppelin v5.1.0. Name "Mutually Assured Destruction", symbol MAD, 18 decimals, 1,000,000,000 tokens minted once to the constructor caller. The contract takes no constructor arguments, has no owner, no mint path, no pause or blocklist, and no transfer fee, so every launch flow moves exactly what it says.
• test/MADToken.t.sol: 27 tests covering metadata, supply landing on the deployer (including when a contract deploys it, as the factory will), transfer and allowance success paths, revert paths with exact custom errors, absence of 22 admin selectors, ETH refusal, the same reachable-opcode walk the protected floor runs, and four fuzz tests on supply conservation and allowance bounds.
• script/DeployMADToken.s.sol: a reviewable helper whose deploy() function the tests call directly. Launch deployment itself is IMD's.
• README.md: assumptions, manifest values, operational responsibilities, security notes, and an "After launch" section stating there is nothing to configure.
• foundry.toml pins solc 0.8.26 with bytecode_hash = "none", metadata disabled, ffi off, no fs permissions. Dependencies are vendored as plain files under lib/ with no git directories or submodules: forge-std v1.9.7 and the five OpenZeppelin files the token needs.

Verification

Notes

• The ?? entries git shows for dotfiles such as .gitmodules and .bashrc are pre-existing device nodes in the workspace, not files I created.
• Slither and Mythril are not on this machine and did not run.
• I did not commit, since .git/ is off limits. All deliverables are in the working tree under src/, test/, script/, lib/, foundry.toml, remappings.txt, README.md and .gitignore.

I found no math defects in MADToken, and I've written an empty findings list with full coverage to .imd-findings.json. I checked this by reading the code; I wrote no Foundry tests and changed no project files.

src/MADToken.sol is a plain OpenZeppelin ERC20. Its constructor mints TOTAL_SUPPLY = 1_000_000_000 * 10 ** 18 (exactly 1e27) to the deployer once. There is no fee, burn, tax or custom arithmetic, so the precision, boundary and numerical-gap guides apply only to OpenZeppelin's own logic.

Coverage, all marked holds:

• transfer: subtracting from the sender's balance is checked and reverts if the balance is too low. The unchecked addition to the receiver can't overflow, because no balance can exceed the fixed supply of 1e27, far below 2^256.
• transferFrom: the allowance is checked before the unchecked subtraction. A maximum (type(uint256).max) allowance is never reduced, which is the intended "unlimited" behaviour. The balance math is the same as transfer.
• approve: it does no arithmetic.
• Fixed supply: total supply stays at 1e27 forever, since the constructor is the only place tokens are minted and nothing can mint or burn after that.

The only static-analysis lead was aderyn's "large numeric literal" at line 24. That's cosmetic: the value is computed exactly, so I left it out.

Done. I wrote launch.json for the Mutually Assured Destruction (MAD) launch and verified it against the accepted tree.

What the manifest says

• Kind is custom_token. The token contract is MADToken, with name "Mutually Assured Destruction", symbol MAD, and 18 decimals.
• The constructor takes no arguments, so constructorArgs is an empty list. The compiled ABI confirms the constructor has no inputs.
• totalSupply is one billion tokens in minor units, matching the TOTAL_SUPPLY constant the constructor mints to msg.sender.
• The contracts list is empty. The accepted tree contains only the token, so there are no application contracts to name.
• pool and economics are copied exactly from the launch reference: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's economics object verbatim.
• Notes describe the token's plain ERC-20 behaviour, the absence of owner or privileged calls, and why no launch placeholders are needed. They are well under the 4000 character limit.

Verification

• forge build compiled cleanly with solc 0.8.26.
• forge test with the verifier's fuzz seed passed all 27 tests.
• The manifest parses as JSON with only the six schema keys.
• git status shows launch.json as the only new or changed file.

Review complete. No defects found, and the findings file is written with an empty list and full coverage.

What I checked, in my area (Execution Trace, Periphery, First Principles)

• Execution trace of all three entry points. The token is OpenZeppelin v5.1.0 ERC20 with nothing overridden. I traced transfer, approve and transferFrom through the balance, allowance and zero-address guards, including zero value, self-transfer, whole balance, one wei over balance, infinite allowance, and allowance residuals. Every path moves exactly the requested amount or reverts. Supply never changes after the constructor.
• Periphery. The vendored OpenZeppelin subset is byte-identical to upstream v5.1.0, confirmed by diffing the five files against the tagged release. The Context base returns plain msg.sender, so there is no forwarder path.
• First principles. The supply constant evaluates to exactly the manifest figure of 1e27 minor units. The aderyn "large numeric literal" lead is a compile-time constant and not a defect. The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions, no receive or fallback, no mint, burn, owner or initializer. The project's reachable-opcode test for DELEGATECALL, CALLCODE and SELFDESTRUCT passes.
• Launch flows. A scratch test deployed the token via CREATE2 from a factory-like contract, moved the swarm share to a distributor, claimed it, and spent via a contract spender. All balances matched and supply was unchanged. The scratch file was removed afterwards.

Not reached. The seed and swap through a real Uniswap v4 PoolManager were not run locally because v4-core is not vendored. The token has no transfer hook, so no caller can be treated differently, and the coverage row says so.

Output. The file .imd-findings.json holds zero findings and seven coverage rows, one per listed entry point plus the constructor, periphery, runtime and launch-flow invariants. The working tree is otherwise unchanged.

The review is complete. The findings file at .imd-findings.json reports no defects and ten coverage rows, and the working tree is otherwise untouched.

Result: no economic, invariant or flow-gap defect found in the MAD token.

What I checked, in the assigned area:

• Economic Security. The token has no external dependency, oracle, callback, fee, rebase, pause or blocklist. Approving the max value and pulling the whole supply in one transferFrom succeeds. Zero-address paths revert. There is no price-dependent operation or capped shared accounting to drain.
• Invariants. A stateful fuzz run over six actors with random transfer, approve and transferFrom calls never changed the supply from 1e27 and never broke the sum-of-balances equality. The only mint is in the constructor. The compiled ABI exposes no mint, burn, owner, receive or fallback, and an opcode walk of the runtime found no CALL, DELEGATECALL, CREATE or SELFDESTRUCT.
• Flow Gap. I replayed the launch flows with a factory-like CREATE2 deployer, a distributor, a claimant, a pool-manager stand-in that measures balance deltas the way Uniswap v4 settle does, and a trader. Every flow delivered exactly the requested amount, so the swarm share, the seed and buys and sells cannot arrive short.
• Vendored library. All five OpenZeppelin files under lib are byte-identical to upstream v5.1.0, so the inherited ERC-20 logic is the audited original.
• Static-analysis lead. The aderyn large-literal note on line 24 evaluates to exactly 1,000,000,000 with 18 decimals, confirmed by the project's tests. Not a defect.

Each of the three listed entry points, approve, transfer and transferFrom, has a holds row. The project's own 27 tests pass with the verifier's fuzz seed. The standard ERC-20 approve race is recorded in the approve row as an inherent design property, not a finding. Nothing in my area was left unreached.

I added two test files, test/MADToken.invariant.t.sol and test/MADToken.edge.t.sol. The existing test/MADToken.t.sol is unchanged. forge build and forge test pass with the verifier's fuzz seed: 54 tests in 3 suites, none failing or skipped.

What the token is: a plain OpenZeppelin v5.1.0 ERC20. Its name is "Mutually Assured Destruction", its symbol is "MAD", and it has 18 decimals. The constructor mints 1,000,000,000 MAD once to the deployer. There is no owner, no admin function, no fee and no further minting.

Invariant suite (MADHandler driving 5 actors; 256 runs × 64 calls, set inline in the test file):

• The handler makes the normal calls: transfer, approve (finite or unlimited) and transferFrom, with amounts bounded to what is actually held and allowed.
• It also makes calls that must fail: spending more than the balance or the allowance, sending to the zero address, approving the zero address as spender, and calling functions that don't exist. Each must revert with the exact OpenZeppelin error and change nothing. Every handler call is required to succeed (fail-on-revert = true).
• After every call sequence, these hold:
  • the supply never changes;
  • the actors' balances add up to the total supply;
  • balances and allowances match an independent model kept by the test;
  • no spender pulls more than it was ever approved for (unless it was given an unlimited allowance);
  • name, symbol and decimals never change, and the contract holds no ETH.
• All 16,384 calls ran with 0 reverts, and every handler function was hit about 1,400–3,000 times.

Edge and failure-path tests:

• Launch split: deploying the token and paying out the 10% / 80% / 10% split in a single transaction leaves exact balances.
• Deployment: the constructor emits exactly one Transfer event, and two deployments are independent.
• Transfers: one wei, type(uint256).max, a transfer of 0 to the zero address (still reverts), sending to yourself more than you hold, and sending to the token contract (the tokens are not burned). A failed transfer leaves all state unchanged.
• Approvals:
  • approving again replaces the old amount rather than adding to it, and approving 0 revokes;
  • an approval larger than the balance still can't overdraw, and the failed attempt doesn't use up the allowance;
  • an allowance of max − 1 still goes down when spent;
  • spending your own tokens through transferFrom still needs an allowance;
  • transferFrom to the zero address, or from the zero address, reverts;
  • allowances are per spender and one-directional;
  • transferFrom emits no Approval event.
• Fuzz tests (1,000 runs each): a stranger can't pull tokens without an allowance; approve sets the exact amount; transferFrom keeps the supply constant and lowers the allowance; spending more than the balance reverts even with an unlimited allowance; random calldata to non-existent functions reverts.

Findings: none. I found no defect in src/MADToken.sol, so I didn't write .imd-findings.json. I haven't committed anything.

The review is complete and .imd-findings.json is written at the repository root. The working tree is otherwise unchanged (the findings file is gitignored, and my scratch test was removed).

Result: no defects in the Access Control, Trust Gap or Asymmetry area. The token is a 30-line wrapper over an unmodified OpenZeppelin v5.1.0 ERC20 that mints 1e27 units to msg.sender in its constructor and adds nothing else.

What I verified, with evidence:

• Permission model is empty by construction. The compiled ABI has exactly three non-view functions: approve, transfer, transferFrom. There is no owner, role, initializer, proxy, mint, burn, pause, blocklist or rescue path. A fuzz over arbitrary selectors from arbitrary callers never changed supply or any balance.
• Deployer has no power over holders. The factory, which receives the whole supply, cannot transferFrom a holder without an allowance and cannot write another account's allowance row.
• Paired entry points are symmetric. transfer and transferFrom move identical amounts through the same _update; supply is conserved under 2000-run fuzzing.
• Vendored library is genuine. All five vendored OpenZeppelin files hash byte-for-byte to the upstream v5.1.0 tag I fetched from GitHub. No assembly, delegatecall, selfdestruct or external calls exist in the source or the library.
• Build and tests pass. 27 of 27 project tests pass under the verifier's fuzz seed, and my 5 scratch tests passed before I deleted them.

One info-level note is recorded: the inherited ERC-20 approve is set-not-delta, so a spender can front-run an allowance reduction and spend old plus new. This is the standard ERC-20 approve race, a holder trust assumption rather than a code defect, and I recommend no change since adding increase/decrease helpers would alter the agreed design.

The coverage record answers all three listed entry points as holds, plus six invariant rows covering the constructor, admin surface, opcode safety, library integrity, the deploy script and the Trust Gap seams. Nothing in my area was left unreached.

Review complete. The findings file is written and the tree holds no other change.

Outcome: no defect in MADToken. The token is an unchanged OpenZeppelin v5.1.0 ERC20 with one constructor mint of 1e27 units to msg.sender, no owner, no fee, no mint path, no receive or fallback, and no DELEGATECALL or SELFDESTRUCT in the runtime. The vendored library files match upstream line for line, and the project's own 54 unit, fuzz and invariant tests pass.

The one specialist finding was reproduced and kept at info severity. The audit_permissions reviewer reported the standard ERC-20 approve race, where a spender front-runs an allowance reduction. I reran the exact sequence in a scratch test and bob ends with all 150e18 tokens as described. It is a property of the standard, not a code defect, so it is recorded as a trust assumption with no fix recommended. The other three specialists and the independent tester reported nothing, so there was nothing to merge.

My own pass found nothing further. I checked the deployment model against the factory's rules: the constructor takes no arguments, matching the manifest's empty constructorArgs, and the creation and runtime code sizes are well under the limits. The manifest's keys, lowercase addresses, supply and decimals all agree with the code. The aderyn lint on the large numeric literal is style only. The value evaluates exactly to the manifest supply.

Coverage answers all three entry points, plus three invariant rows covering fixed supply, deployability and the static-analysis lead.