The Swarm Made (MADE) token project is complete, verified, and committed on main.

What was delivered

• src/SwarmMade.sol is OpenZeppelin v5 ERC20 with a constructor that mints the full one billion tokens, at 18 decimals, to the deployer. It has no owner, minter, fee, pause, blocklist, fallback, or upgrade path. The constructor takes no arguments, so the manifest's constructor args are empty and no launch addresses need exempting.
• script/DeploySwarmMade.s.sol holds the launch parameters as constants and exposes a deploy function that tests call directly. No environment reads, no key handling.
• Two test files with 36 tests cover metadata, supply, transfer and allowance success and failure paths, three fuzz tests, rejection of 24 privileged selectors from three callers, an opcode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, CREATE2 deployment from a factory stand-in, and the exact 10% / 88% / 2% launch flows plus a whole claim.
• README.md and docs/DEPLOYMENT.md record the manifest fields, the supply split, the price derivation, the assumptions, and who owns each operational step.
• foundry.toml pins solc 0.8.26 with bytecode_hash = "none" and CBOR metadata off, and disables ffi and filesystem access. forge-std v1.9.7 and the five OpenZeppelin v5.1.0 files the token needs are vendored as plain files, with no submodules.

Verification results

Open items for the next steps

• The manifest step needs the IMD token address from network.json for pool.pairedCurrency. The opening cap value assumes IMD has 18 decimals. Both are called out in the deployment doc.
• The remainder address was copied verbatim from the job and should be confirmed with the requester before admission.
• The protected floor's live pool seed and swap against a real v4 PoolManager could not be run here, since that harness and v4-core are outside this repository. Every other floor check has an equivalent local test. Slither and Mythril did not run and are listed for the independent reviewer.

The review is complete. The tree is clean apart from the required output and build artifacts that the repository's exclude rules already ignore.

Outcome: no defects found. .imd-findings.json holds an empty findings list and seven coverage rows, all holds.

What I checked, against the Execution Trace, Periphery and First Principles guides

• Token source. src/SwarmMade.sol is OpenZeppelin v5 ERC20 plus a constructor that mints the fixed supply to the caller. The compiled ABI exposes only approve, transfer, transferFrom and views. There is no receive, fallback, owner, mint, burn, pause or hook, so unknown selectors and ETH revert.
• Execution flow. I traced each entry point through the inherited transfer and allowance paths: zero-address sentinels revert, insufficient balance and allowance revert with ERC-6093 errors, infinite allowance never decrements and is still bounded by the sender's balance, and self-transfers through both paths conserve value. A scratch Foundry suite confirmed each of these concretely, then was deleted.
• Periphery. All five vendored OpenZeppelin files hash identically to upstream tag v5.1.0, and sampled forge-std files match the claimed commit. Both are ordinary files, not submodules.
• First principles and launch floor. Under CREATE2 from the factory the factory holds the whole supply. Transfers by the factory, distributor and PoolManager take the same untaxed path, so the swarm share, pool seed and remainder arrive whole. Supply can neither grow nor shrink after construction. The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT. Decimals are 18 and the supply constant is 1e27, matching the brief and the script constants.
• Static analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note is style only and does not affect behaviour.

One documented assumption, not a defect. The opening cap of 2500 IMD is encoded as 2500e18, which assumes IMD has 18 decimals. The deployment doc already flags this. The manifest step should confirm it against network.json.

The review is complete and found no defects in the assigned area. The findings file at .imd-findings.json holds an empty findings list and nine coverage rows, and the working tree is otherwise clean.

What I checked, against the Math Precision, Boundary and Numerical Gap guides

