Implemented the token, immutable 2% buyback-and-burn hook, client-side wallet site, Pepe P&L cards, and IPFS package.

Passed forge build, forge fmt --check, 52 Foundry tests, 18 site tests, and four mainnet IMD fork tests.

Deployment, publishing, domain activation, and live addresses remain pending with the launch pipeline. Instructions are in README.md.

Done. The only file created is launch.json at the repository root. Nothing else in the tree was changed.

What the manifest declares

• Hook contract IMDBHook with constructor arguments written as the two placeholders, pool manager then token, matching the declaration order (IPoolManager manager_, IMDBToken token_).
• Permissions copied from the hook's getHookPermissions: beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta, afterSwapReturnDelta. These correspond to the hook's address flag mask 0x20cc.
• Token contract IMDBToken, name IMDBundler, symbol IMDB, 18 decimals, no constructor arguments.
• Pool values exactly as the launch facts give them: IMD pair address, fee 12500, tick spacing 60, initial price "79228162514264337593543950336".
• Notes describe the 2% IMD-side fee on settled deltas, the in-swap buyback and burn via ERC-6909 claims, the permissionless processFees retry, the beforeInitialize key check, and the absence of any owner or admin.

No $owner, $factory or $launchNumber placeholder is needed: the hook has no owner, does not check who initializes the pool, and never calls the factory. No hand-written address appears other than the IMD pair currency.

Checks run

• forge build succeeded with lint warnings only.
• forge test with the pinned fuzz seed passed 52 of 52 tests across 5 suites, including both invariant campaigns.
• launch.json parses as JSON, its first key is "kind": "univ4_hook", and the notes are well under the 4000 character cap.

I added 36 tests, and they found one real defect in the hook, which I've reported rather than tested around. The full suite passes: 88 tests (52 that were already there plus my 36) with the verifier's fuzz seed, and forge build is clean.

The defect (medium): sellers can pay for the hook's burn

When the hook buys back IMDB after a swap, it pulls those tokens out of the PoolManager with take and burns them, while the trader's transaction is still open (src/IMDBHook.sol:243). Uniswap v4 lets a trader pay in a different order: record the manager's balance (sync), send the tokens, swap, and only then confirm payment (settle). In that order the manager sees its balance lowered by the hook's withdrawal, so it credits the trader less than they sent.

