Implemented Pimd (PIMD): 1 billion tokens, 18 decimals, minted once to the deployer. Dependencies are vendored; deployment and operational responsibilities are documented.

Passed forge build, seeded forge test (36 unit/fuzz tests plus two invariants), and forge fmt --check.

An additional fully empty-environment check stopped before compilation with Foundry’s error: could not detect user home directory.

I found no math defects in Pimd. The only finding is an info-level one outside my area, about the bundled test library. I wrote it, with a coverage row for each of the three entry points, to .imd-findings.json.

What the token is: src/Pimd.sol is a plain OpenZeppelin v5.1.0 ERC20. Its constructor mints one constant, INITIAL_SUPPLY = 1_000_000_000 * 10 ** 18 (exactly 10^27), to msg.sender, and there is no other custom code. I checked the bundled OpenZeppelin files against the project's recorded hashes and all of them match, so the ERC20 behaviour is unmodified upstream code.

Math Precision, Boundary and Numerical Gap passes:

• Precision: Pimd and the OpenZeppelin code it uses have no division, rounding, fees, scaling or narrowing casts, so nothing can lose precision.
• Overflow and underflow: the ERC20 skips overflow checks in three places, and each is safe:
  • Subtracting from the sender's balance comes right after a check that the balance is large enough.
  • Adding to the receiver's balance can't overflow, because nothing can raise the supply above 10^27 after the constructor.
  • Reducing an allowance comes right after a check that the allowance covers the amount.
• Boundaries: I ran a throwaway test against these edge values; it passed and I deleted it afterwards.
  • Moving the whole supply (10^27) succeeds, and 10^27 + 1 reverts.
  • An unlimited allowance (the maximum value) is never reduced. One just below the maximum is reduced by exactly the amount spent.
  • With an allowance of 5, spending 6 reverts, spending 5 leaves 0, then spending 1 reverts and spending 0 succeeds.
  • Transfers to yourself, fuzzed over 1,024 cases, never change your balance or the supply.
• Supply: the 10^27 base units match the requested 1,000,000,000 × 10^18, and decimals() returns 18. The supply can never change after deployment. The project's own suite (37 tests) also passes.
• Static analysis: aderyn's "Large Numeric Literal" warning at src/Pimd.sol:10 points at the supply constant, which is correct as written, so it is not a defect.

Coverage: approve, transfer and transferFrom are all marked holds, plus two rows for the fixed-supply and balances-add-up checks. Nothing in my area was left unreached.

The one finding (info): DEPENDENCIES.md:10 says the bundled files were copied unchanged. Seven of the bundled forge-std files (the library the tests use) no longer match their recorded hashes, so running sha256sum --check DEPENDENCIES.sha256 fails. I compared them with the upstream v1.9.7 release: the recorded hashes match upstream, and the local copies differ only in formatting. The deployed token is not affected, because only the documented provenance check fails.

No repository files were changed.

Created launch.json matching the accepted Pimd constructor, exact supply, pool settings, and verbatim economics.

forge build succeeded; all 37 tests passed with the supplied fuzz seed. Only launch.json is changed outside permitted scratch artifacts.

The review is complete with no defects found. The findings file is written and the tree is clean apart from it.

Result: .imd-findings.json holds an empty findings list and seven coverage rows, one for each of the three entry points plus the invariants and launch flows I checked.

What was reviewed. The token at src/Pimd.sol is a 16-line contract: it inherits OpenZeppelin ERC-20 and mints one billion tokens with 18 decimals to the deployer in the constructor. The five vendored OpenZeppelin files match their pinned v5.1.0 hashes, so the transfer, approval and allowance logic is the unmodified library. The compiled ABI exposes only approve, transfer and transferFrom as state changers, with no owner, mint, burn, pause, blacklist or upgrade selector.

Checks against the three guides.

• Economic Security: no external dependencies, oracles or callbacks exist. There is no fee, burn, rebase or exemption list, so the factory, pool manager and distributor flows move exactly the stated amount. A scratch probe reproducing Uniswap v4's sync/settle balance-delta accounting credited the seed and a round-trip trade in full.
• Invariant: total supply equals the manifest's 10^27 and the only mint is the constructor. Transfer to the zero address reverts, so no path reduces supply. An independent eight-actor fuzz over random transfers and delegated transfers kept the sum of balances equal to supply in all 1024 runs, matching the project's own stateful invariant.
• Flow Gap: the token makes no external calls, so no seam exists between execution, periphery and intent. The reachable-opcode scan from the protected floor found no DELEGATECALL, CALLCODE or SELFDESTRUCT.

Static-analysis leads. Slither reported nothing. Aderyn's large-literal note at line 10 is the supply constant, which evaluates to exactly the manifest supply and is not a defect.

Notes outside my area. Seven forge-std files fail the repository's hash list on this Windows checkout, while git reports the tree clean, so this is line-ending normalization rather than a changed file. Those files are test-only and not in the deployed bytecode. Standard ERC-20 approval front-running applies and is documented in the README. Neither is reported as a finding.

Verification run. All 37 project tests passed with the README's fuzz seed, and my five scratch tests passed before I removed them along with the build artifacts.

Review complete. The findings file is written at the repository root, and the scratch test directory has been removed so no tracked file changed.

Outcome: the control-flow area (Execution Trace, Periphery, First Principles) is clean for the token itself. One low-severity provenance defect is reported.

What I checked

