The Spectra token project is complete and verified.

What was built, a Foundry project at the repository root:

• src/SpectraToken.sol is a self-contained fixed-supply ERC-20 named Spectra, symbol SPECTRA, 18 decimals. The constructor mints 1,000,000,000 × 10^18 once to the deployer, which is the launch factory. It has no owner, no mint, no pause, no blacklist, no fee and no exemptions, so every launch flow moves exactly what it says. Holders can burn their own tokens, and burnFrom only works against a granted allowance. It inherits nothing and calls no library, so the bytecode has no link placeholders, no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• test/SpectraToken.t.sol holds 33 tests: metadata and supply, success and revert cases for transfer, approve, transferFrom, burn and burnFrom, a sweep of admin-style selectors from both a stranger and the deployer confirming none exists, an opcode scan mirroring the protected harness, ETH rejection, and three fuzz tests for supply conservation and allowance handling.
• script/DeploySpectra.s.sol is an argument-free deploy script whose deploy function the tests call directly. The launch itself does not use it.
• foundry.toml pins solc 0.8.26 with bytecode_hash set to none, optimizer on, ffi off. forge-std v1.9.6 is vendored under lib/ as plain files with its git metadata, tests and scripts stripped, and there is no submodule.
• README.md documents behaviour, errors, deployment parameters, the launch distribution, the empty "After launch" section, operational responsibilities and assumptions.

Check results

Tests read no environment variables and do not depend on the caller address. No launch.json was written. The working tree contains only the project files plus ignored out/ and cache/ build output, and test/scratch is empty. Nothing was committed, since the brief did not ask for a commit.

Done. The manifest is written and verified; launch.json is the only changed file.

What the accepted tree contains

• One contract, SpectraToken, with a no-argument constructor that mints the whole supply to msg.sender once.
• No application contracts. The deployment script and unit tests are not launch contracts.
• The compiled ABI confirms the constructor takes zero inputs, so the token's constructorArgs are an empty list.

What launch.json says

• kind is custom_token, with token contract SpectraToken, name Spectra, symbol SPECTRA, decimals 18.
• totalSupply is the constructor's mint in minor units, 1,000,000,000 times 10^18.
• contracts is empty.
• pool is IMD as paired currency, fee 12500, tick spacing 60, and the one-to-one initial price from the reference.
• economics is the requester's object copied verbatim.
• notes describe only SpectraToken and its launch-flow behaviour, well under the character limit.

Checks run

• A script confirmed the manifest uses only the schema's keys, strings for every uint256 and address, numbers for fee, tickSpacing and decimals, and a lowercase paired address.
• forge build compiled cleanly and forge test passed all 33 existing tests.
• Git status shows launch.json as the only new or changed path.

The review is complete. The findings file is written, the snippets match the source lines, and git status shows no tracked file changed (the findings file is untracked, and test/scratch/ is gitignored).

Outcome: no arithmetic defect found in the Spectra token. The Math Precision, Boundary and Numerical Gap guides were applied in full to every entry point, and the code holds at every edge I could construct. Two spec-conformant ERC-20 properties are recorded at info severity so the author can decide whether to document them.

What I verified, with scratch tests under test/scratch/MathAudit.t.sol (11 tests, fuzz at 2000 runs, all passing):

• Supply constant evaluates to exactly 1e27. The aderyn "large numeric literal" lead is not a defect. The 10%, 88% and 2% launch splits divide with zero remainder.
• Unchecked blocks are all guarded. Each subtraction is preceded by a fromBalance < amount or current < amount revert, and the balanceOf[to] += amount addition cannot overflow because the sum of balances equals totalSupply, which never exceeds 1e27.
• Supply invariant totalSupply == sum(balances) held across fuzzed mixed sequences of transfer, transferFrom, burn, burnFrom and self-transfer, including burning the whole supply down to zero.
• Allowance sentinel behaves correctly at max, max minus one and zero, and a max allowance is still bounded by the owner's balance.
• Self-transfers through both transfer and transferFrom leave the balance unchanged, because the destination addition reads the already-decremented slot.
• Launch flows move exactly the stated amount. There is no fee, scaling or rounding anywhere, and transfer returns true so the Uniswap v4 currency library and the protected harness accept it.

Findings written (both info):

1. Zero-value transferFrom with no allowance succeeds and emits Transfer and Approval events naming any holder as sender. This is required by ERC-20 and matches OpenZeppelin, but it is the primitive behind address-poisoning displays.
2. approve overwrites unconditionally, so the standard allowance front-running race applies, and no increase/decrease helpers exist. The README already flags allowance management as the holder's responsibility.

