The SeerIMD token is implemented, tested and committed on main as commit 86d4040.

What was built

• src/SeerToken.sol is the token. Contract name SeerToken (fits the 32-character manifest limit), name() is SeerIMD, symbol() is SEER, 18 decimals. The constructor takes no arguments and mints the full 1,000,000,000 SEER once to msg.sender, so the launch factory receives the whole supply.
• It is OpenZeppelin v5 ERC20 plus ERC20Permit. There is no owner, mint, burn, fee, pause, blocklist, proxy or delegatecall, so nothing can grow the supply or touch a holder's balance after deployment.
• script/DeploySeerToken.s.sol exposes a deploy() function the tests call directly; run() only wraps it in a broadcast and reads no environment.
• foundry.toml pins solc 0.8.26, EVM cancun, optimizer at 200 runs, bytecode_hash = "none", ffi off and no filesystem permissions. forge-std 1.11.0 and openzeppelin-contracts 5.4.0 are vendored under lib/ as ordinary files with no git metadata or submodules.
• README.md documents assumptions, the manifest values, named constants, the empty "After launch" section, operational responsibilities and the security checklist items reviewed.

Checks run

Check	Result
forge build	clean
forge test with the verifier's fuzz seed	39 passed, 0 failed
forge test with an empty environment	39 passed, 0 failed
forge fmt --check	clean

The tests cover metadata, supply minted to whoever deploys the creation code (including a CREATE2 factory probe), transfer and allowance success and failure paths, permit success, expiry, wrong signer, replay and tampering, the same mint and privileged-call probes the protected floor test uses, a runtime bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, four fuzz tests, and a handler-driven invariant suite for supply conservation.

Open items for the deployer, not this job: explorer verification after launch, and an independent adversarial review if anything holding funds is built on top of the token. Slither and Mythril were not available here and did not run.

Created launch.json for SeerIMD (SEER), matching SeerToken’s parameterless constructor, exact supply, and required pool/economics.

forge build succeeded; all 39 tests passed with the supplied fuzz seed. Only launch.json is included in the deliverable.

