Implemented MAD: 1,000,000,000 tokens with 18 decimals, minted once to the deployer, with no admin powers or additional minting.

Dependencies are vendored for offline builds. README documents assumptions, deployment, and operations.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed all 29 tests using the supplied fuzz seed.
• forge fmt --check passed.

I wrote launch.json for the MAD launch, and it's the only file I changed. The JSON parses, and forge build and forge test passed (29 tests) with the fuzz seed you gave. The two protected floor tests weren't part of that run: they import files that aren't in this tree, like src/LaunchLiquidity.sol, so the verifier runs those.

The manifest follows the accepted src/MADToken.sol:

• Token: contract MADToken, name "Mutually Assured Destruction", symbol MAD, 18 decimals.
• Constructor arguments: none. The constructor takes no parameters, so constructorArgs is [].
• Supply: totalSupply is "1000000000000000000000000000" (1 billion × 10^18), which is what the constructor mints once to msg.sender (the factory).
• Application contracts: none. The accepted tree only has the token, so contracts is [].
• Pool: FWA pair 0xa0df17b5ac76ababa36e1450e2cbcd18a620c845, fee 12500, tick spacing 60, starting price 79228162514264337593543950336 (one to one).
• Economics: copied exactly from the brief.
• Notes: a short description of the token. It has no owner, mint, burn, pause, fees or transfer restrictions.

The file isn't committed yet.

The review is complete. The math audit of MADToken found no defects, and .imd-findings.json holds an empty findings list with a full coverage record.

What was reviewed. The token is a 17-line contract that inherits OpenZeppelin ERC-20 v5.4.0 and mints a fixed supply once in its constructor. I confirmed all five vendored OpenZeppelin files are byte-identical to the upstream v5.4.0 tag, so the transfer and allowance arithmetic is the audited upstream code. The compiled ABI exposes only the three listed entry points plus views, with no receive or fallback.

Math Precision pass. The contract contains no divisions, scale conversions, downcasts, or fixed-point mixing. The supply constant evaluates exactly to 10^27 at compile time, which closes the aderyn large-numeric-literal lead as a non-defect. The unchecked blocks in the vendored _update and _spendAllowance are each preceded by the guard that makes them safe, and the single mint leaves over 2^160 of headroom below the uint256 ceiling.

Boundary pass. There are no external calls, payable paths, sentinel branches, or decoded bytes to exercise. I probed the remaining edges with a scratch Foundry suite of 12 tests, all passing:

• Transfers of type(uint256).max and supply plus one revert with the exact ERC-6093 error and leave state untouched.
• An allowance of max minus one stays finite and decrements. An allowance of exactly max is infinite and survives a full-supply spend.
• When allowance exceeds balance, the balance check wins and the allowance is restored by the revert.
• A zero-address sender through transferFrom reverts for both zero and nonzero values.

Numerical Gap pass. Supply conservation holds across 1-wei hop chains, zero-value transferFrom with no allowance, and a 1024-run split-transfer fuzz, in addition to the project's own 256-sequence stateful invariant. The launch's 10/80/10 split of 10^27 divides with no remainder, so no leg of the factory flow can arrive short.

Coverage. All three entry points are marked holds, with four extra rows for the invariants checked. Nothing in the assigned area was left unreached. The scratch tests were removed and the working tree is unchanged apart from the findings file.

The review is complete. Findings are in .imd-findings.json at the repository root with an empty findings list and a full coverage record. The working tree shows no tracked changes; the scratch test lives under the gitignored test/scratch/ and the findings file is the review output.

Result: no defects in the assigned area. The token is a 17-line wrapper over the unmodified OpenZeppelin v5.4.0 ERC-20 with a single constructor mint to msg.sender and no roles of any kind. Each check from the three guides came up empty against reproducible probes.

Access Control. The permission map has exactly one authority: a holder over its own balance and allowance rows. There is no owner, minter, pauser, initializer, proxy or upgrade path, so no inconsistent-guard, escalation or confused-deputy chain exists. The ABI exposes only the eleven standard ERC-20 members. I pranked 22 privileged selectors from both the factory and a stranger. All reverted with supply and holder balance unchanged. The factory calling transferFrom on a holder without allowance reverts.

Asymmetry. The only paired surface is approve against spend. Both write the same allowance row in mirror directions, the infinite-allowance branch is preserved, and revert paths leave balance and allowance intact. The transfer and transferFrom branches deliver identical balances for the same inputs. The mint branch of _update is reachable only in the constructor and the burn branch is unreachable.

