Implemented the immutable 1% burn hook, fixed-supply BTAX token, vendored dependencies, tests, and deployment documentation.

Verified:

• forge build
• forge test: 38 passed
• forge fmt --check
• Clean offline build and tests with an empty test environment

README documents rounding, deployment, and limits: taxed BTAX-specified partial fills revert; sells with empty manager BTAX reserves require router prepayment.

Created launch.json with matching contracts, constructor placeholders, permissions, and native ETH pool parameters.

Schema validation and ABI checks passed. forge build succeeded; all 38 tests passed. Only launch.json is changed outside scratch artifacts.

Recorded one medium finding in .imd-findings.json: insufficient existing BTAX reserves block otherwise executable sells.

Included a concrete reproduction and coverage for all four entry points. All 38 existing tests passed; the reserve test explicitly expects this failure. No source files changed.

Recorded one medium finding in .imd-findings.json: ordinary sells revert when PoolManager lacks BTAX reserves for the immediate burn.

Coverage: 4/4 entry points. All 38 repository tests pass; one explicitly reproduces this expected revert. Production files unchanged.

Recorded no substantiated defects and coverage for all four required entry points in .imd-findings.json.

All 38 existing tests and 3 additional numerical tests passed. Temporary artifacts were removed; implementation files remain unchanged. Protected verifier and fork tests were not run.

This content was flagged for possible cybersecurity risk. If this seems wrong, try rephrasing your request. If you’re doing authorized security work that requires more cyber permissive safeguards, apply for Daybreak access via https://platform.openai.com/settings/organization/status-and-access before retrying.

The review is complete. Findings and coverage are in .imd-findings.json; no repository file was changed, and the scratch tests live only under test/scratch/.

What I found

1. Medium: sells revert when the PoolManager holds under 1% of the sale in BTAX. The hook calls take inside afterSwap, before any swap-then-settle router has paid the trader's BTAX in. Buys are always funded by pool output, but sells depend on BTAX already sitting in the manager. After buyers exhaust a bounded-range launch position, the manager holds 1 wei of BTAX and over a million ETH, and every sell of 100 wei or more through an ordinary router reverts with ERC20InsufficientBalance wrapped in HookCallFailed. The proof at test/scratch/BurnTaxSellReserves.t.sol fails on this tree and passes against a variant that mints an ERC-6909 claim when the balance is short. That is the fix the task reference prescribes, and it keeps the 1%, the dead recipient and the no-admin design.

2. Low: taxed specified-side swaps refuse partial fills. An exact-input sell of 10,000 BTAX with a price limit at tick 60 fills 3013 BTAX on the hookless control pool but reverts with PartialFillWithSpecifiedTax on the hooked pool. The README documents this limit, so it is reported for the author's decision.

3. Info: beforeInitialize validates nothing. A dynamic-fee BTAX pool with this hook initializes and trades at a permanently zero LP fee because the hook never sets one. Nobody loses funds, and the fee tiers are enforced by the manifest, so this is informational.

What holds

All three callbacks restrict the caller to the immutable PoolManager, the hook has no mutable state, admin, withdraw or upgrade path, and the return deltas net to zero in all eight swap modes across both currency orderings. The specified and unspecified branches charge the same tax in both directions, and the pool's LP and protocol fees are untouched. The token is unmodified OpenZeppelin ERC20 with a constructor-only mint, so its three entry points hold. All four listed entry points have coverage rows, plus seven invariant rows.

The findings file is in place at the repo root; it is excluded from git by the harness's own .git/info/exclude, which is expected for that protocol file. Nothing else remains.

Outcome

forge test passes: 58 tests across 8 suites, 0 failures, with the sequence invariants also green under two extra fuzz seeds. One defect was found that cannot be tested around, so it is reported in .imd-findings.json with a runnable proof rather than asserted as correct.

What I delivered (all under test/)

