Implemented Drift Pebble (DPBL): 1,000,000,000 tokens, 18 decimals, minted once to the deployer. Includes vendored dependencies, success/failure tests, fuzz tests, invariants, and deployment documentation.

Verified with Solidity 0.8.26:

• forge build passed.
• forge test passed: 33 tests.
• forge fmt --check passed.

Offline verification with an empty environment also passed.

Created launch.json matching DriftPebble’s constructor, supply, and required pool/economics values.

Manifest consistency checks passed. forge build succeeded; forge test passed all 33 tests. Only launch.json changed outside permitted scratch artifacts.

The findings file is in place at the repository root and is deliberately excluded from git by the harness's own exclude list, so the working tree stays clean. The review is complete.

Result: no defects found in the assigned area. The review covered the Economic Security, Invariant and Flow Gap guides against src/DriftPebble.sol, and every entry point holds.

What I verified:

• Source is minimal. The token is an unmodified OpenZeppelin v5.4.0 ERC-20 plus a constructor that mints the fixed supply to the caller. I downloaded the upstream v5.4.0 archive and confirmed its hash matches the one recorded in the dependency notes, and all five vendored files are byte-identical to upstream.
• Supply and mint. The constant equals the stated supply exactly, is minted once to msg.sender under CREATE2 so the factory holds it all, and nothing else can mint or burn. This also closes the aderyn large-literal lead.
• Conservation invariant. I fuzzed transfers to arbitrary addresses, including the token itself and the factory, and the sum of balances always equals total supply.
• Flow exactness. Round trips through distributor and pool-custody addresses return the exact amount, and the direct transfer path and the allowance path produce identical end states. With no fee, tax, exemption, callback or external dependency, the launch flows and swaps cannot arrive short.
• Allowance accounting. Finite allowances cannot be over-spent, failed transfers roll back allowance and balance together, and no privileged address bypasses allowance checks.
• Privileged surfaces. No owner, pause, freeze, seize, upgrade or forbidden opcodes exist. The project's own 33 tests also pass.

The report lists seven coverage rows: one per entry point, plus the constructor, the supply invariant, launch flows and the privileged-hand checks. The scratch probe tests were deleted after running, and no repository file was changed.

The review is complete. No defects were found in the Access Control, Trust Gap and Asymmetry area, and the findings file records an empty list with seven coverage rows.

What was reviewed

• src/DriftPebble.sol is a 17-line constructor-only specialization of OpenZeppelin's ERC20. It mints 10^27 units once to msg.sender and adds no roles, modifiers, initializer, owner, hooks or fallback.
• The five vendored OpenZeppelin files were fetched from the upstream v5.4.0 tag and compared byte for byte. All are identical, so no backdoor entered through the dependency.
• The compiled ABI exposes only the nine ERC-20 functions plus the supply constant. An independent opcode scan of the runtime bytecode found no CALL, DELEGATECALL, CALLCODE, STATICCALL, CREATE or SELFDESTRUCT.
• The project's own 33 tests pass, and the project files pass the formatter check.

Checks run for the three guides

• Access control: every state-changing entry point is scoped to msg.sender or to an explicit allowance. A scratch fuzz test over 512 unknown selectors reverted from both the factory and a stranger with no state change, and 512 fuzzed callers without allowance could not move a holder's balance.
• Asymmetry: transfer and transferFrom write the same balance slots in the same direction and differ only by the allowance decrement. There is no admin variant, no exemption branch and no privileged path that treats the factory, distributor or PoolManager differently from a holder.
• Trust gap: there is no privileged actor at all, so none of the four seams exist. The only asymmetric party is the factory as initial holder of the full supply, which is the launch design rather than a defect.

Leads not promoted

• The aderyn large-numeric-literal line is the supply constant. It evaluates to exactly 10^27, matching the manifest supply in the README.
• The standard ERC-20 approve replacement race exists as in every OpenZeppelin token. It is inherent to the standard, documented in the README, and not a defect in this contract.

The scratch test lives under test/scratch/, which is gitignored and not kept. No tracked file was changed.

The findings file is on disk, excluded from git by the harness's own rule, and no tracked file changed. The review is complete.

Result: no defects found in Drift Pebble. The report at .imd-findings.json holds an empty finding list and ten coverage rows, one for each of the three listed entry points plus the constructor, the periphery, the runtime bytecode and the launch invariants.

What I covered, by guide:

• Execution Trace. Traced approve, transfer and transferFrom through OpenZeppelin's _approve, _transfer, _update and _spendAllowance. Every failure path reverts atomically. The only sentinel paths are address(0) rejection and the infinite uint256.max allowance, both standard and documented in the README. A transferFrom with a zero sender reverts inside the allowance step, so there is no mint route.
• Periphery. The only base code is the vendored OpenZeppelin ERC20 closure. I downloaded the v5.4.0 archive, confirmed its hash matches DEPENDENCIES.md, and compared all six vendored files byte for byte. They are identical to upstream. No libraries, assembly or storage-context hazards exist.
• First Principles. The constructor mints exactly 10^27 once to msg.sender with no arguments or immutables, so a CREATE2 deployment from the factory leaves the whole supply at the factory. Decimals are 18. No owner, pause, blocklist, burn or mint entry point exists, and the token has no receive or fallback.

