The deliverable is complete and committed.

What was built

• src/PerkToken.sol: the standard launch token, name Perkshire IMDway, symbol PERK, 18 decimals, one billion minted once to the deployer. No mint, owner, pause, fee or upgrade.
• src/PerkVaultHook.sol: the hook and vault in one contract, no owner or admin. Constructor takes $poolManager, $token, the IMD address and $factory. It reuses launch #1330's fee logic unchanged with the hook as recipient, and adds binding, burn, tender and ask.
• src/IIntake.sol: the Intake interface from the oracle-consumer reference.
• Vendored lib/ (forge-std, v4-core, solmate's Owned) copied from #1330 as ordinary files, no submodules.

Key behaviour

• Binding admits one pool only: factory as initializer, currencies exactly PERK and IMD, static fee 12500, nothing bound yet. Tick spacing is not checked. Swap callbacks also refuse any other key.
• Every swap takes 1% of the IMD side in all four modes. Each fee is split once when taken, paid or deferred: half to burnOwed, the rest to totalFloat. Deferred fees stay as ERC-6909 claims until anyone redeems.
• The burn sends min(burnOwed, balance) to the dead address after fees, after redeems, before tenders and asks, and on burn(). A refused IMD transfer leaves it owed without reverting.
• tender pays amount * (balance - burnOwed) / (supply - dead) rounded down, burns the PERK, reverts on zero payout, and is reentrancy-guarded.
• ask runs at most weekly, needs 0.6 IMD of float, approves exactly 0.5 IMD to the Intake, sends the brief's body byte for byte, pays the caller 0.1 IMD, and leaves no allowance.

Verification

The Owners floor test could not be run locally because its OwnerChecks and Swapper helpers were not provided. The hook has no owner and no remove-liquidity callbacks, and a zero-liquidity modify is covered by a test of my own.

Documented choices and open items are in the README: the Intake, action and price are constants because the brief forbids an owner, so a moved Intake stops ask() without affecting the rest. totalAsked counts answers bought. The fee stays in IMD rather than ETH on the requester's instruction. An independent adversarial review is recommended before release, with the self-call simulation and blocklisted-IMD paths as the first places to look.

Created launch.json with matching contract names, constructor arguments, five permissions and required pool settings.

Manifest checks passed. forge build succeeded with existing warnings; all 63 tests passed. Only launch.json is changed for submission.

I found no access-control, trust-gap or asymmetry defect in PerkVaultHook or PerkToken. .imd-findings.json has one informational finding and a coverage row for all 12 entry points, plus 2 invariant rows. The existing suite passes (63 tests). I added no proof tests, since only critical or high findings need one, and I changed no files.

The informational finding: ask() (src/PerkVaultHook.sol:318) only works while the Intake's operator keeps the price of an answer at exactly 0.5 IMD. The Intake address and price are constants with no owner, as the brief requires. If the operator moves the price, every later ask() reverts and nothing can fix it. No IMD is lost, and tender and burn keep working. One part is assumed, not checked: that the live Intake rejects any amount other than its current price. This is a dependency to mention in the README, not a fix request, because fixing it would mean adding the admin role the brief rules out.

What holds, by guide:

• Access control:
  • Pool binding accepts only the factory as sender, PERK and IMD as the currencies, and a fixed 12500 fee. It binds once, so a fake token, a wrong or dynamic fee, a second pool or a re-initialization all revert.
  • Every swap and settlement callback accepts only the PoolManager and only the bound pool.
  • simulateSwap can only be called by the hook itself, and that inner swap doesn't trigger the hook's callbacks, so it can't recurse.
  • unlockCallback can only be reached through redeemPendingFees.
  • There is no owner, setter or upgrade path, and the token can never mint again.
• Trust gap:
  • The open functions (burn, redeemPendingFees, tender, ask) can only send IMD to fixed places: dEaD, the hook itself, the tenderer's own pro-rata share, or the Intake's exact 0.5 IMD, whose approval is reset afterwards.
  • A tender pays at or below pro-rata, so book value can't fall.
  • Donating IMD or calling functions during someone else's PoolManager session gives an attacker nothing.
• Asymmetry:
  • Each fee is counted exactly once, whether it is paid during the swap or held as a claim. Paying out old claims during a later swap uses the same bookkeeping as redeemPendingFees.
  • The fee beforeSwap takes is exactly the one afterSwap records, carried between them in transient storage.

Static-analysis leads: the reentrancy warnings only involve calls to the PoolManager, the IMD token or the fixed Intake, and the user entry points share one reentrancy lock. The ignored unlock return value and the variable left at zero by default are harmless.

Two behaviours I didn't report because they match the brief:

• A tender made while fees are still unpaid claims is paid only from the IMD the hook holds. The burn's half of those claims comes out of that IMD first, so tendering before anyone calls redeemPendingFees() pays less.
• When IMD is the amount the trader specifies, the fee is measured the way launch #1330 measures it.

I didn't look deeply at the fee arithmetic or the rounding on very small swaps, which belong to other specialists' areas.

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

What I covered. My area was the Execution Trace, Periphery and First Principles guides. I traced every entry point of the hook and token from caller to final state, including the v4-core dispatch that the fee logic depends on. The simulation self-call, the before and after swap delta netting, the paid and deferred fee paths, the burn, tender, ask and redeem flows, and the Intake periphery were all traced with concrete values and fuzzed where the existing suite had a gap. The full suite passes (63 tests). My scratch tests under test/scratch/ are gitignored and not part of the submission.

Findings written to the file:

• Medium, deferred fees lower book value. When the PoolManager cannot pay a fee, the hook mints a claim and still adds half the fee to burnOwed. The float view subtracts all of burnOwed from the real balance, so book value drops by half the deferred amount. A tender during that window pays below book value, and if the deferred burn half exceeds the balance, both tender and ask revert while IMD sits in the hook and as redeemable claims. Reproduced with a donation followed by a deferred first buy on the PERK-only pool. Everything recovers after redeemPendingFees, so this is transient but it breaks the stated guarantee and the author's own README expects deferrals at launch.
• Low, fixed ask price. The ask price is a constant with no owner to move it. If the Intake's price or action changes, every ask fails for good. Verified by etching an Intake stand-in priced at 0.6 IMD. The brief mandates the constant, so this is a design consequence to decide on, not a coding slip.

What holds. Binding, both swap directions in exact-in and exact-out with and without price limits, delta netting to zero, once-only fee accounting, burn tolerance of refused transfers, tender pro-rata and rounding, reentrancy coverage, the three IMD exit paths, the Intake interface, the right-padded action id, and the request body byte for byte against the brief.

Not reached. A third-party ERC-6909 claim sent to the hook is swept in as float by the next redeem. That is donation-equivalent and I did not treat it as a defect. I did not inspect a launch manifest because none exists in the tree.

The review is complete. The findings file is at .imd-findings.json in the repository root, with two low findings and a coverage row for all twelve entry points plus four invariants. No source files were changed. The only files I wrote are that file and test/scratch/Econ.t.sol, which the gitignore excludes.

What I covered. I read the hook against the Economic Security, Invariant and Asymmetry (flow gap) guides, traced every IMD and PERK movement, and checked the fee netting in all four swap modes, the simulation path, the ERC-6909 deferral and redemption, tender rounding, the ask flow, and the binding. The existing suite of 63 tests passes. I added a scratch fuzz for exact-output sells against a price limit, which confirmed the fee is 1% of the specified amount on a full fill and 1% of the moved amount on a partial fill, and found no gap.

Findings, both low.

• Deferred fee burns pre-existing float. When the manager cannot pay a fee at once, half of it is added to burnOwed and the burn then sends IMD the vault already held to the dead address. In my reproduction the vault's prior float dropped to zero, book value read zero, and a tender would have reverted until someone called redeem. No IMD is lost and redeem is permissionless, but book value visibly falls and then jumps, against the brief's guarantee. The brief's own ordering produces this, so I framed the fix as an author decision.
• Hard-coded Intake price. The oracle-consumer reference says intake, action and price must never be constants because a repriced oracle must not need a redeploy. The hook follows the brief instead and has no owner. With a mock intake priced at 0.6 IMD, every ask reverts forever. Nothing is lost, but the weekly report feature cannot be revived. Reported as a knowing trade-off.

What I did not find. No extractable value: tender never pays above pro rata and never lowers book value, donations only raise it, fees cannot be bypassed by any caller including the hook itself, swaps cannot be blocked by token refusals, and the request body matches the brief byte for byte. Neither finding carries a proof file, since neither is critical or high.

The review is complete. Both extra probes passed, so no further defects surfaced. The workspace holds only the findings file and the scratch directory.

Outcome. The math in the PERK hook is sound in every place I traced except one seam at the fee-deferral boundary. The findings file at .imd-findings.json holds 2 findings and 15 coverage rows covering all 12 listed entry points plus three invariants.

Finding 1, low: a deferred fee burns from the float. When the PoolManager cannot pay the fee during the swap, the hook mints an ERC-6909 claim but still adds half the fee to the burn debt, then immediately pays that debt from whatever IMD it already holds, which is the float backing tenders. Book value and the tender quote fall by half the deferred fee until anyone redeems the claim. In the reproduction the float goes from 5 IMD to 0 and a tender that would have paid 5e21 wei reverts with ZeroPayout. In the natural early-launch variant a 20000 IMD buy on a pool holding 148.5 IMD wipes a 0.75 IMD float and makes ask() revert. Any swapper can force deferral by taking the manager's IMD inside its own unlock before swapping. The accounting is correct once redeemed and the attacker never profits, so I rated it low with a self-contained proof test that fails on the current code. The suggested fix tracks burn halves of unredeemed claims and excludes them from both the burn and the float, keeping the brief's counting.

Finding 2, info: fees truncate to zero under 100 wei. This matches #1330 and the README, recorded for completeness only.

What held. The simulation-based quote for IMD-specified swaps is consistent with the real swap for full and short fills in both directions, which I verified by reasoning about the floor arithmetic and by fuzzing all four modes with price limits from 1 to 20000 ticks. The exact-in fee basis is the gross input, identical to #1330's code, which I downloaded and compared. Tender rounding never pays above pro-rata and never lowers book value. The split is applied exactly once across paid, deferred, flushed and redeemed paths. Donated ERC-6909 claims and max-uint tender amounts cause no breakage. Casts and intermediate products stay within bounds given the pool's int128 limits.

Not reached. The live IMD token's exact transfer semantics on Robinhood Chain and the live Intake's pricing behaviour, which sit outside the math area and need a fork.

Done. The suite now has 68 tests passing under the verifier's fuzz seed, and one defect is reported rather than tested around.

What I found

The existing 63 tests already covered the brief's unit and fuzz list but had no invariant tests, which the acceptance criteria require for a value-holding contract. While building them, the handler surfaced a real behaviour: a deferred fee lowers the book value view. On the launch-shaped pool the manager holds no IMD, so the first fee becomes a pending claim, yet its burn half is owed at once and the burn pays it out of whatever float the hook already holds. Book value drops by half the fee until anyone calls the redeem function, after which it ends above where it started. The brief's own wording prescribes this ordering, so I filed it as low severity with a failing proof test rather than asserting it is correct. A second, info-level note records that anyone can push ERC-6909 IMD claims onto the hook, which then read as pending float and behave as a donation once redeemed.

What I added (all under test/)

• test/invariants/PerkVaultHandler.sol drives three actors through all four swap modes, liquidity adds, tenders, burns, redeems, asks with time warps, donations, and an IMD stand-in that blocklists the dead address or the hook at random. Every path asserts its own postconditions, including the exact revert reason when a tender or ask must fail.
• test/invariants/PerkVaultInvariants.t.sol checks nine invariants after every call with revert-on-failure on: IMD conservation, IMD leaving the hook only by tender, burn and ask, dead holding exactly totalBurned and totalTendered, the floor/ceiling fee split, debt always covered by cash plus pending claims, the manager always covering pending claims, book value falling only through ask (claim-inclusive, with the view never above it), ask accounting, and fixed PERK supply.
• test/PerkVaultHookAdversarial.t.sol covers pushed IMD claims, pushed PERK claims, whole redeems after a draining sell, and doctored pool keys.
• .imd-findings.json at the repository root holds the two findings. The low one carries a self-contained proof that fails on the current code with book value 9500000000 against an expected 10000000000.

Verification

forge build                      ok
forge test (seed pinned)         68 passed, 0 failed, 9 invariants passed
forge fmt --check on new files   ok

Nothing outside test/ was modified, nothing was installed, and the scratch reproduction lives under test/scratch, which is discarded. The findings file is excluded from git by the harness's own exclude list, so it is read from disk as intended.

The review is complete. The findings file is at .imd-findings.json and no tracked file was changed.

Outcome. The six specialist reports collapse into two real defects and one note. I reproduced each against the code with Foundry before keeping it, and the existing suite of 68 tests passes unchanged.

Findings kept

• Medium, merged from four reports: a deferred fee's burn half is burned out of the float the hook already holds. When the PoolManager cannot pay a fee inside the swap, the hook mints a claim but still adds half the fee to burnOwed, and the burn that follows spends existing float. Book value falls, a tender in that window underpays or reverts, and ask can revert, until someone redeems. The specialist proof fails on this code as stated. I also showed the deferral is reachable at will: any swapper can take the manager's IMD inside its own unlock before swapping, which zeroes book value for the window. The proof file is attached to the finding.
• Low, merged from three reports: ask hard-codes the Intake price at 0.5 IMD with no owner, so a repriced or moved Intake ends the weekly report permanently. Verified with a repriced Intake stand-in. This follows the brief's no-admin rule, so it is recorded as a trust decision for the author.
• Info: pendingFloat counts any IMD claim pushed onto the hook, not only deferred fees. Harmless, behaves as a donation.

Dropped. The sub-100-wei fee rounding note matches launch #1330's measurement and the README, so it is not a defect.

Coverage. All 12 entry points are answered, plus three invariant rows and the manifest. Nine hold. afterSwap and tender carry finding 1, ask carries finding 2. The manifest's constructor arguments, permissions, fee, and notes length check out, and the hook's runtime size is within the limit.

The file is excluded by the harness's own .git/info/exclude entry alongside .imd/, so it is picked up from the working tree rather than from a commit. That is the expected layout. The work is complete.

Outcome. The reopened medium finding reproduced and is fixed. The two advisory findings reproduced but are by design, and both are answered as disputed with the reasoning in .imd-responses.json.

What was wrong. When the PoolManager could not pay a fee inside the swap, the hook minted the fee as a claim but still added half of it to the burn debt at once. The next burn then paid that debt out of IMD the hook already held, so a deferred fee lowered book value, underpaid tenders, and could block asks until someone redeemed the claim. Any swapper could trigger this at will by emptying the manager's IMD inside their own unlock before swapping.

The fix in src/PerkVaultHook.sol, the minimal one the reviewer proposed:

• New storage counter for the burn halves of fees still pending as claims, plus a view for the burn that is due now.
• The burn only sends what is owed beyond the deferred part. The float, book value, tender quote, and the ask minimum subtract only that part.
• Redemption, whether by the permissionless redeem or by the next swap's flush, releases the deferred part against the redeemed IMD first, so it never exceeds what is owed or pending.

Tests. Six regression tests were added in the deferred-fee section of the hook suite, including the reviewer's scenario with the correct intermediate state, a forced-deferral attacker contract in test/mocks/ForcedDeferral.sol, a large buy exceeding the manager's IMD, a partial redemption, and a fuzz that no swap, redeem, burn or donation ever lowers book value. Build, format check, and all 69 tests pass with the verifier's fuzz seed.

Why the proof is disputed rather than marked fixed. The reviewer's proof asserts, before its final check, that the dead address already received 0.5 IMD, that burn debt is zero, and that the hook holds 9.5 IMD. Those three assertions are the defect itself, and no implementation that keeps the float whole can satisfy them. On the fixed tree the proof fails only on that line, and the same test with those three assertions removed passes. The response file states this with the exact numbers so the reviewer can confirm.

Documentation. The README now describes the deferred burn accounting, the updated tender and ask formulas, the new views, the keeper note, and records the fixed Intake price and the pushed-claim behaviour as deliberate choices.

Build and all 69 tests pass. The manifest in the tree already describes the accepted implementation exactly, so no revision was needed.

What I verified in launch.json against the source

• Discriminator: the first field is "kind": "univ4_hook".
• Hook contract and constructor: PerkVaultHook takes four arguments in declaration order. The manifest lists them as $poolManager, $token, the IMD address the brief fixes, and $factory. The IMD address is a value the brief gives, not a stand-in, and it is written in lowercase.
• Permissions: the hook's getHookPermissions enables beforeInitialize, beforeSwap, afterSwap, beforeSwapReturnDelta and afterSwapReturnDelta. The manifest lists exactly those five, which is what the protected permissions test compares the mined address against.
• Token: PerkToken has no constructor arguments, name "Perkshire IMDway", symbol "PERK", 18 decimals. All three match the manifest.
• Pool: paired currency is IMD, fee 12500, tick spacing 60, initial price "79228162514264337593543950336", as the launch reference gives them.
• Notes: one string of 1935 characters, under the 4000 cap. It names the binding rule, the fee split, deferred claims, burn, tender, ask and the absence of any owner or upgrade path.

Checks run

forge build   -> ok
forge test    -> 4 suites, 69 passed, 0 failed

No file was changed. The working tree is identical to the accepted commit, so the submission is the existing launch.json.

Your existing tests now pass against the revised hook: forge test with the verifier's seed runs 74 tests in 6 suites, all passing. Only the 9 invariants, which run as a single suite, had broken. Each invariant ran 128 random sequences of 50 calls, and every handler action was exercised.

What broke. Since my last round, the hook's author added deferredBurn. When a fee can't be paid out yet, its burn half now waits for that fee to be redeemed instead of being paid from IMD the hook already holds. So the burn can only take burnDue() (burnOwed - deferredBurn) from the hook's balance. My invariant suite still assumed the old rule, where the burn could use all of burnOwed, and it failed on the first short sequences.

What I changed (only in test/invariants/PerkVaultHandler.sol and test/invariants/PerkVaultInvariants.t.sol; the other test files are untouched):

• After burn(), the check is now that either burnDue() is zero or the hook holds no IMD.
• New invariants:
  • deferredBurn is never more than burnOwed or the pending fees.
  • burnDue() equals burnOwed - deferredBurn.
  • The float equals the hook's IMD balance less burnDue.
  • The hook's IMD balance always covers burnDue.
• Every swap, paid at once or deferred, must now leave bookValuePerPerk unchanged or higher. Before the fix, a deferred fee could lower it; my old handler allowed that and pointed to the earlier finding.
• A deferred swap must add exactly half its fee to deferredBurn.
• A donation must raise the float by exactly the amount donated.

One finding, info level, in .imd-findings.json. The brief says a tender pays amount * (hook's IMD balance less burnOwed) / circulating. The revised hook subtracts burnDue instead, and the ask threshold and bookValuePerPerk do the same. I confirmed this with a scratch test:

• Setup: a pool with PERK-only liquidity, 10 IMD donated to the hook, then a 100 IMD buy whose 1 IMD fee is deferred.
• Result: tendering the whole circulating supply would pay 10 IMD. The brief's formula gives 9.5 IMD.

The invariants show this is solvent: the pending fees cover deferredBurn, and every burn half still reaches 0x…dEaD exactly once. It is still a departure from the formula you wrote, so you should confirm it is what you want.

Nothing has been committed.

Review complete. The findings file holds an empty findings list with a 15-row coverage record, and no tracked file was changed.

The medium finding is fixed. The author implemented exactly the fix I proposed: a deferredBurn counter records the burn half of fees still pending as claims, the burn sends only burnOwed - deferredBurn, book value and tender payouts subtract only that part, and redemption releases the deferred half first. I re-ran my attached proof on the revised code. It fails only at my own assertion that the dead address holds 0.5 IMD right after the deferred buy, which was the defective state the finding complained about, so the author's dispute of that assertion is correct. With those three lines removed both tests pass and book value is unchanged across the deferred buy. Independent scratch checks also pass:

• A third-party claim redeemed ahead of a deferred fee pays the deferred burn half first. Book value does not move, and the dead address ends with exactly one burn half once all claims are redeemed.
• A full tender of all PERK inside the deferral window pays the whole float on hand, and the burn half still reaches the dead address once after the redeem.

The two advisory items are dropped. The fixed 0.5 IMD Intake price follows the brief's wording and the no-admin rule, and the README now states plainly that a repriced or moved Intake ends asks with nothing spent. The pushed-claim behaviour of pendingFloat is documented in the natspec and README and only raises book value.

Nothing new. The full suite passes with the author's fuzz seed, 74 tests including the invariant suite. The manifest's constructor arguments, permissions, fee, tick spacing, price and notes length all check out against the code.