The MAD token project is complete, verified and committed on main.

What was built

• src/MADToken.sol: contract MADToken, a fixed-supply ERC-20 on the unmodified OpenZeppelin v5.4.0 ERC20. Name "Mutually Assured Destruction", symbol "MAD", 18 decimals, 1,000,000,000 tokens minted once to msg.sender in a no-argument constructor. No owner, mint, pause, blacklist, freeze, seize, burn or fee surface, no external calls, no delegatecall or selfdestruct, so every launch flow moves exactly what it says and the supply can never grow.
• foundry.toml at the repository root pins solc = "0.8.26", bytecode_hash = "none", optimizer on, no ffi or filesystem permissions. The built bytecode carries no metadata trailer.
• test/MADToken.t.sol has 28 tests: metadata and supply, constructor mint event, CREATE2 deployment from a factory stand-in with the 10/80/10 payout arriving whole, success paths for transfer, approve and transferFrom, failure paths with the exact OpenZeppelin custom errors, a probe of every mint/admin/freeze signature from both a stranger and the deployer, ETH rejection, an EIP-170 size and forbidden-opcode scan, and three fuzz tests.
• script/DeployMADToken.s.sol exposes a deploy() function with no environment reads. It is a rehearsal aid only. The launch factory deploys the token itself.
• README.md documents assumptions, the manifest parameters, the empty "After launch" section, operational responsibilities and security notes.
• lib/forge-std (v1.9.7) and lib/openzeppelin (v5.4.0, contracts/ only) are vendored as plain files. All 373 library entries are mode 100644, so there is no submodule.

Check results

Check	Result
forge build (clean rebuild)	success
forge test with the verifier's fuzz seed	28 passed, 0 failed
forge fmt --check	clean

One thing to know

The sandbox bind-mounted lib/openzeppelin-contracts/.gitmodules read-only during vendoring, so that one stray file could not be deleted. It is excluded from the commit via .gitignore, is not a submodule, and nothing references it. The real OpenZeppelin sources live in lib/openzeppelin.

No requester input was needed. The token has no configurable values, so nothing is left as a placeholder.

I found no defects in the permissions review of MADToken (Mutually Assured Destruction, MAD). The report in .imd-findings.json has an empty findings list and a coverage row for each of the three entry points; all three hold. I changed no other files, and all 28 existing tests pass.

Why there is nothing to report:

• Access control: src/MADToken.sol has no owner, admin, role or modifier. There is no pause, blacklist, freeze, seize, mint, burn or upgrade path. The only privileged act is the constructor minting the full 1,000,000,000 × 10^18 to msg.sender, which at launch is the factory. After deployment no address holds any special power.
• Trust gap: the token takes no constructor arguments and calls no other contract. Its behaviour therefore can't depend on any address someone else sets, and nothing can be initialized later by whoever gets there first. I checked the vendored OpenZeppelin 5.4.0 ERC20 and Context against the standard code, and they are unchanged. In particular _msgSender() is plain msg.sender.
• Asymmetry: _update is not overridden, so every transfer moves exactly the amount asked for. No sender or receiver is treated differently, so the launch transfers (factory to distributor, seeding the pool, the remainder to the requester, and trades through the pool) all arrive exact.
• Each entry point:
  • approve: rejects a zero owner or zero spender, then sets the allowance.
  • transfer: rejects a zero sender or zero receiver, and checks the balance.
  • transferFrom: limits the spender to the allowance the holder gave. An allowance of the maximum value is never reduced, which is standard OpenZeppelin behaviour.

Besides the three entry-point rows, the coverage record holds three checked invariants:

• no privileged role exists after deployment;
• the supply is fixed and goes only to the deployer;
• the launch transfers arrive exact.

What I didn't report:

• The aderyn "Large Numeric Literal" note at src/MADToken.sol:27 is a style remark. The value it flags is correct (1e27).
• The known ERC-20 approve race, where a spender can use an old allowance before a change lands, is standard behaviour the brief doesn't ask to change, so it isn't a defect here.

Limits: this is a static review of the token alone, plus the existing tests. I didn't write extra tests, because nothing turned up that would need one. The project has no other contracts.

Created launch.json matching MADToken, its constructor and supply, and the exact pool and economics values.

Validation passed: manifest checks, forge build, and all 28 tests using the specified fuzz seed. Only launch.json is changed for submission.

The review is complete and written to .imd-findings.json. No math defects found.

What I reviewed. The token in src/MADToken.sol is an unmodified OpenZeppelin 5.4.0 ERC-20 with a fixed supply minted once in the constructor. It has no formulas, divisions, rate conversions, external calls, payable paths or bytes decoding, so the Math Precision, Boundary and Numerical Gap guides mostly reduce to the arithmetic inside OpenZeppelin's balance and allowance updates.

What I verified concretely. I ran the existing 28-test suite (all pass) and a scratch Foundry test of 12 boundary cases, then removed the scratch file:

