feat: added pool key registration#164
Draft
mgretzke wants to merge 1 commit into
Draft
Conversation
zhongeric
reviewed
Jun 8, 2026
Comment on lines
+134
to
+139
| if (!ERC165Checker.supportsInterface(hook, type(IInitializerHook).interfaceId)) { | ||
| revert InvalidHook(hook); | ||
| } | ||
| if (IInitializerHook(hook).authorized() != address(this)) { | ||
| revert InvalidHook(hook); | ||
| } |
Collaborator
There was a problem hiding this comment.
Did you split these up for readability?
Collaborator
There was a problem hiding this comment.
Delete this file? Not sure what this is for
Comment on lines
+236
to
+237
| // Ensure the pool id is still registered, to prevent replay attacks | ||
| if (registeredInitializers[poolId] != address(initializer)) revert InitializerNotRegistered(initializer); |
Collaborator
There was a problem hiding this comment.
this is to prevent a hook (for example) re-entering this function?
Comment on lines
+452
to
+474
| function _createPoolKey(address currency, address token, uint24 lpFee, int24 poolTickSpacing, address hook) | ||
| private | ||
| pure | ||
| returns (PoolKey memory key) | ||
| { | ||
| return _createPoolKey(Currency.wrap(currency), Currency.wrap(token), lpFee, poolTickSpacing, hook); | ||
| } | ||
|
|
||
| function _createPoolKey(Currency currency, Currency token, uint24 lpFee, int24 poolTickSpacing, address hook) | ||
| private | ||
| pure | ||
| returns (PoolKey memory key) | ||
| { | ||
| key = PoolKey({ | ||
| currency0: currency < token ? currency : token, | ||
| currency1: currency < token ? token : currency, | ||
| fee: lpFee, | ||
| tickSpacing: poolTickSpacing, | ||
| hooks: IHooks(hook) | ||
| }); | ||
| return key; | ||
| } | ||
|
|
Collaborator
There was a problem hiding this comment.
No reason to have both of these imo.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reserve migration pool keys to prevent shared-key migration griefing
Addresses audit finding #1 ("Shared pool-key reuse can force launches into recovery instead of liquidity migration").
Problem
LBPStrategynever reserved a launch's final v4 pool key at registration. The pool was only initialized later duringmigrate(), so a competing launch sharing the same(currency, token, fee, tickSpacing, hook)could initialize the shared key first and force the victim's migration into the recovery path instead of creating liquidity.Changes
initializeDistribution()now derives the finalpoolIdand recordsregisteredInitializers[poolId] = initializer, revertingPoolIdOccupiedif the key is already taken. Replaces the previous per-initializerreservesmapping.validateHookrejects already-initialized pools. ThegetSlot0check now runs for every hook (includingaddress(0)), so a doomed launch fails fast at registration.migrate()clears the reservation before attemptingtryMigrate, so neither a successful migration nor a recovery can be replayed (closes a double-migrate path that could re-trigger recovery and pay outreservedTokenAmountForLPagain from the shared singleton balance)._initializePool; the migration now uses exactly the reserved key.Result
Open question — should we block
hook == address(0)?The reservation is a strategy-side claim; it cannot bind the PoolManager. v4 has no pool-key reservation primitive — a key is uninitialized or initialized (one-way, permanent), and the only gate on who may initialize is the hook's
beforeInitialize. A hookless (hook == address(0)) pool has no gate, so anyone can front-runpoolManager.initializeon the raw key during the auction and force the launch into recovery — for the cost of a single call. This is exactly the reported PoC (vector 1) and it is not closed by reservation; removing the old fallback actually made it cheaper (no competing auction required).Since a gated hook is the only v4 mechanism that can protect the key, proposal: require a hook (reject
hook == address(0)), with options:validateHookto allowhook == address(this)(skip theIInitializerHookERC165/authorized()probe, sinceSelfInitializerMixinalready self-gates init). Fully safe for fresh-token launches; mild residual registration-squat for already-circulating tokens (shared key, needs token supply, reroute via different fee/tickSpacing). Static-fee only.LBPStrategyHook, currently stubbed) — unique address per launch ⇒ uniquepoolId⇒ no shared-key collisions at all. Eliminates the residual, at the cost of per-pool hook discovery for routing.Decision needed before merge: keep
hook == address(0)supported (and document it as best-effort / recover-only) or block it and pick option 1 or 2.Follow-ups / nits
_initializePoolstill describes the removed fallback.PoolIdOccupiedrevert suggestsaddress(0)/ the strategy address as alternatives —address(0)is the unprotected option and the strategy address currently failsvalidateHook.