The v4 hook

What a hook is

Uniswap v4 lets a contract attach itself to a pool and run code at specific moments in that pool’s life: when it is created, before and after every swap, and before liquidity is added or removed. A contract that does this is a hook.

The difference from the older design is where the logic lives. A vault sitting on top of a v3 pool can only react after the fact, on its own schedule, paying its own gas. A hook runs inside the swap itself, so the work happens exactly when there is something to do and the trader’s transaction carries it.

The fee follows how much the price actually moved

Before each swap, the hook prices it from how far the price has moved recently. A calm pool charges the floor; a pool that is moving charges more, up to a ceiling.

The floor and the ceiling are written into the contract when it is deployed and cannot be changed afterwards. Nothing off-chain can produce a fee outside that band, because the contract clamps the value before it uses it — a compromised input can push toward one end of the band and no further.

The reason to do this at all: a fixed fee either underpays liquidity when the market is violent or overcharges traders when it is quiet. Tracking realised movement pays liquidity for the conditions it is actually carrying.

Compounding inside the swap

After a swap, the hook takes its cut and checks whether the fees waiting are worth collecting. When they are, it folds them into the position in the same transaction that generated them.

The check is a real gate rather than a formality. It compares the fees waiting against both a materiality threshold and the current cost of gas, so a compound only happens when it pays for itself. When it does not, the fees stay in the position and the next qualifying swap picks them up.

The hook is the pool’s only liquidity provider

The hook refuses liquidity from anyone else. That is what makes one shared position possible, and one shared position is what makes compounding inside a swap cheap enough to do at all.

It also means the accounting has exactly one owner. There is no path where an outside position and the hook’s position disagree about what the pool contains.

Its permissions are encoded in its address

Uniswap v4 reads which callbacks a hook is allowed to use out of the hook’s own address. A hook cannot claim a permission it was not deployed with, because the claim is the address.

So the contract has to be deployed to an address mined to carry exactly the permissions it needs, and no others. Change a compiler setting and the address has to be mined again — which is also why the build settings are pinned and checked in CI.

What is live, and what is not

The hook is deployed on Robinhood Chain and runs one pool, pairing PONS against native ETH. Its address is on the Contracts page, and the mined permission bits are the six callbacks described above.

Deposits and withdrawals are available from the pool list. A deposit is native ETH only: the hook swaps roughly half of it into the token inside the pool, so half of what you deposit trades at the pool’s price and a deposit that is large next to the pool moves that price against itself. The quote on the deposit screen is a simulation against the live pool and already includes it.

There are two ways out. Burning shares for both legs pays ETH and the token and does not trade, so it is always available. Burning for ETH only sells the token leg inside the pool on the way out, and that path is allowed to refuse — when it does, the two-sided exit still pays.

The hook holds no value between transactions. Everything it moves settles inside the same call, which is a property you can check on the explorer: its balance of both the token and native ETH is zero after every transaction it has ever made.