The Dog hood (DOG) token is built, tested and committed on main. The working tree is clean and no stray files remain.

What was delivered

• src/DogHoodToken.sol is a plain OpenZeppelin v5.1.0 ERC-20. The constructor takes no arguments and mints the full supply once to the deployer. There is no owner, mint, burn, pause, blocklist, fee or ether path, and the runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• foundry.toml pins solc 0.8.26, sets bytecode_hash = "none", keeps ffi off and grants no filesystem permissions.
• lib/ holds forge-std v1.9.7 and the OpenZeppelin token, interfaces and utils trees as ordinary files. No submodule or nested git metadata is present.
• test/DogHoodToken.t.sol covers metadata, supply, a CREATE2 factory deployment mirroring the launch, transfers, allowances, every standard failure path, the absence of any admin or mint function for both the deployer and a stranger, and the same opcode scan the protected floor test runs. Four fuzz tests check supply conservation and balance and allowance bounds.
• README.md documents the token values, launch assumptions, manifest-relevant fields, operational responsibilities and the fact that there are no open deployment choices and nothing to set after launch.

Verification results

Check	Result
forge build	passes, runtime 2,164 bytes
forge test with the verifier's fuzz seed	26 passed, 0 failed
forge fmt --check	passes
git status --porcelain	clean after commit

