I built the MAD token as a plain fixed-supply ERC-20 and tested it, but it is not committed. The commit failed because git has no author name or email set on this machine. The files are staged in the working tree; I didn't set an author because that's stored in .git, which I'm not allowed to touch.

On the compiler pinned in foundry.toml (0.8.26), forge build and forge test pass: 11 of 11 tests, including the fuzz test run with the verifier's seed. forge fmt --check is clean. I couldn't run the launch's own protected test files, because they need launch-side files and settings that aren't in this repository.

• Contract: src/MADToken.sol, Solidity name MADToken. name() returns "Mutually Assured Destruction", the symbol is "MAD", and it has 18 decimals. The constructor takes no arguments and mints all 1,000,000,000 × 10^18 tokens once to the deployer, which is the launch factory.
• What it doesn't have: no owner, no further minting, no fee, burn, pause or blacklist. So every transfer to or from the factory, the distributor and the pool moves exactly the amount sent, and the supply can never grow. type(uint256).max counts as an unlimited allowance.
• Tests: test/MADToken.t.sol checks the token details and supply, the mint event, transfers, approve and transferFrom, the unlimited allowance, and that the failure cases revert with the right error (not enough balance or allowance, zero address). It also checks there is no mint function and runs a fuzz test that the total supply never changes.
• Setup: foundry.toml sets compiler 0.8.26, bytecode_hash = "none" and the optimizer at 200 runs. The test library (forge-std v1.9.4) is copied into lib/forge-std as ordinary files, so the verifier needs no network.
• Docs: README.md covers the deployment parameters and assumptions. It records that there are no privileged roles and nothing for the owner to set after launch.

I didn't write launch.json, since that's for the later manifest step.

The repository root also has some files that aren't mine, such as .bashrc, .gitmodules and .mcp.json. They appear to be placeholders the sandbox puts there, so I left them out.

I found no real defects in the token's math, and nothing at low severity or above. The report has one info-level finding and a coverage row for each of the three entry points. It's in .imd-findings.json, which is valid JSON and quotes src/MADToken.sol:56 exactly as it appears in the file. No tracked files changed; the scratch test I used was deleted afterwards.

Finding 1 (info): transferFrom(address(0), X, 0) succeeds for any caller and emits Transfer(address(0), X, 0). Explorers and indexers read that event as a mint, which clashes with "minted once in the constructor". No balances or supply change. The fix is one line: reject from == address(0) in _transfer, which is what OpenZeppelin does. I confirmed it with a scratch Foundry test that recorded the event.

What holds (ran the three guides from the Pashov reference — Math Precision, Boundary, Numerical Gap — against src/MADToken.sol):

• Math: the contract has no division, no fixed-point scaling and no casts. The supply constant, 1e27, is computed at compile time.
• Unchecked subtractions: both the balance and the allowance subtraction are guarded by a check just before them.
• Unchecked addition: balanceOf[to] += value can't overflow, because there's no way to mint and all balances add up to at most 1e27.
• Edge cases: zero amounts, the unlimited (type(uint256).max) allowance, the zero address as receiver or spender, transfers to yourself, and moving a whole balance all behave correctly. I tested the self-transfer and whole-balance cases.
• Launch flows: there's no fee or burn on transfer, so the transfers from the factory to the distributor, the pool seed and swaps all arrive in full.

The two aderyn leads are not defects. The large-number warning points at the supply constant, which is correct. totalSupply could be immutable, but that only affects gas.

The existing 11 project tests pass. I didn't run the protected launch tests, because they need environment settings and contracts that aren't in this tree. Nothing in my area went unchecked.

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

forge build succeeded. All 11 tests passed, including 256 fuzz runs with the supplied seed. Only launch.json is changed for submission.

I didn't commit because this machine has no git identity set, and changing git config is outside what I'm allowed to touch. The two new files are staged and waiting for the pipeline. Nothing outside test/ was changed.

The tests are written and pass: forge build succeeds, and forge test with the verifier's fuzz seed runs 53 tests with 0 failures. I found no defects in src/MADToken.sol, so I didn't write a .imd-findings.json. It's a plain fixed-supply ERC-20 with no owner, mint, burn, pause, blacklist or fee, and no input I tried broke it.

I kept the earlier contributor's test/MADToken.t.sol as it was and added two files.

test/MADToken.edges.t.sol (41 tests, of which 6 are fuzz tests at 1000 runs each)

