Implemented GOTCHI: 1 billion tokens, 18 decimals, minted once entirely to the deployer. Dependencies are vendored, with deployment and operational documentation in README.md.

Passed forge build, seeded forge test (35 reported tests), forge fmt --check, and an offline rebuild. Full protected launch integration checks remain for the verifier.

Done. I wrote launch.json for the Gotchi Finance launch and it is the only change in the tree.

What the manifest says

• Kind is custom_token. The token contract is GotchiToken with name Gotchi Finance, symbol GOTCHI, 18 decimals.
• Constructor arguments are an empty list. The accepted constructor takes no parameters, confirmed from the compiled ABI.
• Total supply is 1000000000000000000000000000 minor units, exactly the INITIAL_SUPPLY constant minted once to msg.sender.
• Contracts is an empty list. The accepted tree contains only the token, so no application contracts are described.
• Pool is IMD at 0xd34a99bc0f67ae1bbd63c660e6d0b0dd03e263b7, fee 12500, tick spacing 60, and the one-to-one provenance price from the reference.
• Economics is the requester's object copied verbatim.
• Notes describe the token's behavior in 1,293 characters, within the 4,000 limit.

Verification

• forge build compiled cleanly.
• forge test with the verifier's fuzz seed passed all 35 tests across both suites.
• A JSON check confirmed only the six schema keys are present and the supply string equals 10^27.
• git status shows launch.json as the only new or changed file.

The review is complete. No defects found in the economics area, and the coverage record is written to .imd-findings.json with an empty findings list.

What the token is. src/GotchiToken.sol is a 17-line contract inheriting the vendored OpenZeppelin v5.0.2 ERC-20 unchanged. Its constructor mints the full supply to the deployer once. The compiled ABI exposes only the standard ERC-20 functions plus the supply constant.

What I checked against the Economic Security, Invariant and Flow Gap guides:

• Conservation. The only mint is in the constructor and nothing external reaches mint, burn or the update hook. The project's 128-run stateful suite and a 3650-day warp keep the balance sum at exactly 1e27.
• Launch flows. Transfers to the distributor, pool manager and requester, a claim, a buy via a pool-manager payout, and a sell via both direct transfer and approve-then-pull all moved exact amounts in a scratch test I wrote and ran. No fee, hook, exemption, or pre-transfer amount that could diverge from what is delivered.
• External dependencies and sentinels. No oracle, callback, receiver hook, ETH acceptance or proxy. Zero-address receiver and spender revert rather than silently succeeding. Vendored library file digests match the recorded dependency manifest.
• Privileged powers. None exist. Eighteen common admin selectors and raw ETH revert from both the deployer and a stranger. The runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• Static-analysis lead. The aderyn large-numeric-literal note is 1_000_000_000 * 10 ** 18, which the tests confirm equals the manifest supply. Not a defect.

Verification run. The seeded project suite passed all 35 tests, format check passed, and my 5 scratch tests passed. The scratch directory was removed afterward.

Not reached. A real Uniswap v4 seed and swap were not simulated locally because the protected harness and manifest inputs are not in this tree. Only the token side of those flows is verified, which is what this review area covers.

The review is complete and .imd-findings.json holds the result: no defects, with a coverage row for every entry point.

What I reviewed. The token is a 17-line contract on the unmodified OpenZeppelin v5.0.2 ERC-20, with one constructor mint of the full supply to msg.sender and no constructor arguments. I checked it against the Access Control, Trust Gap and Asymmetry guides and the Senior Auditor's Mindset section. The vendored OpenZeppelin files match the digests in DEPENDENCIES.json, and Context.sol returns plain msg.sender, so there is no meta-transaction path.

What held, with evidence.

• Access control. The compiled ABI exposes only approve, transfer and transferFrom as state-changing calls. There is no owner, minter, pauser, blacklist, initializer, receive or fallback. A scratch probe confirmed the deployer contract, the deployment's tx.origin and a stranger all fail to pull a holder's balance, that a caller can only write their own allowance row, and that ETH or unknown selectors sent to the token revert.
• Asymmetry. transfer and transferFrom route through the same _update and move identical amounts for identical inputs under fuzzing. Finite allowances decrement exactly and the max allowance stays unchanged. transferFrom does not emit Approval, which is OpenZeppelin v5 behavior and is documented in the README.
• Trust gap. With no privileged actor, no fee recipient, no price formula and no caller-class branch, none of the four seams in the guide has an actor or primitive to exploit.
• Launch floor. No transfer hook or exemption list exists, so the factory, distributor and PoolManager flows move exactly what they request. The creation bytecode carries no metadata hash, and the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Trust assumption to record. Whoever deploys the token receives the entire supply. Under the factory's CREATE2 launch that is the factory, as intended. A direct EOA deployment would put the supply in that EOA instead.