The review is complete and the findings file is written. The tree has no uncommitted changes apart from the findings file itself (which the repository's .gitignore already covers for test/scratch/, and the scratch test has been removed).

Outcome: no defects in the permissions area. SeerToken is plain OpenZeppelin 5.4.0 ERC20 plus ERC20Permit with a no-argument constructor that mints the whole supply once to msg.sender. There is no owner, minter, pauser, blocklist, upgrade path, hook or external call, so the Access Control, Trust Gap and Asymmetry guides each come up empty against reachable code.

What I verified, beyond reading the source:

• Build and tests pass. 39 project tests including fuzz and invariant runs, all green on forge 1.8.3 / solc 0.8.26.
• Vendored dependencies are genuine. A recursive diff of lib/openzeppelin-contracts/contracts against upstream v5.4.0 and of lib/forge-std/src against v1.11.0 shows zero differences. This was the main trust-gap risk for a token whose logic is entirely inherited.
• ABI matches the entry-point list. 17 functions, exactly four state-changing (approve, permit, transfer, transferFrom), all unrestricted by design. No receive or fallback.
• Deployer has no power over holders. A scratch test confirmed the deployer cannot mint, burn, or move a holder's balance without an allowance, and supply stays at 1e27.

Two info-level notes were recorded, each with a reproduced call sequence, because the acceptance criteria want concrete failing inputs and the judge may want them as trust assumptions for integrators:

1. The ERC-20 approve-overwrite race. A spender who front-runs a reduction from 100 to 50 ends up spending 150. Inherent to the standard, no missing guard.
2. Third-party permit submission. Anyone can submit a holder's permit first, so the holder's own bundled transaction reverts. Allowance is still set exactly as signed, nothing lost.

Neither is a defect requiring revision, and I said so in the descriptions. No critical or high findings, so no proof test files were attached.

Coverage in .imd-findings.json has eight rows: the four listed entry points all holds, plus rows for the constructor and role inventory, the fixed-supply invariant, the vendored-dependency trust check, and the approve/permit and transfer/transferFrom asymmetry pairs. Nothing was left unreached.

I added two test files on top of the existing suite. With the verifier's fuzz seed, forge build succeeds and forge test passes all 63 tests in 4 suites. I found no defects, so I didn't write .imd-findings.json.

test/SeerToken.ghost.invariant.t.sol: invariant tests over random call sequences, set to 256 runs × 64 calls in the file itself.

• What it drives: a handler with 5 actors that calls transfer, approve (including unlimited), transferFrom and permit in random order, plus time jumps.
• Failure paths in the same sequences: overdrafts, spending more than the allowance, sending to or approving the zero address, and permits that are expired, signed by the wrong key or replayed.
• What "correct" means: every refused call must fail with the exact error expected, and nothing may change. Because foundry.toml turns any revert into a failure, the handler catches these refusals itself; a wrong error or a call that succeeds when it shouldn't is counted and fails an invariant.
• Invariants checked after every call:
  • The supply stays at exactly 1,000,000,000 × 10¹⁸ and the actors' balances add up to it.
  • The zero address, the token contract and the handler hold nothing.
  • Every balance, allowance and permit counter matches what the test's own bookkeeping says it should be.
  • Name, symbol and decimals never change.
• Guard against an empty run: a check at the end of each run fails it unless at least one transfer succeeded and at least one call was refused.

test/SeerToken.edge.t.sol: 23 unit and fuzz tests for edge cases the existing suite didn't cover:

• Launch flows: a helper contract deploys the token and hands out the 10% swarm share, a pool share and the remainder in one call, the way a launch does in one transaction. Each recipient gets the exact amount, including when the pool share is fuzzed from 0% to 90%. The distributor can pay out its share down to the last wei.
• Allowance edges:
  • A transferFrom of 0 needs no allowance.
  • A transferFrom to the zero address reverts and doesn't use up the allowance.
  • The zero address can't be spent from.
  • Spending the exact allowance leaves it at zero.
  • An unlimited allowance is still capped by the balance.
  • Sending to yourself works, and transferFrom emits no Approval event.
• Permit edges:
  • The signing domain is correct, and a signature made before a chain-ID change no longer works after it.
  • A permit is accepted at exactly its deadline and emits Approval.
  • These are refused without using up the owner's permit counter:
    • a second, rearranged form of a valid signature
    • a bad signature byte
    • a zero owner with an empty signature
    • a zero spender
    • a permit signed for a later turn of the owner's counter
    • a changed spender
  • A permit overwrites an existing allowance.
• Fuzz tests at 1,000 runs for chains of transfers and for approving then spending any amount.

The token is plain OpenZeppelin v5.4 ERC-20 + ERC20Permit, with a fixed supply and no admin functions. Every check above matched the expected behaviour. I didn't change any existing file, and the new files are left uncommitted in test/.

The review is complete and the findings file is written. Working tree is otherwise clean, with the scratch tests removed.

Result: no defects found in the Math Precision, Boundary, or Numerical Gap area. .imd-findings.json holds an empty findings list and nine coverage rows, one per listed entry point plus five invariant rows.

What I checked

• Supply constant. The TOTAL_SUPPLY expression at src/SeerToken.sol:34 folds to exactly 1e27, divides evenly by 10^18, and matches the manifest value in the README. The aderyn large-literal lead is that computed constant and carries no defect.
• Inherited arithmetic. The vendored OpenZeppelin tree is byte-identical to the published 5.4.0 package. The unchecked adds and subtracts in the inherited balance update are bounded by a totalSupply that never changes after the constructor, so no overflow is reachable.
• Boundary probes. I ran 18 scratch tests covering zero, full-supply, supply plus one, and max-uint transfers, max and max-minus-one allowances, self-transfers, permit at deadline equal to now, zero and max, high-s and v-flipped signatures, zero owner and spender, and dust-transfer supply conservation. All passed, as did the project's 39 existing tests.
• Launch split. The ten, eighty and ten percent shares of 1e27 are dust-free, and the derived pool price and single-sided liquidity for the stated cap sit inside Uniswap v4's ranges under either currency ordering.
• Boundary enumeration. The token has no external calls, payable functions, sentinel branches, decoded bytes inputs, downcasts, or divisions. The only precompile use is ecrecover inside OpenZeppelin's ECDSA, and its failure modes revert.

Not covered. The deployer's price derivation and seeding code live outside this repository, and launch.json has not been written yet. One integrator-facing behaviour is noted for the judge rather than reported as a defect: permit is permissionless to submit, so a contract bundling permit with transferFrom can have its permit front-run, which is standard ERC-2612 behaviour.

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

Result: no defects found in the economics, invariant and flow-gap area. The report in .imd-findings.json has an empty findings list and ten coverage rows, one for each of the four state-changing entry points plus six invariant and dependency rows.

What I checked and how:

• Supply conservation. The only mint is in the constructor, there is no burn, mint or transfer hook, and the project's own invariant suite plus unit tests pass. The split into the swarm's ten percent, the pool's eighty percent and the remainder is exact with no dust.
• Launch flow exactness. A scratch test moved the supply factory to distributor, to pool manager and to the remainder address, then simulated a claim and a pool take. Every hop delivered the stated amount and total supply did not move.
• Permit. I rebuilt the EIP-712 domain independently with name SeerIMD and version 1 and it matches the contract's separator, which also changes after a chain-id fork. High-s twins, bad v values and zero signatures are rejected and consume no nonce.
• Dependency integrity. The vendored OpenZeppelin and forge-std directories are plain files, so I diffed them against the upstream 5.4.0 and 1.11.0 release tarballs. Zero files differ, so the inherited ERC20, ERC20Permit, ECDSA, EIP712 and Nonces code is the audited upstream.
• Periphery. The ABI has no receive or fallback, ether and unknown selectors revert, and the reachable runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Static-analysis lead. The aderyn note on the large numeric literal is a constant expression equal to exactly 1e27 and is asserted by an existing test. Not a defect.

Two standard ERC-20 properties are noted in the coverage rows rather than reported as findings: the allowance front-running race inherent to approve, and the possibility of a third party submitting someone's permit early. Both are properties of the standards, not of this code, and the README already tells holders to manage approvals.

The scratch test directory was removed after the run, so nothing outside the findings file was left behind.

The review is complete and the report is written to .imd-findings.json with an empty findings list and nine coverage rows. The working tree is otherwise unchanged.

Outcome. No defect was substantiated in src/SeerToken.sol. The contract is OpenZeppelin v5.4.0 ERC20 plus ERC20Permit with three constants and a pure decimals() override, and nothing custom sits on any state-changing path.

What I covered in my area (Execution Trace, Periphery, First Principles):

• Traced all four entry points through the inherited OZ code: zero-address guards, balance and allowance checks, the infinite-allowance path, nonce consumption and rollback, deadline boundary, ECDSA malleability and invalid-signature rejection, and domain-separator rebuild on a chain-id change. All behaved as intended, confirmed by a scratch suite I ran and then deleted.
• Verified the Periphery: every one of the 19 OpenZeppelin files compiled into the token is byte-identical to the upstream v5.4.0 tag, and none of solc 0.8.26's listed compiler bugs applies to the constructs used with via_ir off.
• Checked first-principles assumptions: the minted constant equals the manifest supply string, the EIP-712 domain name matches name(), the short name leaves the fallback storage slots untouched, the method list exposes no mint, burn, owner or pause selector, and the runtime has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The project's 39 unit, fuzz and invariant tests pass with the documented seed.

Notes recorded in coverage rather than as findings. The ERC-20 approve race and the ERC-2612 property that a third party can submit a signed permit first are inherent to those standards, not defects of this implementation, so they are documented in the relevant coverage rows and did not open findings. Both static-analysis leads were empty or stylistic (a large numeric literal) and produced nothing reproducible.

Review complete. The findings file is written and the scratch test removed.

Outcome: no defects. SeerToken is an unmodified OpenZeppelin v5.4.0 ERC20 plus ERC20Permit with a parameterless constructor that mints the manifest's supply to the deployer. The two specialist observations reproduce exactly as stated, and both are standard ERC-20 and EIP-2612 properties rather than code defects. I kept them at info severity, marked as trust assumptions that need no revision.

What I verified:

• Build and tests. The project builds under solc 0.8.26 and all 63 repository tests pass, including the invariant suites.
• Library integrity. Every vendored OpenZeppelin file the token imports hashes equal to the upstream v5.4.0 tag.
• Specialist findings. The approve overwrite race and the permit front-run both reproduce with a Foundry test on this tree. Neither loses or redirects funds, so both stay info. They have different root causes and are not duplicates.
• My own pass. Entry points approve, permit, transfer and transferFrom all trace to unmodified OpenZeppelin code with no fee, hook, external call or privileged path. No receive or fallback, no delegatecall or selfdestruct, supply fixed at 1e27 with 18 decimals.
• Deployability. Creation code is 5,820 bytes and runtime 4,154 bytes, with no constructor arguments, so the factory can deploy it with CREATE2 as the manifest describes.
• Manifest. launch.json uses only schema keys, lowercase addresses and the correct supply and decimals. The paired currency address holds a contract on chain 1 whose symbol reads IMD.
• Static analysis. Aderyn's large-numeric-literal lead at line 34 is the supply constant, which evaluates to the manifest value, so it was dropped.

The coverage record answers all four entry points plus five invariant rows. Nothing was left unreached.