Implemented LARPToken: 1 billion LARP, 18 decimals, minted once entirely to the deployer.

• Offline build and formatting checks passed.
• All 36 reported tests passed, including fuzz and invariant checks.
• Slither reported no High or Medium findings.
• Vendored dependencies, deployment documentation, and review notes included.

Full factory/pool integration remains for the network verifier.

I found no defects in LARP's control flow, so .imd-findings.json has an empty findings list plus a coverage record. The file is valid JSON and no repository files were changed.

What the code is. src/LARPToken.sol is only a constructor that mints 1,000,000,000 × 10^18 units once to msg.sender (the factory). Everything else comes from the bundled OpenZeppelin ERC-20, which I read line by line. It has no overrides, no fees and no exemptions, and it makes no calls to other contracts. The bundled files match their recorded checksums.

Execution Trace:

• transfer and transferFrom check the balance before the unchecked subtraction. The unchecked addition can't overflow because the supply is fixed at 10^27.
• transferFrom rejects a too-small allowance and leaves an unlimited allowance unchanged. A failed call reverts everything.
• approve replaces the old allowance and refuses the zero address as spender.

Periphery: nothing calls back into the token, so there is no reentrancy surface. Transfers to and from the factory, the distributor and the PoolManager deliver the exact amount, which is what the protected launch test requires.

First Principles:

• The supply can't grow: there is no public mint, owner, initializer, pause, blacklist or upgrade path.
• Decimals are 18.
• I scanned the 1,740-byte compiled contract and found no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Leads: the only tool hint, a "large numeric literal" note at line 11, is just the supply constant and isn't a defect. The usual ERC-20 risks (the race when replacing an allowance, and tokens sent to an address that can't move them) are documented, standard behaviour.

Coverage: approve, transfer and transferFrom are each marked holds, along with two checked properties: the fixed supply and the absence of forbidden opcodes.

Checks run: forge build and forge test both pass, 36 tests. I couldn't run the protected launch test because its pool and launch files aren't in this workspace. I traced its requirements against the code instead, as described above.

Done. The manifest is written and the build and tests pass with no other file changed.

What I wrote in launch.json, matching the accepted tree:

• kind is custom_token, with the token contract named LARPToken, name "Linked Avatar Registry Protocol", symbol LARP, 18 decimals.
• constructorArgs is an empty list, since the accepted constructor takes no parameters and mints to msg.sender.
• totalSupply is the exact minor-unit value of one billion tokens at 18 decimals, matching INITIAL_SUPPLY in the source.
• contracts is empty. The accepted tree contains only the token, so no application contracts are described.
• pool and economics are copied verbatim from the launch reference: IMD pair address, fee 12500, tick spacing 60, the one-to-one provenance price, and the requester's economics object.
• notes describes the token's fixed supply, absence of privileged functions, and the factory's payout of the supply, at 868 characters.

Verification results:

Check	Result
Manifest shape, key set, supply, economics, pool	ok
forge build --offline	successful
forge test --offline	36 passed, 0 failed
git status	only launch.json added

The protected harness test reads the token creation code and manifest supply through environment variables, so it will run against this manifest after submission rather than locally.

I found no math defects in LARP. .imd-findings.json has an empty findings list and a coverage row for each of the three entry points. All three rows say holds.

Why there is little to check: src/LARPToken.sol is OpenZeppelin's standard ERC-20 with nothing added. The constructor mints the fixed supply (1_000_000_000 * 10**18, exactly 1e27) once, to the deployer. There are no fees, burns, divisions, scaling, narrowing casts or later mints. The vendored OpenZeppelin files match DEPENDENCIES.sha256, so the library code is unedited.

What I checked against the three guides:

• Math precision: none of the guide's patterns appear. There are no divisions, so nothing can round the wrong way or round to zero. The supply is 1e27, far below the uint256 limit.
• Boundaries: the unchecked arithmetic inside OpenZeppelin is safe here:
  • Every subtraction is checked first: a transfer reverts if the balance is too small, and a transferFrom reverts if the allowance is too small.
  • Additions can never exceed the fixed supply.
  • An unlimited approval (2^256 − 1) is never decremented.
  • Transfers to or from the zero address revert.
• Numerical gaps: there is no fee or rounding term, so balances always add up to the total supply.

I ran the project's tests plus a temporary test of my own covering:

• a 1 wei transfer, a full-supply transfer, a zero transfer and a transfer to yourself;
• spending exactly the allowance, one wei over it, and from an almost-unlimited approval;
• a fuzz check that balances always add up to the supply.

All 40 tests passed. I deleted my temporary test afterwards, and I changed no tracked files.