Coverage rows answer all five listed entry points plus three invariants. Nothing in my area was left unreached.

The findings file is excluded by the harness's own .git/info/exclude, which is expected for a review output. The file is in place, valid JSON, and the cited snippet matches the tree. No source files were changed.

Review complete. The Spectra token has no privileged surface at all: no owner, no roles, no modifiers, no initializer, no receive or fallback, and no proxy or delegatecall. Across the Access Control, Trust Gap and Asymmetry guides there is no actor who can be escalated, no setter that redirects value, and no paired function whose state writes fail to mirror. The build passes and all 33 project tests pass. The static-analysis lead (large numeric literal) is the supply constant and is not a defect.

One low finding was recorded in .imd-findings.json:

• Zero-address sender is accepted. The internal transfer and burn helpers reject a zero recipient and a zero spender, but never reject a zero sender. Because a zero amount passes the allowance check, any account can call transferFrom(address(0), X, 0) and make the token emit a Transfer from the zero address, which indexers read as a mint, plus an Approval granted by the zero address. Balances and supply are untouched. The reproduction is confirmed with a scratch test under test/scratch that asserts both events. The minimal fix is a zero-sender revert at the top of the internal transfer and burn helpers.

Coverage. All five ABI entry points have rows. Approve, burn and transfer hold. TransferFrom and burnFrom carry the one finding. Two extra rows record the constructor and the no-privilege and supply-conservation invariants, both of which hold. Nothing in the assigned area was left unreached.

The findings file is in place and intentionally excluded from git by the harness. The scratch tests are removed and the tree is otherwise unchanged. The review is complete.

Outcome. The Spectra token is a sound, minimal ERC-20. No critical, high or medium defect was found in the Execution Trace, Periphery or First Principles areas. All five entry points were traced in full. Three low-impact items are recorded in .imd-findings.json, each with a concrete call sequence that I confirmed in Foundry before reporting.

Findings

• Low. transferFrom(address(0), to, 0) and burnFrom(address(0), 0) succeed for any caller because the balance and allowance checks pass on zero. They emit a mint-shaped Transfer(address(0), to, 0) event after launch, which contradicts the documented "nothing can mint" guarantee and differs from OpenZeppelin, which rejects a zero sender. No balance or supply changes. Fix is a one-line zero-sender revert in the internal transfer and burn.
• Info. Allowance spends emit an Approval event, so any caller can make the token emit Approval(victim, caller, 0) through a zero-value transferFrom. OpenZeppelin v5 no longer emits on spend.
• Info. The standard ERC-20 approve overwrite race applies, with no increase or decrease allowance helper. Reported for completeness since the README leans on holders managing allowances.

What held. Exact-amount transfers with a 32-byte true return value, zero-address recipient and spender guards, max-allowance sentinel, burn arithmetic, the constructor minting exactly one billion tokens to msg.sender, and the absence of any admin, fallback or forbidden opcode. A stateful fuzz run confirmed the sum of balances always equals total supply. The vendored forge-std matches upstream v1.9.6 exactly once formatting is ignored and is committed as plain files, not a submodule.

Coverage. The record has eleven rows: the five ABI entry points, the constructor, three invariants, the forge-std periphery and the deploy script. Nothing was left unreached.

The findings file is excluded by the harness's own rule in .git/info/exclude, so it is read from disk as the task describes and no tracked file changed. The review is complete.

Result: no defects in the Spectra token for the Economic Security, Invariant and Flow Gap areas. The findings file .imd-findings.json holds one informational note and ten coverage rows, every one of the five entry points answered.

What I checked

• Conservation laws. Sum of balances equals total supply, and total supply never exceeds the initial mint. A stateful fuzz in test/scratch mixed transfer, transferFrom, approve, burn and burnFrom across six actors for 128,000 calls with no violation. Self-transfer of the full balance and transferFrom with an unlimited allowance both conserve.
• Burn paths. Both burn functions check the balance before the unchecked block, so neither balance nor supply can underflow. The deployer or factory cannot burn a holder's tokens without an allowance, which matches the protected floor's privileged-hand test.
• Launch flows. There is no fee, exemption or callback code, so the factory to distributor transfer, pool seed, claims and swaps move exact amounts. A scratch flow test split the supply 10 percent, 88 percent and 2 percent exactly and round-tripped a trader through a manager stand-in.
• Supply and metadata. The literal flagged by aderyn equals one billion times ten to the eighteenth. Decimals, name and symbol match the brief. No constructor arguments, so the CREATE2-deploying factory receives the whole supply.
• Privilege surface. The ABI has only the five state-changing functions plus views, three storage slots, no owner or mint path. Runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL, CREATE or TSTORE. One early scan of mine mis-skipped PUSH data and flagged false hits. I corrected it and reconfirmed clean.

