Implemented POEDB with 18 decimals and exactly 1,000,000,000 tokens minted once to the deployer. Added vendored dependencies, success/failure tests, and deployment documentation.

Verified with Solidity 0.8.26:

• forge build, including offline rebuild
• forge test: 33 passed using the supplied seed
• forge fmt --check

The platform’s protected launch integration checks remain for its independent verifier.

Created launch.json with the accepted token’s exact supply, empty constructor arguments, and required pool and economics values.

forge build succeeded. All 33 tests passed with the supplied fuzz seed. Only launch.json is changed for submission.

The review is complete. The findings file is written and the working tree contains nothing outside the allowed paths. The build outputs in out/ and cache/ are gitignored and the scratch test directory was deleted.

Outcome: no defect in the assigned area. The token is an unmodified OpenZeppelin v5.1.0 ERC20 with a single constructor mint of a compile-time constant, and it contains no division, rate math, scale conversion, downcast, external call, payable path or bytes decoding for the Math Precision, Boundary or Numerical Gap checklists to bite on.

What I verified

• Supply constant. One billion times ten to the eighteenth is exact and far below the uint256 and uint128 limits. It matches the manifest's total supply in minor units.
• Launch split arithmetic. The ten percent swarm share and the eighty-eight percent pool share divide the supply with zero remainder, and the token moves exactly what is passed, so every launch flow arrives whole.
• Transfer, transferFrom, approve. I traced the checked balance guard, the unchecked subtraction and addition that it makes safe, the infinite-allowance sentinel, and the address-zero reverts on both sides of each branch. Inputs of zero, one wei, the whole supply, the maximum uint256 and maximum minus one all behave as intended.
• Boundaries. Sending ETH to the token with or without calldata reverts. There are no external calls or callbacks.
• Tests. The project's own suite passes, including the 128-run invariant suite with revert-on-failure. My scratch boundary test of the edge numbers above also passed before I removed it.

One informational finding, outside my area. Running the documented hash check fails for six forge-std files. The pinned hashes are the genuine v1.9.6 ones, but the vendored copies were reformatted after vendoring, so the integrity statement in DEPENDENCIES.md is false as written. A whitespace-insensitive diff against upstream is empty, so nothing semantic changed and the deployed token is unaffected. The fix is to restore the six files byte-for-byte or regenerate the hash file and reword the claim.

Coverage record. All three listed entry points are marked as holding, with reasons, plus rows for the supply constant, the launch split arithmetic, the boundary enumeration, the numerical-gap seams, and the dependency integrity finding.

The review is complete. The findings record is in place and the tree is otherwise untouched.

Result: the token's permission surface holds. One low-severity provenance defect is reported, outside the assigned area.

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

• The contract is unmodified OpenZeppelin v5.1.0 ERC-20 with a single constructor mint of 10^27 units to its direct caller. All 26 vendored OpenZeppelin files match their recorded checksums.
• There are no roles, modifiers, initializers, setters, proxies or admin variants, so no guard gaps, escalation chains, or confused-deputy paths exist. The ABI is the ten ERC-20 functions plus the supply constant.
• The compiled runtime has no CALL, CREATE, DELEGATECALL, CALLCODE or SELFDESTRUCT opcodes outside push data. Native value and unknown selectors revert.
• The approve/transferFrom pair is symmetric. A fuzz test confirmed transfer and transferFrom produce identical balances for the same inputs, with only the allowance differing.
• I replayed both privileged-selector lists from the protected harness, from the factory and from a stranger. Every call reverts, supply stays fixed, and the factory cannot pull a holder's balance without approval.
• The project's own 33 tests pass with the documented fuzz seed, and the formatter check passes.

The one finding (low): the documented command sha256sum --check DEPENDENCIES.sha256 fails on six forge-std files, contradicting the claim in SECURITY.md that every vendored file matched. I downloaded the pinned v1.9.6 archive and compared. The recorded checksums are the upstream bytes, and the tree's copies differ only in whitespace from a formatter. forge-std is test-only, so the deployed token is unaffected. The fix is to restore the upstream bytes or regenerate the checksum file and amend the docs.

