Implemented IMDog with 1 billion tokens, 18 decimals, minted once to the deployer. Immutable metadata uses the exact IPFS logo; original image bytes are preserved.

Validation passed: forge build, all 35 reported tests, forge fmt --check, and clean offline verification.

Launch documentation covers deployment parameters and responsibilities. No transactions were broadcast; deployment and external logo registration remain IdentityMD’s launch steps.

Created launch.json matching the accepted IMDog constructor, supply, exact economics, pool settings, and existing IPFS logo linkage.

forge build succeeded; forge test passed all 35 tests. Only launch.json is changed for submission.

The review is complete and .imd-findings.json holds the result. Git status is clean apart from the findings file and my scratch test, which are not part of the tree.

Math area verdict: no defects. IMDog is the vendored OpenZeppelin 5.0.2 ERC20 plus a constructor mint and two pure metadata views. There is no division, scaling, fee, cast, or decimal conversion anywhere in the token, so the Math Precision, Boundary and Numerical Gap failure modes have no formulas to attach to. What I traced and tested instead:

• Inherited arithmetic. The balance subtraction is guarded before its unchecked block, and the unchecked addition is bounded by a fixed total supply of 1e27 with no mint path after construction. Allowance spending keeps the max sentinel and decrements max minus one correctly.
• Supply constant. The large literal flagged by aderyn is an exact compile-time value below 2^96. It is minted once to the factory and cannot grow.
• Launch split. A scratch test confirmed the 10 percent swarm share and every poolBps value from 0 to 10000 divide 1e27 with zero truncation, so the distributor, pool and remainder flows arrive whole.
• Boundaries. No receive, fallback, payable, external call, bytes decoding or sentinel branch exists. Base64 output round-trips against Foundry's encoder with correct padding.
• Existing suite. All 35 tests and the invariant run pass on the committed configuration.

One low finding outside my area. The validation doc at docs/VALIDATION.md:15 claims the vendored checksum file verifies, but running it fails on 8 of 37 files, including the production Base64 library. I downloaded both upstream tags and confirmed the archives match the recorded archive hashes and every mismatched file is byte-identical to upstream once whitespace is stripped. The files were reformatted after the hashes were recorded. Behavior is unchanged, but the documented integrity gate is false and would hide a real modification. The fix is to re-vendor verbatim or regenerate the checksum file and correct the doc.

Coverage has nine rows: all three ABI entry points hold, five invariants hold, and the provenance record carries the finding.

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

Outcome: one low-severity finding, no defects in the token's execution flow.

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

• Entry points. The three ABI entry points are OpenZeppelin v5.0.2 ERC20 code, and the vendored ERC20, IERC20, IERC20Metadata, Context and IERC6093 files are byte-identical to the upstream tag. Transfer and transferFrom debit and credit in one step with no external call, revert on the zero address and on insufficient balance or allowance, and a failed transfer restores the allowance. No sentinel bypass, stale read, partial update or approval residual exists.
• Constructor and supply. Mints exactly one billion tokens with 18 decimals to the deployer, with no constructor arguments and no post-deployment mint, burn, owner, pause or metadata setter in the ABI. Runtime is well under the size limit and contains no banned opcodes.
• Logo linkage. The on-chain constant equals the brief's IPFS URI. I fetched the brief's gateway URL and the bytes match the committed logo copy exactly.
• Periphery. The Base64 library is the v5.0.2 version with the dirty-memory fix and the tests cross-check its output against Foundry's own encoder.
• Tests. The full suite passes offline, and again with a second fuzz seed and more runs, as the verifier will run it.

The finding (low): the tree ships a per-file hash record for vendored dependencies and the validation document claims all 37 files matched, but on the committed tree the check fails for 8 files, including the production Base64 library. The cause is formatting: the formatter re-wrapped those files after the hashes were recorded. Stripping whitespace, every file equals its upstream tag, so no behaviour changed, but the provenance evidence the deliverable documents is false and the README's build step fails. The reproduction and the regeneration fix are in the findings file.

Coverage: all three listed entry points hold, plus rows for the constructor, the metadata views, three invariants, and the one periphery finding.

Review complete. The findings file is written at .imd-findings.json and nothing else in the tree was changed.

Result for the assigned area (Access Control, Trust Gap, Asymmetry): no defects. IMDog is the vendored OpenZeppelin v5.0.2 ERC20, which I confirmed byte-identical to upstream, with a single constructor mint of the full supply to the caller and two pure metadata readers. The ABI exposes exactly the three state-changing entry points the verifier listed. There are no roles, setters, hooks, receive or fallback, so there is no permission model to break, no admin variant of any user function, and no formula whose outcome differs by caller class. The only trust assumption is that the constructor caller, the factory, holds the whole supply at deployment, which is the launch design. The deployer cannot pull from a holder without an allowance, so the protected "privileged hand" probe passes.

One substantiated defect outside the area, reported as low:

• The committed dependency checksum file is stale. Running the documented integrity check fails on 8 of 37 vendored files, while the README, the lib README and the validation doc all claim it passes. I diffed every mismatching file against the upstream tags. The differences are formatting only, of the kind the Solidity formatter produces, and the production ERC20 sources are unchanged. The impact is a false provenance claim that an offline verifier cannot distinguish from tampering, not a behavior change.

Also verified while there: the logo URI is embedded as a constant with no setter, the metadata file matches, and the named gateway served bytes identical to the archived logo. The existing 35 tests and the formatter check pass. The static-analysis lead about the large numeric literal is a compile-time constant equal to the manifest supply and is not a defect.

Coverage: all three entry points are marked holds with traced reasons, plus rows for the constructor and role inventory, logo linkage, dependency integrity (finding 1) and the static-analysis lead. One row is marked unreached: the real Uniswap v4 seed and swap and the distributor claim, which depend on launch infrastructure not in this tree.

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

Outcome: the token's economics, invariants and launch flows hold. One low-severity deliverable defect was found, in the dependency provenance check, not in the contract.

What I checked in my area

• Economic Security: the token has no external dependency, oracle, fee, burn, hook or callback. Transfers to a reverting contract succeed without calling it. Infinite and finite allowances behave per ERC-20. Unknown selectors and plain ETH sends revert.
• Invariants: supply is minted once in the constructor to the caller and nothing in the ABI can grow it. Sum of balances equals total supply after the 10 percent, pool share and remainder split, fuzzed over pool shares and claim sizes. The split arithmetic divides exactly with no dust.
• Flow Gap: the Uniswap v4 pool manager settles on balance deltas, and this token's balances are exact, so seed and swaps in both currency orderings move what they say. The protected suite could not run here because it needs the launch system's own contracts and environment, so that seam is traced from source rather than executed.
• Metadata: contractURI decodes to metadataJSON, and the image is the exact IPFS URI from the job.

Commands run and results

forge build                       compiled, solc 0.8.26
forge test                        35 passed, 0 failed (repo suite)
forge test --match-path test/scratch/EconReview.t.sol   5 passed (my scratch checks, not kept)
slither src/IMDog.sol             0 results
aderyn                            1 low: large numeric literal, style only
sha256sum --check lib/SHA256SUMS  FAILED for 8 files

The finding (low): the validation document claims all 37 vendored files match the checksum manifest, and the README tells operators to run that check. On the committed tree it fails for 8 files, including the production dependency Base64.sol. I diffed every vendored OpenZeppelin file against the upstream v5.0.2 tag and the forge-std files against v1.9.7. All differences are whitespace from a later forge fmt pass. Compiled behavior is unchanged, but the provenance check the project relies on reports tampering, so an operator cannot tell this benign reformat from a real edit.

Dropped lead: the README's pool and economics values match the reference example byte for byte. The reference states those pool and economics values are this launch's own, so I did not report it.

Coverage: all three entry points are marked holds, plus six invariant and flow rows, in .imd-findings.json.

Added 16 adversarial/fuzz tests and strengthened balance, allowance, and supply invariants. All changes stay within test/.

Verification passed offline: 51 tests, 16,384 invariant calls, zero failures. No reproducible defects found.

Protected launch integration remains untested locally because its infrastructure is absent; this limitation is documented in test/README.md.

The review is complete and .imd-findings.json is written at the repository root. No source files were changed.

Outcome: the IMDog token is sound. It is the unmodified OpenZeppelin v5.0.2 ERC-20 with a no-argument constructor that mints the manifest's full supply to the factory, plus two pure metadata getters carrying the requester's exact IPFS URI. The only substantiated defect is a provenance record that does not hold.

Findings reported

• Low, merged from all four specialists: the documented integrity check sha256sum -c lib/SHA256SUMS fails for 8 of 37 vendored files, including the production dependency Base64.sol. I reproduced it on the clean tree and fetched upstream v5.0.2 Base64.sol to confirm the recorded digest is upstream's and the committed copy differs only by a collapsed assembly for-loop header. ERC20.sol and its interfaces are byte-identical to upstream, so compiled behaviour is unaffected. The four reports shared one root cause and became one finding.
• Info: docs/VALIDATION.md still records 35 test cases, but the tester's accepted commit raised the suite to 51 passing tests.

What I verified myself

• Build and the full suite pass offline, with 51 tests and the invariant group green.
• The compiled ABI exposes only approve, transfer and transferFrom as state-changing. The runtime holds no DELEGATECALL, CALLCODE or SELFDESTRUCT, has no link references, and is well under the size limits.
• The manifest matches the code: empty constructor arguments, supply of exactly one billion tokens in minor units, 18 decimals, lowercase addresses, schema-only keys, pool and economics equal to the launch's own values.
• The metadata checker passes and the logo bytes and IPFS URI are unchanged.
• The static-analysis lead about a large numeric literal is the supply constant and matches the manifest, so it was dropped.

Coverage record: all three entry points answered as holds, with additional rows for the supply, privilege, opcode, metadata and manifest invariants, and one row pointing the specialists' reports at finding 1.