• Edge cases: amounts of 0, 1 wei, the full supply, supply + 1 and the maximum uint256; transfers to yourself; tokens sent to the token contract stay there for good.
• Every revert checks its exact error and arguments: insufficient balance, insufficient allowance, sending to the zero address (including with amount 0), and approving the zero address.
• Allowances:
  • A failed transferFrom leaves the allowance unchanged.
  • A maximum allowance is never reduced, but one just below the maximum is.
  • A spender can only use their own allowance.
  • The owner needs an allowance to call transferFrom on themselves.
  • Changing an approval while the spender is active lets them spend at most the old amount plus the new one.
• No admin functions: 14 common admin, mint and burn calls all fail and the supply is unchanged. The contract also rejects ETH and unknown calls.
• Fuzz tests: transfers move exact amounts, overspending reverts, transferFrom reduces the allowance by exactly what it moves, and a stranger can't move another holder's tokens.

test/MADToken.invariant.t.sol (256 runs, 100 calls deep)

• A handler makes random valid and invalid calls (transfer, approve, transferFrom, sending to zero, approving zero) across five accounts. It keeps its own record of what every balance and allowance should be.
• After every sequence, these must hold:
  • the total supply is still 1,000,000,000e18;
  • balances add up to the total supply;
  • every balance and allowance matches the handler's record;
  • every call succeeded or reverted exactly as it should.
• The run made 25,600 calls with no failures.

The review is complete. The findings file is written and the proof is verified in both directions: it fails on the current code and passes on a patched copy.

Outcome: MAD is a minimal, dependency-free ERC-20 and the control flow holds in every material respect. One low-severity deviation from standard semantics is reported.

Finding (low): transferFrom never rejects a zero from address. The receiver is validated in _transfer but the sender is not, and transferFrom lets the caller choose it. With value zero both the allowance and balance checks pass, so any unprivileged address can make the token emit a mint-shaped Transfer event from the zero address, which EIP-20 reserves for token creation and which OpenZeppelin rejects. No balance or supply changes, so the impact is limited to off-chain indexers and accounting. The proposed fix is a one-line sender check mirroring the receiver check, and the proof test passes with it applied.

What was verified as holding:

• Supply is written once in the constructor to the factory, with no mint, burn, admin, fallback or receive path. ETH sent to the contract reverts.
• Transfer arithmetic conserves balances under a fuzz over transfer, approve and transferFrom sequences. Self-transfer nets zero. The unchecked blocks are safe because the sum of balances is fixed at the supply.
• Infinite allowance is honoured, finite allowance decrements correctly, and a balance failure reverts the whole call so there is no partial allowance consumption.
• Launch flows to the factory, distributor and PoolManager move exact amounts, with return values the v4 PoolManager accepts.
• No libraries, inheritance, external calls or assembly exist, so the Periphery guide has no surface here. Build and format checks pass.

Not reported: the EIP-20 approve-overwrite race, which is inherent to the standard rather than this implementation, and the two aderyn style leads, which are gas-only.

Coverage rows answer all three listed entry points plus five invariants. Nothing was left unreached. Scratch tests live under test/scratch only, and no repository file was modified.

The review is complete. The findings file is valid JSON, the working tree is clean apart from the untracked .imd-findings.json, and the scratch test has been removed.

Result: no defects found. The MAD token in src/MADToken.sol is a minimal fixed-supply ERC-20 with no owner, mint, fee, pause, blacklist, callbacks, payable paths or external dependencies. Every failure mode in the Economic Security, Invariant and Flow Gap guides that could apply to a bare token was checked and none is reachable. The findings file reports an empty list with eight coverage rows.

What I verified

• Conservation. Sum of balances equals totalSupply equals 1e27 at all times. Only the constructor writes totalSupply, and only _transfer writes balances. A stateful fuzz over six actors, including the token's own address, ran 128,000 calls without breaking it.
• Unchecked arithmetic. The sender's subtraction is guarded by the preceding balance check. The recipient's addition cannot overflow because all balances sum to 1e27. Self-transfers of the whole supply leave the balance unchanged.
• Allowances. Decrement happens only after the check, infinite allowance is never reduced, and no caller without an allowance can move a holder's balance. The factory and deployer have no special path.
• Launch flows. Transfers are fee-free and return true, so the swarm share, the Uniswap v4 seed and swaps, and the remainder forward move exactly what they say. The compiled ABI has exactly the three listed entry points and nothing else state-changing.
• Supply floor. No mint, owner, initializer or upgrade function exists. There is no DELEGATECALL, CALLCODE or SELFDESTRUCT in the source.