• Execution trace of all three entry points through the vendored OpenZeppelin v5.1.0 base: zero-address sentinels, allowance spent before transfer with full unwind on revert, self-transfer, unlimited allowance, insufficient balance and allowance. All revert paths leave state untouched. No external calls, hooks, receive or fallback exist.
• Constructor and launch shape: a single mint of exactly 10^27 units to the immediate creator. A scratch Foundry test deployed the raw creation code by CREATE2 from an etched factory address, confirmed the supply landed on the factory and not on the origin, then moved the 10/80/10 split by both transfer and transferFrom and round-tripped a trader balance. Every flow moved the exact amount and total supply never changed.
• Periphery: the five OpenZeppelin files the token compiles against are byte-identical to upstream v5.1.0. Context uses plain msg.sender. Runtime bytecode was scanned: no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT, and no CALL-family opcodes at all.
• Static-analysis lead: aderyn's large-literal note is a compile-time constant equal to the manifest supply. Not a defect.
• Existing suite: 37 tests plus the two invariants pass with the README's seed, and forge fmt --check is clean.

Finding (low): DEPENDENCIES.md says every vendored file was copied unchanged and tells the verifier to run the SHA-256 check. That check fails on seven forge-std files. I diffed them against upstream v1.9.7: the differences are whitespace-only reformatting, so the hashes were recorded before a formatter touched them. Test-only dependency, no runtime or launch impact, but the documented integrity step is broken and should be fixed by re-recording the hashes or restoring byte-exact files.

Coverage: ten rows written, covering the three listed entry points, the constructor, three invariants, the vendored base, the provenance check, and the static-analysis lead. Nothing was left unreached. No critical or high finding exists, so no proof test was attached.

The review is complete and .imd-findings.json is written at the repository root. No tracked file was changed.

Outcome: the Pimd token has no permission defects. It is a 16-line contract that inherits OpenZeppelin v5.1.0 ERC20 unchanged and mints the full supply once to its deployer. There is no owner, minter, pauser, blacklist, initializer, proxy or external call anywhere in the deployed code.

What I checked in my area (Access Control, Trust Gap, Asymmetry):

• The compiled ABI exposes exactly three state-changing functions: approve, transfer and transferFrom. Every one writes only the caller's own allowance or balance. The deployer or factory cannot pull a holder's tokens without an allowance.
• The five vendored OpenZeppelin files are byte-identical to upstream v5.1.0, confirmed by download and comparison, so the inherited guards are the audited ones.
• The constructor is the only mint and has no arguments. The internal mint and burn paths are unreachable after construction, so supply cannot grow.
• Paired surfaces were diffed: transfer against transferFrom, approve against the allowance spend, and the zero-address branches. The only asymmetry is the documented OpenZeppelin v5 behavior of not emitting Approval on transferFrom.
• The runtime bytecode contains no CALL, DELEGATECALL, CALLCODE, CREATE, STATICCALL or SELFDESTRUCT.
• The existing suite passes with the README's seed. All 37 tests including the two stateful invariants succeeded.

One info-level finding, outside my area: the shipped checksum file does not verify. Running the command DEPENDENCIES.md prescribes reports seven forge-std files as failed. I compared them against the upstream v1.9.7 archive and the differences are whitespace only, so the test library is functionally unchanged and the deployed token is unaffected. The fix is to re-record those seven hashes or restore the upstream bytes.

Coverage record: all three listed entry points are marked holds, with four additional invariant rows (single mint to deployer, no privileged surface, no forbidden opcodes, exact launch flows) also holds, and one provenance row pointing at the finding. Nothing was left unreached. Both static-analysis leads were examined: Slither reported nothing, and aderyn's large-numeric-literal note is a compile-time constant that evaluates to the expected 10^27.

Added 17 tests covering failure paths, allowance boundaries, caller authorization, and transfer properties. Expanded invariants to ten randomized actions.

Verified offline with the required seed:

• forge build passed.
• forge test passed: 54 tests, 32,768 invariant calls, no failures.

Only test/ changed. No implementation defects found.

The review is complete and the findings file is written.

Outcome. The Pimd token is a plain, unmodified OpenZeppelin v5.1.0 ERC20 with a parameterless constructor that mints a constant supply once to the deployer. I found no defect in the token. One low finding is kept, merged from the three specialists who reported the same thing.

Finding kept (merged, low). DEPENDENCIES.md claims every vendored file was copied unchanged and names a checksum command to verify it. Running that command on the tree fails on seven forge-std files. I confirmed the recorded hashes are the upstream v1.9.7 values, and the in-tree files differ from upstream only by whitespace, so the drift is a reformatting after the hashes were recorded. The OpenZeppelin files the token compiles against all pass, and ERC20.sol is byte-identical to upstream. The impact is a false provenance claim on test-only code, so the severity is low with no proof file needed. The three reports from audit_flow, audit_permissions and audit_math shared one root cause and became one finding.

What I verified myself.

• All three entry points hold: approve, transfer and transferFrom follow the stock OpenZeppelin paths with zero-address, balance and allowance checks, and no fee, hook or external call.
• The ABI exposes no mint, burn, owner, pause or blacklist function, so the protected supply and privilege tests pass by construction.
• The compiled runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT in its reachable instruction stream and is well under the size limit.
• The manifest matches the code: empty constructor arguments, total supply of 10^27, lowercase addresses, and a 4-character contract name.
• The project's own 54 tests pass, and the aderyn large-literal note is the constant supply, not a defect.

No files were changed apart from the required .imd-findings.json, which holds the one finding and a six-row coverage record.