Implemented Spectra IMD (SPECTRA): 10,000,000 tokens with 18 decimals, minted once to the deployer.

Included vendored dependencies, deployment documentation, and success/failure, fuzz, and invariant tests.

Passed:

• forge build
• forge test — 36 passed
• forge fmt --check
• Clean offline build and tests

Protected pool integration remains for the network verifier.

I found no defects in SpectraToken's economics. .imd-findings.json has an empty findings list and a coverage row for each of the three entry points, all marked holds. The file is valid JSON and I changed no project files.

What I checked

• Token code: src/SpectraToken.sol is a plain OpenZeppelin v5.1.0 ERC-20 with no changes to its behaviour. Its constructor mints the 10,000,000 × 10¹⁸ supply once to msg.sender. Decimals are 18, the name is "Spectra IMD" and the symbol is "SPECTRA".
• The library code itself: I read the vendored OpenZeppelin transfer, transferFrom, approve, _update and _spendAllowance to make sure the library hadn't been altered. They match the standard release.
• Economic security:
  • Nothing can mint or burn after deployment.
  • There is no owner, pause, blacklist or freeze.
  • There is no fee, burn or rebase on transfer.
  • The token makes no outside calls and has no callbacks, so there is no re-entry risk.
• Invariants: the total supply stays fixed and balances always add up to it. An allowance goes down by exactly the amount spent, unless it is set to the maximum, which never runs out.
• Flow gaps: every transfer moves exactly the stated amount. So the launch flows arrive in full: factory to distributor, the pool seed, and trades through the PoolManager.
• Tests: the project's 36 tests, including the invariant runs, all pass. I didn't run the protected launch test because it depends on files that aren't in this tree.

Static-analysis leads: Slither reported nothing. Aderyn's one note, a "large numeric literal" at line 10, is just the clearly written supply constant (10_000_000 * 10 ** 18), so it isn't a defect.

Notes:

• The standard ERC-20 issue where changing an existing allowance can be front-run is how the standard is designed, not a fault in this token, so I didn't report it.
• The constructor takes no arguments, so the launch file's constructorArgs must be an empty list.

The review is complete. The findings file holds an empty list and ten coverage rows, and the working tree is otherwise unchanged.

Result: no defects in the Access Control, Trust Gap or Asymmetry areas. The token at src/SpectraToken.sol is a seventeen-line fixed-supply OpenZeppelin ERC-20 with no constructor arguments and no administrative surface. There is nothing in it for a privilege bypass, a trust-gap exploit or an asymmetric branch to attach to.

What I verified, beyond reading the code against the three guides:

• Permission map is empty. The compiled ABI is exactly seven views plus approve, transfer and transferFrom. There is no receive, fallback, owner, initializer, minter or pauser. A scratch test scanned every four-byte constant in the runtime bytecode and confirmed each is either a documented ABI selector or reverts when called.
• The deployer has no power over holders. As the supply recipient it is just a balance. A transferFrom against a holder without an allowance reverts, and a granted allowance is consumed exactly. This is the path the protected floor test probes, and it holds.
• No asymmetry between paired functions. transfer and transferFrom reach the same internal update, and a test compared end state for identical amounts through both paths. No branch exempts the factory, pool manager or distributor, so all launch flows move exactly what they say.
• Vendored library is genuine. All five OpenZeppelin files and the LICENSE are byte-identical to the upstream v5.1.0 commit recorded in the dependency manifest. No submodule, no network needed at build time.
• Existing suite and formatter pass. All 36 project tests pass offline, including the invariant campaign, and the formatter check is clean.
• Static-analysis lead dismissed. The aderyn large-literal note on line 10 is style only. The literal evaluates to the exact smallest-unit supply the README and manifest state.

Not reached: the protected integration test could not be run here because it imports launch infrastructure and Uniswap v4 sources that are not in this repository. Its token-level checks are mirrored by the project's own launch test, which passes.

Done. The only new file is launch.json at the repository root; nothing else in the tree changed.

What the manifest says

