The SuperIdentity token is implemented, verified and committed on main.

What was built

• src/SuperIdentityToken.sol: a self-contained ERC-20 named SuperIdentity, symbol SUPER, 18 decimals. The constructor takes no arguments and mints the whole supply of 1,000,000,000 tokens to the deployer once. It also implements EIP-2612 permit with replay and malleability protection.
• The contract has no owner, mint, burn, pause, blacklist, proxy or external call, so the supply can never grow and no privileged hand can move a holder's balance. Transfers move exact amounts, so the factory, PoolManager and distributor flows need no exemptions.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", disables ffi and grants no filesystem permissions. forge-std 1.9.7 is vendored under lib/ as ordinary files with no git metadata.
• script/Deploy.s.sol exposes a unit-tested deploy function; its run entry point reads no environment variables.
• README.md documents assumptions, the manifest values the launch step will need, deployment parameters and operational responsibilities.

Checks

Check	Result
forge build	passes
forge test	38 passed, 0 failed
forge fmt --check	passes

Tests cover success and failure paths for transfer, approve, transferFrom, infinite allowance, zero-address rejection, permit (expiry, wrong signer, replay, tampering, high-s), the launch payout flows arriving whole, the same admin and freeze call lists the protected harness probes, bytecode opcode and link-placeholder scans, and fuzzed supply conservation.

Open items for the launch, not this repository

• Slither and Mythril were not available on this machine and were not run.
• Explorer verification and the launch manifest belong to the IdentityMD deployer and manifest steps.

I found no defects I could back up, so .imd-findings.json holds an empty findings list and one coverage row per entry point. No repository files were changed, and the existing suite passes (38 of 38 tests).

What I covered (the Execution Trace, Periphery and First Principles guides, against src/SuperIdentityToken.sol, 182 lines with no imports):

• transfer — holds. It checks the balance before the unchecked subtraction and refuses the zero address. A transfer to yourself leaves the balance unchanged, because the second write re-reads the slot. The addition can't overflow because all balances together always equal the fixed total.
• transferFrom — holds. The allowance is checked and reduced before the balance moves, and an allowance of the maximum value is treated as unlimited. If any check fails, the whole call reverts with nothing changed.
• approve — holds. It sets the allowance to exactly the amount given and refuses the zero address as spender.
• permit — holds. Each signature is tied to the owner's current nonce, and the nonce is used up only if the call succeeds. It rejects high-s signatures using the correct cutoff (half the curve order), a failed signature recovery (address zero), and an expired deadline. The signing domain is recomputed if the chain id changes.
• Supply and access — holds. The constructor mints 1,000,000,000 × 10^18 to msg.sender once, and nothing can create or destroy tokens afterwards. There is no owner, pause, blacklist or burn-from, and no DELEGATECALL, CALLCODE or SELFDESTRUCT. The constructor takes no arguments, so the manifest's constructorArgs should be an empty list.
• Launch flows — holds. There is no fee or burn on transfer, so the factory's payout to the distributor, contributor claims and pool settlements all move exactly the stated amounts.

Static analysis leads, rejected:

• Slither, timestamp: the timestamp comparison is the normal permit deadline check.
• Aderyn, ecrecover malleability: already handled by the high-s and zero-address checks.
• Aderyn, large literal: the literal is the correct fixed supply.

Not covered: I didn't run the protected launch test. It needs launch contracts and environment variables that aren't in this tree. I also didn't review a launch.json, because none exists yet.

Created launch.json matching the accepted token, constructor, supply, pool and exact economics.

Validation passed: manifest checks, forge build, and all 38 tests from forge test. Only launch.json is changed.

The review is complete. No defects were found in the assigned area, and the findings file records that with full coverage.

Outcome. The findings file at the repository root holds an empty findings list and eight coverage rows. All four verifier entry points are marked holds. No tracked file was changed. The scratch tests live only under the ignored scratch directory.

What I checked, against the Access Control, Trust Gap and Asymmetry guides:

• Permission model. The compiled ABI exposes only approve, permit, transfer and transferFrom as state-changing, with no fallback, receive, owner, minter, pauser, blacklist, initializer or upgrade path. Every write is scoped to the caller or to a signer, so there is no privileged actor and no guard gap.
• Constructor. Takes no arguments, makes no external calls, and mints the constant supply once to the deployer. On the launch that is the factory, which the protected floor test requires.
• Asymmetry. transfer and transferFrom share one internal path. approve and permit share one internal path. Allowance spending is the only other writer of the allowance slot and only decrements what the owner granted. Storage lifecycle is clean: every variable is both written and read.
• Trust gap. No economic formula, price, fee or recipient exists, so there is no seam between access and economics to exploit.
• Edge probes. I ran eleven scratch tests covering zero owner and spender in permit, invalid v, the exact s boundary at n/2, deadline equality, replay after a chain-id change, transferFrom from the zero address, self-pull without allowance, infinite versus finite allowance accounting, and whole-balance self-transfer. All behaved as intended and none burned a nonce on a reverting path.

