Uniswap v4 Hooks are starting to change how trading profits are split across onchain markets.
In early October, the Ethereum memecoin project Claus replaced part of what it described as its trading system’s "brain." Claus routes trading fees into buybacks, burns, liquidity, and rewards for NFT holders.
At one point, that treasury logic was tied to weather data. Claus used the weather report at London Heathrow Airport to decide how much of the fee flow should go to token burns and how much should be sent back into the pool to support trading. Rain favored burns. Clear weather favored liquidity. If the weather feed failed, funds were split evenly.
That weather experiment was only one feature inside the pool. On Oct. 6, the team said it had removed the arbitrage function while keeping the token contract address, the trading pool, and all other features unchanged. Holders did not need to swap into a new token. That was possible because the pool was built with an upgradeable Uniswap v4 Hook.
A Hook is a smart contract that can attach extra instructions to the trading flow. Developers use Hooks to change fees, put idle liquidity to work, and build differentiated markets inside an existing exchange instead of launching a separate decentralized exchange and trying to move users over.
By Oct. 8, a check of Uniswap’s public Hook registry showed that the contract handling all of Claus’s fee logic had switched from the older FeeWeatherHook to new code called FeePrivacyHook.
The project team described the token itself as an intelligent agent: the token is the body, and the upgradeable Uniswap v4 Hook is the brain. In older designs, once token rules were written into the contract, exchanges would keep using that fixed logic. Hooks move those rules out of the token contract and into the market layer. Some Hooks can later rewrite the trading rules as well.
A new business layer is forming around that idea. It is producing new products, and it is also introducing new ways users can lose money.
What a Hook does inside Uniswap v4
Take a simple example. If one pool prices ETH at $2,000 and another prices it at $2,020, a bot can buy in the cheaper pool and sell in the more expensive one. After fees and gas, the remainder is arbitrage profit. Those trades close the price gap between pools. In most cases, the bot keeps the profit and the pool only earns swap fees.
Developers may want some of that value to stay with users. A Hook is a separate smart contract that runs extra instructions at specific points in a trade. Some Hooks can detect a price gap after a swap, execute the arbitrage in the same transaction, and then distribute the captured profit to liquidity providers, traders, and the project that deployed the Hook.
In Uniswap v4, a shared contract called PoolManager handles swaps and records balances for all pools. Every v4 pool on the same chain uses that PoolManager, while each pool keeps its own liquidity and parameter settings.
If a user swaps ETH for CLAUS, PoolManager calls the ETH/CLAUS pool to process the trade. If that pool has a Hook attached, the system also checks when the Hook should run.
A Hook can include a beforeSwap function, which runs instructions before the trade executes. That can mean calculating the fee for the swap or checking whether the trader is allowed to trade. It can also include an afterSwap function, which runs after the trade is complete. That can trigger a buyback or record the updated price. A Hook can use one of those functions, both of them, or combine them with other functions tied to adding and removing liquidity.
Those instructions do not have to change often. A Hook can keep the same rules for years, such as sending a fixed share of fees to rewards.
Pools can also run without a Hook. In that case, PoolManager follows the standard v4 logic. Hooks are for developers who want custom trading behavior.
The hard part comes later, when the logic needs to change. When a pool is created, its configuration includes the Hook contract address, and PoolManager calls that address. In Uniswap v4, that address is a permanent part of the pool’s identity. Deploying a new Hook at a different address does not automatically attach it to an existing pool.
Without an upgrade path, using a new Hook would mean creating a new pool and moving liquidity over.
Claus avoided that by using an upgradeable structure. Its Hook is split into two parts: one contract keeps a permanent address for the pool to call, and a second contract stores the executable logic. The first contract acts as a proxy.
When an authorized Claus administrator wants to change the rules, the team deploys new logic and tells the proxy to point to the new version. The pool still calls the same Hook address, but the code being executed has changed.
That is why the existing pool can gain new features without forcing users to migrate their tokens. It also means the party that controls upgrades has the power to control pool behavior. That is the trust risk users need to assess.
Why Hooks solve problems older token designs could not
Before Hooks, developers could still build special token logic, but compatibility with DeFi was often poor.
One route was to write the rules directly into the token contract. That produced so-called tax tokens on Ethereum, where an ERC-20 automatically deducts a fee on transfer. If a user sends 100 tokens into a swap and the token contract takes 2, only 98 reach the pool while the exchange contract expects the full 100. The trade fails.
Uniswap v3 documentation states that such tokens are not compatible with the standard router contract. Developers had to rely on wrappers or custom routing. The tax mechanism could raise funds for rewards, but it also made the token harder to trade and left many exchanges unable to process the automatic fee deduction.
Developers could also build contracts around a pool or modify exchange code and deploy a separate DEX. But building and maintaining a full stack of infrastructure was much more work than the feature itself.
Hooks give developers a dedicated place to hold trading rules. They can be used to:
- take funds only during trades for buybacks or rewards, without taxing ordinary wallet-to-wallet transfers;
- adjust trading fees automatically, such as changing rates when volatility rises;
- share captured arbitrage profits with traders and liquidity providers;
- restrict trading so only whitelisted wallets can use the pool;
- connect liquidity to lending protocols so idle assets can earn interest when they are not being used for swaps;
- build all of that inside an existing exchange instead of deploying and maintaining a separate DEX.
Hooks are also creating a business model of their own: products whose core value is custom pool logic.
On Oct. 14, Uniswap deployed VolatilePair, a Hook that sets different fees for buys and sells. It first went live in an ETH/USDC pool on Ethereum. The Hook charges buyers and sellers different fees based on recent price volatility. According to the official announcement, StablePair, an earlier Hook for stablecoin pairs, reached $3.1 billion in volume in its first four weeks.
Other teams are also changing fees based on the type of asset being traded.
Fables, a DEX project on Robinhood Chain, uses that approach for tokenized stocks and similar assets. Its Hook adjusts fees based on signals such as time and volatility. When the underlying securities market is closed, tokenized stocks can still trade, but reliable price feeds and hedging opportunities are more limited.
The logic behind dynamic fees is straightforward: providing liquidity during those periods carries a different risk profile from providing liquidity during active market hours.
Fables changes fees based on U.S. stock market open and close times. Some tokenized funds are only available to qualified investors.
In July, Uniswap Labs launched permissioned pools for Uniswap v4. Superstate, Securitize, and Dowgo were the first partners. The setup uses Hooks to check whether a wallet is eligible to trade or provide liquidity.
Its DualPool Hook lends out idle market-maker tokens and pulls them back when swaps need them. Spark has already moved $150 million of liquidity to v4 and plans to integrate that Hook. An auction Hook can sell a new token over time and then create a pool based on buyers’ clearing price. Aztec used that Hook to raise about $59 million from more than 17,000 bidders.
On the data side, v4 recorded $39.7 billion in volume over the past 30 days, about half of Uniswap’s total volume, and generated 64% of Uniswap’s fees. A large share of that volume came from Robinhood Chain. When Bitquery examined pools on that chain in early September, only about one-third of v4 pools had Hooks attached, yet those pools accounted for 74.5% of trading.
Ethereum tooling built around Hooks
If Hooks become the place where token trading rules live, one obvious business is selling ready-made rule sets. programmable.market is one example. It describes itself as open launch infrastructure for Uniswap v4. In practice, it is a toolkit that lets users deploy tokens with preset trading rules on Ethereum and Robinhood Chain.
Its Classic version can deploy a token with custom buy and sell fees and pair it with a permanently locked ETH pool.
Functionally, that still resembles a tax token, except the fee logic now sits inside the pool and can be recognized by routing contracts in advance. Its API-based Custom version is aimed at teams that want a tailored Hook setup. On Robinhood Chain, programmable’s default setting for new custom projects takes a 0.2% fee and sends it to a specified address. Its documentation also says the contracts have not gone through an external audit or a public security competition.
Claus launched through programmable.market. Buybacks, NFT rewards, and weather-based fee allocation can all be integrated into the token’s trading system. Claus can change how trading fees are used without issuing a new token. That also means holders need to keep watching for changes, because the rules they accepted when they bought in may later be revised.
Robinhood Chain also has a similar platform called Hookrfun, which offers 22 "Hook components" that creators can select, including anti-sniping protection and auto-burn. One module, called What The Hook, captures price gaps between pools before arbitrage bots do and shares the profit with traders and liquidity providers. Hookr’s token launch toolkit includes that service.
For third-party pools that integrate What The Hook directly, the default split is 45% to liquidity providers, 5% to traders, 40% to the treasury, and 10% to referrers. Those percentages apply to captured arbitrage profits. What The Hook is the only tool in this group that has published related data, and most of the arbitrage funds it has distributed have remained in its own treasury.
Solana takes a different route
Uniswap is not deployed on Solana. Trading there is spread across DEXs such as Raydium, Orca, and Meteora. There is no shared PoolManager that can host Hooks, so Solana puts the logic into the token itself.
Solana’s Token-2022 standard lets creators attach a transfer hook. The program runs every time the token moves, covering both trades and ordinary wallet transfers. It can enforce rules, such as checking whether the receiving address is allowed to hold the asset, and block the transfer if the condition is not met.
Hooked is a token launch platform on Solana where every token comes with a transfer hook. Creators can choose from 39 prebuilt rule sets, including a "hot potato" mechanism or a rule that forces buyers to wait 15 minutes before selling. They can also use AI to generate custom rules. Each rule comes with a plain-language explanation. Some tokens let the project team or holders vote later to rewrite the rules. Every trade carries a 1% fee, and most of that goes to buying back and burning Hooked’s native token.
There are limits. Raydium will not create a pool for tokens with transfer hooks unless an administrator approves it. Meteora can support those tokens on a bonding curve, but once the token graduates into the main trading pool, the transfer-hook logic is removed. Hooked’s workaround is to keep the token on the curve permanently so the rules stay active.
That differs from Uniswap v4. In v4, the extra rules belong to the pool. The same token can trade in a pool with a Hook or in one without a Hook. Users can choose the pool themselves, or a router can choose for them.
On Solana, transfer-hook rules are attached to the token itself, so any transfer triggers them, including wallet-to-wallet transfers. Both models come with their own surrounding infrastructure: routers decide which pool order flow reaches, and exchanges decide which token features they will support.
Developers now have more tools for market design. The choices they make will shape whether a project can attract users and liquidity.
Why upgradeability may matter more than Hooks alone
The article argues that upgradeability matters more than Hooks by themselves. A fixed Hook is an improved tax token. An upgradeable Hook turns a token’s market into something closer to an application that can receive version updates.
Before that, changing token logic usually meant a token migration. A project would deploy a new contract, ask holders to swap, ask exchanges to relist, and watch liquidity split between old and new versions. In September 2024, Polygon replaced MATIC with POL, requiring holders to convert at a 1:1 ratio while exchanges helped users complete the switch.
Some holders are always left behind in that process. Upgradeable Hooks let a project change trading behavior without forcing a mass migration, which sharply lowers the cost of experimentation.
The article suggests the most valuable use case may not be memecoins at all. It may be tokenized securities, where trading rules can change over time. A fund that opens access to investors in additional countries may need to update investor eligibility checks. An upgradeable Hook can make that change while keeping the existing pool in place. It does not rewrite investors’ legal rights or remove restrictions inside the token contract, but it can let the trading venue keep up with changing rules. For markets meant to run over long periods, that may be more useful than locking every rule at launch.
Different projects will want different levels of control. A fund may need to update trading rules. A memecoin community may want rules that the team can never touch. The article says users should focus on what the controller is allowed to change. Updating access checks is one thing. Changing fees or redirecting reward flows gives the controller much more power over pool users.
It also says users should have time to review changes before those changes affect their funds, and a chance to exit if they disagree. Projects can build notice periods into contracts and limit the scope of what developers are allowed to change. Giving up upgrade rights entirely removes the risk of later changes, but it also removes the ability to patch bugs. Before depositing funds, the article says it is worth reviewing those terms along with fees and expected returns.
Claus calls the Hook the token’s brain. The article then sketches a possible next step: project teams could let AI agents update Hooks automatically based on market conditions, adjusting fees within preset boundaries and explaining each change. That kind of automation may be attractive, but the same questions remain: who sets the AI’s limits, and who can shut it down if it makes a bad decision?
From monetary rules to programmable markets
The article closes with a historical comparison. During the Great Depression in 1932, the Austrian town of Wörgl issued a local currency. To keep the paper money valid, holders had to buy a stamp worth 1% of face value at the end of each month. The design encouraged spending instead of hoarding.
The local government used the mechanism to fund public works and allowed residents to pay taxes with the currency, including overdue taxes. In 1933, Austria’s central bank intervened and the experiment ended.
At that time, governments wrote the rules of money. Governments still do. What crypto changes is that developers can now write similar rules for individual tokens and markets, while buyers can choose the setup that fits them best.
By that framing, choosing a token is really a judgment about whether its rule set suits the user.
