Implemented Idatsy (IDATSY): 1 billion tokens, 18 decimals, minted once entirely to the deployer.

• Solidity 0.8.26 build passes, including offline rebuild.
• All unit, fuzz, and invariant tests pass with the supplied seed.
• forge fmt --check passes.
• Dependencies are vendored; deployment parameters and responsibilities are documented in README.md.

I've written launch.json for the Idatsy launch, and it is the only file changed.

What's in it:

• Token: the contract is Idatsy (name "Idatsy", symbol "IDATSY", 18 decimals). constructorArgs is empty because the constructor in src/Idatsy.sol takes no arguments.
• Supply: totalSupply is "1000000000000000000000000000". That is the 1,000,000,000 × 10^18 the constructor mints once to msg.sender, which is the factory.
• Application contracts: the list is empty. The accepted tree contains only the token, so there is nothing else to name.
• Pool: paired with native ETH (the zero address), fee 12500, tick spacing 60, and the one-to-one initialPrice. All of these come from the launch's own terms.
• Economics: copied exactly from the brief.
• Notes: a short description of the token. It is a fixed-supply ERC-20 with no mint, burn, fee, pause, owner or upgrade function, so transfers during the launch move exactly what they say.

Checks: the file parses as valid JSON. forge build and forge test with your fuzz seed passed all 37 tests. Those tests are the repo's own and don't check the manifest itself. I couldn't run the two protected test files locally because the files they import (floor/OwnerChecks.sol, src/LaunchLiquidity.sol and others) aren't in this tree. So the manifest's schema compliance was checked by reading it against the rules in the brief, not by a validator.

The review is complete and .imd-findings.json is written with one low finding and ten coverage rows. No tracked source, test, or configuration file was changed. The only addition is the scratch test under test/scratch/, which is not kept.

What I audited. The token is a single contract, src/Idatsy.sol, that inherits the vendored OpenZeppelin v5.1.0 ERC20 unchanged and mints the full supply to the constructor's caller. I checked it against the Access Control, Trust Gap and Asymmetry guides, read the protected launch floor tests, and confirmed the vendored OpenZeppelin files are byte-identical to the upstream v5.1.0 release.

Permission result. The permission model holds. There is no owner, minter, pauser, initializer, upgrade slot or fee setter, so no privileged actor exists after deployment. A scratch test tried 30 admin-style selectors, empty calldata and ETH sends from both the deployer and a stranger. All reverted and left supply and holder balances unchanged. The transfer and transferFrom paths share the same validation and state writes, the holder itself and the factory cannot pull without an allowance, and the compiled runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT on any reachable path. The existing suite of 37 tests also passes.

One finding, low, outside the assigned area. The documented integrity check in DEPENDENCIES.md fails on the committed tree. Seven forge-std files differ from the hashes in lib/SHA256SUMS and from the pinned v1.9.7 release. The drift is line-wrapping only, from a formatter pass, and touches test-only code. The reproduction is the command below, which reports seven FAILED lines instead of all OK.

sha256sum --check lib/SHA256SUMS

Coverage. All three listed entry points are marked holds, with additional rows for the constructor's role handout, the fixed-supply and opcode invariants, and the three guide passes. The dependency integrity row points to the finding. Nothing in the assigned area was left unreached.

The review is complete and the findings file is written and validated.

Outcome. The token's math holds. Idatsy is OpenZeppelin v5.1.0 ERC20 with one constructor mint and nothing else, so there is no division, rate, fee, scaling or downcast anywhere in the value path. I found no defect in my area. One low finding outside the area is reported.

What I checked, per guide

• Math Precision. The supply literal evaluates to exactly 10^27, which clears the aderyn large-literal lead. The supply fits comfortably under the int128 and uint128 limits Uniswap v4 uses for deltas and liquidity. Balance updates in the inherited _update are guarded before their unchecked subtraction, and the unchecked add cannot exceed the fixed supply.
• Boundary. No external calls, no payable or receive function, no bytes decoding. The only sentinel branches are the zero-address checks, walked on both sides. A scratch Foundry test exercised transfer of the whole balance, balance plus one, max uint, self-transfer, zero amounts from empty accounts, and allowances at zero, exact, max minus one and max. All behaved as intended and the scratch file has been removed.
• Numerical Gap. No seam exists because every state change is an exact add or subtract of the caller's value. The existing invariant suite ran 8192 calls with no unexpected reverts.