Static analysis leads. The Slither timestamp line is the standard EIP-2612 deadline comparison. The Aderyn ecrecover line is mitigated by the low-s check and nonces. The large literal is the correct secp256k1 n/2 constant. None is a defect.

Not reached. Nothing within the assigned area was left unexamined. The deploy script was read and is reference-only; it broadcasts from whatever signer forge script is given, which is outside the launch path.

The review is complete. The working tree holds only the findings file, which is untracked and expected.

Result: no math, boundary or numerical-gap defect in SuperIdentityToken. The findings file at .imd-findings.json carries one info-level note and seven coverage rows, all holds.

What I checked against the three guides

• Math Precision. The contract has no division, no downcast, no scale conversion and no fee formula. The only arithmetic is the supply constant, two unchecked subtractions each preceded by the matching bound check, and one unchecked addition bounded by the fixed supply. The Approval value emitted after a finite spend is computed outside the unchecked block and is safe for the same reason.
• Boundary. There are no external call sites, payable functions, bytes inputs or token-address parameters, so the guide's call-site and decode questions have no targets. I exercised the sentinels that do exist: zero addresses revert everywhere, the max-uint allowance is infinite while max-minus-one stays finite, and infinite allowance is still bounded by balance.
• Numerical Gap. The supply-conservation invariant held under a five-actor Foundry invariant run mixing transfer, approve and transferFrom with the token's own address as a sink. Self-transfer at full balance preserves the balance because the addition re-reads storage after the subtraction write. Launch shares of 10% and 80% of 1e27 divide exactly, so no dust can arise in the factory flows.
• Permit edges. Deadline equal to the timestamp is accepted and one second later is rejected. The s-bound literal equals secp256k1 n/2 exactly, so the flipped high-s encoding reverts and the low-s one passes. v outside 27 and 28, and zero r and s, recover to the zero address and revert. A failed permit rolls back the nonce increment. Max value and max deadline work.

Static-analysis leads. The Slither timestamp line is the intended deadline comparison. The Aderyn ecrecover line is mitigated by the s-bound check, and the large literal is that bound, verified numerically. None became a finding.

The one info note. The permit domain hashes version "1" but the contract exposes neither eip712Domain() nor a version getter, so integrators must know the version out of band. Nothing can be lost; a mis-built signature is simply rejected. It sits outside the assigned area and is recorded only because it is concrete.

Coverage. All four listed entry points are holds with reasons, plus three invariant rows. Nothing was left unreached.

The review is complete and the findings file is written. The tree is otherwise untouched: git status shows nothing, since .imd-findings.json and test/scratch/ are both gitignored.

Outcome: no defects in the economics, invariant or flow-gap area. The token is a self-contained ERC-20 with EIP-2612 permit, no external calls, no fee, no privileged role, and a compile-time constant supply. Every failure mode the three guides list either has no surface here or was checked and holds.

What I verified

• Supply conservation. A stateful invariant run of 128,000 random transfer, approve, transferFrom and permit calls across six actors, including the token's own address, never moved the sum of balances off the fixed supply.
• Allowance semantics. The infinite-allowance sentinel is exact, max minus one is decremented, zero-amount transferFrom by a stranger changes no state, and from-zero can never pass since the zero address can never hold an allowance.
• Permit economics. Deadline is inclusive per the spec, nonce moves only on success, high-s and bad-v signatures recover to zero and revert, and a signature for the old chain id is refused after a fork while a fresh one is accepted.
• Launch flows. Traced by reading, not executed, because v4-core is not vendored here. Transfers move exactly the stated amount and return true, so the distributor share, the pool seed via sync/settle, claims and swaps all arrive whole.
• Static-analysis leads. The timestamp, ecrecover malleability and large-literal lines are all non-issues on inspection.

Recorded as informational, not defects

1. The approve race inherent to EIP-20, with a reproduction where a spender takes old plus new allowance. No relative-allowance helpers are offered, matching OpenZeppelin v5.
2. Permit front-running: anyone can submit a signed permit first, making an integrator's bundled permit call revert. Funds are never at risk and the fix belongs to integrators.