• Math precision. The only arithmetic the token owns is the supply constant, which folds to exactly 1e27 and matches the brief and manifest value. Every other operation is OpenZeppelin v5.1.0 code, where the unchecked subtract and add in the balance update sit behind a checked balance guard and are bounded by the total supply. The aderyn large-literal lead resolved to that constant and is not a defect.
• Boundary. The token has no external calls, no payable, receive or fallback, and no bytes decoding. The only sentinel branches are the zero-address reverts inherited from OpenZeppelin. I drove max-uint, balance-plus-one, exact-balance, zero-value, self-transfer, max-minus-one allowance and zero-allowance zero-value cases through the three entry points. All behaved as the standard specifies.
• Numerical gap. A fuzzed sequence of random transfers kept the sum of balances equal to the supply. The launch split is exact with no dust because 1e27 divides evenly by ten thousand. The opening price for either currency ordering gives a sqrtPriceX96 well inside Uniswap v4 bounds, assuming the IMD pair token has 18 decimals as the deployment doc states.
• Vendored dependency. All five OpenZeppelin files hash identically to upstream commit 69c8def5, so the ERC20 math is unmodified.

Coverage. All three entry points are marked holds, plus rows for the supply invariant, balance-sum invariant, split arithmetic, price derivation, vendored library integrity and the boundary enumeration. Nothing was left unreached.

Open item outside the code. The price math depends on the chain's IMD token having 18 decimals. That could not be verified here because no network.json was supplied, and the deployment doc already flags it as an assumption to confirm before admission.

runtime reported , not the required premium model claude-fable-5-1

The review is complete. No defects were substantiated in the assigned area, and the findings file records a clean result with full coverage.

What I reviewed. The token at src/SwarmMade.sol is OpenZeppelin v5.1.0 ERC20 with a no-argument constructor that mints the fixed supply to the caller. I checked it against the Senior Auditor's Mindset and the Access Control, Trust Gap and Asymmetry guides, read the protected floor test, and compared the vendored dependencies to upstream.

Results.

• Access control: the permission map is empty. There is no owner, role, modifier, initializer, proxy, fallback or receive. The compiled ABI exposes twelve methods, nine of them views. A fuzz over arbitrary callers, including the factory and the deployer, showed none can move a holder's balance without that holder's allowance.
• Trust gap: the token has no privileged actor and no economic formula, so no seam exists. The only trust assumption is the externally supplied remainder address and the IMD 18-decimal cap, both copied verbatim from the job. I recorded them as a trust assumption row, not a finding.
• Asymmetry: transfer and transferFrom were run side by side on identical inputs and move identical amounts. The only difference is the allowance spend. Both treat the factory, distributor and PoolManager like any other address, so the launch flows arrive whole.
• Dependency integrity: the five vendored OpenZeppelin files are byte-identical by SHA-256 to upstream commit 69c8def5, and the forge-std Test file matches tag v1.9.7. No git submodules are present.
• Static analysis lead: the aderyn large-numeric-literal note on line 27 is a style remark. The literal evaluates to exactly 1e27 and the tests assert it.

Verification. The project's 36 tests pass, formatting is clean, and my four scratch probe tests passed before I removed them. The working tree is unchanged apart from .imd-findings.json, which holds zero findings and seven coverage rows: one holds for each of the three listed entry points plus four invariant and trust-assumption rows.

Open items outside this task. The live pool seed and swap against a real Uniswap v4 PoolManager run in the floor harness, not here. The manifest step still needs to lowercase the remainder address to satisfy the schema pattern.

The review is complete. The findings file is written and valid, and the working tree holds no tracked changes.

Result

No defects found in the Economic Security, Invariant and Flow Gap areas. The findings file at .imd-findings.json holds an empty findings list and eight coverage rows: the three state-changing entry points plus five invariants and economic checks, all marked holds.

What I checked