• test/BurnTaxHookEdges.t.sol (18 tests): exact Burned payloads for all four modes in both currency orderings, derived from an unhooked control pool; dead-address monotonic accumulation and that only BTAX ever reaches it; pools at the 500 and 10000 fee tiers; protocol fees enabled; a dynamic-fee pool; hookData ignored; the same swap twice; a zero-liquidity pool (taxed specified trade refused atomically, zero-tax and unspecified trades report a zero burn); dust-splitting under 100 wei; ether and unknown selectors rejected; the exact int128 boundary for both specified directions; beforeSwap and afterSwap driven directly with crafted deltas, including the partial-fill refusal ordering and the overflow guard firing before any take. Two fuzz properties read the hook's own return to prove the exact-output gross-up is minimal and the exact-input tax can never consume the whole input.
• test/BurnTaxSequenceInvariant.t.sol: a handler with three traders, both pool orderings, all four modes, tight price limits, and liquidity adds/removes. Every hooked swap is mirrored on an unhooked control pool with the gross amount. Invariants: hooked pool price, tick, liquidity and fee growth equal the control after any sequence; dead balance equals the sum of burns and stays within rounding of 1% of gross volume; supply fixed and fully accounted for with the hook holding no tokens and no ERC-6909 claims; manager fully settled after every call. The only revert ever accepted is the atomic partial-fill refusal, which a scripted run confirms is reached.
• test/BurnTaxTokenInvariant.t.sol: random transfers, pulls, overdraws and admin-call attempts among five holders; supply stays fixed and fully held.
• test/helpers/BurnTaxFixture.sol: one small change. The fixed-address mock tokens are now deployed from compiled creation code instead of an artifact lookup, which removes the only filesystem-dependent step in the accepted fixture.

Findings reported

• Medium. Sells revert through ordinary post-settlement routers once the manager holds less BTAX than the tax. After a token-only launch range is bought out, the first sell through v4's own router reverts inside afterSwap because the burn is paid by immediate take before the trader's input is settled. Proof under test/scratch/BuyoutSellLock.proof.t.sol, embedded in the findings file; it fails on current code with the exact wrapped error. The existing reserves test asserts this revert as expected behaviour, which is why I flagged it instead of extending that assertion.
• Low. beforeInitialize accepts the dynamic-fee flag, so anyone can open a taxed BTAX pool whose LP fee is permanently zero.
• Info. Taxed specified trades cannot partially fill, and BTAX legs under 100 wei are untaxed. Both are documented limits and are pinned by tests.

Notes

• The README lives outside my allowed paths, so the README deliverable was left as the earlier contributor wrote it. It already states the rule and the limits above.
• I did not commit; the working tree holds the three new files, the fixture edit, and the findings file.

The review is complete. .imd-findings.json is written at the repository root with 3 findings and 13 coverage rows. No tracked file was changed; the findings file and my scratch tests sit on paths git already excludes.

Outcome of the specialist panel

• Kept, merged, medium: the sell-lock. All four specialists and the tester reported the same root cause, so it is one finding. afterSwap calls poolManager.take for the burn before any ordinary router has settled the seller's BTAX. When the manager holds less BTAX than the 1% tax, the transfer reverts and the whole sell fails. I reproduced it with the permissions specialist's proof, which fails on this tree with the exact wrapped ERC20InsufficientBalance error and is attached as the proof. I sharpened the precondition: in a single-pool manager it is reached once roughly 99% or more of the in-range BTAX is bought out, because smaller buyouts hit the partial-fill revert first. No funds are lost, so medium rather than high.
• Dropped proof: the tester's proof file fails on this tree but with PartialFillWithSpecifiedTax, not the reserve error, because its thin range cannot absorb the sell after the buyout. It does not demonstrate the stated defect, so it was not carried.
• Kept, merged, low: taxed exact-input sells and exact-output buys refuse partial fills. My probe showed the hookless control pool filling to a price limit while the hooked pool reverts atomically. Documented and loss-free, so low.
• Kept, merged, low: beforeInitialize accepts the dynamic-fee flag and fee 0, giving a parallel BTAX pool with a permanent 0% LP fee. Reproduced on a fresh manager. The launch pool itself is unaffected.
• Dropped: the dust-splitting note. Legs under 100 wei burn nothing, which is the inherent integer floor of a 1% rule and is documented. It is recorded as a checked invariant, not a defect.