All four listed entry points have coverage rows marked holds, plus four invariant rows. Nothing was left unreached.

Done. The full suite is green: 88 tests across 4 suites, including 10 invariants over 14,400 randomized calls with fail-on-revert enabled.

What I added (two new files under test/, the existing suite left untouched):

• test/SuperIdentityToken.invariant.t.sol: a handler with six keyed actors holding the whole supply, driving transfer, transferAll, self-transfer, approve, transferFrom, permit, time warps, unknown selectors and ether sends in random order with bounded inputs. Each failure-path handler asserts the exact custom error and that nothing moved. Invariants check fixed supply, conservation across actors with nothing leaking to the handler, zero address or token, a ledger model of every balance, every allowance and every nonce, the EIP-712 domain separator against the live chain id, immutable metadata, and no ether held. A second suite lets the chain id change mid-sequence.
• test/SuperIdentityToken.edges.t.sol: 48 unit and fuzz tests for edges the base suite skipped. CREATE2 deployment lands the supply on the deployer, stray constructor data is ignored, zero-amount transfers emit events, one wei, whole supply, max uint, self-transfer above balance, exact-allowance spend emits Approval(0), infinite allowance emits no Approval, max-minus-one is finite, permit at the exact deadline, one second past it, max deadline, zero value, zero spender, zero owner, invalid v, zero signature, high-s boundary one above n/2, future nonce, cross-chain-id rejection, and non-payable calls refusing ether.

Harness grounding. I ran the invariant file against two deliberately broken copies of the token in scratch. A 1% burn on transfer broke conservation and the self-transfer check within 23 calls. Removing the infinite-allowance short-circuit broke the allowance model. Both were caught, so the properties are not vacuous.

Defects found: none. I read the token adversarially before writing tests and found nothing to report, so no findings file was written. The unchecked arithmetic is bounded by the fixed supply, nonces roll back on failed permits, high-s signatures are refused, and there is no fallback, payable path or privileged surface.

Build emits only forge lint style warnings about reading block.timestamp before a warp, the same pattern the existing accepted test file uses. The new files are formatted and uncommitted in the working tree.

The review is done. I found no defects and dropped all three specialist findings. .imd-findings.json contains an empty findings list and a coverage row for each entry point; the JSON parses and no tracked files changed.

What I checked

• The local suite passed: 88 tests in 4 suites, 0 failed. I couldn't run the protected launch test here because the files it imports (src/LaunchLiquidity.sol, PoolInitializationGuard, HookFlags) aren't in this tree. The token itself is a plain ERC-20 with no transfer fee or hooks, so the launch flows (factory → distributor → claimant, the pool seed, swaps) should move exact amounts.
• Size: runtime is 2,594 bytes and creation code 2,945 bytes, well within both limits.
• Manifest: launch.json matches the code. The constructor takes no arguments, so constructorArgs: [] is right. Supply is 1000000000000000000000000000, decimals 18, and the contract name is valid.
• Supply and privileges: the constructor mints once to msg.sender and totalSupply() is a constant. There is no owner, mint, pause, blacklist, burn, DELEGATECALL or SELFDESTRUCT.

Coverage (all holds)

• approve: sets the allowance exactly and rejects a zero spender.
• permit: rejects expired deadlines, and the nonce is consumed only on success. The domain separator is recomputed if the chain ID changes. It rejects high-s (malleable) signatures, and a signature that recovers to zero or to anyone but the owner.
• transfer: moves the exact amount, reverts on a short balance or zero receiver, and a transfer to yourself leaves the balance unchanged.
• transferFrom: spends the allowance before moving funds and leaves an unlimited allowance untouched.

Specialist findings I dropped

1. approve front-run race (economics): this is how EIP-20 is specified; OpenZeppelin v5 behaves the same. It's not a defect in this code.
2. permit front-run griefing (economics): EIP-2612 lets anyone submit a signed permit. The allowance still gets set, nothing can be lost, and there are no application contracts in this tree that could be affected.
3. No eip712Domain() or version() getter (math): this is accurate, but neither EIP-2612 nor the launch requires them. A wrong signature just fails and nothing can be lost. Adding the getter is an optional improvement, not a defect.

Static-analysis leads

• The slither timestamp warning is the normal permit deadline check.
• The aderyn ecrecover warning is handled: the code rejects high-s signatures and a zero recovered address.
• The large-number warning is the supply constant, 1_000_000_000 * 10 ** 18, which is correct.