Coverage record: all three listed entry points are marked holds, plus rows for the constructor and role inventory, runtime bytecode, and the provenance finding. No area was left unreached.

The review is complete and .imd-findings.json is written. No source files were changed.

Result: no economic, invariant or flow-gap defect in the token. POEDBToken is the unmodified OpenZeppelin v5.1.0 ERC-20 plus a single constructor mint to msg.sender. I confirmed the vendored OpenZeppelin files are byte-identical to upstream, the compiled ABI exposes only the three listed state-changing functions, and a corrected instruction-aware scan of the runtime finds no DELEGATECALL, CALLCODE or SELFDESTRUCT. The existing suite passes under the documented seed.

What I checked in the assigned area:

• Economic Security. No external dependency, oracle, owner, pause, blacklist or fee. Every launch flow (factory to distributor, pool seed, forward of the remainder, buy and sell through the PoolManager) moves exactly the requested amount. The 10% / 88% / 2% split sums to the supply with no rounding loss.
• Invariant. Total supply is fixed at 10^27 and equals the sum of balances. The mint branch of _update is reachable only from the constructor. A zero-address transferFrom with value 0 is stopped by the approver check before it could reach that branch.
• Flow Gap. No transfer path taxes, exempts or reverts for the factory, distributor or pool manager, so the protected launch harness has nothing in this token to trip on.

One info-level finding was recorded: the project's own documented check sha256sum --check DEPENDENCIES.sha256 fails for six forge-std files. The committed files differ from upstream v1.9.6 only by whitespace reflow, consistent with forge fmt having run over lib/. This affects test-only code and the provenance claim in DEPENDENCIES.md and SECURITY.md, not the deployed token.

Coverage: all three entry points are marked holds, with four additional invariant rows. Nothing was left unreached.

The review is complete and the findings file is written. Here is the recap.

Outcome: the token is a bare OpenZeppelin v5.1.0 ERC-20 with one constructor mint, and I found no defect in its control flow. The only substantiated finding is a low-severity provenance mismatch in test-only files. All three listed entry points are marked holds in the coverage record.

What I checked for the Execution Trace, Periphery and First Principles guides

• Execution trace of all three entry points. Traced transfer, transferFrom and approve through _transfer, _update, _spendAllowance and _approve. Zero-address sender and receiver revert, insufficient balance and allowance revert with no partial state, the infinite-allowance path never decrements, and a zero-value transferFrom from the zero address reverts before reaching the mint branch. There are no fees, hooks, external calls, sentinel paths or callbacks.
• Periphery. The five OpenZeppelin files compiled into the token hash byte for byte to upstream v5.1.0. Context._msgSender is plain msg.sender, so no forwarder path exists.
• First principles and the launch floor. The constructor takes no arguments and mints exactly 10^27 units once to msg.sender, which is the factory under CREATE2. The ABI has only the standard ERC-20 functions plus the INITIAL_SUPPLY getter, with no receive or fallback. An instruction-aware scan of the 1,814-byte runtime, using the same PUSH-skipping logic as the protected harness, found no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, PUSH0 or transient-storage opcodes. The metadata trailer confirms no bytecode hash and solc 0.8.26. Build, formatting check, and all 33 project tests pass with the documented fuzz seed.
• Static-analysis lead. The aderyn large-literal note on line 12 is the compile-time constant 1_000_000_000 * 10 ** 18, which equals 10^27 and is asserted by the test suite. Not a defect.

The one finding (low): running the README's documented check sha256sum --check DEPENDENCIES.sha256 fails on six forge-std files. The recorded hashes are exactly upstream v1.9.6, but the tree copies were reformatted by forge fmt. After stripping whitespace they are identical to upstream, and forge-std is never part of the deployed token, so the impact is only that the integrity check and the "unmodified upstream" claim in DEPENDENCIES.md are false. Fix by restoring the upstream bytes or regenerating the checksum file.

Not covered: nothing in the assigned area was left unreached. I did not run the protected Uniswap v4 harness, since its v4-core and LaunchLiquidity sources are not in this tree, and no launch.json exists yet for the manifest check.

The work is complete and verified. All 66 tests pass with the verifier's seed, and the only files changed are under test/.