My own pass found nothing beyond these. Delta accounting cancels exactly, the tax can never flip the swap sign into a NoOp, all callbacks are gated to the PoolManager, the address bits match the manifest's permissions, and the token is unmodified OpenZeppelin ERC20 with a one-time mint. The static-analysis leads are benign defaults and a harmless event-after-call ordering. The three token entry points hold; afterSwap carries the medium finding.

The full suite passed on a clean offline run before the scratch files were added, with 58 of 58 project tests green.

All three findings reproduced and are fixed. The working tree is clean, committed, and the responses file is in place.

Main finding (sells revert when the manager holds less BTAX than the 1%): reproduced with the reviewer's proof, which failed on the starting tree with the exact wrapped ERC20InsufficientBalance error. The cause was the hook calling take to DEAD inside afterSwap, before an ordinary router has settled the seller's input. The hook now reads the manager's BTAX balance first. When it covers the tax, the burn is immediate as before. When it does not, the hook mints the tax as its own ERC-6909 claim and emits BurnDeferred after Burned. A permissionless burnPending() unlocks the manager, burns the whole claim and takes it to DEAD. The next swap whose reserves cover both its own tax and the pending claim also redeems the claim automatically, so no operator is needed. The claim can only ever reach DEAD. The proof now passes.

Advisory finding on partial fills: the atomic revert for taxed exact-input sells and exact-output buys is kept, because the tax is reserved from the requested amount in beforeSwap and a partial fill would overcharge with no BTAX-side refund possible. I applied the reviewer's suggested alternative and documented the router requirement in the README: use the extreme price limits plus a minimum-output or maximum-input check on the final delta.

Advisory finding on dynamic-fee pools: reproduced. beforeInitialize now rejects the dynamic-fee flag and any static fee outside 500, 3000 and 10000 with UnsupportedPoolFee, for all pools using the hook. The three launch tiers remain accepted, so the launch can still initialize.

Verification, from a clean build in an empty environment:

New tests cover the deferred sell on a fresh manager, exact-output sells, the bought-out launch pool scenario from the finding, automatic redemption by the next covered swap, gifted claims, nested-unlock and unauthorized-callback refusal, the empty-claim revert, and the refused fee tiers. The README gained a "Deferred burns" section plus the fee rule and router requirement, and SECURITY.md rows were updated. .imd-responses.json answers all three findings as fixed, with what was run and what changed.

Done. The manifest is the only changed file and it passes every check I could run locally.

What I found. The existing launch.json already had the right structure: contract names BurnTaxHook and BurnTaxToken, constructor arguments $poolManager then $token, the five permissions the hook declares, token metadata BurnTax / BTAX / 18 decimals, native ETH as the paired currency, LP fee 3000, tick spacing 60, and an initial price of 2^96 as decimal. The notes, however, still described the burn as always immediate via a direct transfer. The accepted hook now checks the PoolManager's BTAX balance first and, when a sell's tax cannot be funded yet, mints the tax to itself as an ERC-6909 claim, emits a second event, and exposes a permissionless redemption that sends the claim to the dead address. The next covered swap also redeems it automatically.

What I changed. Only the notes field. It now describes the covered and deferred burn paths, the three events, the redemption function, the partial-fill revert, the fee tiers beforeInitialize accepts, and the fact that no ETH ever goes to the dead address. Everything else in the manifest is untouched.

Verification.

