Implemented the fixed-supply PIXEL token, immutable canvas hook, SVG rendering, and CREATE2 salt helper. Dependencies are vendored for offline builds.

Validation passed: forge build, all 40 tests, and forge fmt --check.

Deployment parameters, assumptions, and responsibilities are documented in README.md. No deployment was performed.

The review is complete. The findings file is written and validated, the scratch directory is removed, and the working tree is unchanged.

Outcome: no critical, high or medium defects in the economic, invariant or flow-gap areas. One low, conditional finding is recorded.

What I checked

• Economic Security. The hook has no value flows at all: no take, settle, mint, burn or transfer, all return-delta flags off, and afterSwap always returns zero. The only external dependency is a decimals() static call at initialization, so after launch no token misbehaviour, oracle or dependency failure can block swaps. There is no revert path in afterSwap for a legitimate swap on the locked pool, so the hook cannot brick trading. Spam painting costs only gas and the LP fee on dust, which is the brief's design.
• Invariants. Strokes advance by exactly one per swap, pixel index is (strokes-1) % 1024, canvas bytes stay in 1..8 so the SVG palette lookup is bounded, and the pool lock is set once with rollback if the manager rejects the pool. The hook never calls the manager, so v4's self-call skip cannot bypass beforeInitialize.
• Flow gaps. Buy and sell direction holds for both currency orders through real PoolManager swaps. Brightness uses the executed IMD delta, including LP fee on buys, as the README documents. The aderyn reentrancy lead at the decimals() read is not exploitable because it compiles to STATICCALL. render() costs about 2M gas, and hook overhead per swap is around 50k.
• Verifier floors. I ran the protected hook and token floors with launch-like inputs (12500 fee, token probe, factory probe, ERC-20 pair, supply 10^27, 18 decimals). All 11 tests pass.

The one finding (low). beforeInitialize refuses a native-ETH pair at src/PixelHook.sol:74. If the manifest's paired currency were the zero address, the launch transaction would revert and the verifier's launch-factory floor fails, which I reproduced. The brief and README treat IMD as an ERC-20, so this is a note for the manifest author rather than a code change, unless IMD on the launch chain is native.

Coverage. All five listed entry points have rows: four hold, beforeInitialize carries the finding. Four extra rows record the invariants checked.

Review complete. The findings file is written at .imd-findings.json and the scratch probe was removed, so the tree holds only that file beyond the original commit.

Outcome: no math defect found in the assigned area. The hook's arithmetic is sound at every boundary the Math Precision, Boundary and Numerical Gap guides name. One info-level note is recorded.

What I verified, with concrete values:

• Signed delta handling. The int128 swap delta is widened to int256 before negation, so int128.min yields 2^127 and casts cleanly to uint256. The existing test covers this and I traced the manager's Hooks.afterSwap to confirm the hook receives the raw swapper delta, so the sign always matches zeroForOne.
• Threshold scaling. Decimals are capped at 74, so 500 × 10^74 stays below 2^256. With 18, 6 and 74 decimals the shade boundaries at exactly 5, 50 and 500 units behave as the brief states, strict-less-than on the lower side.
• Byte packing. The mask clears exactly one byte for shifts up to 248 and the fuzz test compares 1,100 strokes against an unpacked reference, including the wrap at 1024.
• SVG buffer. Each circle is at most 48 bytes. With all 1,024 dots painted the output measured 48,516 bytes against a 57,472-byte buffer, so the internal assert is unreachable. The view costs about 2M gas.
• Static-analysis leads. The reentrancy lead on the decimals() read is dead because the trace shows a STATICCALL. The encodePacked and unsafe-cast leads are intentional text concatenation and byte extraction.

The one note (info): the Painted event emits a one-based stroke beside a zero-based pixel. The first swap emits stroke 1, pixel 0. State is correct and the README documents it, but an indexer computing the pixel from the stroke is off by one. I did not rate it as a defect.

Coverage record. All five listed entry points have rows. Both hook callbacks and the three token functions hold, the token being unmodified OpenZeppelin v5.1.0. One deployment caveat is recorded on beforeInitialize: the hook refuses a native-currency pair, which is consistent with the brief naming IMD as a token but would block a native-paired manifest.

