The seal (SEAL) token project is complete, verified, and committed on main.

What was delivered

• src/SealToken.sol is a fixed-supply ERC-20 built on OpenZeppelin v5.4.0. The constructor takes no arguments and mints 1,000,000,000 SEAL with 18 decimals once to the deployer. There is no owner, mint, burnFrom, pause, blacklist or transfer tax, so every launch flow moves exact amounts.
• test/SealToken.t.sol holds 26 tests covering metadata, the single mint event, absence of mint and privileged selectors, exact transfers, approvals, every documented revert, the launch-style distributor and remainder flows, a bytecode scan for DELEGATECALL, CALLCODE and SELFDESTRUCT, and three fuzz tests. Tests read no environment variables and do not depend on the caller.
• script/DeploySealToken.s.sol exposes a deploy() function the tests call directly. Its run() reads nothing from the environment.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", keeps ffi off and grants no filesystem permissions.
• README.md documents assumptions, the manifest values for the launch step, the "after launch" section (nothing to configure), and operational responsibilities.
• lib/ vendors forge-std and the ERC20 subset of OpenZeppelin as plain files with their licences. No submodules or git metadata remain.

Verification

A clean offline rebuild passed forge build, forge test with 26 of 26 passing, and forge fmt --check. The protected harness test imports its own v4-core and LaunchLiquidity sources, so it was not run locally, but my tests mirror its supply, decimals, privileged-call and bytecode checks.

Open items for the launch

The manifest step fills token.contract as SealToken, constructorArgs as empty, and totalSupply as 1000000000000000000000000000. Explorer verification and the independent adversarial review belong to the launch and its reviewers.

Created launch.json with the exact supply, economics, pool settings, and constructor arguments.

Offline build and all 26 tests passed, including expanded fuzz testing. Slither found no high or medium issues. Only launch.json was added.

The review is complete. No defects were found in the Math Precision, Boundary or Numerical Gap areas, and the findings file records an empty list with nine coverage rows.

What was checked

• Math. The token contains one arithmetic expression, the compile-time constant for the supply. It evaluates to exactly 1e27 and matches the manifest string, with a widening cast and no overflow, division or rounding anywhere in the requester's code. OpenZeppelin's unchecked balance updates are bounded by that supply.
• Boundaries. The runtime has no call-family opcodes, no payable, fallback or receive, and no bytes decoding. The only sentinel branches are the library's zero-address reverts. Scratch tests exercised max-uint transfers, self-transfer of the whole supply, transferFrom with sender equal to receiver, zero amounts with zero allowance, and allowance of max minus one versus max.
• Numerical seams. A 256-run fuzz and a Foundry invariant run of about 128,000 handler calls across approve, transfer and transferFrom kept the sum of balances equal to a constant total supply with nothing at the zero address.
• Dependencies and tools. All five vendored OpenZeppelin files are byte-identical to upstream v5.4.0. The compiled ABI exposes only the standard ERC-20 surface plus three view constants. Slither reported only pragma and solc-version informationals on library files, and Aderyn only the large-numeric-literal note, which is already written with underscores.

Commands run

forge build                      # success
forge test                       # 26 passed, 0 failed
forge test --match-path test/scratch/Boundary.t.sol    # 10 passed
forge test --match-path test/scratch/Invariant.t.sol   # 1 passed
slither src/SealToken.sol        # 5 informational results, none at low or above
aderyn --src src                 # 1 low: large numeric literal

Not reached or noted

• No launch.json exists in the tree, so manifest fields could not be reviewed. The README's stated deployment parameters are consistent with the constructor and supply.
• The DECIMALS constant does not drive the inherited decimals function. Both are 18 today, so this is a maintenance note recorded in coverage, not a finding.

Scratch tests were removed and the working tree is clean apart from the ignored findings file. Passing tests and clean analyzer output are not proof that no defect exists.

The review is complete. The findings file is written and the working tree has no other changes.

Result: no defects found. The token is an unmodified OpenZeppelin v5.4.0 ERC-20 with a single constructor mint, and every failure mode in the Access Control, Trust Gap and Asymmetry guides was checked against it without a reachable failing input.

What I verified:

• Access control. The compiled ABI has exactly three state-changing entry points: approve, transfer and transferFrom. There is no owner, minter, pause, blacklist, initializer, receive or fallback. The internal mint and burn helpers have no caller after construction. The deployer cannot pull one wei from a holder without an allowance.
• Vendored library integrity. All five vendored OpenZeppelin files hash-match upstream v5.4.0 byte for byte, so there is no hidden backdoor in the sender resolution or transfer path.
• Asymmetry. Transfer and transferFrom share one transfer path. Allowance is decremented exactly and infinite allowance is preserved. A reverted pull leaves both allowance and balance intact. Self-transfer leaves the balance unchanged.
• Trust gap. No privileged actor exists after deployment, so there is no access-times-economics seam. The factory holding the whole supply at construction is the launch design, documented as a trust assumption.
• Launch floor. Supply is exactly one billion tokens at 18 decimals minted to msg.sender, confirmed through a CREATE2 deployer. The runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE opcodes.
• Invariant fuzzing. A scratch Foundry invariant run of 128,000 calls across six actors kept total supply constant and equal to the sum of balances with zero reverts. The scratch test was removed afterwards.

The static-analysis lead about the large numeric literal is a compile-time constant equal to 1e27 and is a style note only.

One non-defect observation for the author: the contract declares a public DECIMALS constant used to compute the supply, while decimals() returns the inherited hardcoded 18. The two agree today, but they are two sources of truth and would silently diverge if someone changed one without the other.

The findings file at the repository root holds an empty findings list and ten coverage rows: one per listed entry point plus the constructor, the invariants I checked, the vendored-library check and the static-analysis lead. All existing project tests pass.