• Full suite from a clean build, run offline with an empty environment: 46 tests passed, 0 failed.
• Manifest checked against the schema by script: first key is kind, no extra fields, patterns and enums satisfied, initial price below 2^256.
• Declared permissions map to flag bits 0x20cc, the same value the hook's getHookPermissions produces and the constructor validates.
• Notes length is 3141 characters, under the 4000 cap.
• git status --porcelain shows only launch.json modified. No scratch files were left in the tree.

The change is left uncommitted in the working tree, since the assignment asked for the file rather than a commit.

Done. The full run is green: 68 delivered tests across 9 suites pass, plus the 2 scratch copies that are discarded before verification.

What was wrong. The rejected attempt reported a runtime error, and the tree as handed to me reproduced it: forge test failed on one of my previously accepted tests. The hook author's later commit changed beforeInitialize to refuse the dynamic-fee flag and added a deferred-burn claim path, after my edge test had been written against the older hook that accepted dynamic fees. The test asserted the old behaviour, so it reverted in the PoolManager.

What I changed, all under test/:

• Revised the stale test in test/BurnTaxHookEdges.t.sol. It now checks the current rule: initializing a dynamic-fee pool with this hook reverts with UnsupportedPoolFee, the pool is never created, a swap aimed at it fails with PoolNotInitialized before any hook callback runs, and nothing is burned. The rest of the file is untouched.
• Added test/BurnTaxDeferredInvariant.t.sol, because the revised hook now holds value as an ERC-6909 claim and no existing invariant exercised that path under random sequences. The handler drives a fresh native-ETH/BTAX pool on a PoolManager that starts with zero BTAX, using three traders and eight actions: ordinary sells that must defer, prepaid sells that burn at once, buys that redeem, a drain that buys out the range so deferral recurs, burnPending, third-party claim donations, and liquidity changes. Invariants: dead balance plus pending claim equals everything taxed or donated, the claim is always backed by the manager's balance so redemption cannot fail, supply is fixed with nothing stuck in the hook or routers, and the manager is fully settled with the pool's own LP fee intact. A deterministic test walks the handler through every branch and checks its counters, so the invariants are provably non-vacuous.

Verification. The new file passed under six fuzz seeds, and a scratch copy at 300 runs and depth 120 also held. No test uses vm.setEnv, ffi, or the filesystem. I found no defect in the implementation that I could not test around, so there is no findings file to report.

Review complete. All three findings from the previous round are settled as fixed, and I found no new reproducible defect. The result is written to .imd-findings.json with an empty findings list and a ten-row coverage record. The tree is otherwise unchanged.

What I verified

• Medium, sells revert when the manager holds under 1% BTAX. Fixed. Both attached proofs now pass on this tree. The hook reads the manager's BTAX balance in afterSwap and, when it cannot cover the tax, mints the amount as its own ERC-6909 claim instead of transferring. My own probe on an ETH-only seeded pool confirmed an exact-input sell of 777 BTAX executes with the full input charged and 7.77 BTAX pending, an unrelated address redeems it to DEAD through burnPending, an exact-output sell defers the grossed-up tax, and the next buy redeems the claim automatically while still paying the buyer its correct net.
• Low, taxed partial fills revert. Settled by documentation, as I proposed. The revert is kept and the README now states the router requirement to use MIN/MAX price limits with output or input checks.
• Low, dynamic-fee and zero-fee pools accepted. Fixed. beforeInitialize refuses the dynamic flag and any fee outside 500, 3000 and 10000, and the three tiers still initialize.

Checks run

• Full project suite offline: all tests and invariant suites pass.
• Protected floor tests for hook and token, run with the compiled creation code supplied through the expected environment variables: all pass.
• Slither leads: the uninitialized locals are intentional zero defaults, the ignored unlock return is harmless, and the post-call events have no reentrant path. None is a defect.

Not done

I attached no proof, since there is no finding to prove. My scratch tests were deleted after running so the submission changes only the findings file.