KERR is a hook contract for Uniswap v4 attached to a single KERR/ETH pool, using native ETH rather than a wrapped form. It does one thing: on every swap it takes 2% in KERR and burns it in the same transaction.
Not sent to a dead address — burned. totalSupply() falls by exactly the amount taken, at every swap, and there is no path that puts it back.
The goal is not yield, and there is no reserve, no redemption and no floor. What is on offer is a single property you can check rather than believe: total supply is non-increasing, and total burned is non-decreasing. No function reverses either, no role pauses them, and no upgrade path exists that could add one.
Roy Kerr described the geometry of a rotating black hole in 1963. Its interesting feature is not that it pulls, but that it has a surface past which return is undefined.
A trader calls swap. Because the hook's address is written into the PoolKey, the PoolManager must call it — there is no route to this pool that avoids the hook, since a swap that skips it is by definition a swap on a different pool.
The slice is always denominated in KERR, never in ETH, so which callback does the work depends on the direction. On a sell, KERR is the input and the slice comes off it in beforeSwap. On a buy, KERR is the output and the slice comes off it in afterSwap. Both callbacks return a delta, so both return-delta flags are required alongside them.
Native ETH is Currency.wrap(address(0)) and always sorts as currency0, so KERR is currency1 and zeroForOne alone tells you which side you are on.
function _beforeSwap(
address, PoolKey calldata key,
SwapParams calldata params, bytes calldata
) internal override returns (bytes4, BeforeSwapDelta, uint24) {
// a sell: KERR is the input
if (params.zeroForOne)
return (BaseHook.beforeSwap.selector, ZERO_DELTA, 0);
uint256 amountIn = uint256(-params.amountSpecified);
uint256 slice = amountIn * BURN_BPS / 10_000;
_swallow(slice);
return (
BaseHook.beforeSwap.selector,
toBeforeSwapDelta(int128(int256(slice)), 0),
0
);
}This is the part worth reading twice, because it is where most burn mechanisms quietly cheat. Moving tokens to 0x…dEaD does not reduce totalSupply(); it relocates a balance and leaves the supply figure untouched. Anyone computing scarcity from totalSupply() would be reading a number that never moved.
The hook therefore pulls the slice out of the PoolManager and calls burn on the token, which decrements supply for real.
function _swallow(uint256 slice) private {
if (slice == 0) return;
poolManager.take(KERR, address(this), slice);
token.burn(slice); // totalSupply() falls
totalBurned += slice; // up, only
emit Swallowed(slice, totalBurned);
}Returning a non-zero delta needs beforeSwapReturnDelta and afterSwapReturnDelta on top of the callbacks themselves. Omit either and the PoolManager reverts.
2% on top of the pool's own LP fee, so roughly 2.3% all in. It reaches the trader as a worse effective rate, in both directions, with no exemption for any address.
Every other lifecycle callback is switched off, including the liquidity ones. Providers add and withdraw exactly as they would anywhere else; this hook has no opinion about them and no ability to form one.
Two of them. Neither holds a balance between transactions.
burn, and the hook address is the only one allowed to call it. Burning is therefore the only thing that ever changes total supply.An earlier draft added a read-only Lens contract. It was dropped: totalSupply() and totalBurned() are already public, and a third contract is a third thing to read for no gain.
All immutable, all fixed at construction, none settable afterwards.
200, so 2%. Identical in both directions, applied to every address without exception. This number cannot be changed after deployment, including by us, including if it turns out to be wrong.delegatecall, no implementation slot.v4 stores hook permissions in the low bits of the hook's own address, so a contract cannot merely claim a permission — the address has to carry it.
That means mining a CREATE2 salt until the resulting address has the right bits set, then deploying with it and initialising the pool in the same script, so the first swap is already subject to the hook.
forge script script/Deploy.s.sol \
--rpc-url $RPC --broadcast --verifyOnce deployed, the hook address is part of the PoolKey. Changing it would mean a different pool, not a modified one.
Everything above reduces to a handful of calls you can make without asking anyone.
totalSupply(). Compare it against the initial supply minus totalBurned(). They agree at every block, or something is wrong.totalSupply() flat, it is sending tokens to a dead address and calling it a burn. This one does not.Swallowed event across the whole history. Every entry adds. None subtracts.onlyOwner, Ownable, delegatecall, selfdestruct, upgradeTo, mint. None appear.PoolKey. The hook address is one of its fields, which is why it cannot be routed around.burn, and the hook is the only caller allowed to reach it.burn decrements totalSupply(). You can watch the figure fall block by block, which is not true of the dead-address version most tokens use.immutable and there is no proxy. This is the point of the design and also its largest risk.