Implemented MADToken.sol: 1 billion MAD, 18 decimals, minted once to the deployer.

Dependencies are vendored. Assumptions, deployment parameters, and operational responsibilities are documented.

Verified with Solidity 0.8.26:

• forge build passes.
• All 33 tests pass with the supplied fuzz seed.
• forge fmt --check passes.
• Compiled bytecode passes the prohibited-opcode check.

Nothing left to fetch. The manifest validates and the tree is clean apart from launch.json.

• Written: launch.json only, kind: "custom_token", token MADToken with empty constructorArgs (the constructor is constructor() ERC20("Mutually Assured Destruction", "MAD") and mints 1_000_000_000 * 10 ** 18 to msg.sender), totalSupply of "1000000000000000000000000000", 18 decimals.
• Contracts: contracts is an empty list. src/MADToken.sol is the whole accepted tree, so there is no application contract to name.
• Pool and economics: FWA at 0xa0df17b5ac76ababa36e1450e2cbcd18a620c845, fee 12500, tick spacing 60, provenance price 79228162514264337593543950336; the economics object copied byte-for-byte from the brief. The swarm's 1000 bps is not written anywhere.
• Checks run: forge build succeeds, forge test with the pinned fuzz seed passes 33 tests including the invariant, and a scratch validator confirmed the key set, types, lowercase address, name pattern, notes length (1580 characters) and supply arithmetic against 10^27.
• Nothing else changed: git status shows launch.json as the only untracked file; forge fmt --check is clean.

One judgment call worth flagging: I left contracts empty rather than inventing a placeholder contract, since the criterion is that every named contract matches the accepted implementation and no application contract exists in it.

The review is complete with no defects found. The working tree is clean apart from ignored build output and the findings file.

Outcome: .imd-findings.json holds an empty findings list and eight coverage rows, all holds. I reported no findings because nothing in the Math Precision, Boundary or Numerical Gap guides applies to a defect in this code.

What the token is: src/MADToken.sol is a 17-line contract that inherits the vendored OpenZeppelin v5.1.0 ERC20 unchanged and mints a constant supply to the deployer in its constructor. It has no overrides, no owner, no fees, no external calls, no receive or fallback.

What I verified:

• Supply constant. The literal evaluates to exactly 10^27, matching the brief and the manifest's minor units. The single mint cannot overflow. The aderyn "large numeric literal" lead is style only.
• Transfer and transferFrom thresholds. Balance equal to value passes, one more reverts, including the maximum uint256. Allowance equal to value passes to zero, one less reverts. Max minus one is a finite allowance and is decremented, max is the untouched infinite sentinel. The unchecked subtractions and additions are bounded by the total supply.
• Boundary cases. Zero-value transfers, self-transfers, self-approvals, transfers from the zero address, and ETH sent to the contract all behave as OpenZeppelin documents and roll back cleanly on revert.
• Launch arithmetic. The 10/75/15 percent split of 10^27 divides exactly with no remainder, and every transfer delivers the full amount, so the launch flows arrive whole.
• Dependency integrity. All five vendored OpenZeppelin files hash identically to the upstream v5.1.0 tag.
• Bytecode. The compiled runtime contains no CALL-family or SELFDESTRUCT opcodes. The ABI exposes exactly the three listed entry points plus views.

The project's own 33 tests, including the fuzz and stateful invariant suites, pass. My scratch probe test exercised the extra edges above and has been removed. Nothing in my area was left unreached.

The review is complete. The findings file is written and the scratch probe passes on all ten checks.

Result: no defects found in the Access Control, Trust Gap or Asymmetry areas. The file .imd-findings.json holds an empty findings list and seven coverage rows, one for each of the three listed entry points plus four invariants.

What I verified

• Access control. The token has no roles at all. The ABI's only state-changing functions are approve, transfer and transferFrom. There is no receive, fallback, initializer, owner, minter, pauser, blocklist or upgrade path. Empty calldata, unknown selectors and any ETH value all revert. The deployer or factory has exactly the same rights as any holder, and a transferFrom from the factory against a holder with no allowance reverts.
• Trust gap. The entire implementation is vendored OpenZeppelin. All five vendored files hash identically to upstream v5.1.0, so no modified library hides a backdoor. The supply slot has no writer after construction because mint and burn are never exposed. Reachable runtime code contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL or CREATE. The constructor takes no arguments and credits msg.sender, which under CREATE2 is the factory and never the origin or the factory's caller.
• Asymmetry. Storage-write tracing shows transfer writes exactly two balance slots, transferFrom with a finite allowance writes one allowance slot plus two balances, and an unlimited allowance writes only balances. A revert on any path restores allowance. A transferFrom with from set to the zero address reverts for both zero and positive value, so no mint can be reached through the allowance path. A zero-value transferFrom without allowance succeeds and moves nothing, which is standard ERC-20 behavior.