Trust Gap. No privileged actor, pricing formula or caller-class branch exists, so no two-lens seam can be built. Launch legs for factory, distributor, claimant and pool round-trip exactly.

Supporting checks: the vendored library files hash identically to upstream v5.4.0 fetched from GitHub. The compiled runtime contains no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT. The existing 29-test suite passes with the pinned seed.

Deliberately not reported: the standard ERC-20 approve front-running race and tokens sent to the token's own address. Both are inherent ERC-20 properties the README already documents, not defects of this code.

The findings file is in place and excluded from git by the workspace's own exclude rules, so the tree is unchanged.

Result: no defects in the Economic Security, Invariant or Flow Gap areas. The findings file holds one informational note and seven coverage rows.

What I verified

• The token is an unmodified OpenZeppelin v5.4.0 ERC-20 with a single constructor mint of 1e27 units to msg.sender. All five vendored files are hash-identical to upstream v5.4.0, fetched from GitHub for comparison.
• Supply conservation holds: only the internal update function writes balances or supply, mint is reachable only from the constructor, and burn is unreachable. The project's invariant test passes with its pinned seed and again with a different seed and double the runs.
• Launch flows arrive whole. There is no fee, burn, hook, callback, blacklist, pause, owner or payable path, so the distributor share, pool seed, claims and swaps each move exactly the requested amount. A scratch test confirmed this with contract recipients and checked that they receive no call.
• Sentinel and edge paths behave as standard: zero receiver, zero spender and zero sender all revert, zero-value transferFrom needs no allowance, a finite allowance is consumed exactly, an infinite one is not, and a failed transferFrom leaves the allowance intact.
• The compiled runtime contains no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT, the constructor takes no arguments, and decimals returns 18, matching the manifest expectations in the protected test.

The one note, severity info: the standard ERC-20 allowance replacement race is inherited, since OpenZeppelin v5 has no increaseAllowance or decreaseAllowance. A spender who front-runs a reduced approval can spend old plus new allowance. The README already documents the revoke-to-zero mitigation, and it is not a deviation from the requested plain-ERC-20 design, so I recorded it as a trust assumption with a reproduction rather than a defect.

Outside my area but worth a line for the judge: the token's name suggests a destruction mechanic, and the README states explicitly that no transfer rule is inferred from it. The brief in this task specifies only name, symbol, supply, decimals and the single mint, so the plain implementation matches what was asked.

Both static-analysis leads were checked. Slither reported nothing, and aderyn's large-numeric-literal note is a compile-time constant that evaluates to exactly 1e27.

The review is complete. No defects were found, and .imd-findings.json holds an empty findings list with seven coverage rows.

What was reviewed. The only production contract is src/MADToken.sol: a 17-line OpenZeppelin v5.4.0 ERC-20 whose constructor mints one billion tokens with 18 decimals to the immediate deployer. I applied the Execution Trace, Periphery and First Principles guides from the Pashov reference, plus the Senior Auditor's Mindset, to the three state-changing entry points and the constructor.

Evidence gathered.

• All five vendored OpenZeppelin files hash identically to the upstream v5.4.0 release fetched from GitHub, so the periphery the token trusts is exactly the published library.
• The compiled ABI exposes only approve, transfer and transferFrom as state-changing calls. No receive, fallback, mint, burn, pause, blacklist, owner or upgrade surface exists.
• The reachable runtime bytecode contains no DELEGATECALL, CALLCODE or SELFDESTRUCT under the same scan the protected floor uses.
• The project's 29 tests pass with the README's seed, and formatting is clean. A scratch suite I wrote and ran confirmed the privileged-selector list from the protected floor all revert from the deployer, that a holder can still transfer afterwards, that infinite allowance is never decremented while finite allowance is, and that a transferFrom from the zero address reverts even for a zero value. The scratch directory was removed afterwards.

Traced behaviors. Transfers deliver the exact amount with no fee, burn or callback, so the factory, distributor and pool manager legs need no exemptions. Insufficient balance or allowance reverts before any state change. Self-transfers and zero-value transfers are no-ops that still emit events. The unchecked additions in the library are bounded by the fixed supply.

Items noted but not defects. The aderyn large-numeric-literal lead is a compile-time constant. No launch.json exists yet, which the brief states is expected before the manifest step. The token name implies a destruction mechanic, but the task text asks only for a plain fixed-supply token and the README states that choice explicitly.

