Skip to content

Conversation

Ponx
Copy link
Contributor

@Ponx Ponx commented Oct 9, 2025

This PR introduces a new extensible structure for hooks to be added to Uniswap Labs routing utilizing the HookRegistry schema. As a result, this PR heavily modifies how the list of allowed hooks is generated, and simplifies the logic for manually inflating pool TVL

Summary

  • Adds a new hooks directory which is where hook PRs will be added going forward (lib/util/hooks/prod)
  • Updates all existing allowed hooks to the HookList schema and includes them in the new hooks directory
  • Scales the logic for manually inflating pool TVL
    • Pools specified in a hook with non-zero TVL are picked up for manual TVL inflation
    • Pools may be configured with zero TVL for future use cases of testing routing through a sample pool without modifying the pool's TVL.
  • Scales the logic for manually adding pools to the pool cache
    • Pools specified with all required fields are picked up for addition to the pool cache
  • Reduces the logic for bypassing Zora pools (by relying on HookRegistry keywords)
  • Replaces the use of bunni-pools.ts, but preserves the ability for the Bunni team to self-manage their own HookList.

Details of Major Changes in hooksAddressesAllowlist.ts

HookLists
Previously hooksAddressesAllowlist.ts was a straightforward list of hardcoded hook addresses which were compiled into a single array of hook addresses mapped to chain IDs. Due to the expectation that more hook metadata (not-on-chain) information will be needed by more services and features in the future, it was necessary to start capturing more information than just a hook's addresses. To support this, the HookList format proposed by Uniswap Foundation is used to include metadata with each hook.

To allow hook builders to provide PRs and modify their hook and pool lists without interfering with other hook builders' PRs, it made sense to allow multiple HookList files to be provided, so that a hook builder can have their own list which they maintain. Therefore, the lib/util/hooks/prod directory allows multiple HookLists to exist. Those hooks that have been ported into the HookList format include some for specific builders with many pools or hooks, and one general.json file for one-off hooks that are allowlisted. Going forward, hook PRs should be formatted in the prescribed HookList format, and may add additional metadata, which may be used by Uniswap Labs for display or additional information lookup.

Allowed Hooks List Building
The hooksAddressesAllowlist.ts is restructured to be a reader of HookList files, with the output being array objects of specific information needed by different processes. This may evolve further in the future to simply compile all available HookList metadata into an array so that any process can use the single standard data format. But for now, two different lists are produced:

  1. Replacing the original HOOKS_ADDRESS_ALLOWLIST, the updated version is now an array of objects keyed by chain ID. The reason for replacing the hook address string with a hook object is that more information can be passed downstream, specifically the HookList keywords, which are used further on in the v4HooksPoolsFiltering.ts to identify Zora pools, which have special handling logic. The Hook name is included but not used.
  2. Adding a new HOOK_POOLS_DATA, which is an array of pools utilizing the V4PoolData structure. This is used in v4HooksPoolsFiltering.ts to manually override pool TVL and in cached-pools.ts to set specific hooked pools into the cache of pools. These changes shift hardcoding of pools from functions out to the HookLists so that functional logic and hardcoded values are separate.

The hooksaddressAllowlist.ts is designed to support the addition of future HookLists. It also specifies the expected format of the modified HookList by defining the interface of a HookList.

Detail of Major Changes in v4HooksPoolsFiltering.ts

In the prior logic, v4HooksPoolsFiltering.ts performed two key functions which have been updated:

  1. It manually inflated the TVL of pools based on a hardcoded list of pools and their desired TVLs. This has been simplified by pre-compiling the list of pools in hooksAddressesAllowlist.ts and only performing the manual override in the v4HooksPoolsFiltering.ts The updated logic only checks for pools which have non-zero TVLs. Zero-TVL pools may be defined for a hook so that the hook's routing can be tested ahead of allowlisting - currently a manual process but eventually to be automated.
  2. It reviewed pools with a Zora hook and performed additional processing to include or disinclude them from the ultimate list of routable pools based on their TVL. This is now accomplished by checking which hooks have the "Zora" keyword from the HookList which specifies Zora hooks. This removes any hard-coded values from v4HooksPoolsFiltering.ts and instead gives it the information it needs in a scalable way to perform logic on a subset of the allowed hook list. This logic is a little brittle because it relies on a harcoded keyword, but this trades off against the simplicity of expanding this logic (as may be needed in the future) by simply adding keywords to HookLists and performing processing here.

Details of Major Changes in cache-pools.ts

Previously several specific pools were hardcoded so that they would be populated into the V4 pool cache in case they are not picked up by the pool identification logic. Now, any pool which is provided through a HookList and which contains sufficient information (feeTier, tickSpacing, liquidity, token, and TVL) will be placed into the pool cache. This updated logic required all hard-coded pool information to be moved into the appropriate HookList. It also replaces the previous logic specific to bunni pools, allowing the full removal of the bunni-pools.ts file. This updated logic infers that a complete set of pool details in the HookList means that a pool should be cached.

Misc.

  • The extraV4FeeTiersTickSpacingsHookAddresses.ts used a single hardcoded value from hooksAddressesAllowlist.ts. The effort to add file reading to this file to find that address was too high for the use case, and other hardcoded values already exist in this file. Therefore, the hardcoded Sepolia hook address has simply been moved into this file.
  • The bunni-pools.ts has been removed since its information has been collected into the bunni.json HookList.

Resolved ROUTE-635

@Ponx Ponx marked this pull request as ready for review October 10, 2025 19:24
Copy link

@johnsmithy4k-bit johnsmithy4k-bit left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Process completed with exit code 1.

try {
const files = fs.readdirSync(hooksDir).filter((file) => file.endsWith('.json'))

for (const file of files) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: we can parallelzie the file read.

}

function loadAllHookFiles(): HookFile[] {
const hooksDir = path.resolve(process.cwd(), 'lib', 'util', 'hooks', 'prod')
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

also, im a bit unsure if we want to read from local actually, because we usually read from https://raw.githubusercontent.com. in future, when we want to externalize the hooks config into a standalone github repo, it's easier to make the change

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants