Source: Chain Community
Original link: https://mp.weixin.qq.com/s/Jz3ONarTdRuCEzJ0_PfjrQ
Hooks are the defining feature of Uniswap v4, enabling developers to customize and extend the behavior of liquidity pools. In this guide, our goal is to establish a standard for hook developers, hook data indexers, and analysts so that all users, from developers and LPs to analysts, can use the same shared framework when working with hook data.
Hooks and Uni v4
But first, let's clarify how hooks fit into v4. They can be viewed as plugins or external APIs for the PoolManager contract. Each pool can only be linked to one hook, but a single hook contract can serve multiple pools. Once a pool is initialized with a hook, it becomes a "hooked pool" (as opposed to a "vanilla pool"), and the hook itself is considered "initialized". In contrast, a hook contract without a pool is just an unused Solidity contract that implements a subset of the core hook functions.
Remember that Uniswap v4 is a singleton: PoolManager manages all v4 pools and their states from one place. The visualization below shows how these components—pools, hooks, and PoolManager—are associated.
Hook Standards
While hooks can contain any Solidity code, they are all anchored to 10 core hook functions in Uniswap v4. These functions correspond to key points in the pool lifecycle (such as before/after swaps or liquidity modifications) and provide clear "entry points" for customization. For reference, see the Hooks.sol contract in the Uni v4 core library and the BaseHook.sol template created by OpenZeppelin, which defines all hook entry points.
In addition to these core functions, there are 4 "delta-returning" flags, bringing the total possible "hook flags" to 14. Each hook contract indicates which of these 14 flags it implements through the last 14 bits of its address (refer to our previous v4 data guide on how to read these bits). This allows developers and indexers to quickly determine a hook's attributes. If you're unfamiliar with return deltas, please refer to the v4 documentation on custom accounting, unlock callbacks, and Deltas and BeforeSwapDelta.
While hooks can do more than the standard 10 core functions, these functions create a consistent foundation:
Developers can rely on known "entry points" to customize pool behavior. Indexers can reliably parse tracking data from core hook calls across different hooks.
In many cases, hooks will only modify or extend the normal v4 PoolManager process, inheriting common events from Uniswap v4 core contracts. However, some hooks may bypass or replace certain logic, leading to skipped default v4 events or making them inaccurate. To fill this gap—and ensure accurate metrics for trading volume, TVL, and fees—we propose a set of hook-specific events. By emitting them at the right time, hooks remain discoverable, analytics stay reliable, and LPs get a complete risk-reward picture.
We are collaborating with OpenZeppelin to incorporate these standards into the Uniswap Hooks library and with Atrium Academy to adopt them in developer training. As with any major standard (such as ERC20, EIP1559), broad community support is key to success.
[The rest of the translation continues in the same manner, maintaining the specified translations for technical terms]Now that we have discussed the relationship between hooks and Uniswap v4, as well as hook standards and various use case flows, it is time to handle metrics. Establishing a shared terminology ensures that when we discuss metrics related to hooks and v4, we all have a clear, consistent understanding of the content. We will focus on two key metric categories - TVL and trading volume. Below, we will define these metrics and provide recommendations for their calculation. TVL (Total Locked Value) Overall TVL The overall TVL in Uniswap v4 is the total value of all liquidity locked in the protocol (usually measured in dollars). This includes liquidity held in the singleton v4 Pool Manager contract and any liquidity held in externally initialized hook contracts. A hook contract is considered "initialized" once it is registered in at least one Uniswap v4 pool. Singleton TVL Singleton TVL refers to the portion of total liquidity stored only in the Uniswap v4 core (singleton) Pool Manager contract. Even if a pool is initialized with an external hook, the singleton TVL only calculates the assets locked in the core contract itself, excluding any external liquidity held by hook contracts. External TVL External TVL refers to the total liquidity stored outside the Uniswap v4 core Pool Manager contract, specifically in initialized hook contracts. A hook contract is considered "initialized" once it is registered in at least one Uniswap v4 pool. Hook TVL Hook TVL refers to the total liquidity in pools using hooks. It includes regular hook pools (liquidity retained in the Uniswap v4 Pool Manager contract) and special hook pools (e.g., custom curves) (liquidity residing in external hook contracts). Note on Advanced Hook Scenarios Hooks may introduce more complex liquidity flows that go beyond the simple "locked" model described above. For example, a re-staking hook might deploy liquidity to an external lending protocol where it can earn yield, rather than staying in the v4 Pool Manager contract. Similarly, just-in-time (JIT) liquidity hooks might only extract liquidity from elsewhere when a swap is needed. These scenarios mean that the "TVL" in v4 (singleton and external) may differ from the actual capital available for swaps or residing in the protocol at any given moment. We are actively collaborating with the broader Uniswap community and hook developers to improve our TVL definition and measurement methods for these advanced use cases. We will share updates immediately after finalizing these revised TVL standards. Calculation TVL can be determined in two ways: 1. Tracking liquidity modification events - Monitor liquidity changes, including swaps, to derive the total net liquidity. 2. Tracking token flows - Measure inflows and outflows in relevant contracts. Due to v4's singleton architecture, TVL at the pool level can no longer be derived solely from token flows. However, for broader overall TVL calculations, tracking token flows is often more efficient than monitoring liquidity modification events. Trading Volume Trading volume represents the total trading activity on Uniswap v4 (usually measured in dollars), measured per trade. For example, exchanging 2,673.83 USDC for 1 ETH (using the ETH price on February 13 at 5:23 PM) is counted as a $2,673.83 trading volume, rather than twice the total of the two assets in the trade. Total Trading Volume (Over a Period) Total trading volume (over a period) is the cumulative trading volume across all Uniswap v4 pools during a given time range, including vanilla pools and hook pools. Hook Trading Volume (Over a Period) Hook trading volume (over a period) is the total trading volume in hook pools during a given time range. This includes swap amounts facilitated by delta-returning hooks (e.g., custom curves or asynchronous swaps) using their own custom logic and/or liquidity. Vanilla Trading Volume (Over a Period) Vanilla trading volume (over a period) is the total trading volume in vanilla pools, i.e., pools not initialized with any hooks. Calculation To accurately measure trading volume in Uniswap v4, there are two primary methods: 1. Event-based tracking - You can track emitted events, but to get a complete picture, you must simultaneously monitor: - Swap events from v4 core contracts - HookSwap events from delta-returning hook contracts (e.g., custom curves). Relying only on swap events will miss volume facilitated by delta-returning hooks 2. Tracking data indexing - A more comprehensive approach is to index trace data for swap function calls in v4. This requires parsing the swapDelta field based on swap parameters to reconstruct amount0 and amount1. This method ensures capturing all swaps, including those processed through delta-returning hooks. You can already query overall trading volume from dex.trades on Dune and Allium, which use data indexing tracking. We are also collaborating with Uniswap Labs to apply this to the v4 open-source subgraph. Closing Remarks We hope this guide helps clarify the landscape of Uniswap v4 hook data, from standards and events to indexing and analysis. As we conclude, here are our main calls to action: Hook Developers: Adopt the four standard events and emit them at the suggested points. This helps everyone in the ecosystem easily understand and integrate your hook's behavior. By adhering to this standard, you can also use our upcoming open-source repository, enabling you to seamlessly retrieve your hook's metrics, display them on frontend interfaces, and conduct internal analysis - keeping your hook at the forefront of the broader ecosystem and saving your team significant work hours. Indexers and Analysts: Update your pipelines to detect initialized hooks and parse standard hook events. This ensures comprehensive coverage of swaps, fees, and liquidity changes in v4. By working together in the way standards like ERC20 or EIP1559 emerged, we can shape a consistent, discoverable, and transparent future for Uniswap v4 hooks!
