Implemented MAD with 1 billion tokens, 18 decimals, minted once to the deployer. Standard ERC-20 behavior, with no administrative powers.

Dependencies are vendored; deployment assumptions and operational responsibilities are documented in README.md.

Passed: forge build, forge fmt --check, and all 33 tests using the requested fuzz seed.

Created launch.json matching MADToken, its exact supply, empty constructor arguments, and the required pool and economics.

forge build succeeded. All 33 tests passed with the supplied fuzz seed. Only launch.json is changed for submission.

I added two test files to the existing suite and found no defects in src/MADToken.sol. forge build and forge test with the verifier's seed both pass: 49 tests, none failing. My changes are only under test/.

test/MADToken.ledger.invariant.t.sol checks every call against a separate record of what each balance and allowance should be:

• It runs transfer, approve and transferFrom in random order across several holders. Inputs are allowed to exceed balances and allowances, hit the exact limit or one over it, use the maximum value, or target the zero address.
• Each call's result is checked against that record. A call expected to succeed must return true. A call expected to fail must revert with the exact error OpenZeppelin defines (insufficient allowance, then invalid receiver, then insufficient balance, in that order).
• After every call, these must hold: every balance and allowance matches the record, the balances add up to exactly 10²⁷, the total supply never changes, the zero address is never approved as a spender, and nothing the token contract itself holds can be authorised away.
• Over 256 sequences of 64 calls there were no unexpected reverts. A throwaway probe confirmed every sequence included both successful and rejected calls, so the invariants are actually exercised.

test/MADToken.edge.t.sol adds 15 unit and fuzz tests:

• Fixed values: the supply is exactly 10²⁷, and any deployer address receives the whole supply.
• Opcode scan: the deployed code contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. It covers all of the code except the compiler's metadata at the end.
• Recipients and approvals: transfers to any non-zero recipient arrive exactly, and approve stores any value unchanged.
• Allowances:
  • Spending an allowance in two parts leaves the same result as spending it in one.
  • An allowance one below the maximum is still reduced when spent.
  • An exhausted allowance cannot be spent again.
  • A maximum allowance still can't take more than the holder's balance.
  • An owner needs an approval to use transferFrom on their own tokens.
  • A transferFrom from any caller without an allowance reverts.
• Events and unknown calls: spending an allowance does not emit an Approval event, and unknown function calls revert.

Findings: none, so I did not write .imd-findings.json. One behaviour worth knowing, which is standard ERC-20 and was already documented in the README: tokens sent to the token contract's own address can never be moved again. A test now pins this down.

The protected launch tests in .imd/reads/ can't run here because the Uniswap v4 code they import isn't in this repository; they belong to the later launch checks.

The review is complete. The findings file is written and the working tree is clean apart from the gitignored scratch test.

Result: no defects found in the Access Control, Trust Gap and Asymmetry areas. The findings file at .imd-findings.json holds an empty findings list and eight coverage rows, all holds.

What the token is. src/MADToken.sol is sixteen lines: it inherits the vendored OpenZeppelin ERC20 and its constructor mints one billion tokens with 18 decimals to msg.sender. The compiled ABI contains only the standard ERC-20 functions, events and ERC-6093 errors, plus the supply constant getter.

What I verified.

• The permission model has no roles, modifiers, owner storage, initializer, proxy or admin setters. Balances are written only through the OpenZeppelin update path, allowances only by their owner or by a spender decrementing their own grant.
• The deployer holds no power after construction. Twenty-two common privileged selectors revert whether called by the deployer or a stranger, and the deployer cannot pull from a holder without allowance.
• The transfer and transferFrom paths share one internal transfer, so no caller class is treated differently. A fuzz test confirmed symmetric delivery and correct allowance accounting, including the unlimited-allowance case.
• The five vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 release archive, whose hash matches the one recorded in the repository.
• Runtime and creation bytecode contain no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT, and the contract rejects ETH.
• The project's own 33 tests pass with the pinned fuzz seed, and my six scratch tests pass.

