Implemented LARPToken with the requested name, symbol, 18 decimals, and 1,000,000,000 tokens minted once to the deployer.

Dependencies are vendored. README documents assumptions, deployment parameters, and operational responsibilities.

Verified with Solidity 0.8.26:

• forge build — passed
• forge test — 33 passed, including failure, fuzz, and invariant tests
• forge fmt --check — passed

A fresh offline build and parallel test run also passed with only HOME/PATH retained for Foundry.

Created launch.json matching LARPToken’s constructor, metadata, supply, and the exact requested pool and economics.

Manifest checks and forge build passed. forge test: 33 passed, 0 failed.

Only launch.json is changed for submission.

The review is complete and the findings file is written. No source file was changed.

Result: no defects found. The token at src/LARPToken.sol is an unmodified OpenZeppelin v5.0.2 ERC-20 whose constructor mints the full supply once to the deploying address. Nothing in my area (Execution Trace, Periphery, First Principles) produced a reproducible failure, so the findings list is empty and the coverage record answers every entry point.

What I verified:

• Execution trace. Traced approve, transfer and transferFrom through the inherited base. Zero-address sender, receiver and spender revert, insufficient balance or allowance reverts before any write, a max allowance is left unchanged, and the factory has no allowance bypass. No fee, hook, callback or external call exists on any path.
• Periphery. The five vendored OpenZeppelin files hash identically to the upstream v5.0.2 release fetched from GitHub and to the project's own dependency manifest. The compiled ABI exposes only the standard ERC-20 surface plus the supply constant. Storage layout is stock.
• First principles. The supply constant evaluates to exactly 1e27, so the manifest value and the harness check line up. The constructor takes no arguments, so no launch address is baked in and no exemption list is needed because no transfer rule exists. Mint and burn are internal and unreachable after construction.
• Tooling. All 33 unit and fuzz tests and the stateful invariant suite pass. The Aderyn large-literal lead is a compile-time constant and not a defect. Slither reported nothing.

Coverage rows are holds for all three listed entry points, plus four invariant rows covering the fixed supply, the exact launch flows, the upstream match of the base contracts, and the forbidden-opcode scan. Nothing was left unreached.

The review is complete. The findings file is valid, the cited line matches the tree, the scratch directory is removed, and no tracked file changed.

Result: the LARP token's economics hold. One low-severity provenance defect, no code defects.

The token is a 17-line contract that inherits the vendored OpenZeppelin v5.0.2 ERC-20 unchanged and mints the whole supply to msg.sender once in the constructor. Against the three guides:

• Economic Security. The token has no external dependencies, oracles, callbacks, hooks, owner, pause, blacklist or upgrade path, so there are no privileged trust assumptions to document and nothing an actor with unlimited capital can lever. Zero-address receiver and spender revert. ERC-20 compliance matches the standard, including the approve race the README already documents.
• Invariant. The sum of balances equals totalSupply, fixed at one billion tokens. Only the constructor's mint writes supply upward, there is no burn or mint selector and no fallback, and transfers to the zero address revert so the library's burn branch is unreachable. The repo's stateful invariant suite and my own fuzz run both confirm conservation.
• Flow Gap. Every launch leg moves exactly the stated amount: factory to distributor, distributor to claimant, factory to pool, and trader buy and sell. The 10/80/10 split of the supply leaves no rounding dust. A CREATE2 factory deployment receives the full supply with no constructor arguments, as the protected harness expects.

The one finding (low): lib/DEPENDENCIES.json records per-file SHA-256 hashes that the README directs the deployer to use for provenance checks, but seven forge-std files were reformatted after vendoring and no longer match. I confirmed the difference is whitespace only against the upstream v1.9.7 tarball, and all six OpenZeppelin files match upstream byte-for-byte. Test-only impact, no effect on runtime bytecode or economics. The fix is to regenerate the hashes from the files as vendored.

Verification that ran: forge build, the full 33-test suite including the 128-run invariant campaign, forge fmt check, a scratch test of the launch legs and supply paths (3 tests, 1024 fuzz runs), and upstream tarball comparisons for both vendored libraries. Slither and Mythril were not run beyond the supplied static-analysis lines; the one aderyn lead, a large numeric literal, is the supply constant and is not a defect.

Coverage: all three entry points marked holds, plus six invariant and supply-chain rows, one of which carries the finding. Nothing was left unreached.

The review is complete. The findings file is valid, and the working tree has no tracked changes.

Result: no defects found in the assigned area. The Linked Avatar Register Protocol token is a 17-line contract that inherits the unmodified OpenZeppelin v5.0.2 ERC20 and mints one billion tokens with 18 decimals to the deployer in its constructor. There is nothing else to it.

What I checked, against the Access Control, Asymmetry and Trust Gap guides and the custom-token launch floor:

• Permission model. The compiled ABI exposes only approve, transfer and transferFrom as state changers. There is no owner, role, modifier, initializer, proxy, delegatecall, receive or fallback. Fourteen common admin selectors revert from both the deployer and an outsider.
• Each entry point. All three act only on the caller's own balance or allowance. The deployer cannot pull a holder's tokens without an allowance. Zero-address paths revert, so the mint and burn branches are unreachable after construction.
• Asymmetry. Both transfer paths funnel into the same internal update. Approve and allowance spending write the same slot with the same checks. No branch does different work for different caller classes.
• Trust gap. With no privileged setter, fee, oracle or pricing inside the token, there is no seam where an authorized actor extracts value asymmetrically. The only trust assumption is the launch design itself: the factory holds the supply at deployment and distributes it.
• Launch floor. Supply is exactly 10^27, decimals are 18, there is no fee or hook, so every launch flow moves exactly what it says. The existing opcode scan for forbidden instructions passes.
• Dependency integrity. All six vendored OpenZeppelin files match the recorded hashes and the upstream v5.0.2 tag byte for byte.

Evidence: the existing suite of 33 tests passed, including the stateful invariant run. My own scratch probe of six unauthorized paths passed and was removed afterwards. Slither reported nothing. The aderyn large-literal lead is stylistic and evaluates to the correct supply.

The coverage record has eight rows: holds for all three entry points plus five invariant rows. Two documented design properties, the standard ERC-20 approve race and the missing Approval event on transferFrom, are noted but not reported as defects since the README already discloses them and they are inherent to the requested plain token.

The review is complete and the findings file is written. Nothing further is needed from the tree.

Outcome: no math, boundary or numerical-gap defect in the token. The only reportable item is an informational provenance discrepancy in test tooling.

What was checked

• The token is 17 lines over stock OpenZeppelin v5.0.2 ERC-20 with no overrides. The vendored OpenZeppelin files are byte-identical to the upstream v5.0.2 tag and to the hashes recorded in the dependency manifest.
• Math Precision: the supply constant evaluates to exactly 10^27 at compile time and is minted once with checked arithmetic. The token contains no division, scaling, casts, fee math or runtime multiplication, so there is nothing to round or truncate.
• Boundary: no external calls, no payable function, no receive or fallback, no bytes decoding. ETH sends and unknown selectors revert. Transfers above balance, including the maximum uint256, revert with the typed ERC-6093 error rather than a panic. Zero-amount paths, self-transfers, exact-balance transfers and the max-allowance sentinel all behave per spec.
• Numerical gap: the only seam candidate is the infinite-allowance sentinel, and it behaves correctly at max, max minus one, and zero.
• Launch floor: every transfer moves exactly the requested amount, so the swarm, pool and remainder flows arrive whole.
• The project's own 33 tests pass, including the stateful invariant suite, and a scratch suite of nine boundary tests I wrote also passed before I deleted it.

The one finding, informational

Seven vendored forge-std files do not match the sha256 values recorded in the dependency manifest. Diffing against upstream v1.9.7 shows the differences are line-wrapping only. With whitespace stripped the files are identical to upstream, so the test tooling is unmodified in substance. The README directs readers to that manifest for file hashes, so the record is stale. Test tooling never reaches deployed bytecode, so there is no on-chain impact.

Coverage names all three listed entry points as holding, plus rows for the constructor, the supply invariant, the external-call boundary, the vendored-library identity, the numerical seams and the launch flows. No row is marked unreached.

Added 17 adversarial tests and strengthened invariants with independent balance tracking and randomized failure paths.

• Offline forge build passed.
• Offline forge test: 50 passed, zero failures.
• Invariants passed 24,576 calls.
• No contract defects found.

All changes are under test/.

Review complete. The findings file is written at .imd-findings.json and the working tree is otherwise unchanged.

Outcome. The token itself is clean. One low-severity documentation defect survives, merged from the two specialists who reported it.

What I verified

• The token is a bare OpenZeppelin v5.0.2 ERC-20 with a zero-argument constructor that mints the full supply once to the deployer. It adds no functions, no owner, no fees, no hooks and no prohibited opcodes. Creation code is 2,658 bytes and runtime is 1,752 bytes.
• All five vendored OpenZeppelin source files and the LICENSE are byte-identical to the upstream v5.0.2 tag, so the compiled dependency chain is intact.
• The project builds, formatting checks pass, and all 50 tests pass, including the fuzz and stateful invariant suites.
• The manifest is schema-consistent with the source: empty constructor arguments, matching supply, decimals, name and symbol, lowercase addresses, and no extra keys.

The one finding kept (low)

The dependency provenance record in lib/DEPENDENCIES.json lists per-file hashes for forge-std v1.9.7 that do not match seven vendored files. I reproduced it with the specialists' script, downloaded the upstream v1.9.7 archive, confirmed the archive hash matches the record, and confirmed each of the seven files is identical to upstream once whitespace is stripped. The reformat and the hash record were both introduced in the builder's own first commit. The README tells the deployer to use that record for pre-release verification, so a reviewer following it sees seven mismatches on a test-only library. No on-chain or economic effect. The fix is to regenerate the seven hashes or restore upstream formatting.

Coverage. All three listed entry points hold. I also recorded rows for the constructor, the fixed-supply invariant, the manifest and the dependency record.