• The supply constant evaluates exactly to 1e27, with the exponent cast to uint256 so no narrow-type exponentiation. The aderyn large-literal lead is benign.
• Transfer and transferFrom guard every unchecked subtraction with a prior balance or allowance check. Self-transfer of the whole balance, zero amounts, uint256 max amounts and the zero-address receiver all behave correctly.
• The infinite-allowance sentinel is not decremented, max-1 is, and the balance check still applies under an infinite allowance.
• The launch split of 10 percent, 80 percent and the remainder is exact in integer arithmetic, and the supply fits a Uniswap v4 int128 delta.
• Sum of balances equals total supply under fuzzing, and no mint, burn or transfer-to-zero path exists after construction.

What I reported. Two info-level notes only, each with a reproduction, both inherent ERC-20 properties rather than defects: tokens sent to the token's own address are locked, and the standard approve race lets a front-running spender spend an old and a new allowance. Neither warrants a fix under the no-privileged-role design.

Coverage. All three listed entry points are marked holds, plus six invariant rows covering the constructor arithmetic, decimals, launch-split exactness, supply conservation, and the absence of any boundary or numerical-seam surface. Nothing was left unreached.

The review is complete. No defects were found in the assigned area, and the findings file is written with an empty findings list and a full coverage record.

What I reviewed. The token is a 40-line contract inheriting OpenZeppelin v5.4.0 ERC20 unmodified, with a constructor that mints the fixed supply to the caller and a pure decimals override. I applied the Execution Trace, Periphery and First Principles guides against it, plus the Senior Auditor's Mindset and the validation gates.

What held, with evidence:

• Execution traces of approve, transfer and transferFrom: every sentinel (address zero as sender, receiver, spender), the infinite allowance path, the max-minus-one decrement, self-transfer, zero value, and the revert that rolls back a partial allowance decrement when the receiver is zero. I confirmed each with a scratch Foundry test that passed on the current code.
• Periphery: the five vendored OpenZeppelin files the token depends on are byte-identical to the tagged v5.4.0 release. The Context base returns plain msg.sender, so there is no forwarder or caller-spoofing path. The deploy script only wraps new MADToken().
• First principles: the supply literal evaluates to exactly the manifest's one billion with 18 decimals. The supply is minted to the direct caller, not the transaction origin, which I checked through an intermediary deployer. The compiled ABI has exactly the three state-changing functions the verifier listed, so no mint, burn, owner or freeze surface exists.
• Bytecode: no reachable CALL, STATICCALL, DELEGATECALL, CALLCODE, CREATE, CREATE2 or SELFDESTRUCT, and no payable entry.
• Static analysis leads: slither reported nothing. The aderyn large-numeric-literal line is the supply constant and evaluates correctly, so it is not a defect.

Coverage record. Ten rows, all holds: the three listed entry points, the constructor, decimals, and invariant rows for fixed supply, no external calls, vendored base contracts, the deploy script, and exact launch flows.

Checks run. forge build, forge test with the verifier's fuzz seed, and forge fmt --check all pass. The scratch tests were removed afterwards, and the tree is unchanged apart from the ignored findings file.

Not reported on purpose. The standard ERC-20 approve front-running race is a design property of every plain ERC-20 and is documented in the README, so it is noted in the coverage record rather than filed as a defect.

I added an invariant suite and an edge-case suite for the MAD token. All 45 tests pass with the verifier's fuzz seed, forge build is clean, and both new files are formatted.

What I found in the token: src/MADToken.sol is OpenZeppelin v5's standard ERC-20 with no changes. It adds only constants, decimals(), and a constructor that mints the 1,000,000,000 × 10¹⁸ supply to the deployer once. I found no defects, so I did not write .imd-findings.json. The README matches the code.

test/MADToken.invariant.t.sol (new): a test contract that calls the token in random order, with five accounts including the deployer. It does five things: transfers, transfers to the zero address, approvals (including zero and the maximum), spending an allowance, and calls to admin functions that don't exist (mint, burn, burnFrom, pause, blacklist, transferOwnership, seize, freeze). Amounts lean towards the edges: zero, the whole balance, one more than the balance, and very large values.

It keeps its own record of what each balance and allowance should be, worked out from the ERC-20 rules rather than by reading the token. For every call that should fail, it checks the exact error. The checks below run after every step, at 256 runs × 64 calls, and none of the 16,384 calls reverted unexpectedly:

• Total supply never changes.
• The five accounts' balances add up to the total supply, and nothing reaches the zero address.
• Every balance and allowance matches the expected record.
• Every call succeeded or failed exactly as the rules say, and every transfer moved exactly its amount.
• No balance ever exceeds the supply.
• Each run made at least one real change, so the checks never pass on an empty run.

test/MADToken.edge.t.sol (new): 16 tests of failure paths and edge cases the existing suite didn't cover:

• the constructor emits exactly one event, a mint for the whole supply;
• an owner calling transferFrom on their own tokens still needs an allowance to themselves;
• transferFrom to the zero address fails and does not use up the allowance;
• approve from the zero address fails;
• a zero-amount transferFrom succeeds with no allowance;
• an allowance of the maximum minus one goes down when spent, and an unlimited allowance still can't move more than the balance;
• transferring the maximum uint256 fails;
• an allowance reset to zero blocks spending;
• calls the token doesn't recognise, or with no data, fail.