The one finding (low). The dependency notes say no vendored source was modified and tell reviewers to run the checksum verification. That command fails on seven forge-std files. The checksums match upstream v1.9.7, so the local copies were reformatted after copying. With whitespace stripped they are byte-identical to upstream, so no behaviour changed and production bytecode is unaffected. The reproduction is the single command below.

sha256sum --check lib/SHA256SUMS

Coverage. All three listed entry points are marked holds, plus four invariant rows covering fixed supply, narrow-type fit, boundary enumeration and the precision seams. Nothing was left unreached.

The findings file is complete and its citation now matches the tree. No further checks are needed.

Outcome: the Idatsy token is clean in my area. I found no defect in the production contract. The one finding is a low-severity integrity-documentation defect in the vendored test library.

What I covered (control flow: Execution Trace, Periphery, First Principles)

• Execution Trace. All three entry points are unmodified OpenZeppelin v5.1.0 calls. Zero-address sentinels revert, the unlimited allowance is the documented ERC20 convention, self-transfer conserves balance because the recipient increment reads storage after the sender write, and transferFrom checks allowance before moving funds with full rollback on any revert. No external calls, callbacks, encoding, or msg.value anywhere.
• Periphery. I fetched the upstream OpenZeppelin v5.1.0 and forge-std v1.9.7 tarballs. Both tarball hashes match what DEPENDENCIES.md states. All six vendored OpenZeppelin files are byte-identical to upstream, and Context returns plain msg.sender with no forwarder logic.
• First Principles. The constructor's msg.sender is the deploying factory under CREATE2, confirmed by a scratch test with a pranked caller and origin. The supply constant equals exactly 10^27, decimals default to 18, the compiled ABI holds nothing beyond ERC20 plus the supply constant, ETH and unknown selectors revert, and a replay of the launch floor's reachable-opcode scan found no DELEGATECALL, CALLCODE, SELFDESTRUCT, or any external-call opcode.
• The aderyn large-literal lead is a compile-time constant with the correct value, not a defect. The existing 37-test suite passes with the README's seed.

Finding (low): DEPENDENCIES.md says no dependency files were modified and instructs reviewers to run the SHA256SUMS check. That check fails on seven forge-std files. The differences are whitespace-only reflows of upstream v1.9.7, so there is no behavioral impact and forge-std is test-only, but the documented provenance procedure does not pass as written. Fix is to restore upstream bytes or regenerate the sums file.

Coverage record: ten rows written, three for the listed entry points plus seven for invariants and periphery checks. All hold except the forge-std row, which points to the finding. Nothing was left unreached. The scratch test directory was removed, and no repository files were changed.

I added 20 tests to the existing Idatsy suite and found no defects in the token. The full suite passes under the verifier's fuzz seed: 53 unit and fuzz tests plus two invariant suites, each with 128 runs and 8,192 calls and no reverts. I didn't write .imd-findings.json because there is nothing to report.

src/Idatsy.sol is a bare OpenZeppelin v5.1 ERC-20. Its constructor mints the 1,000,000,000 × 10¹⁸ supply once to msg.sender, and it has no other functions of its own.

New files (the existing tests are unchanged):

• test/IdatsyLaunch.t.sol (17 tests):
  • Launch in one call: a stand-in factory deploys the token with CREATE2 and pays out the 10% swarm share, the pool share and the remainder in a single call. Each share arrives whole, including when the pool share is fuzzed from 0 to 90%. Redeploying with the same salt reverts.
  • No privileged access: 21 mint, owner, pause, freeze and seize style calls, plus burnFrom and an unapproved transferFrom, all fail from both the deployer and a stranger. The holder's balance is unchanged afterwards and they can still transfer.
  • Malformed calls: an unknown selector, empty calldata, a truncated selector and a transfer with its amount cut off all revert.
  • Bytecode scan: the token's runtime code has no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT.
  • Edge cases: an allowance one below the maximum is spent down normally; a maximum allowance still can't exceed the balance; approving yourself works; approvals stay separate per owner and spender; transfers to fuzzed addresses work; strangers can't spend without an allowance. Tokens sent to the token's own address stay there, and nobody can pull them back out.
  • Wallet gas: the supplied helper confirms transfer, approve and transferFrom (with both a limited and an unlimited allowance) behave the same at a wallet's estimated gas. Nothing in the token checks gas left, forwards a fixed amount of gas or catches a failed call, so this check isn't strictly required here.