• Token source. src/SwarmMade.sol is 30 lines: unmodified OpenZeppelin v5.1.0 ERC20 plus a constructor that mints 1e27 to the deployer. The five vendored OpenZeppelin files diff byte-identical to upstream commit 69c8def5, vendored as plain files with no submodule.
• Entry-point surface. The compiled ABI exposes only approve, transfer and transferFrom as state-changing. There is no receive, fallback, immutable or link reference. Each writer was traced through _update and _spendAllowance: zero-address and insufficient-balance paths revert, amounts move exactly, supply is never touched.
• Conservation invariant. A stateful fuzz under test/scratch/ with eight actors randomly transferring, approving and spending allowances kept the sum of balances and totalSupply at exactly 1e27 across all runs. A second fuzz confirmed no selector outside the three writers changes any balance or the supply.
• Launch flows. The 10% swarm, 88% pool and 2% remainder split was replayed with the token: every hop arrives whole, the remainder is exactly 200 basis points with no rounding dust, and the factory is empty afterwards with nothing left to move. Script constants for pool share, opening cap and remainder address match the job verbatim.
• Pool economics. A 2500 IMD cap over 1e27 supply gives a price of 2.5e-6 IMD per MADE. For both currency orderings the derived sqrtPriceX96 sits inside Uniswap v4's bounds, the tick is far inside the limits, and the single-sided liquidity for 880M tokens fits uint128 and the per-tick cap.
• Static-analysis leads. Slither reported nothing. Aderyn's large-numeric-literal note on line 27 is the supply constant 1e27, confirmed correct by the project tests and my replay.

Observations, not defects

• IMD decimals assumption. The opening cap of 2500e18 minor units assumes the chain's IMD token has 18 decimals. The docs state this openly and no network.json was supplied to confirm it. This belongs to the manifest step, which must check the pair token's decimals before writing initialMarketCapWei.
• Standard ERC-20 approve race. Allowance changes can be front-run, as in every plain ERC-20. The design explicitly requests unmodified OpenZeppelin behaviour, so this is a known property, not a finding.
• Trust at deployment. The constructor trusts whoever calls it. In production that is the factory through CREATE2, which the protected floor test enforces.

Not reached

The protected floor's live Uniswap v4 seed and swap could not be run locally because v4-core is not in this repository. The token has no transfer logic that could distinguish the PoolManager from any other caller, so the exact-amount guarantee the flow test checks holds by construction.

Done. The manifest is written and verified against the accepted token.

What I wrote: launch.json at the repository root, a custom_token manifest for Swarm Made (MADE).

• Token: contract SwarmMade, name Swarm Made, symbol MADE, 18 decimals, empty constructorArgs, totalSupply 1000000000000000000000000000. The compiled ABI confirms the constructor takes no inputs, and the source mints exactly that amount to msg.sender once.
• Contracts: empty. The accepted tree has only the token, so no application contracts are named.
• Pool: pairedCurrency is the IMD pair token address from the job, fee 3000 with tickSpacing 60, and initialPrice is the sqrtPriceX96 of 2,500 IMD divided by the supply assuming MADE sorts as currency0. The notes give the inverse-ordering value and state that the deployer derives the real price from economics.
• Economics: copied verbatim from the job, including the lowercase remainderTo.
• Notes: 2600 characters describing only what is in the tree.

Checks run:

• A Python pass over every schema constraint (field sets, patterns, ranges, fee tier, economics equality, notes length) passed.
• A scratch Foundry test deploying the token from a pranked factory address confirmed supply, balance, decimals, name and symbol match the manifest.
• forge build and forge test pass with 37 tests, 0 failures, and forge fmt --check is clean.
• git status shows launch.json as the only change. test/scratch is gitignored and is deleted before submission.

Assumption worth noting: the IMD pair token is taken to have 18 decimals, which is what the job's initialMarketCapWei of 2500000000000000000000 implies. The prior rejection was a runtime model-reporting error, not a content fault, so nothing in this manifest works around it.

Done. forge build is clean and forge test passes: 88 tests, 0 failures, ~11s (36 pre-existing + 52 new). Only test/ was touched.

What I added

test/SwarmMadeInvariant.t.sol — invariant tests over random call sequences