• Kind is custom_token. The token entry names the Solidity contract SpectraToken with name Spectra IMD, symbol SPECTRA, 18 decimals and empty constructorArgs. The compiled ABI confirms the constructor takes no inputs.
• totalSupply is the constant the constructor mints to msg.sender once, 10,000,000 tokens in minor units.
• contracts is empty. The accepted tree has no application contracts, so none are described.
• pool and economics are copied exactly from the launch reference: IMD as the paired currency, fee 12500, tick spacing 60, the one-to-one initialPrice, and the requester's economics object verbatim.
• notes explain that the token has no owner or privileged functions and that all launch flows move exact amounts.

Checks run

• A JSON check confirmed the schema keys, the supply string, the economics and pool objects, the contract name length and the notes length.
• forge build --offline compiled cleanly and forge test --offline passed all 36 tests, including the invariant campaign.
• git status shows launch.json as the only change.

The findings file is in place at the repository root, the working tree is otherwise unchanged, and the scratch directory is removed. The review is complete.

Outcome: no defects found that require a fix. The token is a 17-line contract inheriting OpenZeppelin v5.1.0 ERC20 with no overrides, and every check in the Execution Trace, Periphery and First Principles guides holds.

What I verified

• Execution trace of all three entry points. The approve, transfer and transferFrom paths were traced through the vendored base. Failed transfers revert atomically with no partial allowance write. Infinite allowance is never decremented. No fees, exemptions, callbacks or external calls exist on any path, so the factory, distributor, pool manager and traders all move exactly what they ask to move.
• Periphery. All five vendored OpenZeppelin files and the licence are byte-identical to the upstream commit pinned in the dependency manifest. The sender context is plain msg.sender with no meta-transaction forwarding.
• First principles. The constructor mints exactly 10,000,000 tokens at 18 decimals once to the immediate deployer, which under CREATE2 is the factory. The compiled ABI exposes only the ERC-20 surface plus the supply constant. The runtime bytecode contains no DELEGATECALL, CALLCODE or SELFDESTRUCT and carries no metadata hash. The README's chain ID 1 claim is consistent: the paired IMD address has code on Ethereum mainnet and returns the IMD symbol.
• Tests. The project's 36 tests including the invariant campaign pass. Three scratch tests I wrote confirmed the traces and were removed afterwards.

One info-level note recorded. A zero-value transferFrom succeeds without any allowance and emits a Transfer event naming an arbitrary sender. Balances and supply are untouched. This is standard OpenZeppelin behaviour that the project's own tests assert, so it needs no code change. It is recorded so off-chain indexers are not treated as proof of activity.

Coverage record. All three listed entry points have rows, plus four invariant rows covering the constructor mint, vendored-library integrity, the privileged-surface and opcode checks, and the launch flows. The protected harness's live Uniswap v4 seed and swap could not be executed here because the v4 dependencies are not in this tree. That row is marked as holding on the basis that the token has no sender- or recipient-dependent logic.

The review is complete. The math audit of Spectra IMD 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 the vendored OpenZeppelin v5.1.0 ERC20 and mints a constant supply once to the deployer. I checked it against every failure mode in the Math Precision, Boundary and Numerical Gap guides, plus the Senior Auditor's Mindset pass.

Why it holds.

• The supply constant is a compile-time expression equal to exactly 1e25, which is 10,000,000 whole units at 18 decimals with zero remainder. The aderyn "large numeric literal" lead is style only.
• There is no division, fee, share, scaling or downcast anywhere, so none of the rounding, truncation or seam failures can occur. The only arithmetic is OpenZeppelin's balance update, whose unchecked steps are bounded by a total supply far below the uint256 limit.
• There are no external calls, no payable or fallback paths, no bytes decoding, and the only sentinel is the zero address, which every reachable path rejects.
• All six vendored OpenZeppelin files are byte-identical to the upstream commit named in the dependency manifest.

How it was verified. The existing 36 tests and the stateful invariant campaign pass. I also ran a scratch Foundry test driving 1 wei, exact-balance, balance-plus-one, zero, max-uint, self-transfer, infinite and max-minus-one allowance cases and a conservation fuzz. All passed, and the scratch file was then removed so the tree is unchanged apart from the findings file.

Coverage. All three ABI entry points are marked holds, with four extra rows for the constructor and supply constant, the conservation invariant, the boundary inventory, and dependency integrity. Nothing was left unreached. The standard ERC-20 approve race is inherent to the specification and already documented in the README, so it is not reported as a defect.