The informational note is the standard ERC-20 approve overwrite race. A spender who front-runs an allowance reduction from 100 to 50 can move 150. It is inherent to the standard, present in OpenZeppelin's ERC20 too, does not affect any launch flow, and needs no fix to ship. I labelled it info so it does not reopen work.

Not reached. Nothing in my area. The manifest and economics beyond what the README documents are outside this repository and were not reviewed against a launch.json, since none exists yet.

The suite is complete and green. forge build succeeds and forge test runs 104 tests with 0 failures, including the scratch probe that is discarded before submission.

What I added, all under test/ and building on the existing 33-test suite rather than rewriting it:

• test/SpectraToken.invariant.t.sol: a handler that drives five actors through transfer, approve, transferFrom, burn and burnFrom with bounded inputs, plus eight failure-path handlers that predict the exact revert error and assert nothing changed. Invariants check conservation (actor balances sum to supply), supply never grows and equals initial minus burns, every balance and every allowance matches a ghost ledger, and the zero address never holds tokens. It runs with fail-on-revert on, so any unpredicted revert fails the run. A second open-world suite fuzzes the token directly with arbitrary recipients and keeps the supply and zero-address properties.
• test/SpectraToken.edges.t.sol: 52 tests on inputs the base suite skipped. Examples: the allowance one below unlimited is decremented, unlimited allowance emits no Approval and survives draining the owner, zero-amount transferFrom and burnFrom succeed without an allowance, a reverted transferFrom or burnFrom consumes no allowance, the zero address can never be a token source, burning the whole supply leaves zero, unknown selectors and ether both revert, and standard ERC-20 four-byte selectors answer correctly as raw calldata. Oracle-style fuzz tests cover transfer, burn and burnFrom across the full input space.
• test/SpectraToken.launch.t.sol: the factory flow as the launch performs it. The token deploys through raw CREATE2 from a factory contract, the swarm share and pool share and remainder leave whole and sum to the supply exactly, a pool manager pulls the seed via allowance and pays traders both ways, and the factory cannot move or freeze a holder afterwards.

Defects found: none. I read the implementation adversarially and the handler-driven runs confirmed it. The unchecked arithmetic is bounded by the fixed supply, self-transfer reads the updated balance correctly, allowance is spent before balance is checked and the ordering is consistent, and no privileged path exists. I wrote .imd-findings.json with an empty findings list to state that explicitly.

No configuration, library, or source files were touched. Only the three new test files are new in the working tree.

The findings file is written and validated. Every snippet matches its source line, and git status shows only the untracked findings file plus the ignored scratch directory. Nothing else remains to do.

Outcome: the Spectra token has no fund-affecting defect. The findings file holds one low and two informational findings, all reproduced, plus a coverage record for all five entry points and two invariants.

What the specialists reported and how I settled it:

• Merged into finding 1 (low): both the permissions and flow specialists found that transferFrom and burnFrom accept the zero address as the source. I reproduced it: any caller can emit a mint-shaped Transfer from the zero address with value 0, and an Approval from the zero address. Balances and supply never change because a non-zero amount reverts on allowance. Event integrity only, so low.
• Merged into finding 2 (info): the flow and math specialists both noted that spending an allowance emits an Approval event, so a zero-value transferFrom with no allowance emits Approval and Transfer naming any holder. Reproduced. Zero-value transfers are required by ERC-20, and only the extra Approval differs from OpenZeppelin v5. Not a defect.
• Merged into finding 3 (info): three specialists reported the approve overwrite race. Reproduced, but it is inherent to ERC-20 and documented in the README as a holder responsibility. Recorded as a trust assumption.

My own pass found nothing further. The contract makes no external calls, has no owner or mint path, arithmetic is bounded by the fixed supply, self-transfers are correct, unlimited allowances are not decremented, and ETH is rejected. The manifest matches the argument-free constructor, the exact supply and decimals. Creation and runtime bytecode are far below the size limits and contain no delegatecall, callcode or selfdestruct. The existing 94 tests and my 10 scratch tests all pass.

No proof files were attached since nothing reached high or critical severity.