The static-analysis lead (aderyn's "large numeric literal" at line 11) is just the supply constant written out as a number. It is correct and readable, so I didn't report it.

Not covered: the launch manifest (launch.json), which doesn't exist yet. I also didn't run the protected launch test (Token.protected.t.sol), because it needs Uniswap v4 and factory files that aren't in this repository. Neither is part of the math review.

I found no defects in the economics of LARP, so .imd-findings.json has an empty findings list plus a coverage record. The file is valid JSON, and no tracked files changed.

What the code is: src/LARPToken.sol is a plain OpenZeppelin 5.x ERC-20 with nothing added. Its constructor mints exactly 1,000,000,000 × 10^18 to whoever deploys it, which in the launch is the factory. It takes no constructor arguments and hands out no roles. It has no fee, burn, exemption list, hooks, owner, pause, extra mint or upgrade path. The vendored OpenZeppelin files match their pinned checksums in DEPENDENCIES.sha256, and I read through ERC20.sol and Context.sol and found no edits.

Coverage: all three entry points (approve, transfer, transferFrom) are marked holds. I also added rows for the supply invariant, the exactness of the launch flows, and the constructor and starting state.

• Economic Security: nothing depends on outside contracts. The token has none of the misbehaviours the guide lists (fee on transfer, rebasing, blacklist, pause, missing return value), and decimals() returns 18. There is no price, oracle or incentive logic that could be manipulated.
• Invariant: the sum of balances equals the total supply, the supply can never grow, and a failed allowance check undoes the whole call. The project's own invariant suite passes: 36 tests, and 128 runs × 64 calls with zero reverts.
• Flow Gap: the factory-to-distributor, distributor-to-claimant, pool seed and swap transfers each move exactly the amount requested, with no callbacks during a transfer.

Left out on purpose: aderyn flagged a "large numeric literal" at line 11. That line is the readable supply constant 1_000_000_000 * 10 ** 18, so I didn't report it. The approve front-running race is ordinary ERC-20 behaviour, and the token's own REVIEW.md already documents it.

Not covered: I couldn't run the launch acceptance test (Token.protected.t.sol) because it needs the network's launch files and settings, which aren't in this workspace. I checked the code against it by reading instead. There is no launch.json yet, which is normal before the manifest step. When it is written, the token's constructorArgs should be an empty list [], since the constructor takes no arguments.

The review is complete. The findings file is written with an empty findings list and a full coverage record. Only .imd-findings.json was created, and git status shows no other change to the tree.

Result: no defects found in the Access Control, Trust Gap and Asymmetry areas for src/LARPToken.sol.

What I checked and how:

• Permission model. The compiled ABI exposes only approve, transfer, transferFrom and the standard views. There is no owner, modifier, inline role check, mint, burn, pause, blacklist, upgrade path, initializer, delegatecall or selfdestruct. The constructor is the single mint path and sends the whole supply to its immediate caller with no arguments and no external call.
• Inconsistent guards. Each storage slot has one internal writer chain. Balances change only through the inherited update function, reached from both transfer entry points under identical validation. Allowances change only through approve or the allowance-spending helper, both scoped to the caller's own grant.
• Trust gap. No privileged actor exists after deployment, so there is no seam between authorization and value flow. The deployer's full-supply custody is the factory by design.
• Asymmetry. The two transfer paths converge on the same update logic. The only difference is upstream OpenZeppelin not emitting Approval when an allowance is spent. That is documented in the README and moves no value.
• Dependency integrity. All vendored checksums verified. I read the vendored ERC20 and Context sources line by line and they match upstream OpenZeppelin v5 semantics.
• Execution. The project builds offline and all 36 unit, fuzz and invariant tests pass. The aderyn low-severity lead at line 11 is a compile-time constant equal to the stated supply and is not a defect.

One limit: the network's protected launch floor could not be executed here because its Uniswap v4 and launch fixtures are not in this workspace. I reasoned through it instead. The token has no constructor arguments, mints to the CREATE2 caller, reports 18 decimals and taxes nothing, so the swarm, seed and swap flows move exact amounts.

Added failure-path and property tests, plus stateful invariants covering 13 actions across four actors.

forge build and forge test pass: 52 tests, including 32,768 randomized invariant calls.

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

The review is complete with no defects found. .imd-findings.json holds an empty findings list and a coverage record answering all three entry points as holding, plus four invariant rows. No tracked file was changed.

What I checked

• The token at src/LARPToken.sol is a sixteen-line OpenZeppelin ERC-20 with one constructor mint of 1e27 units to msg.sender. No other function reaches mint, burn, pause, blacklist or ownership, and the constructor makes no external calls.
• The four specialists and the independent tester reported nothing, so there was nothing to reproduce or merge.
• The vendored library is the real risk surface for a wrapper this thin. The checksum file verifies, and a code-line diff against an upstream OpenZeppelin 5.1.0 copy shows only import ordering and the equivalent < versus != max-allowance comparison. Context returns plain msg.sender.
• The existing suite passes with 52 tests, including launch-flow, rollback-on-revert, fuzz and invariant tests. Runtime is 1,740 bytes and creation code 2,646 bytes, well under the deployment limits, and the opcode scan finds no forbidden opcodes.
• The manifest uses only schema keys, an empty constructorArgs list matching the no-arg constructor, the exact minted supply, 18 decimals and lowercase addresses.
• The static-analysis lead about a large numeric literal is a style note on the supply constant and not a defect.

Deliverable

• .imd-findings.json with {"findings":[]} and seven coverage rows: approve, transfer and transferFrom hold, and the supply, deployment, vendored-library and manifest invariants hold.