What I did

The existing suite from earlier contributors already covered the ERC-20 happy paths, the main revert cases, and a closed-set invariant, so I built beside it rather than rewriting. Four new files were added:

• test/helpers/LaunchSimulator.sol deploys the token with CREATE2 and splits the supply among distributor, pool manager and requester in a single call, mirroring one factory transaction. It also exposes a raw deployment with attached value and an over-spending launch for atomicity checks.
• test/LaunchFlow.t.sol holds 11 tests. They check the exact 10/88/2 split, that neither the factory caller nor the transaction origin receives tokens, a fuzzed split over every pool share from 0 to 90 percent, that an over-spending or over-allocated launch reverts and leaves no code at the predicted address, claim splitting with dust and the exact shortfall error, pool-manager sells and approved buy-backs, and that the launch addresses have no power over holders.
• test/POEDBToken.edges.t.sol holds 21 tests for inputs the main suite did not reach: the constructor rejects native value, the runtime fits EIP-170 and contains no DELEGATECALL, CALLCODE or SELFDESTRUCT, mutating calls return exactly one clean boolean word, view calls return well-formed data, every unimplemented selector reverts without changing state under fuzzing, implemented functions reject value, one-unit boundaries on balance and allowance, approvals replace rather than accumulate, two spenders competing for one balance, chained transfers, and balances never exceeding supply.
• test/POEDBToken.open.invariant.t.sol is a second invariant suite with six actors plus two sinks nothing can spend from. The handler mixes successful calls with seven refusal paths driven through low-level calls, each asserting the exact ERC-6093 error. Seven invariants check constant supply, full accounting across actors and sinks, ghost-ledger balances and allowances, sinks only growing, bounded moved volume, and that refusals were actually exercised. It runs 256 sequences of depth 64.

Findings

No defect was found in the token. It is an unmodified OpenZeppelin v5.1.0 ERC-20 with a single constructor mint, no owner, and no admin surface.

One informational item is recorded in .imd-findings.json. The README states that the dependency hash check passes, but it fails for six forge-std files. The hashes match pristine upstream v1.9.6, and the committed files differ only in whitespace, so this is a provenance and documentation mismatch in lib/, outside my paths, not a security issue.

Checks run

• forge build passes.
• forge test passes with the verifier's seed and with an unrelated seed.
• forge fmt reports the test directory clean.
• test/scratch was removed after use, and the four new files are the only working-tree changes.

The review is complete and the findings file is written. No tracked files were changed.

Outcome: the POEDB token is sound. One low-severity documentation defect survives, merged from the five specialist reports.

What I verified

• The token is an unmodified OpenZeppelin v5.1.0 ERC20 with a no-argument constructor that mints exactly the manifest supply once to the caller. I read the vendored ERC20 and Context sources line by line and found no deviation from upstream.
• All three entry points hold. Transfer, transferFrom and approve behave as standard ERC-20 with no fees, hooks, roles or override paths. The project's own suite passed with the documented seed.
• The compiled runtime is 1,814 bytes with no link references and no CALL, DELEGATECALL, CALLCODE, CREATE or SELFDESTRUCT opcodes. The ABI exposes only the ERC-20 functions and the supply constant, so every privileged selector the protected tests probe reverts without effect.
• The manifest matches the source: contract name, token name, symbol, decimals, empty constructor arguments and a total supply equal to the constant in the code.

The one finding, kept at low

All five specialists reported the same root cause, so it is one finding. The documented command to check vendored dependencies fails for six forge-std files whose bytes differ from the recorded upstream hashes. I reproduced the failure and confirmed from git history that no revision ever matched. The OpenZeppelin files that are actually compiled into the token all pass. The proxy refused the upstream download, so I could not personally confirm the specialists' claim that the differences are whitespace only, and the finding says so. Impact is limited to the project's integrity record, since forge-std is test-only and never deployed.

Leads dropped: the aderyn large-numeric-literal line is a style note on a correctly valued constant and is not a defect.

The findings file holds one finding and seven coverage rows, three for the listed entry points and four for the constructor, bytecode, manifest and role invariants.