Implemented PABOXO.sol: 1 billion tokens, 18 decimals, minted once entirely to the deployer. Dependencies are vendored, and deployment responsibilities are documented.

Verified with Solidity 0.8.26:

• forge build passes, including offline rebuild.
• All 33 local tests pass with the requested fuzz seed.
• forge fmt --check passes.

The external protected launch harness remains for the verifier.

I found no defects in PABOXO's permissions. The findings list in .imd-findings.json is empty, and its coverage record has a "holds" row for each of the three entry points, plus three for invariants I checked.

Why there's nothing to report: src/PABOXO.sol is OpenZeppelin's standard ERC20 (v5.1.0) and nothing more. Its constructor mints the 1,000,000,000 × 10^18 supply once, to whoever deploys it, which in the launch is the factory. It has:

• no owner or roles, and no initializer;
• no way to mint, burn, pause, blacklist, set fees or exempt anyone after deployment.

So none of the three guides finds anything to work on:

• Access Control: the only storage written after deployment is balances and allowances. transfer and approve touch only the caller's own entries, and transferFrom spends the allowance before it moves anything. There's no route to raise your own privileges, no initializer to call first, and no contract acting on someone else's behalf.
• Asymmetry: the only paired actions are approve and spending an allowance, and transfer against transferFrom. Each pair updates state the same way. The one deliberate difference is that a maximum allowance never runs down, which is how the upstream library works.
• Trust Gap: with no privileged actor and no fee or exemption logic, there's no point where who may call combines with who profits or who is treated differently.

What I checked:

• The library files in lib/ match their recorded checksums (all 5 .sol files), and I read the transfer, allowance and supply code myself.
• The project builds, and all 33 existing tests pass.
• The aderyn "Large Numeric Literal" warning at src/PABOXO.sol:12 (1_000_000_000 * 10 ** 18) is about style. The value is correct, so it isn't a defect.

Limits: I didn't run the protected launch tests in .imd/reads/protected/, because they import src/LaunchLiquidity.sol and other files this tree doesn't have. The project's own launch test, which covers the factory, distributor and pool transfers, passed. I changed no repository files; the findings file doesn't show as a change in git status.

Created launch.json matching PABOXO’s constructor, supply, pool settings, and exact economics.

Manifest and ABI checks passed. forge build and all 33 local tests passed with the supplied fuzz seed, using a temporary Solidity 0.8.26 wrapper.

Only launch.json is delivered.

The review is complete. The findings file is valid JSON, the snippet matches the tree, and no tracked file was changed. The scratch test lives under the gitignored test/scratch/ directory.

Outcome: the math holds. PABOXO is a stock OpenZeppelin v5.1.0 ERC20 with one constructor mint and nothing else, so the Math Precision, Boundary and Numerical Gap guides find no reachable failure mode. I reported one info-level provenance discrepancy outside my area.

What I checked in the assigned area

• Supply literal. The constant is evaluated exactly at compile time to 1e27. It fits uint128, so pool liquidity and v4 balance deltas cannot saturate, and every basis-point share of it divides without truncation.
• Transfer arithmetic. The unchecked subtraction is guarded by an explicit balance comparison, and the receiver's add is bounded by total supply. Scratch probes covered 0, 1 wei, whole supply, supply plus one, max uint, and 1000 dust transfers. All conserve supply exactly.
• Allowance arithmetic. The unchecked decrement is guarded by an allowance comparison. Only the exact max sentinel is treated as infinite. Allowance equal to balance, max minus one, and whole-supply spend under infinite approval all behave as specified, and a failed transfer rolls the allowance back.
• Boundaries and seams. The contract makes no external calls, has no payable, receive, fallback, sentinel branch, division, or bytes decoding, so the Boundary and Numerical Gap checklists have nothing to attach to. Zero-amount paths run the full update rather than an early return.
• Bytecode. An opcode scan of the runtime code outside PUSH data found no DELEGATECALL, CALLCODE, SELFDESTRUCT or CREATE.
• Dependency integrity. The five vendored OpenZeppelin files match the upstream v5.1.0 commit byte for byte.

One info finding, outside the area. The dependency note states all vendored files are unmodified and lists checksums. Fifteen forge-std files fail that checksum list because they were reformatted. With whitespace stripped they are identical to upstream, and forge-std is test-only, so no on-chain behavior is affected.

Coverage. All three ABI entry points are marked holds, with four additional rows for the supply, decimals, boundary and seam invariants. Nothing was left unreached. The existing suite of 33 tests and the invariant run of 8192 calls both pass on the current tree.

Review complete. The findings file is written, validated against the tree, and the working tree is otherwise untouched.

Outcome: the PABOXO token holds under the Execution Trace, Periphery and First Principles guides. I found no defect in the token or its on-chain behavior. One low-severity provenance finding is recorded.

What I checked