Not covered. The protected launch floor's real Uniswap v4 seed and swap could not be run locally because it needs the launch environment variables and v4 sources. The token has no fee or exemption logic, so those flows depend only on the exact-transfer behavior verified above. The approve front-running race is standard ERC-20 behavior, documented in the README, and is not reported as a defect.

The review is complete and the report is written to .imd-findings.json.

Outcome: no economic, invariant or flow-gap defect found in the MAD token. The contract is an unmodified OpenZeppelin v5.0.2 ERC20 with a single constructor mint of 10^27 units to the deployer, and nothing in it can tax, block, grow or freeze a balance.

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

• Every vendored OpenZeppelin file was diffed byte for byte against upstream v5.0.2 on GitHub. All five are identical, so the library is not a hidden defect source.
• The compiled ABI holds only the constructor, the three listed state-changing functions and seven views. No mint, burn, owner, pause or initializer selector exists.
• Supply conservation: the only writer of balances and total supply is the inherited update routine, and mint is reachable only from the constructor. The project's invariant suite and my scratch fuzz both preserve every unit.
• Launch flows: the 10/85/5 split and the swarm's 2/8 sub-split each divide 10^27 with zero dust, and factory, distributor, pool and trader legs all arrive whole. No exemption list is needed because no path takes a fee.
• Allowance paths: finite allowances decrement exactly, unlimited ones stay untouched, a zero-address sender fails the allowance check so there is no mint path, and self-transfers preserve balances.
• External dependencies, oracles, callbacks, sentinel addresses and shared caps: none exist in the token, so nothing can be broken, starved or sandwiched.

One info-level note is recorded: the standard ERC-20 approve overwrite race, reproduced with a concrete sequence where a spender holding a 100 allowance front-runs a reduction to 50 and moves 150. It is inherent to the interface the brief asked for and the README already documents it, so no change is required. I flagged it only so the judge has the record.

Coverage record: all three entry points are answered, approve as finding with the info reference and transfer and transferFrom as holds, plus five invariant rows. A scratch test file under test/scratch/ verified the claims and all six of its checks pass. The project's own 33 tests also pass.

The review is complete. No math defects were found, and the findings file holds an empty list with a full coverage record.

What was reviewed. The token is a 16-line wrapper over OpenZeppelin ERC20 v5.0.2 with a single constructor mint of 10^27 units. All arithmetic lives in the vendored library. I compared the five vendored files byte-for-byte against the upstream v5.0.2 tag, and all are identical.

What was checked in the assigned area. Each check was run as a Foundry test under test/scratch/, alongside the existing 33-test suite, and everything passed.

• Math Precision. The supply constant folds at compile time to exactly 1e27 with no overflow. It fits uint96 and int128, so Uniswap v4 deltas and vote-style packing cannot truncate it. The 10/85/5 percent launch split in basis points divides 1e27 exactly with zero dust and no intermediate overflow. The aderyn large-literal lead is style only.
• Boundary. Transfers of max uint and balance plus one revert cleanly with the balance error. Full-balance self-transfer preserves the balance. An allowance of max minus one is finite and decremented, while max is infinite. A zero-value transferFrom from the zero address reverts before reaching the mint path. The token has no external calls, no payable paths, no sentinel branches and no bytes decoding.
• Numerical Gap. Supply conservation held across 1024 fuzzed holder and allowance splits. The derived opening price from the 2e24 FWA cap sits inside Uniswap v4 sqrtPrice and tick bounds in either currency order.

Coverage record. All three listed entry points are marked holds, plus seven invariant rows covering the constant, downcast fit, launch split, price bounds, library provenance, the constructor mint and the Boundary guide's empty applicability.

Nothing in the area was left unreached. No repository file outside .imd-findings.json and test/scratch/ was touched.