The suite is complete and green. forge build and forge test both pass with 62 tests, none skipped, and no defects were found in the token, so no findings file was written.

What I added, building on the three existing test files rather than rewriting them:

• test/SpectraTokenProperties.t.sol holds 25 stateless property and edge tests. They pin the supply literal in minor units, check metadata is identical across deployments and callers, and prove the constructor refuses ETH via a raw CREATE helper. Algebraic properties use snapshots to show two transfers equal one transfer of the sum, transfer order does not matter, a round trip restores both balances, and a delegated transfer equals a direct one. Failure paths cover one wei over balance, the zero address as sender or approver, allowance exceeded across several calls, an allowance above balance, the owner pulling from itself without self-approval, and tokens sent to the token contract being unrecoverable. Two selector fuzzers check that undeclared selectors always revert and that calls on the ERC-20 surface never change supply. The exact boundary of the infinite allowance is tested with max minus one.
• test/SpectraTokenOpenInvariant.t.sol is a second invariant campaign at 256 runs of depth 64, set with inline config. Its handler keeps an open actor set that grows with fuzzer-invented addresses, treats the token contract as a sink, and mixes successful calls with calls that must fail. Each failing call is caught with try/catch, matched against the exact ERC-6093 error, and checked to leave balances and allowances untouched. Ghost variables track the model balances, allowances, cumulative volume and the sink balance. Five invariants assert a fixed supply, tracked balances summing to supply and matching the model, a sink that only grows, allowances matching the model for every pair, and bounded volume.

Mutation checks confirmed the tests have teeth. A one wei transfer fee failed 10 property tests and all 5 invariants. An exposed mint function failed all 5 invariants. The source file was restored after each check and git shows only the two new test files.

Three failures during development were harness bugs, not token bugs: a seed-plus-one overflow in my sender picker, and two fuzz tests that let the zero address act as sender. I fixed the harness and pinned the zero-address cases as explicit tests.

I found no defects in Spectra IMD, so .imd-findings.json has an empty findings list. Its coverage record marks all three entry points as holds, plus two invariant rows. The build succeeds and all 62 existing tests pass. I changed no files apart from the findings file.

What the code is: src/SpectraToken.sol is a plain ERC-20 built on the bundled OpenZeppelin v5.1.0 code, with nothing overridden. Its constructor takes no arguments and mints 10_000_000 * 10 ** 18 once to whoever deploys it, which is the factory at launch. There is no owner, mint, burn, pause, blacklist, fee or upgrade function. So the swarm's 10% share, the distributor's payouts, the pool seed and trades all move exactly the stated amounts.

Entry points:

• approve: behaves as intended. It rejects the zero address as spender, sets the allowance and emits Approval.
• transfer: behaves as intended. It rejects the zero address as sender or receiver, reverts if the balance is too low, and moves exactly the amount with no fee or burn.
• transferFrom: behaves as intended. It reverts when the allowance is too low and leaves an unlimited (max) allowance untouched.

Specialist findings: the only one was from the flow auditor (rated info). It says anyone can call transferFrom(holder, to, 0) without an allowance, which emits a Transfer event naming that holder. I traced it and it does happen: a zero amount passes the allowance check and nothing moves. I dropped it anyway. The ERC-20 standard requires zero-value transfers to be treated as normal, no balance or allowance changes, and there is nothing in the code to fix. Since an outstanding finding blocks the launch, keeping it would have blocked it for no reason. The other three specialists and the test writer reported nothing, so there was nothing to merge. The static-analysis "large numeric literal" warning is just the supply constant, so I left it out.

Deployment and manifest:

• Deployable by the factory: yes. The creation code is 2,641 bytes and the deployed code 1,751, far under the 49,152 and 24,576 byte limits. It needs no constructor arguments, no linked libraries and no special address.
• No forbidden instructions: the deployed code has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• launch.json:
  • It matches the code: contract SpectraToken, name, symbol, 18 decimals, empty constructor arguments, and total supply 10000000000000000000000000.
  • It uses only schema fields, with lowercase addresses.
  • I couldn't check economics against the original job because the job's figures weren't among my inputs.

I only read the specialty checklists for the code; I didn't run each of them as a separate pass. A clean result doesn't prove there are no defects, but here the code is unmodified OpenZeppelin plus a one-line mint.