GridLadder

How it works

Every AMM curve has a single price at any moment, and both sides of the market trade against it. That is the defining simplification of the design, and it means a pool cannot express the one thing a quoting desk exists to express: I will buy at this, and sell at that, and the gap between them is what I am paid. The gap is not the same thing as a fee.

A fee is symmetric and proportional; a spread is a position. A desk that is long and wants to get flat quotes a keen bid and a wide ask, and it does that by moving the two sides independently. An AMM with a fee cannot say that at all: raising the fee makes it less willing to trade in both directions equally, which is exactly not what the desk wanted.

This pool holds two ladders. The bid ladder is what it pays for currency0, the ask ladder is what it charges, and each has its own base price, its own increment and its own band width. Set them symmetrically and it behaves like an ordinary stepped pool with a spread.

Set them apart and the pool leans: keen on one side, wide on the other, which is a resting position rather than a fee schedule. Both ladders step with inventory, so the pool also becomes less willing to keep going the way it is already leaning, which is the same self-correction any inventory-aware desk applies. The spread is the providers' revenue and it never leaves the reserves, so there is no separate fee parameter: a swap that crosses the spread simply hands the pool more than the mid, and the shares are a claim on reserves that grew.

Setting `askBaseX96` equal to `bidBaseX96` makes the pool free to trade and is allowed, because refusing it would be an opinion rather than a safety property.

Using it

Uniswap v4 removed hookData from initialize, so per-pool parameters arrive out of band. Fix them for a pool key whose pool does not exist yet, then initialize. Nobody can change them afterwards, including you.

poolManager.initialize(key, startingSqrtPriceX96);

Parameters

This hook takes no per-pool configuration.

From TypeScript

npm i @hookforge/sdk

import {getHook, hookAddress, poolKeyFor} from "@hookforge/sdk";

const hook = getHook("grid-ladder");
const key  = poolKeyFor({
  hook: hookAddress("grid-ladder", 8453),   // Base
  currencyA: USDC, currencyB: WETH,
  tickSpacing: 60,
});

What it reverts with

The callbacks it claims

Uniswap v4 reads a hook's permissions from the low fourteen bits of its own address, which is why deploying one means mining a CREATE2 salt. This hook claims 0, so every deployment of it has an address ending in 0x0.

• beforeInitialize
• afterInitialize
• beforeAddLiquidity
• afterAddLiquidity
• beforeRemoveLiquidity
• afterRemoveLiquidity
• beforeSwap
• afterSwap
• beforeDonate
• afterDonate
• beforeSwapReturnsDelta
• afterSwapReturnsDelta
• afterAddLiquidityReturnsDelta
• afterRemoveLiquidityReturnsDelta

It says what it is, on-chain

Nothing about a hook's address tells an indexer, a wallet, a router or an agent what the pool does, which is why hook discovery today is a curated list. This hook answers for itself, in one eth_call, with no registry in the loop.

cast call $HOOK "hookName()(string)"    # GridLadder
cast call $HOOK "specURI()(string)"     # https://grid-ladder.pages.dev/hook.json
cast call $HOOK "hookTags()(string[])"  # curve, custom-curve, market-making, spread, inventory

Build, test and deploy

git clone --recurse-submodules https://github.com/nirholas/grid-ladder
cd grid-ladder
forge build && forge test

# Dry run: mines the salt, prints the address, sends nothing.
forge script script/Deploy.s.sol --rpc-url $RPC_URL

# For real.
forge script script/Deploy.s.sol --rpc-url $RPC_URL --broadcast --verify