• Reproduction: an exact-input sell of 100 IMDB paid this way costs the seller 101.95 IMDB.
• The extra 1.95 IMDB is exactly the amount the hook burned.
• A stricter router would revert instead of paying twice.
• Who is affected: traders and integrators who settle this way. The common routers (the periphery's settle helper, Universal Router) sync, pay and settle in one step, so they don't hit it. The hook's own accounting stays consistent, which is why the existing invariants didn't catch it.

The finding is in .imd-findings.json with a self-contained proof test that fails on the current code. It suggests two fixes:

• leave the bought IMDB as a claim during swaps and burn it in processFees, which opens its own unlock; or
• skip the take while IMDB is the currency someone has synced.

What the new tests cover

• test/IMDBHookEdges.t.sol (17 tests, run with IMD as both currency0 and currency1):

  • Fuzz tests check that the fee is exactly 2% under random price limits (forcing partial fills), with Uniswap's protocol fee switched on.
  • They also check that an exact-output sell delivers exactly the requested net amount, and an exact-input buy never takes more than its budget.
  • Pinned tests check the rounding at 1, 49, 50, 99, 100 and 149 wei.
  • Failure paths: wrong pool keys rejected even when the PoolManager calls, the reentry guards, the 2¹²⁶ amount limit, and disabled callbacks reverting. Also processFees reverting inside another unlock and a buyback skipped at the extreme price without reverting.
  • Two more: claims donated to the hook are bought back and burned, never withdrawable, and four swaps in one unlock are each charged.

• test/HookStatefulInvariant.t.sol runs random call sequences: three traders, a liquidity provider adding and removing positions, batched swaps, claim donations, and processFees from random callers. It checks after every sequence that:

  • supply only falls by the hook's burns;
  • IMD claims are conserved;
  • the manager holds enough to cover the hook's claims;
  • the hook never holds tokens directly, and its counters never go down.

  At the end every liquidity provider withdraws and processing still works. 2,048 calls per ordering, zero reverts.

• test/mocks/BatchRouter.sol is a test router that runs several PoolManager operations inside one unlock.

Apart from this defect, the hook's 2% fee math held across all four swap modes and partial fills. Nothing is committed; the new files are untracked in test/.

The review is complete and .imd-findings.json is written with the findings and a full coverage record. No source files were changed. The untracked dotfiles in git status are machine-provided device nodes, not my edits, and .imd-findings.json plus test/scratch/ are covered by the repository's ignore rules.

Result of the audit (Access Control, Trust Gap, Asymmetry lenses on IMDBHook and IMDBToken):

• One low finding, with proof. The hook's afterSwap physically takes IMDB out of the PoolManager mid-swap to burn it. A router that pays its IMDB input before swapping, using the valid v4 order of sync, transfer, swap, then settle, is credited input minus the burned amount and the unlock reverts with CurrencyNotSettled. The same router succeeds on an identical hookless pool and succeeds with the hook when it settles after the swap. Uniswap's own V4Router is unaffected, so this is an integration liveness gap, not fund loss. The proof test under test/scratch/PrepaidRouter.t.sol fails on the current code for this reason and both control tests pass. Suggested minimal fix: keep bought IMDB as a claim in afterSwap and redeem plus burn only on the processFees unlock, or skip the take when the manager has that token synced.
• One informational note. The buyback runs at the post-trade spot price with a 2% bound and processFees is permissionless, so just-in-time liquidity can be the counterparty fee-free. I could not show a material victim: sandwiching the buyback is unprofitable because the attacker pays 2% plus 1.25% each way while the buyback moves price at most about 2%. The project already documents this residual risk.

What held. Every enabled callback and the unlock callback are restricted to the PoolManager. The self-quote is only-self and always reverts. Pool key, fee tier 12500 and spacing 60 are enforced in beforeInitialize, and pre-deployment initialization fails on empty code. The hook holds no operator or approval over its ERC-6909 claims, so no actor can redirect fee value. Buy and sell fee branches and their specified versus unspecified return deltas are symmetric and reconcile to zero. The token is unmodified OpenZeppelin ERC-20 with caller-only burn. No liquidity callbacks are enabled, so the factory's fee collect cannot be blocked. The site keeps keys module-private, allows only read-only RPC methods, and signs only through an explicitly chosen EIP-6963 provider after rechecking sender and chain.

Coverage. All nine listed entry points have rows, plus rows for beforeInitialize, the constructor, two invariants and the site's key boundary. The one finding row is afterSwap. The Math, Boundary and Economic lenses were only checked where they intersected my area.

The review is complete and .imd-findings.json holds three substantiated findings plus a coverage row for every listed entry point.

Outcome. The core 2% fee arithmetic is sound. I traced all four trade shapes (buy/sell, exact-in/exact-out), proved the partial-fill identity floor((C+F)/50) == F for F = floor(C/49), showed the real swap input always covers the quoted fill, and fuzzed 1,200 runs across gapped liquidity and arbitrary price limits without a single FeeMismatch. Overflow, downcast and clamp paths in the buyback bound also hold. No critical or high defects.

Findings written:

• Low, src/IMDBHook.sol:243. The hook physically takes IMDB inside the user's afterSwap. A sell router that syncs and pre-funds IMDB before calling swap is credited less at settle and reverts with CurrencyNotSettled. A router that tops up remaining debt instead would charge the trader the buyback amount extra. Buys and settle-after-swap routers are unaffected. Reproduced for both currency orderings.
• Low, src/IMDBHook.sol:220. When no liquidity is in range, the buyback swap moves the pool price exactly 1% with zero spend, and processFees is permissionless. With the full-range position withdrawn, 29 calls walked the price into a range 6,000 ticks away, where the hook then spent its pending IMD about 35% above the prior price. Precondition is that the launch's full-range liquidity is gone, so launch-day state is unaffected.
• Info, src/IMDBHook.sol:115. Fees floor to zero below 50 wei. Documented, at most 49 wei per swap, not exploitable.

Coverage. All nine ABI entry points have rows. Seven hold, afterSwap and processFees reference findings 1 and 2. Two invariant rows record the quote-equals-fill proof and the bound arithmetic. The site, release artifact and manifest are marked unreached as outside the math area.

Scratch tests live in test/scratch/Probe.t.sol and are not part of the submission. No repository files were changed.

The review is complete. The findings file is valid JSON, both snippets match the tree exactly, and the working tree is clean apart from the gitignored scratch tests and the findings file itself.

Outcome: no critical, high or medium defects in the economic area. The hook's fee accounting is correct and I could not break it.

What I verified

• All four fee paths (buy/sell × exact-in/exact-out) in both currency orderings charge floor(IMD side / 50) on settled deltas. The self-quote plus FeeMismatch identity holds under integer rounding. I proved this by hand and with a 1000-run fuzz using tight price limits, liquidity exhaustion and pre-moved prices. No honest trade reverts.
• Delta conservation: hook claims, buyback, remint and burn-and-take always net to zero. The pending-claim invariant and "hook holds no ERC-20" invariant held across every scratch scenario.
• Buyback cannot DoS a swap: the price bound is clamped and strictly past the current price, the amount is nonzero and bounded, and zero-liquidity swaps just remint.
• Sandwiching the buyback with swaps is unprofitable: a round trip costs about 6.5% in hook and LP fees against at most 2% of permitted price movement.

Findings reported

1. Low: deferred fee claims plus permissionless processFees let a just-in-time liquidity provider convert IMDB to IMD with no 2% sell fee and capture the buyback's LP fee. Measured: a 20M IMD whale buy leaves ~191.8k IMD pending, and a JIT position then swaps 439 IMDB for 188k IMD with zero hook fee. The burn quantity is unchanged, so impact is bounded.
2. Info: the fee and burn apply only to the one hooked pool key. A hookless IMDB pool trades fee-free, which follows from the brief's own "standard ERC-20, no transfer tax" constraint and should be stated on the token page.

Coverage: all nine entry points have rows (eight hold, processFees references finding 1), plus five invariant and economic rows. Slither and Aderyn leads were checked and none substantiated beyond the trusted-manager call ordering already documented.

Findings file validated: one low finding with an exact snippet match, 13 coverage rows covering all 9 verifier entry points plus checked invariants. The scratch test lives only under test/scratch, and the tree is otherwise untouched.

Result: one low-severity finding, no critical/high/medium defects in the hook's control flow.

Scope covered in depth (Execution Trace, Periphery, First Principles guides, plus the senior-auditor mindset): every path through beforeSwap, afterSwap, quoteSwap, processFees, unlockCallback, beforeInitialize, the _process buyback and _burnAvailableTokens, HookBase, HookFlags, IMDBToken, and the v4-core primitives they rely on. I verified the vendored v4-core skips this hook's callbacks for hook-initiated swaps, which the self-quote and buyback depend on, and confirmed the mainnet IMD pair is an OpenZeppelin-based LayerZero OFT with plain transfer semantics. The fee arithmetic for all four buy/sell exact-in/out cases, including partial fills, checks out with the quoted fill always equal to the real fill. The project's 52 tests pass.

Finding (low), src/IMDBHook.sol:243. Inside afterSwap, the hook physically takes purchased IMDB out of the PoolManager. A router that pays its input before swapping (sync, transfer, swap, settle) has its IMDB prepayment partly consumed by that take, so settle() undercounts and the unlock reverts with CurrencyNotSettled. The same prepaid flow for a buy works. Uniswap's own routers settle after the swap, so the standard path is unaffected. Reproduced in both currency orderings with a scratch test. Suggested fix: redeem IMDB claims only in processFees, or cap the take by the manager's synced reserves when IMDB is the synced currency.

Not reported after testing: repeated permissionless processFees calls do spend all pending fees despite the per-call 1% bound, but pending is only about 2% of post-trade reserves, so cumulative impact is dust and matches the documented design. Static-analysis leads were all benign on inspection.

I kept 2 findings and wrote them to .imd-findings.json, with a coverage row for each of the 9 entry points. No tracked files were changed, and I deleted the scratch tests afterwards.

Kept:

1. Medium – IMDB is taken from the PoolManager in the middle of a swap (src/IMDBHook.sol:243). Four specialists reported this same cause, so it is one finding here. Inside afterSwap, the hook pulls the IMDB it bought back out of the PoolManager while the seller's transaction is still open. A seller whose router pays its IMDB in before calling swap() and settles after it is short by exactly the amount the hook burned. The transaction then either reverts with CurrencyNotSettled, or the router covers the gap and the seller overpays: an exact-in sell of 100 IMDB cost 101.95 IMDB, and the extra 1.95 IMDB equals totalBurned. Both supplied proofs fail on this code for that reason. One of them includes a control with no hook, which passes. I attached the overpay proof. I rated it medium, not high: buys are unaffected, and so are routers that settle before swapping or settle all at once after the swap, such as Uniswap's own.
2. Low – a buyback can move the price without buying anything (src/IMDBHook.sol:220). When the pool has no liquidity at the current price, the buyback swap moves the price 1% and spends nothing. Anyone can call processFees() repeatedly to walk the price into an LP's range far above market, where the hook then spends its accumulated fees at an inflated price and burns fewer IMDB. My scratch test confirmed the exact 0.99× move with no spend and the pending fees unchanged. This only happens if the launch's full-range liquidity has been removed.

Dropped:

• Liquidity added just before processFees() (two specialists). This is how any AMM liquidity provider sells into a trade, and the burn itself is intact, so it is not a hook defect.
• No fee on other IMDB pools. This follows from the brief's plain ERC-20 with no transfer tax.
• Fee rounds to zero below 50 wei. It is documented and too small to exploit.

My own pass found nothing new:

• The fee math works out in all four swap modes (buy and sell, exact-in and exact-out).
• The trial-swap fee estimate run before each swap matches what the swap actually fills.
• The hook's balances net to zero on every path.
• The reentrancy guards hold.
• launch.json is consistent with the code: the address flags (0x20cc), constructor arguments and LP fee 12500 all match.

The specialists' concern about beforeInitialize restricting who creates the pool is also covered: it accepts calls only from the PoolManager and only for this pool's exact settings.

Both findings reproduced and are fixed. The hook diff is two guarded early-exits; nothing else in the accepted implementation changed.

Finding 841aea96 (medium, with proof): fixed. The proof failed on the starting tree exactly as reported, with the seller overpaying by the burned amount. The cause was the burn step taking IMDB out of the PoolManager during the swapper's open sync. The hook now checks the manager's synced currency before taking, and defers the burn as a claim when a payer has IMDB synced. The proof passes. Regression tests for both currency orderings cover the prepaying seller (fixed and fuzz, exact-in and exact-out), plus two controls that still burn in flow: a seller who settles before swapping, and a buyer with IMD synced. The seller tests fail on the old hook.

Finding 03615ec5 (low, advisory): fixed. Running the new test against the old hook confirmed the free price walk: three retries moved the square-root price by exactly 0.99 cubed with nothing spent. The buyback is now skipped when the pool has zero liquidity at the current tick. The test checks that repeated retries leave the price and pending fees untouched, and that a retry spends once liquidity returns.

Checks on the delivered tree:

Check	Result
forge build, forge fmt --check	pass
forge test with the pinned fuzz seed	62 passed, 0 failed
Reviewer proof copied under test/scratch	passes on the fix, failed before
node site tests	18 passed

Files changed: src/IMDBHook.sol, test/IMDBHook.t.sol, test/mocks/TestRouter.sol (new prepaying swap mode), and the docs in docs/HOOK.md, docs/SECURITY.md and the README. Both responses are recorded in .imd-responses.json. One residual is documented rather than changed: a buyback that starts in range and runs off its end still moves to its bound, which is the same cost-free move v4 allows any swapper through an empty range.

Done. The manifest at launch.json is verified against the accepted implementation and is the only file changed.

What I checked

• Constructor: the hook takes (IPoolManager, IMDBToken), so the arguments are $poolManager and $token in that order. No owner or factory parameter exists, so no $owner or $factory placeholder applies.
• Permissions: getHookPermissions returns beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta. The manifest lists exactly those, and they match the flag mask the hook validates against in its constructor.
• Token: contract IMDBToken, name IMDBundler, symbol IMDB, 18 decimals, no constructor arguments.
• Pool: paired currency is the IMD address, fee 12500, tick spacing 60, initialPrice as the launch facts give it.
• Notes: every behavioural claim (IMD-side fee, ERC-6909 claim minting, same-swap buyback and burn, processFees retry, public burn counters, disabled liquidity callbacks) matches the current source. Length is well under the 4000 character cap.

What I changed

One sentence was added to the notes stating that no owner or factory placeholder applies, and one describing the client-side site in the tree, since the task asks the manifest to describe what was built. All previously accepted content is untouched.

Verification

forge build and forge test with the verifier's fuzz seed pass: 62 tests, 0 failures, including the invariant suites. git status shows only launch.json modified.

I added tests for this revision's two hook changes, and I found no new defect, so there is no .imd-findings.json. forge build succeeds, and forge test with the verifier's fuzz seed passes all 112 tests across 11 suites (it was 98 before), with no skips.

The two changes are:

1. The hook no longer burns IMDB while a payer has IMDB "synced" for a later settlement.
2. It no longer runs the buyback when the pool has no liquidity at the current price.

New file test/IMDBHookRevision.t.sol (7 tests, run for both token orderings):

• Prepaid payer fuzz test: a payer syncs IMDB or IMD, prepays a random amount, swaps in any direction and mode, then settles. It must pay exactly the swap's amounts, the 2% fee rule must hold, and a later processFees() must clear all pending IMDB.
• Someone else with IMDB synced: this only delays the burn and gains them nothing. They pay their full budget, the delayed IMDB stays the hook's, and a retry burns exactly that amount.
• Two swaps before one settlement: the payer's outflow equals the two swaps' amounts combined, and the next ordinary swap burns the backlog.
• Settling before the swap: the burn happens immediately, which shows the delay is tied to a live sync, not to prepaying.
• Burn with zero liquidity: the no-liquidity rule only stops the buyback. Delayed burns still go through and the price doesn't move.
• Tiny liquidity at the current price: it re-enables one buyback, which never moves the price beyond the fixed ±1% bound. The next retry then moves nothing.
• User swap ending where the pool is empty: the 2% fee is charged on what was actually settled, the fee waits as pending IMD, and the price stays exactly at the swap's limit.

Change to my existing test/HookStatefulInvariant.t.sol: I added a midSyncTrade action to the random-sequence handler. On every call it checks that the payer's real token flows equal the swap's amounts and that nothing burns while IMDB is synced. It ran about 300 times per campaign with no reverts.

Check that the tests catch the bugs: I temporarily removed both guards from src/IMDBHook.sol, then restored the file; src has no changes. With the guards gone, 6 of the 7 new tests failed, and every invariant failed with "mid-sync payer IMDB overcharged". The one test that still passed only checks the user-side behaviour when the burn happens immediately.

Two notes:

• The forge-config fuzz-run overrides don't apply to tests inherited from shared abstract contracts in this forge version, so those fuzz tests run the default 256 times.
• I'm not filing this as a finding: the buyback's ±1% limit is measured from the current price, which a trader can push first. Any loss is capped at that bound on whatever IMD is pending, and I have no concrete losing case.

Nothing is committed: the changes are the new test file and the edited invariant file.

Both of my earlier findings are fixed, and I found nothing new. The review is recorded in .imd-findings.json with an empty findings list and a coverage row for every entry point.

Medium, prepaid seller overpays or reverts (841aea96): fixed. The hook now reads the manager's synced currency in _burnAvailableTokens and skips the IMDB take when IMDB is synced, leaving the purchased IMDB as a claim for the next swap or processFees(). I copied both attached proofs under test/scratch and ran them against the revised code. All four tests pass, including the two controls. I also wrote my own probe for two cases the author's tests do not cover directly: a prepaid exact-out sell, and a prepaid sell followed by a second plain swap inside the same unlock. In both orderings the seller pays exactly the swap delta, the deferred claim is burned on the second swap, and all deltas and counters reconcile.

Low, zero-liquidity price walk (03615ec5): fixed. The buyback now runs only when the pool has in-range liquidity. The author's regression test shows three retries leave slot0 and pending claims unchanged, and the residual walk off the end of a range is documented in docs/HOOK.md.

Other checks this round:

• The hook diff between revisions is exactly the two guards above, nothing else changed in src.
• The full project suite passes: 112 tests across unit, edge, revision, and stateful invariant suites.
• The specialists' remaining low and info items (JIT liquidity as buyback counterparty, fee-free hookless pools, dust fee floor) are design properties already documented, not reproducible losses, so I did not open findings for them.
• launch.json matches the constructor, permissions and flag mask.

The scratch directory is removed and the working tree is clean apart from the findings file.