• test/IdatsyOpenActors.invariant.t.sol: an invariant suite whose set of holders grows as tokens reach new addresses, including the token's own address. It checks that the supply never changes and the zero address never holds tokens, that all holders' balances add up to the supply, and that no spender ever moves more than it was approved. Each allowance must also equal what was approved minus what was spent. Its handler also tries to overspend and confirms the attempt fails and changes nothing.
• test/helpers/WalletGas.sol: the supplied helper, copied unchanged.

I haven't committed anything. The repository root also has untracked files I didn't create: shell and git config dotfiles, .claude/, .idea, .vscode, .mcp.json and .gitmodules. I left them alone. They should be kept out of the submission, which can only include test/.

The review is complete and .imd-findings.json is written at the repository root. No tracked file was changed, and the scratch test directory has been removed.

Outcome: the token's economics hold. src/Idatsy.sol is an unmodified OpenZeppelin v5.1.0 ERC20 with one constructor mint of 1e27 units to its deployer. I checked it against the Economic Security, Invariant and Flow Gap guides and found no defect in the token itself.

What I verified, with the three listed entry points and the launch flows all marked holds:

• Supply and conservation. The only mint is in the constructor. No burn, mint, owner, pause, blacklist, freeze or seize function exists. Fourteen common admin selectors called from the factory and from a stranger all revert and leave supply and balances unchanged. The project's own invariant suite (128 runs, depth 64) and all 36 unit tests pass.
• Launch flows are exact. From a CREATE2 factory stand-in, the whole supply lands at the factory. The 10% swarm share, 88% pool share and 2% remainder leave to the wei and sum to the supply. A claim leaves the distributor empty. A trader round trip through transfer and transferFrom with both unlimited and finite allowance is exact, and the factory cannot pull a holder's balance without allowance.
• Dependencies and bytecode. All six vendored OpenZeppelin files are byte-identical to upstream v5.1.0. Disassembly of the runtime shows zero CALLCODE, DELEGATECALL or SELFDESTRUCT opcodes. Sending ETH to the token reverts.

One low finding, outside my area but concrete. DEPENDENCIES.md tells readers to verify the vendored libraries with the checksum list and states no dependency file was modified. Running that check fails on seven forge-std files. The listed digests are correct for upstream v1.9.7; the vendored copies were reformatted, and a whitespace-stripped comparison shows them otherwise identical. This is test-only code with no effect on the token's bytecode, so I rated it low. The fix is to restore the upstream bytes or regenerate the checksum list and correct the sentence.

Not reported as findings, since they are standard and documented behaviour the requester asked for: the approve allowance race and the ability to send tokens to the token's own address with no rescue path.

Not reached: the protected harness itself could not be run here because it imports Uniswap v4 core and launch sources absent from this tree, so the seed and swap path was exercised with a pool-manager stand-in rather than the real PoolManager.

The review is complete. The findings file is valid JSON, the quoted snippet matches line 13 of DEPENDENCIES.md, and no repository file was changed.

Outcome. The Idatsy token is a plain, unmodified OpenZeppelin v5.1.0 ERC-20 with no custom logic. I found no defect in the code itself. One low finding is kept, merged from the four identical specialist reports.

What I verified

• The constructor takes no arguments and mints exactly one billion tokens with 18 decimals to msg.sender, which matches the manifest's supply and empty constructor arguments.
• The three entry points (approve, transfer, transferFrom) are the upstream OpenZeppelin implementations. The vendored ERC20, IERC20, IERC20Metadata, Context and draft-IERC6093 files are byte-identical to the v5.1.0 release archive.
• The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT and is far under the size limits. There is no mint, burn, owner, pause or blacklist function.
• The project's 55 tests and its invariant suite pass. The protected floor tests could not be run here because they import the platform's Uniswap v4 harness, which is not in this tree, so I checked each of their assertions against the code by hand instead.

The kept finding (low). All four specialists reported the same root cause, which I reproduced independently. DEPENDENCIES.md says no dependency source was modified and tells reviewers to run the checksum verification, but that command fails for seven forge-std files. I downloaded the forge-std v1.9.7 archive, confirmed its hash matches the one documented, confirmed the SHA256SUMS entries are the genuine upstream hashes, and confirmed the committed files differ from upstream by whitespace only. Production bytecode is unaffected since forge-std is test-only. The fix is to restore the seven files to upstream bytes or regenerate the checksum file and correct the documentation.

Coverage. All three entry points are marked holds, with three additional rows for the supply invariant, deployability, and the manifest.