Not run. The protected Uniswap v4 seed-and-swap harness needs the factory and v4 sources, which are not in this repository. Since the token has no transfer rules, nothing in it can tax or block those flows, but that harness remains the launch process's check.

The project's own 35 tests pass with the verifier's fuzz seed. I removed my scratch probe file and changed nothing else in the tree.

The review is complete and the result is clean. The findings record is written to .imd-findings.json with an empty findings list and seven coverage rows, and the working tree is otherwise unchanged.

What I reviewed. The token is a 17-line contract inheriting the vendored OpenZeppelin v5.0.2 ERC20 with one constructor mint of 10^27 units to msg.sender. I applied the Senior Auditor's Mindset and the three assigned guides, plus the deployment-phase and token-behaviour items from the x-ray reference and the entry-point inventory from the Trail of Bits reference.

Execution Trace. I traced all three state-changing entry points from caller to final state. Each path either moves exactly the stated amount or reverts atomically with no partial update. There are no external calls, callbacks, sentinel paths, value paths, or stale reads. The factory-style deploy-then-distribute in one call moves exactly ten, eighty and ten percent with nothing left behind.

Periphery. Every vendored OpenZeppelin file hashes identically to the digest recorded in DEPENDENCIES.json and to the upstream raw file at tag v5.0.2 fetched during the review. The base contract is unmodified and its storage layout is standard.

First Principles. The constructor's only assumption is that msg.sender is the intended recipient, which holds under CREATE2 from the factory and ignores tx.origin. The compiled ABI exposes ten functions: the three listed entry points and seven views. There is no receive, fallback, mint, burn, owner or admin selector, and the runtime contains no DELEGATECALL, CALLCODE, SELFDESTRUCT, CALL, STATICCALL, CREATE or CREATE2.

Checks run. The project's own 35 tests pass under the verifier's fuzz seed, including the 8,192-call stateful suite. My scratch tests covering the edge cases the suite omits also pass and were removed afterward. The static-analysis lead about the large numeric literal is a style note on the supply constant and is not a defect.

Trust assumptions. None. There are no privileged roles. The inherent ERC-20 approval race and unrecoverable tokens sent to the contract itself are standard-interface properties already documented in the README, not defects in this code.

Not reached. The protected launch harness that seeds a real Uniswap v4 pool depends on infrastructure outside this tree and was not run; the token-side transfers it relies on were verified directly.

The review is complete and .imd-findings.json holds the result: no defects, with seven coverage rows.

What the token is. src/GotchiToken.sol is a 17-line contract inheriting the vendored OpenZeppelin v5.0.2 ERC20 unchanged. It has one compile-time constant for the supply and a constructor that mints it to the deployer. The five vendored OZ files match the SHA-256 hashes pinned in DEPENDENCIES.json, so the arithmetic under review is exactly upstream's.

Math Precision guide. There is no division, multiplication at runtime, downcast, scale conversion, fee, or share formula anywhere in the token. The supply literal evaluates exactly to 10^27 and equals one billion times ten to the token's own decimals. The only checked addition is the single mint into total supply. The unchecked subtractions and additions in OZ's balance update are each preceded by the balance guard or bounded by the fixed supply, which I confirmed with max-uint, supply-plus-one, one-wei and zero inputs. The aderyn "large numeric literal" line is stylistic and does not change the value.

Boundary guide. The token makes no external calls, has no payable function, receive or fallback, and decodes no bytes. The only sentinel branches are the zero-address rejections in transfer, approve and mint, and both sides of each behave as documented. The infinite-allowance sentinel is handled correctly: max-uint is never decremented, max-minus-one is finite and decremented exactly, and an allowance equal to the value spends to zero while value-plus-one reverts with the exact custom error.

Numerical Gap guide. The invariant that balances sum to total supply has no rounding seam to drift through, since no operation truncates. A fuzzed eight-party random split and the repository's own invariant suite of 8,192 calls conserve supply exactly. Revert paths roll back allowance and balance together.

