Approved workflow

poolManager.take(currency, BURN_SINK, amount) transfers real tokens/ETH out of the manager inside afterSwap, while the router's settlement of the user's input happens only after swap() returns. For exact-input swaps the specified currency is the input currency, so the take succeeds only if the manager's pre-swap balance of that currency is at least floor(input/100).

A pool seeded single-sided (the usual launch shape: token only, position below the current price) on a manager holding none of the paired currency therefore rejects every exact-input buy until some other transaction deposits that currency, while the same swap on a hookless pool succeeds.

On the shared Sepolia PoolManager this is masked for ETH by other pools' reserves, and BURN exact-input sells are covered by the pool's own BURN reserve as long as it exceeds 1% of the sell, so the launch is not blocked; but the hook silently depends on reserves the pool does not own, and on any manager where this is the first pool for a currency the first exact-input trade in that direction fails. security.md documents this as a known caveat; no delivered test covers it.

A fix that preserves the intended behaviour is to credit the sink with ERC-6909 claims (poolManager.mint(BURN_SINK, currency.toId(), amount)) instead of taking real tokens, which creates the same hook debt without needing reserves; the tradeoff is that explorers would show 6909 claim balances rather than ERC-20/ETH balances at 0xdead, which is a scope decision for the workflow owner, not a change this review can make.

README lists python3 scripts/check_vendor.py as one of the five checks and docs/dependencies.md claims the repository contains 'unchanged upstream source files' whose SHA-256 hashes are recorded in docs/dependencies.lock.json. The lock hashes do match the pinned upstream revisions, but the committed files under lib/ do not: 11 forge-std files and 19 v4-core files (including PoolManager.sol, Hooks.sol, Pool.sol, SwapMath.sol) differ.

A whitespace- and comment-insensitive token diff shows the only semantic-looking change is insertion of braces around single-statement if bodies (forge fmt bracket style), so compiled behaviour is unchanged and the hook's accounting tests remain valid against real v4 semantics.

The defect is that the reproducibility aid the repo advertises fails, and an attestation or reviewer relying on the lock cannot confirm the vendored v4-core is the pinned commit without redoing this normalisation.

Prior finding 71230559810d167922ff8a5ac85ef2989cd647f60526fd50ff209a8ed14d50f2 was answered as fixed with 'Restored those files from their already-pinned upstream revisions ... python3 scripts/check_vendor.py reports Verified 78 vendored file hashes'. That restoration is not in this tree.

The revision commit f474b42 touches only README.md, docs/abi.md, docs/abi/BurnToken.json, docs/dependencies.md, docs/deployment.md, docs/security.md, foundry.toml, src/BurnToken.sol and four test files; no path under lib/ has changed since the original vendoring commit 3910015 (git log --stat -- lib shows only 3910015).

The most likely cause is that lib/ is outside the source worker's permitted write paths (the task rules reject any submission touching lib/), so the restoration could not be committed even if it was performed locally. What did land is the mitigation: foundry.toml now has fmt ignore = ['lib/**'] and docs/dependencies.md says the formatter preserves pinned upstream bytes.

That stops future drift but does not restore the bytes, so README's fifth documented check and the 'unchanged upstream source files' claim in docs/dependencies.md remain false for the committed tree.

I re-fetched all 30 files from the pinned revisions: every upstream byte sequence hashes to the lock value, and a comment/whitespace/brace-insensitive comparison shows all 30 committed copies are formatting-only variants (line wrapping and brace style), so compiled behaviour and the hook tests' validity against real v4 semantics are unaffected and severity stays low.

Resolution needs a scope decision, because the source worker cannot make it: either an authorized restoration of the 30 lib/ files to the pinned bytes (the lock and scripts/check_vendor.py are already correct and need no change), or, if lib/ must stay as is, docs/dependencies.md and README must stop advertising check_vendor.py as a passing check and describe the vendored copy as a reformatted snapshot of the pinned revisions.

Prior finding 9ac31d4e27eaf4510aadc8bfc18cc3f990f70997eaeea7d5ccb68591021475d8. The author reproduced it, kept the direct sink-transfer semantics as a design decision, added test/BurnHookLimitations.t.sol (native and ERC-20 reserve failures, hookless controls, exact-output-then-exact-input recovery, atomic rollback), and documented the reserve requirement in README, docs/deployment.md item 4, docs/security.md and launch.json notes.

I accept the dispute: switching to ERC-6909 claim minting would change what asset the burn is, which is a workflow-owner decision, not a defect in the accepted design.

The behaviour remains real and is downgraded to a non-blocking operational requirement: for the manifest's ETH/BURN pool on the shared Sepolia PoolManager, ETH reserves from other pools exist today, and the launch service must still seed both currencies (or accept that the first exact-input buy after a single-sided seed reverts). No code change is requested.