The review is complete. The findings file is written and the working tree is otherwise untouched (the scratch test lives in the gitignored test/scratch/ directory, and the only failing test is that scratch proof, by design).

Outcome

The control flow of the PixelHook is sound. All 40 project tests pass, and I traced both hook callbacks against the Execution Trace, Periphery and First Principles checklists plus the v4 security guide. I recorded one conditional finding and eleven coverage rows in .imd-findings.json.

Finding 1 (medium, conditional): native-currency pairing is refused. beforeInitialize requires the non-PIXEL currency to have code and a callable decimals(). A pool key with currency0 at the zero address, which is how v4 expresses the chain's native currency, reverts with InvalidPool at src/PixelHook.sol:74. Because the factory deploys and initializes in one transaction and the hook locks to the first pool, the launch itself would fail. This only matters if the launch's paired currency is native or lacks decimals(). The brief's phrase "whatever the address order" suggests IMD is an ERC-20, in which case the behaviour is intended. No launch manifest is in the tree, so I could not settle it. I attached a scratch Foundry test that fails on the current code and explained the minimal fix.

What held, with the reasoning recorded per row:

• afterSwap: caller check, direction logic for both currency orders, widening before negation, threshold arithmetic for decimals up to 74, byte masking, zero return delta, no external calls so no swap-blocking path.
• beforeInitialize: first-pool lock, key validation, rollback on manager rejection, and the decimals() read is a static call so the aderyn reentrancy lead is rejected.
• Token entry points: unmodified OpenZeppelin v5.1.0 ERC20 with fixed supply.
• Periphery: HookFlags masks, MineHook CREATE2 formula, render buffer bounds.

Static analysis leads: all three aderyn high-impact lines were traced and rejected as false positives. The encodePacked is string concatenation, the "reentrancy" is after a STATICCALL, and the "unsafe cast" is an intentional byte extraction.

Trust assumptions noted, not findings: the hook accepts any PIXEL/ERC-20 pool from any initializer, so atomic deploy-and-initialize by the factory is essential. The Painted event's stroke is one-based, which is documented.

The review is complete. The findings file is written at the repository root, the working tree is clean, and no tracked file was changed.

Outcome. The permission model of the Pixel Pool hook holds up well. Every callback, enabled or not, is gated on the pool manager, the one-shot pool lock is set only after all checks and rolls back on revert, and there is no owner, setter, upgrade, or fund-moving path. The token is unmodified OpenZeppelin v5.1.0 with a fixed supply. I report one conditional defect and one recorded trust assumption.

Finding 1, medium. The initialization callback refuses a native-currency pair. It requires the non-PIXEL currency to have code and to answer decimals(), so a pool keyed with currency0 equal to the zero address reverts with InvalidPool inside the factory's initialize call. If the launch's paired currency is the chain's native currency, the launch transaction cannot open its pool and the hook is unusable. The same gate also refuses an ERC-20 pair that lacks a decimals function. This depends on the manifest's paired currency, which is not in the tree, so the judge can settle it from that field. A proof test is embedded in the findings file. It fails on the current code and passes once the zero address is accepted as an 18-decimal pair.

Finding 2, info. The callback does not check who initializes, so the first pool is first-come. The window is closed when the factory deploys and initializes in one transaction, which the reference and README both state. If those steps were ever split, anyone could lock the hook to a junk pair and the factory's own initialize would revert permanently. Recorded as a trust assumption, not a defect.

Coverage. All five listed entry points have rows, plus six invariant rows. Only beforeInitialize carries a finding. Static-analysis leads were checked and none held: the reentrancy lead at line 77 is a static call, and the casts and packed encoding are intentional and bounded.

Not reached. No fork rehearsal against the real pool manager and IMD contract, and no gas profiling of the swap callback beyond a manual estimate.

Added failure-path tests, complete canvas/SVG checks, and randomized token/pool invariants. All changes are under test/.

Verified forge build and forge test: 55 passed, 0 failed, 0 skipped. Invariants exercised 24,576 randomized calls with no unexpected reverts.

No confirmed defects found.