Not reached. Nothing within the assigned area was left unverified. Pool seeding and swapping through a real Uniswap v4 PoolManager were not simulated locally, since that harness is not in this tree, but the token has no transfer logic that could differ in that path.

The commit failed because no git identity is set on this machine. I didn't change any git configuration; the two new files are staged and the submission pipeline can commit them.

I added two test files and all 47 tests pass with the verifier's seed (forge test). I found no defect, so I didn't write .imd-findings.json. The token is OpenZeppelin v5.4's standard ERC-20, unchanged. It has no owner, no mint or burn after deployment, no transfer rules, and it mints all 10^27 units (1 billion with 18 decimals) to the deployer. That matches the brief.

test/MADToken.model.invariant.t.sol: random call sequences checked against a separate record of the state.

• A handler acts for five accounts, including the token's own address as a recipient. It keeps its own record of every balance and allowance, updated by hand rather than read back from the token.
• It makes 8 kinds of call. Half are failure paths that must revert with the exact error and change nothing: sending more than the balance, sending to the zero address, approving the zero address, and transferFrom over the allowance or over the balance.
• After every call it checks:
  • total supply never changes;
  • every balance matches the record, and the balances add up to the full supply;
  • every allowance matches the record, including unlimited (max) allowances that are never spent down;
  • name, symbol and decimals never change.
• It uses 256 runs of 64 calls, set in the test file. Each call type ran about 2,000 times with no unexpected reverts.

test/MADToken.edge.t.sol: 17 edge-case and fuzz tests.

• Launch in one transaction: a helper contract deploys the token and sends the 10% / 80% / 10% launch shares in a single call. Each share arrives exact.
• Boundaries: sending exactly the balance works and one unit more fails; the same for allowances; sending the maximum value fails; an allowance one below the maximum still decreases when spent; an unlimited allowance can move the whole supply and no more.
• Zero-address sender: a zero-value transferFrom from the zero address reverts with ERC20InvalidApprover. My first version expected ERC20InvalidSender and failed. That was my mistake: OpenZeppelin checks the allowance owner before the sender. I corrected the test.
• No hidden functions: a fuzz test calls random function selectors from random callers. Every call outside the standard ERC-20 functions reverts and changes nothing.
• No dangerous opcodes: the deployed code is scanned for DELEGATECALL, CALLCODE and SELFDESTRUCT, the same way the launch floor checks.
• Other fuzz tests: approvals store the exact value, split spends never exceed the allowance, round trips restore balances, and other holders are untouched by a transfer.
• Lost tokens: tokens sent to the token's own address can never be moved out. This is the behaviour the README documents, not a defect.

I didn't run the launch floor tests in .imd/reads/protected/. They need Uniswap v4-core and launch settings from the environment, which this repository doesn't have; the verifier runs them.

The review is complete and the report is written to the findings file at the repository root. The tree is otherwise unchanged, and the scratch test directory was removed.

Outcome: the token is clean. No defect was found that would open a revision. One info-level note is kept, merged from the single specialist finding.

What was checked

• Build and tests pass. The full suite of 47 tests, including both stateful invariant suites, passed with the README's seed, and forge fmt --check is clean.
• Vendored OpenZeppelin is genuine. All five vendored files diff byte-identical against the upstream v5.4.0 tag.
• Supply and metadata are right. The constant evaluates to exactly 1e27, matching the manifest, and name, symbol and decimals match the brief. A CREATE2 deployment from a contract leaves the whole supply with that contract.
• Deployability holds. The constructor takes no arguments and needs no prior code. Creation code is 2658 bytes and runtime 1753 bytes. A reachable-opcode scan mirroring the protected test finds no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Manifest is consistent with the code and uses only schema keys with the right value types.
• Static analysis leads: Slither had nothing, and aderyn's large-literal line is style only.

Specialist findings

• The audit_economics allowance-race note reproduces exactly as stated. After approve 100, front-run spend 100, approve 50, spend 50, the sink holds 150. That is the ERC-20 standard's own replace semantics, documented in the README, so it is kept at info as a trust assumption rather than a defect.
• The other four areas reported nothing, and my own pass with the Pashov, x-ray and Trail of Bits checklists found nothing they missed. Every applicable failure mode there concerns external calls, non-standard tokens, callbacks or privileged roles, and this contract has none.

Coverage record: all three entry points are marked holds, plus four invariant rows covering the constructor mint, deployability, the manifest and the aderyn lead.