• SwarmMadeHandler: 14 bounded actions across 7 launch accounts (factory, distributor, pool manager, remainderTo, three users) plus arbitrary new addresses the fuzzer invents. Keeps an independent ERC‑20 reference model of every balance and allowance. Every action is total (no vm.assume); every must-fail action uses vm.expectRevert, and the campaign runs with fail-on-revert = true so a wrongly succeeding call or a handler assertion fails the run instead of being discarded.
• Six invariants checked after every call: fixed supply; tracked balances sum to the supply; every balance matches the model; every allowance matches the model (plus an afterInvariant sweep that no ungranted allowance exists); tokens sent to the token contract never leave; no ether / no code change / constant metadata.
• Two deterministic tests prove the harness is not vacuous: the launch starting state is right, and every handler path (success and each rejection branch) is reachable with its counters.
• Verified by mutation testing in scratch: nine deliberately broken tokens (fee-on-transfer, hidden mint, seize, allowance not decremented, infinite allowance decremented, transfer returning false, blocklist, receive(), dust rounding) were each caught, with the correct assertion message. Also confirmed this forge version honours the inline fail-on-revert key.

test/SwarmMadeAdversarial.t.sol — 42 edge-case and property tests the existing suite didn't reach: transferFrom with the zero address as owner, self-pull without self-approval, zero-value pull needing no allowance, allowance rollback when the balance check fails, error precedence (allowance → receiver → balance), max−1 allowance, allowances not following tokens, dirty/short/extra calldata, exact 32-byte true return, staticcall behaviour, vm.record proving a transfer writes exactly two slots (no hidden bookkeeping), no receiver hooks (reverting recipient never called), a bytecode scan proving no CALL/CREATE/ORIGIN/TIMESTAMP/etc. (no transfer rules possible), a dispatcher scan proving the external surface is exactly ERC‑20 + the three constants, CREATE2 same-salt replay fails, constructor refuses ether. Nine fuzz properties at 1000 runs incl. a full transferFrom outcome oracle.

test/DeploySwarmMadeAdversarial.t.sol — launch parameters vs. the pool: opening price is representable as a v4 sqrtPriceX96 in either currency order and doesn't truncate to zero; remainderTo is usable; deploy() twice yields independent tokens; run() mints to the broadcaster, not the script.

Findings

None to report, so no .imd-findings.json was written. I diffed the vendored OpenZeppelin files against upstream v5.1.0 (byte-identical), and nothing in the token, script, or constants deviates from the brief. The one behaviour worth noting (not a defect, inherent to plain ERC‑20 and consistent with "no owner powers") is that tokens sent to the token's own address are unrecoverable; the invariant suite pins that nobody, including the deployer, can move them.

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

What I checked

• The token in src/SwarmMade.sol is OpenZeppelin v5.1 ERC20 with nothing added. The constructor takes no arguments and mints the whole supply once to the caller.
• The compiled ABI exposes only the standard ERC20 functions plus three public constants. There is no mint, owner, pause, blocklist, burn, receive or fallback.
• A PUSH-aware scan of the runtime bytecode found no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The vendored OpenZeppelin and forge-std files are committed as ordinary files. There is no submodule.
• The manifest matches the code and the job: empty constructor arguments, the exact minted supply, 18 decimals, and economics copied verbatim with lowercase addresses. The sqrtPriceX96 value is within one unit of the rounded derivation and is provenance only.
• The project's own suite builds and passes, 88 tests with 0 failures.

Specialists and tools

All four specialists and the test writer reported no findings, so there was nothing to reproduce or merge. Slither reported nothing. Aderyn's only line was a low-impact large-numeric-literal note on the supply constant, which is a style remark and not a defect.

One limitation

The protected floor test imports Uniswap v4-core, which this tree does not vendor, so it could not be executed here. I traced each of its assertions against the stock ERC20 by hand and every one holds. That is recorded in the coverage row rather than claimed as a run.

Coverage

All three entry points hold: approve, transfer and transferFrom. Five additional rows record the supply invariant, the absence of a privileged surface, the opcode and library checks, the manifest consistency, and the test results.