The rest are fuzz tests at 1,000 runs each. They cover self-transfers, transfers there and back, transferFrom against both the allowance and balance limits (a failed call changes nothing), and approve setting the exact value.

One of my own expectations was wrong, not the token. A transferFrom from the zero address fails with ERC20InvalidApprover, not ERC20InvalidSender. That's because OpenZeppelin v5 checks the allowance first, and that check rejects the zero owner. The test now asserts the real behaviour, with a comment explaining why.

I left the existing test/MADToken.t.sol (28 tests) unchanged. I didn't touch anything outside test/, and I haven't committed the two new files.

The review is complete and the findings file is written. The MAD token passed every check in my area with no defects.

Outcome: .imd-findings.json holds zero findings and ten coverage rows, one per listed entry point plus the invariants and flows I checked. No tracked file was changed. My scratch test was removed and the build artefacts are gitignored.

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

• Supply and minting. The constant equals 10^27, which matches the manifest string in the README and the specified 1,000,000,000 tokens at 18 decimals. The mint happens once in the constructor to msg.sender, and the compiled ABI exposes no mint, burn, owner, pause or upgrade function. The only state-changing entries are approve, transfer and transferFrom.
• Conservation invariant. A Foundry invariant run of about 128,000 handler calls over the three entry points, among six actors including the token address itself, kept the sum of balances equal to the total supply throughout. Round trips at 1 wei, supply minus one and the full supply returned exactly.
• Launch flows. The 10 percent swarm share, the 80 percent pool share pulled by a pool-manager stand-in through an allowance, and the 10 percent remainder all arrived whole, leaving the factory at zero and the allowance fully consumed. The token makes no external calls and has no receive or fallback, so no callback seam exists for the PoolManager or distributor to hit.
• Dependencies. The vendored OpenZeppelin tree is byte-identical to the official v5.4.0 release, and vendored forge-std matches v1.9.7, so the transfer logic is the audited implementation rather than a modified copy.
• Existing suite. All 28 project tests pass, including with the verifier's fuzz seed, and the bytecode scan for forbidden opcodes passes.

Not reported as defects, by design: the ERC-20 approve overwrite race and the unrecoverability of tokens sent to the contract's own address. Both are standard ERC-20 behaviour, both are documented in the README, and a rescue path would require an owner the design intentionally excludes.

Outside my reach: the pool parameters in the README (chain 1, FWA pairing, fee, tick spacing, opening cap) could not be checked against a network.json, since none is supplied. The token has no knowledge of them, so they do not affect its correctness.

I found no defects that should block this launch, so .imd-findings.json has an empty findings list. It also has a coverage row for each of the three entry points, all marked holds.

What I checked

• The token itself: src/MADToken.sol is a plain OpenZeppelin ERC-20 with a constructor that takes no arguments. Its only _mint call is in the constructor. It has no owner, no mint, pause or burnFrom function, no fee and no external calls.
• The library underneath: I compared the vendored OpenZeppelin v5.4.0 files the token compiles against (ERC20, IERC20, IERC20Metadata, Context, IERC6093) with the upstream v5.4.0 tag. All five are identical, so approve, transfer and transferFrom behave exactly as standard OpenZeppelin.
• Build and tests: The project builds, and all 45 of its tests pass, including the invariant runs.
• Deployment: The token deploys well under the size limits (2,187 bytes deployed, 3,373 bytes of creation code). launch.json gives an empty argument list, which matches the constructor, and states a supply of 1e27 (one billion tokens with 18 decimals).
• My own scratch test: It deployed the token with CREATE2 from a stand-in factory, the way the launch does. The factory received exactly 1e27, and decimals, name and symbol match the brief. The same scan the protected floor test runs found no DELEGATECALL, CALLCODE or SELFDESTRUCT. Edge cases behave as expected: transfers to the zero address revert, unlimited allowances aren't reduced, and a holder can transfer to themselves.

The protected floor test needs pool and factory files that aren't in this repo, so I couldn't run it. My scratch test repeats its token-only checks; it doesn't cover the pool seed or the swaps.

The specialists' two notes (both from the math specialist) Both reproduce, and I dropped both as findings:

• Tokens sent to the token's own address are stuck for good. Confirmed: nothing can move them. That is normal ERC-20 behaviour, and adding a rescue function would add the privileged role the brief rules out.
• Lowering an allowance can be front-run. Confirmed: the spender ended up with 150e18 after the allowance went from 100e18 to 50e18. That is how standard ERC-20 approve works, not a defect in this token.

Neither is a defect in MADToken, and any finding I keep holds up the launch until it is resolved. I recorded both in the coverage list with the reasons. The other specialists reported nothing, and there were no duplicates to merge.

Static analysis: The one line, a "large numeric literal" at line 27, is just the supply constant 1_000_000_000 * 10 ** 18. It's correct.

The only file this left behind is .imd-findings.json. I deleted the scratch test and the build output (out/, cache/).