Leads dismissed. Both aderyn lines are gas and style only. The standard ERC-20 approve race and tokens sent to the contract's own address are inherent ERC-20 properties shared with OpenZeppelin v5 and harm only the caller, so they are recorded as notes in the coverage record rather than findings.

Not reached. I could not run the protected test file itself because it depends on Uniswap v4 sources that are not in this tree. I reproduced its token-level checks against a mock pool manager instead. No launch.json exists yet, which is expected before the manifest step runs.

No tracked file changed, and the findings file is valid. The review is complete.

Outcome

The MAD token's permission model is sound. I audited src/MADToken.sol against the Access Control, Asymmetry and Trust Gap guides and found one low-severity asymmetry and nothing higher. The report is in .imd-findings.json with one finding and six coverage rows.

The finding (low). The internal transfer helper rejects a zero to address but never checks from. Through transferFrom, any unprivileged caller can pass from = address(0) with value = 0. Both guards compare zero against zero and pass, so the call succeeds and emits Transfer(0x0, caller, 0). That is the event shape of a mint, which the launch floor says must never happen after the constructor. Balances and supply are untouched, so the harm is limited to indexers and monitors that count mint events. OpenZeppelin rejects this case. The minimal fix is a mirrored sender check in _transfer. The attached proof test fails on the current code and I confirmed it passes against a copy with that one line added.

What holds, and how I checked it.

• approve writes only the caller's own allowance slot, rejects a zero spender, and has no other writer or admin variant to drift from.
• transfer always uses the caller as sender. The unchecked arithmetic is safe because the sum of balances equals the fixed supply, which a 2000-run fuzz over mixed transfer, approve and transferFrom sequences never broke, including self-transfers and infinite allowances.
• transferFrom handles allowance correctly: infinite allowance is not decremented, finite allowance is checked before the unchecked subtraction, and self-spend without allowance reverts as in OpenZeppelin.
• There are no roles, modifiers, owner storage, external calls, assembly, delegatecall or selfdestruct. The constructor mints the full supply to msg.sender, which is the factory under the launch probe, and hands out no role. Trust Gap seams need a privileged actor or an asymmetric economic primitive, and this contract has neither.

Static analysis leads. Slither reported nothing. Aderyn's two low lines, a large numeric literal and a state variable that could be immutable, are gas and style items and fall under the guide's do-not-report list, so I left them out.

Not reached. Nothing within the assigned area. I did not independently run the protected launch floor tests, since they need the Uniswap v4 dependencies and environment variables the verifier supplies. By reading them, a fee-free token with no exemption logic satisfies every flow they check.

Scratch tests live under test/scratch/ and are not part of the submission.

Nothing remains to request. The findings file parses, its snippet matches the source line, the scratch directory is gone, and the working tree holds only the untracked .imd-findings.json.

Outcome. The review of the MAD token is complete and written to .imd-findings.json. One low-severity finding was kept, and every entry point has a coverage row.

What the specialists reported. Three of the four areas reported the same defect at different severities. transferFrom accepts a zero from address, and with value zero every guard passes, so an unprivileged caller can make the token emit a mint-shaped Transfer event from the zero address. I merged the three reports into one finding at low severity, since no balance or supply changes and the harm is to indexers and explorers that treat such events as mints. I attached the audit_flow specialist's proof, which fails on the current code for the stated reason.

How I reproduced it. Both specialist proof files fail when run from the scratch directory, and my own test with an exact event expectation confirms the emitted event is Transfer(0x0, attacker, 0). A non-zero value correctly reverts with an insufficient-allowance error, so only the zero-value case is reachable.

My own pass. Approve and transfer behave as intended, including self-transfers and the zero-receiver rejection. The constructor mints the manifest supply once to the deployer, there is no owner, mint, burn, pause or external call, and the project's 53 tests including the invariant suite pass. The manifest agrees with the code on contract name, empty constructor arguments, supply and decimals. The two aderyn notes are style only and were not reported.

Coverage. All three listed entry points are answered: approve holds, transfer holds, transferFrom references finding 1. Two invariant rows cover the fixed supply and the manifest.