The findings file is valid JSON, both quoted snippets match the tree line for line, and the working tree is clean apart from the findings file and the gitignored scratch test.

Result: no defects in the token's control flow. The review found nothing in the Execution Trace, Periphery or First Principles areas that loses funds, breaks a launch flow or lets a privileged party act. The findings file holds one low and one informational item plus eleven coverage rows.

What was checked

• Execution trace. All three entry points were traced through the OpenZeppelin v5.0.2 internals with concrete inputs: zero address as sender, receiver and spender, zero and max-uint amounts, self-transfers, owner acting as its own spender, infinite allowances, and reverts that must leave allowance and balances untouched. Every path behaves as the standard requires. Transfers make no external call, so there is no callback or reentrancy surface.
• Periphery. Every vendored file was compared against the upstream archives named in the two UPSTREAM.md notes. OpenZeppelin is byte-identical. forge-std has seven files that differ only by whitespace reflow, which I confirmed by hashing with whitespace stripped.
• First principles. Supply is exactly 1e27 minted once to the immediate deployer, which a CREATE2 probe confirms is the factory and not the transaction origin. The compiled ABI exposes only approve, transfer and transferFrom as state-changing functions, no fallback or receive, and the runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT or even CALL on any reachable path. Launch legs move exact amounts since there is no fee, burn or exemption logic.
• Checks run. Build, the seeded project test suite, format check, and nine scratch probes in test/scratch/Probe.t.sol all pass.

Findings recorded

1. Low. The forge-std provenance note claims unchanged upstream files, but seven files were reformatted. No semantic change and no effect on production code. Fix is to restore the files from the tag or amend the note.
2. Info. The standard ERC-20 approve-replacement race, with a concrete trace. Already documented in the README and inherent to the standard, so no code change is recommended.

Not reached. The real Uniswap v4 seed and swap were not executed locally because v4-core is not vendored and lib/ may not be modified. The token's pool interaction is plain transfer and transferFrom, so I marked that row as holding by trace, and the protected suite covers it downstream.

I found no defects, so .imd-findings.json has an empty findings list. Its coverage record marks all three entry points, plus the supply invariant, as holds.

The code. src/MADToken.sol is a plain OpenZeppelin v5.0.2 ERC20 with nothing overridden. The constructor mints 1_000_000_000 * 10 ** 18 once to msg.sender (the factory during launch). There is no owner, no further minting, no burn, no fee, no hook, no pause, and no DELEGATECALL or SELFDESTRUCT.

Entry points:

• transfer: rejects the zero address as sender or receiver, reverts if the balance is too low, and moves exactly the amount asked. So the factory's transfers to the distributor, the pool manager and the remainder address arrive in full.
• transferFrom: checks and reduces the allowance (an unlimited allowance stays unlimited), then does the same exact transfer. A failure reverts the whole call.
• approve: rejects the zero address as owner or spender, overwrites the allowance and emits Approval.

Manifest. launch.json matches the code: 18 decimals, total supply 1000000000000000000000000000, no constructor arguments (the constructor takes none), no application contracts, and only schema fields.

Specialist findings:

• Approve front-running race (audit_flow and audit_economics): these are the same root cause, so I merged them, then dropped the result. A spender spending the old allowance before a replacement lands is how the ERC-20 standard works, not a defect in this code, and the README already tells holders to revoke to zero first.
• forge-std provenance note (low): dropped. It concerns lib/, which is outside this review and which submissions may not touch, and the specialist themselves showed the differences are whitespace only, with no effect on the token's bytecode or the tests.
• aderyn's "large numeric literal": style only, not a defect.

Checks:

• The project's own suite passes: 49 of 49 tests, invariant runs included.
• The supplied protected launch tests did not run here, so they don't count as passed. They import LaunchLiquidity.sol, PoolInitializationGuard.sol, HookFlags.sol and v4-core, none of which this tree has, so they don't compile. I removed the scratch copies afterwards and changed no other files.