Checks that ran. Forge build, the existing 35 tests, an 11-test scratch probe file I wrote and deleted afterwards, and forge fmt --check on the committed sources. All passed. The runtime bytecode contains no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE. No launch.json exists in the tree yet, so there was no manifest to check.

Outside my area. Nothing severe surfaced. The token has no privileged roles, so there are no trust assumptions to document. The working tree is unchanged apart from the findings file.

Done. The full suite passes with the verifier's seed, and no defects were found in the token.

Suite	Tests	Result
Existing unit and fuzz suite	34	pass
New edge and failure-path suite	35	pass
Existing fixed-actor invariants	1 contract, 8,192 calls	pass
New open-address invariants	1 contract, 12,288 calls	pass

What I added, in two new files only, building on the prior contributor's work rather than rewriting it:

• test/GotchiToken.edges.t.sol covers the failure paths the first suite skipped. The zero address as sender, approver, and spender, including the subtle case where a zero-amount pull from the zero address passes the allowance check and is refused only on the allowance write-back. ETH sent to the token, deployment with value attached, and unknown selectors are all rejected. It pins exact allowance boundaries one wei either side, infinite versus max-minus-one allowances, event discipline on every call including that transferFrom emits no Approval, a launch distribution performed inside one creation transaction, and independence between deployments.
• test/GotchiToken.open.invariant.t.sol is a second invariant suite where the fuzzer picks the holders rather than a fixed cast. A handler keeps a ghost ledger of received and sent per address, an enumerable set of every holder, and an allowance book per pair. It drives full-amount, dust, and infinite-allowance stress variants, eight deliberate rejection paths that must revert with the exact error, time and block advancement, and privileged-call probes from both the deployer and a stranger. Run counts are set with inline config so foundry.toml is untouched.

Grounding the invariants. Before trusting them I ran the same handler against three broken tokens in test/scratch: a one-wei burn on transfer, a public mint, and an infinite allowance treated as finite. The first two failed immediately. The third passed, which exposed a vacuous path: a random uint256 never lands on the maximum, so the unlimited-allowance branch was never exercised. I added an explicit infinite-approval handler and the mutation then failed on the allowance book. The scratch files are removed.

No findings to report. The implementation is a plain OpenZeppelin v5.0.2 ERC-20 with one constructor mint, no admin surface, and no forbidden opcodes. Nothing I probed behaved incorrectly, so there is no .imd-findings.json. The two new files are left uncommitted in the working tree under the permitted test path for the submission step to pick up.

The review is complete. The findings file is valid, the snippet anchors to the tree, and the working tree has no stray files.

Outcome: the token is sound. All four specialists reported nothing, and I reproduced nothing against the contract itself. I found one low-severity provenance defect they missed, recorded in .imd-findings.json with full coverage of the three entry points.

What I verified

• Token code. src/GotchiToken.sol is a bare OpenZeppelin v5.0.2 ERC-20 whose constructor mints 10^27 units to msg.sender. The compiled ABI has only approve, transfer and transferFrom as state-changing functions, no receive or fallback, no mint, burn, owner, pause or upgrade path. All six vendored OpenZeppelin files match their recorded upstream digests, so the traced behaviour of the three entry points is the known library behaviour. Each is marked holds.
• Deployability. Creation code is 2,645 bytes and runtime 1,752 bytes, well under the limits. A byte scan found no DELEGATECALL, CALLCODE or SELFDESTRUCT. The constructor takes no arguments and the manifest's constructorArgs is empty, so the factory's CREATE2 deployment works.
• Manifest. launch.json uses only schema keys, lowercase addresses, strings for uint fields, numbers for fee, tickSpacing and decimals, a 1,293-character notes field, and a totalSupply that equals the constant minted.
• Tests and tooling. The build is clean, the seeded suite passes all 71 tests, and the formatter check passes. The aderyn "large numeric literal" lead is a compile-time constant that tests confirm equals 10^27, so it is not a defect.

The one finding (low). DEPENDENCIES.json records per-file SHA-256 digests and the README states the vendored sources are unmodified. Seven forge-std files on disk fail that check. I downloaded the upstream v1.9.7 archive, whose digest matches the recorded one, and compared: the files were reformatted after vendoring and are byte-identical to upstream once whitespace is stripped. This is test-only and does not affect the deployed bytecode, but the shipped provenance record is verifiably wrong. The fix is to restore the upstream bytes or regenerate the digests.

No proof test was written, since nothing at critical or high severity exists. Nothing under test/scratch was created and no repository file other than the findings output was touched.