Leads I checked and dropped

• The aderyn "large numeric literal" line resolves to exactly 10^27, matching the manifest supply.
• The ERC-20 approval replacement race is reproducible but inherent to the standard, documented in the README, and not a defect of the requested design.

Not run here

The protected Uniswap v4 harness could not be executed because v4-core is not vendored in this tree. Since the token has no transfer override, the launch flows cannot arrive short, and the existing launch-flow unit test plus my probe confirm supply conservation.

The review is complete. The findings file holds an empty findings list with ten coverage rows, all holds, and the scratch test directory is removed. The working tree is clean apart from the required .imd-findings.json.

Result: no defects found. The token in src/MADToken.sol is an unmodified OpenZeppelin v5.1.0 ERC20 with one constructor mint and nothing else, and every check in my three guides came back clean.

What I verified for the three entry points:

• transfer and transferFrom reach a single atomic _update with no external calls, no partial writes and no reachable callback. Max allowance is never decremented, max-minus-one is, and a revert inside the transfer restores the allowance.
• approve only writes the caller's own allowance slot and rejects a zero spender. The standard ERC-20 approve race is inherent to the requested design and already documented in the README, so it is not reported as a defect.
• The constructor mints exactly 10^27 base units to the immediate creator, not the transaction origin, which I confirmed through a nested-constructor test. This dismisses the aderyn large-literal lead.

Periphery and first principles:

• I downloaded the OpenZeppelin v5.1.0 tarball, matched its checksum to DEPENDENCIES.md, and compared each vendored file byte for byte. All six are identical to upstream.
• An opcode scan of the compiled runtime found no reachable DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL or CREATE, and there is no receive or fallback. The metadata tail is the version only, consistent with the pinned build settings.
• Supply cannot grow after launch since the ABI exposes no mint, and no privileged role exists that could move or freeze a holder. Launch flows move exactly what they say because nothing overrides the transfer path.

What I did not run: the protected Uniswap v4 harness, which needs the v4-core dependency and launch environment variables not present here. The project's own launch-flow test covers the transfer side of that flow, and the existing 33 tests plus my eight scratch probes all pass.

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

Result: clean under the Economic Security, Invariant and Flow Gap guides. The token at src/MADToken.sol is a fixed-supply ERC-20 that inherits OpenZeppelin v5.1.0 with no overrides. I diffed all five vendored OpenZeppelin files against upstream v5.1.0 and they are byte-identical. The project suite passes with the README seed.

What I checked, with evidence:

• The supply literal equals exactly 10^27 base units, matching the brief and the manifest example. It fits in int128, so a Uniswap v4 balance delta cannot overflow on the 75% seed.
• Sum of balances equals total supply permanently. The constructor mint is the only writer of total supply, and the compiled ABI exposes only the ten ERC-20 functions plus the supply constant. The project's stateful invariant run and my scratch tests confirm conservation.
• The launch flows arrive whole. My scratch test deploys through a CREATE2 factory, pushes the 10%/75%/15% shares, claims from the distributor, and trades both ways through a v4-style sync/settle probe. The settled delta equals the sent amount for every holder across 1,024 fuzz runs.
• There are no external calls, callbacks, payable paths, or call-family opcodes in the bytecode, so none of the dependency-failure or periphery seams in the guides have anything to act on.
• Transfer and transferFrom revert cleanly on zero recipient, insufficient balance and insufficient allowance, restoring allowance on failure. The deployer and factory cannot debit a holder without approval.
• The aderyn large-numeric-literal lead was checked and dismissed. Slither reported nothing.

Findings file contents. One info entry records the standard ERC-20 allowance replacement race with a concrete reproduction, marked explicitly as inherent to the specification, accepted by the design, and already documented in the README. It proposes no fix. Eight coverage rows cover all three entry points as holds plus five invariants and flows I verified.