The review is complete and the findings file is written. The working tree is clean apart from the findings file itself, and the scratch tests are removed.

Outcome: no defects above informational. The token is a plain OpenZeppelin v5.4.0 ERC20 with a single constructor mint of 1e27 units to the deployer, and every path I traced in the Execution Trace, Periphery and First Principles areas behaves as intended.

What I verified:

• Entry points. All three state-changing functions trace cleanly through the inherited code. Zero-address receiver and spender revert, balances are checked before writes, self-transfers conserve balance, infinite allowance is not decremented, and the factory cannot pull from a holder without approval.
• Periphery. The vendored OpenZeppelin files and LICENSE are byte-identical to the upstream v5.4.0 tag. The compiled runtime contains no CALL, DELEGATECALL, CALLCODE, CREATE, CREATE2 or SELFDESTRUCT opcodes, and the ABI exposes no mint, burn, owner, pause or blacklist surface.
• Launch floor. With no transfer override there is no fee, burn or exemption logic, so the distributor funding, claims, seed and swap flows move exact amounts. The protected harness itself could not be run here because its v4-core and LaunchLiquidity dependencies are not in the tree, so the swap path is reasoned rather than executed.
• Tests and leads. The repository's 26 tests pass, plus 8 scratch edge-case tests I wrote and then deleted. The static-analysis large-literal lead at line 24 is benign.

Two informational notes are recorded in .imd-findings.json:

1. The standard ERC-20 approve front-running race, reproduced concretely, reported so the author can decide whether to document it.
2. The public DECIMALS constant is not wired to decimals(), so the two agree only because both are the literal 18. No current input fails.

The coverage record has 8 rows: all three entry points plus five invariant and periphery rows, none marked unreached.

The review is complete. The findings file is valid JSON, the quoted snippet matches line 13 of the source, and the working tree is clean apart from the gitignored scratch test.

Outcome: no defects in the economics, invariants or launch flows of SealToken. The file .imd-findings.json holds one informational note and eleven coverage rows, all three listed entry points answered.

What I checked

• Library integrity. All five vendored OpenZeppelin files are byte-identical to upstream tag v5.4.0, verified by fetching and comparing hashes. The token overrides nothing, so every transfer, approval and revert path is stock ERC-20.
• Invariants. A scratch Foundry invariant run of 128,000 calls across six actors, including the factory and a dead address, held both conservation laws: total supply fixed at 1e27, and sum of balances equal to supply. Allowance accounting was asserted exact on every call, with infinite allowance untouched.
• Flow gaps. The launch flows were replayed with the job's economics: 10% to the distributor, 88% to the pool, 2% to the remainder address, then 1 wei claims and 1 wei swaps each way. Every hop moved exactly the requested amount. There is no tax, burn, exemption list, callback or external dependency that could make a flow arrive short.
• Supply growth. The compiled ABI exposes only nine ERC-20 functions plus three constant getters. Every PUSH4 constant in the 2078-byte runtime maps to one of those selectors, the 1e9 literal, or the six custom-error selectors. No mint, owner, initializer, upgrade, DELEGATECALL, CALLCODE or SELFDESTRUCT exists.
• Economic surface. No oracle, fee formula, share math, payable path or sentinel-address special case exists to manipulate. Zero-address sender, receiver, spender and approver all revert as the standard specifies.

The one note recorded is the inherent ERC-20 allowance race on approve, severity info. It is a property of the standard the brief asked for, not a code defect, and is documented with a concrete sequence so holders know to zero an allowance before lowering it.

Not reached: the protected harness test itself cannot run here because v4-core is not vendored, so the real PoolManager swap was simulated with plain transfers rather than executed. Given the token has no transfer hooks, that does not change the conclusion.

Added failure-path, boundary, fuzz, and four-actor invariant tests under test/.

Offline forge build and forge test pass: 53 tests, zero failures. Invariants exercised 32,768 calls; new fuzz properties ran 1,000 cases each.

No confirmed defects found. All changes are confined to test/.

The review is complete and .imd-findings.json is written. No tracked file was changed, and the scratch tests were removed.

Outcome: the SEAL token has no defect. It is OpenZeppelin v5.4.0 ERC20 unchanged, with an argument-less constructor that mints the manifest supply to the deployer.

Specialist findings, settled

• Allowance race (audit_economics and audit_flow, both info). Same root cause, merged into one info finding. I reproduced it in a Foundry test: after approve 100e18, a front-run transferFrom, approve 50e18, and a second transferFrom, Bob holds 150e18. It is an inherent ERC-20 property, not a defect in this code, so the finding states that no code change is needed and only a README note is worth considering.
• DECIMALS not coupled to decimals() (audit_flow, info). Dropped. The specialist admitted no failing input exists on the current source. Both values are 18 and match the manifest. Recorded as a passing invariant row instead.
• Aderyn large-numeric-literal lead. Dropped. The literal is underscore-separated and its product is the verified supply.

My own checks, all holding

• The three entry points: traced revert paths, exact amount movement, infinite and finite allowance handling, zero-value and self transfers.
• CREATE2 deployment from a factory contract mints the whole supply to the factory. Launch flows arrive whole.
• Bytecode scan with the protected test's logic: no DELEGATECALL, CALLCODE or SELFDESTRUCT. Sizes are well under both limits.
• The five vendored OpenZeppelin files are sha256-identical to the upstream v5.4.0 tag.
• launch.json uses only schema keys, with constructor arguments, supply, decimals and address casing all consistent with the code.
• The existing 53 project tests pass, including invariants.

The protected test itself could not run here because it imports the verifier's v4-core tree, so I read it and confirmed by reasoning and a scratch test that each of its assertions holds for this token.