Checks run. The project's 33 tests pass and forge fmt --check is clean. My scratch tests confirmed the zero-sender path, self-transfer with infinite allowance, exact 10% and 90% custody flows with swap-shaped round trips, CREATE2 deployment from a probe, and an opcode scan showing no DELEGATECALL, CALLCODE, SELFDESTRUCT, external calls or PUSH0 in the runtime. The scratch directory was removed afterwards.

Leads dismissed. The aderyn large-numeric-literal note is a style remark on a compile-time constant that equals the manifest supply. Slither reported nothing. The standard ERC-20 approve race is inherent to the specification and is documented in the README, so it is not reported as a defect.

Not reached. I could not run the protected Uniswap v4 harness because its factory libraries and v4-core are not in this tree. The custody and swap-shaped flows were verified with plain transfers instead, which is sufficient for a token with no fee, exemption or callback logic.

The review is complete. The findings file is written, validated, and the working tree holds only that deliverable.

Outcome: no math, boundary, or numerical-gap defect in Drift Pebble. One info-level provenance discrepancy is reported.

What I checked in the assigned area

• Math Precision. The contract's only arithmetic is the compile-time constant for one billion tokens at 18 decimals. It equals exactly 10^27, matching the manifest supply, and is minted once in the constructor. The inherited OpenZeppelin paths guard every unchecked subtraction with the bound they rely on. There is no division, rounding, downcast, or decimal mixing anywhere.
• Boundary. No external calls, no payable function, no receive or fallback, no bytes decoding. Native value and unknown selectors revert. I walked every zero-address sentinel on all three entry points, plus max-uint amounts, the infinite-allowance sentinel against max minus one, and self-transfers through the unchecked block. A scratch probe of 15 tests passed, then was removed.
• Numerical Gap. The 10 percent and 90 percent launch split divides 10^27 with no residue. The 2,500 IMD opening cap puts the pool tick near plus or minus 129,000 whichever way the pair sorts, well inside Uniswap v4's range. The pool share fits in the int128 and uint128 types the pool uses.

Provenance check. The vendored OpenZeppelin v5.4.0 files are byte-identical to the upstream archive, so the arithmetic the token inherits is exactly upstream's. Seven forge-std files differ from the archive by whitespace-only reformatting, which contradicts the "unmodified" claim in the dependency notes. That is the single reported finding, severity info, with the file hashes as reproduction. It is test-only and does not touch the deployed bytecode.

Coverage. All three entry points are recorded as holds, with six additional invariant and dependency rows. The existing suite of 33 tests, including the 128-run stateful invariants, passes.

Added failure-path and boundary tests, strengthened stateful invariants, and corrected administrative call probes. All changes are under test/.

Offline forge build and forge test pass: 49 tests, including 8,000 fuzz cases and 32,768 invariant calls.

No implementation defects found.

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

Outcome: The Drift Pebble token is sound. It is an unmodified OpenZeppelin v5.4.0 ERC-20 with a parameterless constructor that mints the full supply to the deployer. I kept one informational finding and found nothing new.

Specialist findings settled

• audit_math (info) kept. I downloaded the forge-std v1.9.7 archive, confirmed its checksum matches the one recorded in DEPENDENCIES.md, and compared file by file. Seven of thirty vendored files differ from upstream, and all seven are identical once whitespace is stripped. The provenance line at DEPENDENCIES.md:11 is therefore inaccurate. The token's bytecode is unaffected since forge-std is test-only.
• OpenZeppelin provenance verified. All six vendored OpenZeppelin files are byte-identical to the v5.4.0 archive, so the inherited transfer, approve and transferFrom logic is exactly the audited upstream code.
• The economics, permissions and flow specialists and the independent tester reported nothing, so there were no duplicates to merge.

My own pass

• All three entry points hold. They are the stock OpenZeppelin implementations with the standard revert paths on zero addresses, insufficient balance and insufficient allowance.
• The ABI exposes no mint, burn, owner, pause or blacklist function.
• The runtime contains no DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The manifest is consistent with the code: empty constructor arguments, 18 decimals, and a total supply equal to what the constructor mints.
• Bytecode sizes are far under the factory's limits.
• The existing test suite of 49 tests passes, including fuzz and invariant runs.
• Both static-analysis leads were checked. Slither reported nothing, and aderyn's large-literal note concerns a readable 1_000_000_000 * 10 ** 18 constant that equals the manifest supply.

Deliverable: .imd-findings.json holds the one info finding with its reproduction, plus coverage rows for all three entry points and three additional invariants. No source or configuration files were changed.