• Token source (src/PABOXO.sol): a 17-line contract inheriting OpenZeppelin ERC20 with a single constructor mint of 1e27 to msg.sender. No constructor arguments, no owner, no hooks, no receive or fallback.
• Execution traces: transfer, approve and transferFrom traced through the OpenZeppelin internals. Zero-address sender and receiver, zero amounts, self-transfers, allowance at max and max minus one, and reverts rolling back allowance all behave as intended. A scratch test confirmed the edge paths and was deleted afterwards.
• Periphery: all six vendored OpenZeppelin files verify against their checksums and are byte-identical to upstream v5.1.0.
• Bytecode: the compiled runtime contains no CALL, DELEGATECALL, CALLCODE, STATICCALL or SELFDESTRUCT opcodes anywhere. The ABI exposes only the ERC20 surface plus the supply constant.
• Launch floor: with no fee or exemption logic, the swarm share, pool seed and trader swaps cannot arrive short. The delivered 33-test suite passes with the README's seed. The static-analysis lead about a large literal is a benign compile-time constant.

The one finding (low): DEPENDENCIES.md claims every vendored file is unmodified upstream and verifiable by SHA256SUMS. That holds for OpenZeppelin but ten forge-std files fail the check. I fetched the pinned upstream files and confirmed the recorded checksums are honest and the differences are whitespace-only reformatting. forge-std is test-only, so the token artifact is unaffected. The fix is for the author to restore exact upstream bytes or regenerate the checksums and reword the claim, since lib/ is outside a worker's write budget.

Coverage: all three listed entry points are marked holds, with five additional invariant and periphery rows, one of which references the finding.

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

Outcome: the PABOXO token holds up across the Economic Security, Invariant and Flow Gap checks. No defect in the token itself was found. One informational provenance finding was recorded.

What was checked and holds

• Supply and mint. INITIAL_SUPPLY compiles to exactly 10^27 and is minted once to the constructor's caller. A factory deploying via CREATE or CREATE2 receives the whole supply. No function reaches mint or burn after construction, so the supply can neither grow nor be diluted against the opening cap.
• Launch flows arrive whole. The token is unmodified OpenZeppelin v5.1.0 ERC20 with no fee, rebase, hook or transfer restriction. Factory to distributor, distributor to claimant, factory to pool, and pool pull via transferFrom each move the exact stated amount. The 10 / 50 / 40 percent split divides 10^27 with no rounding residue.
• Conservation. Sum of balances equals total supply under fuzzed transfer sequences, and the delivered stateful invariant suite agrees.
• No privileged surface. No owner, pause, blacklist or seize. The reachable runtime bytecode contains no CALL-family, DELEGATECALL, CALLCODE or SELFDESTRUCT opcodes. Native ETH is rejected.
• Dependencies. The vendored OpenZeppelin files are byte-identical to the pinned upstream commit.

Finding recorded (info)

DEPENDENCIES.md states every vendored file is unmodified upstream and verifiable through SHA256SUMS. That is true for OpenZeppelin but false for forge-std, where 15 files fail the shipped checksum file. The differences are forge fmt line wrapping only, and forge-std is test-only, so there is no on-chain impact. The fix is to restore pristine sources or regenerate the checksums and reword the claim.

Coverage: all three entry points (approve, transfer, transferFrom) are marked holds, with six additional invariant and flow rows. The one gap is that Uniswap v4 settlement was traced by reasoning rather than executed, since v4-core is not vendored in this repository.

Added failure-path and fuzz tests for allowance limits, rollback, retries, and competing spenders. Expanded stateful invariants to check balances, allowances, fixed supply, metadata, and holder transfers.

Validation passed offline with the supplied seed:

• forge build
• forge test: 47 passed, 0 failed
• 32,768 random handler calls

Only test/ files changed. No implementation defects found.

The review is complete and the findings file is validated. Nothing else is needed.

Outcome: the PABOXO token is clean. One low-severity provenance finding is recorded in .imd-findings.json, and all three entry points are marked holds. No tracked files were changed.

What I verified

• The contract is a 17-line wrapper over the vendored OpenZeppelin v5.1.0 ERC20. The constructor mints exactly 10^27 units to msg.sender once, and the ABI exposes no mint, burn, owner, pause, blacklist or initialize path.
• The five vendored OpenZeppelin files are byte-identical to upstream commit 69c8def5, so the compiled bytecode rests on genuine library code.
• Creation and runtime bytecode are well under the size limits, have no linked libraries, and contain no reachable DELEGATECALL, CALLCODE or SELFDESTRUCT.
• The launch manifest matches the tree: parameterless constructor, supply string equal to the minted amount, lowercase addresses, schema keys only.
• The project's own 47 tests, including fuzz and invariant suites, pass. The protected floor tests cannot run here because they import the network's v4-core and launch harness, which are not in this repository, so I checked their assertions by tracing the code instead.

The one finding kept

Three specialists reported the same root cause, which I merged into one low finding. DEPENDENCIES.md states every vendored file is unmodified upstream and checkable with the shipped SHA256SUMS. That holds for OpenZeppelin but fails for 15 forge-std files. I confirmed against the pinned upstream commit that the differences are whitespace-only re-wrapping, so there is no semantic change and no on-chain impact. The fix is the author's: restore the upstream bytes or regenerate the checksums and reword the note.

Dropped or absorbed: the aderyn large-numeric-literal lead is a compile-time constant equal to the documented supply, so it is noted in coverage, not reported as a defect. No specialist attached a proof, and no finding reaches the severity that requires one.