The protected floor tests could not be run here because their harness (v4-core and the floor's helpers) is not in this repository. The token matches every condition they check: the manifest supply is minted to the factory address, no transfer takes a fee, the supply cannot grow, no privileged call exists, and the bytecode has no forbidden opcodes.

Done. The manifest is written and verified, and nothing else in the tree changed.

What I wrote in launch.json:

• kind "custom_token", token contract DogHoodToken, name "Dog hood", symbol "DOG", decimals 18, empty constructorArgs, totalSupply of 1,000,000,000 tokens in minor units.
• An empty contracts list, since the accepted tree contains only the token and no application contracts.
• The launch's pool block as given: IMD pair address, fee 12500, tick spacing 60, the one-to-one initialPrice.
• The requester's economics object copied verbatim.
• Notes describing the token's behaviour and the launch flows, well under the 4,000 character limit.

Verification:

• The compiled ABI confirms the constructor takes no inputs, so the empty constructorArgs matches the accepted implementation.
• The constructor mints exactly the manifest supply to msg.sender, matching what the protected token test checks.
• forge build succeeds and all 26 tests pass under the verifier's fuzz seed.
• A script check confirmed the manifest has only the schema's keys, a lowercase pair address, and the exact economics object.
• git status shows launch.json as the only new file. No configuration or source file was touched.

The review is complete. The findings file holds an empty findings list and a coverage record of eight rows, and the working tree has no other changes.

Outcome: no defects found in the math, boundary or numerical-gap area. The token in src/DogHoodToken.sol is a 31-line wrapper over the vendored OpenZeppelin v5.1.0 ERC20, which I read in full and confirmed is the unmodified upstream implementation. The only arithmetic the token itself adds is the supply constant on line 24, which folds at compile time to exactly the manifest's one billion tokens in minor units and fits within 90 bits.

What I checked, with a scratch Foundry suite that I ran and then removed:

• Max-value inputs. Transfers of the full supply plus one and of the maximum uint256 revert on the balance check before any unchecked arithmetic runs. An allowance of max minus one is treated as finite and decrements normally. Only the exact maximum is infinite.
• Zero and self paths. Zero-value transfers from empty accounts succeed without moving anything. A self-transfer of the whole balance through transferFrom leaves the balance intact and spends the allowance. A transferFrom from the zero address reverts before any state change.
• Conservation. A fuzzed sequence of random transfers among four holders always sums to exactly the supply, and totalSupply never changes since nothing can mint or burn after construction.
• Launch share arithmetic on this supply. The ten percent swarm share and the eighty-eight percent pool share divide with zero remainder, the scaling product cannot overflow, and the sqrtPriceX96 the deployer would derive from the 2,500 IMD opening cap lies inside Uniswap v4's bounds for either currency order.
• Boundary guide call-site list. The contract makes no external calls, has no payable, receive or fallback function, no sentinel branches and no bytes decoding, so that guide's enumeration is empty.

The aderyn large-numeric-literal lead on line 24 is a style note only. The existing 26-test suite passes as shipped.

Coverage: all three listed entry points are marked holds, plus five invariant rows. Nothing in my area was left unreached.

The review is complete. The findings file is written and the scratch test is removed.

Outcome: no defects found in the assigned area. The Dog hood token is OpenZeppelin v5.1.0 ERC20 with a constructor that mints the full supply once to the deployer, and nothing else. The findings file holds one info-level note and a nine-row coverage record.

What I verified

• Access control. The compiled ABI exposes only approve, transfer, transferFrom, the ERC-20 views, five constant getters and the constructor. There is no owner, minter, initializer, proxy, receive or fallback. Internal mint and burn are unreachable from any external function, and unknown selectors revert.
• Vendored library integrity. The five OpenZeppelin files the token depends on are byte-identical to the upstream v5.1.0 tag, so the inherited transfer and allowance logic is the audited one.
• Asymmetry. The transfer and transferFrom pair both route through the same internal path with no fee or privileged branch. The only asymmetry is the standard ERC-20 allowance race in approve, reproduced with concrete numbers and recorded as info, with no code change recommended since changing approve would break pool compatibility.
• Trust gap. There is no privileged actor, settable parameter or pricing formula in the token, so none of the guide's seams is reachable.
• Static analysis leads. Slither reported nothing. The aderyn large-literal lead is a compile-time constant that tests assert equals one billion times ten to the eighteenth, so it is not a defect.
• Build and tests. Both the project suite and my scratch checks pass under forge 1.8.3 with solc 0.8.26, and formatting is clean.

Not covered. The launch flows themselves, meaning the factory, distributor and pool seeding, live outside this repository and were out of reach, though the token's lack of fees means it cannot short them.

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

Outcome: no defects found in the Dog hood token. The findings file holds two informational notes and nine coverage rows. Nothing in it opens a revision.

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

• Periphery. All five OpenZeppelin files the token inherits, including ERC20.sol and Context.sol, hash identical to upstream v5.1.0. The sender context is plain msg.sender, so caller identity is exact.
• Execution trace. Traced approve, transfer and transferFrom through the inherited internals with concrete values in a scratch test. Self-transfer, transferFrom to the sender, zero amounts, zero addresses, max allowance, approve overwrite, and the event counts all behave as ERC-20 specifies. Twelve scratch tests passed, plus the project's own 26.
• First principles. The constructor mints the whole supply once to msg.sender with no arguments and no external calls, and works through a CREATE2 factory stub. No function can grow or freeze a balance. The runtime has no DELEGATECALL, CALLCODE, SELFDESTRUCT or any call opcode. It does use PUSH0 and one MCOPY, so the chain must support Cancun, which the launch's Uniswap v4 PoolManager already requires.
• Static analysis lead. The aderyn large-literal line is the supply constant and equals the brief exactly.

Two informational notes, both with reproductions:

1. The TOKEN_DECIMALS constant drives the minted supply but decimals() is never overridden, so the two agree only by convention today. Harmless as shipped. A one-line override would bind them.
2. The inherited approve is set-not-increment, so the standard ERC-20 allowance race applies. Reproduced at 150 spent against an intended 100. This is by design and the README already warns holders.

Not reached: the protected launch suite itself, which needs v4-core and launch environment variables absent from this tree. The token has no fee or exemption logic, so its flows cannot arrive short.

The findings file is in place and is simply excluded from git by the harness's own exclude rule, so the tree is otherwise untouched. The review is complete.

Result: no defects found. The economics, invariant and flow-gap review of Dog hood (DOG) produced an empty findings list. The file .imd-findings.json holds that empty list plus eight coverage rows, all holds, covering the three listed entry points and five invariants or economic properties I checked.

What the token is. A single contract that inherits OpenZeppelin v5.1.0 ERC20 unchanged and mints the whole supply to the deployer in its constructor. It has no owner, mint, burn, pause, blocklist, fee, hook, external call, or receive function. The compiled ABI exposes thirteen selectors, all standard ERC-20 views and the three writers.

What I verified.

• The vendored OpenZeppelin files the token depends on are byte-identical to the upstream v5.1.0 npm release, so no transfer logic was altered.
• The existing 26-test suite passes. I added a scratch stateful invariant suite that ran random transfer, approve and transferFrom sequences across six actors and held sum-of-balances equal to a constant total supply of exactly 1e27 throughout. It also confirmed each launch hop arrives whole and that the 10/88/2 split has zero rounding. I ran it, saw it pass, and deleted it.
• The aderyn large-literal lead is a compile-time constant that evaluates to exactly 1e27. It is not a defect.
• The only remaining trust point is the standard ERC-20 approve race, which is inherent to the interface and listed as do-not-report in the Pashov validation rules.

Not covered. Pool, price and policy values live in the launch manifest, which this repository does not include, so I could not check them against a concrete file. The token's arithmetic is compatible with them: the pool share fits a Uniswap v4 uint128 delta.

Done. The suite passes with the verifier's fuzz seed, and I found no defect in the token, so there is no findings file.

What was there. The implementation is a thin wrapper over OpenZeppelin v5.1.0 ERC20 with no added logic. The earlier contributor's test/DogHoodToken.t.sol already covered metadata, supply, basic transfers, allowances, and the main revert paths, but had no invariant tests, which the acceptance criteria require.

What I added, both under test/ and left the existing file untouched:

• test/DogHoodToken.invariant.t.sol holds a handler that drives six actors through transfer, approve and transferFrom with bounded inputs, plus failure paths that must revert: transfers above balance, transferFrom above allowance, transfers to the zero address, sixteen privileged signatures tried from every actor including the deployer, and ether sent to the token. Every handler path is non-reverting by construction, so the run uses fail-on-revert = true. Invariants check that supply never changes, balances sum to supply, each balance equals its ghost net flow, inflows equal outflows, every allowance equals what was approved less what was spent, and the token holds no ether. Two unit tests ground the harness by driving every handler path directly and checking the ghost counters.
• test/DogHoodToken.edges.t.sol covers the corners the first file did not reach: approve overwrites rather than adds, self-approval and self-spend, the zero-address owner and spender paths with their exact error selectors, allowance checked before balance, transferFrom to zero not spending allowance, event counts on transferFrom and zero transfers, empty and truncated calldata, deployment from inside another contract's constructor, and fuzzed round-trip, multi-hop, split, allowance-decrement and atomicity properties using bound so no run is discarded.

Verification. Results with the verifier seed:

Suite	Tests	Result
DogHoodToken.t.sol	26	pass
DogHoodToken.edges.t.sol	37	pass
DogHoodToken.invariant.t.sol	3	pass, 8192 handler calls, 0 reverts

To confirm the invariants are not vacuous, I ran the same handler against a scratch 1% burn-on-transfer mutant and it failed on the first sequence. The scratch file was removed. forge fmt --check passes and git status shows only the two new test files.

The review is complete and .imd-findings.json is written. The tree is otherwise unchanged.

Outcome: no defects. The token is a 31-line fixed-supply ERC-20 on the unmodified OpenZeppelin v5.1.0 base, and every entry point and launch-floor property holds.

What I verified

• The five vendored OpenZeppelin files the token depends on match upstream v5.1.0 byte for byte by sha256.
• The constructor takes no arguments and mints exactly 1e27 to the deployer. CREATE2 deployment is deterministic and creation and runtime sizes are far under the protocol limits.
• The three entry points approve, transfer and transferFrom behave as plain ERC-20 on every success and revert path. There is no mint, burn, owner, pause, blocklist, receive or fallback, and the runtime has no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The manifest in launch.json agrees with the code on contract name, metadata, decimals, supply and empty constructor arguments.
• The repository's 66 tests pass, and my scratch test of all of the above passed before I removed it.

Specialist findings

• The two approve-race reports from audit_flow and audit_permissions share one root cause, so I merged them into one info finding and reproduced it. It is standard ERC-20 behaviour and a holder trust assumption, not a defect.
• The TOKEN_DECIMALS coupling report from audit_flow reproduces as described. It has no failing input on the current code, so it is kept as info only.
• Slither reported nothing. Aderyn's large-literal line is the 1e27 supply constant, which is correct.

Coverage: all three entry points answered holds, plus three invariant rows. No finding is critical or high, so no proof file was attached.