Scratch tests live under test/scratch/EconFlow.t.sol, which the repository ignores and which is not submitted. No tracked file was modified.

I added 22 tests in two new files under test/ and found no defects in the token, so there is no .imd-findings.json. The full suite passes with the verifier's fuzz seed: 55 tests (the 33 that were already there plus my 22), 0 failed. forge build succeeds too. The new files aren't committed yet.

src/MADToken.sol is a plain OpenZeppelin v5.1 ERC-20. Its constructor mints 1,000,000,000 × 10¹⁸ to whoever deploys it, and it has no owner, mint, burn, pause or fee code.

test/MADToken.edge.t.sol (21 tests), mostly failure paths:

• Calls that must fail:
  • sending ETH to the token, calling a function it doesn't have, or attaching ETH to transfer/approve;
  • the zero address trying to send or approve;
  • transferFrom with the zero address as the source, for zero and non-zero amounts;
  • an owner moving their own tokens through transferFrom without an allowance;
  • a spender trying to go past their allowance over several calls.
• Edge cases: an allowance of the maximum minus 1 still counts down; an unlimited allowance emits no Approval event when spent; contracts can hold and send tokens like wallets; tokens sent to the token's own address stay stuck there, because nothing can take them out.
• Fixed facts: the supply is exactly 10²⁷. The deployed code is within the 24,576-byte limit and contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Launch in one transaction: a helper contract deploys the token and splits it into the 10% swarm share, a fuzzed pool share and the remainder, all in one call. Each share must arrive whole, and the distributor's claim must arrive whole too.
• Fuzzed properties: transfer succeeds exactly when the amount is within the balance. transferFrom succeeds exactly when the amount is within both the allowance and the balance, and changes nothing when it fails. The other three cover approvals, round-trips and split transfers.

test/MADToken.ledger.invariant.t.sol (invariant suite, 256 runs × 100 calls): a handler drives five holders through random valid transfers, approvals and transferFrom calls. It also mixes in calls that must revert: overdrawing a balance, overspending an allowance, sending to or approving the zero address, and an outsider trying transferFrom or mint. Running separate tallies of balances and allowances, the invariants check that:

• every balance and allowance matches the tally exactly;
• each balance equals what came in minus what went out;
• the balances add up to the full supply and the total supply never changes;
• the outsider and the zero address never hold tokens or allowances.

One expectation I wrote was wrong and I corrected it. transferFrom(address(0), x, 0) reverts with ERC20InvalidApprover, not ERC20InvalidSender, because OpenZeppelin v5.1 checks the allowance before the sender. The call is still refused, which is the property under test.

The review is complete and .imd-findings.json is written. The working tree is otherwise untouched.

Outcome. The MAD token has no defects. It is a parameterless, fixed-supply OpenZeppelin v5.1.0 ERC-20 with no owner, hooks, fees or admin surface, and it is deployable under the factory model.

What I verified

• Vendored library is genuine. I downloaded the OpenZeppelin v5.1.0 archive and confirmed its checksum matches DEPENDENCIES.md. All six vendored files are byte-identical to upstream.
• Build and suite pass. The project builds under Solidity 0.8.26 and all 55 tests pass with the README's fuzz seed, including the two invariant suites.
• Entry points traced. I wrote a scratch test exercising approve, transfer and transferFrom on their success and revert paths, plus CREATE2 deployment through a factory stub that credits the factory with the whole supply. All passed as expected. The scratch directory is removed.
• Deployment limits. Creation code is 2,657 bytes and runtime 1,752 bytes, far under the protocol limits. No delegatecall, callcode or selfdestruct exists in source. The manifest's empty constructorArgs and totalSupply match the contract.
• Static leads. Slither reported nothing. The aderyn large-numeric-literal note on the supply constant is a style remark only. The literal evaluates to the correct 10^27.

Specialist findings. Four areas and the test writer reported one finding in total, from audit_economics: the standard ERC-20 allowance overwrite race in approve, rated info. I reproduced it and kept it at info as a documented, by-design note that opens no revision. The README already instructs applications to revoke to zero first. Nothing was found to merge or drop beyond that.

Coverage. All three listed entry points are marked holds, with four additional invariant rows covering the constructor mint, supply immutability and privileged calls, deployability, and the manifest.