The Hook is the programmable layer
Not a wrapper, not a keeper bot, not a script watching from outside. The pool itself calls into the Hook at defined lifecycle points. Anything the Hook does happens because the pool asked it to.
§ 01
THE THEORY
Liquidity does not have to remain passive.
An automated market maker is, at bottom, a rule about how a reserve responds to a trade. For most of the history of on-chain markets that rule was fixed by the protocol: the pool was a container, and the container had no opinions. Liquidity providers deposited capital and the curve did the rest.
Uniswap v4 introduces Hooks: contracts that a pool calls at defined points in its own lifecycle. A Hook is deployed to an address whose bits encode which of those points it wants, and from then on the pool consults it. The pool still prices the trade — but a second body of code now runs alongside it, in the same transaction, with access to the same state.
That is a structural change, not a feature. It means a protocol can express economic behaviour as executable logic attached to liquidity itself, rather than as a process that someone runs afterwards. The Hook becomes a PROGRAMMABLE layer around the pool.
BEFORE
LIQUIDITYPASSIVE
becomes ⟶
RUNTIME
LIQUIDITYPROGRAMMABLEEXECUTABLE
PROGRAMMABLE
RULES ARE EXECUTABLE · LIQUIDITY CAN BE PROGRAMMED
WHAT UNISWAP V4 ENABLES vs WHAT RUNTIME IMPLEMENTS
The distinction matters. A platform capability is not a protocol claim. RUNTIME uses a narrow slice of what v4 makes possible, and this table is the honest boundary between the two.
| CAPABILITY | UNISWAP V4 | RUNTIME |
|---|---|---|
| Attach custom code to pool lifecycle points The core premise of the experiment. The Hook is the programmable layer. | ENABLED | IMPLEMENTED |
| Custom / dynamic fee logic on swaps Displayed values are read from chain. Nothing is asserted before the ABI confirms it. | ENABLED (OPT-IN) | PENDING VERIFICATION |
| Protocol-side fee capture and accounting Fee capture is the input to the economic loop described in PROGRAMMABLE FEE FLOW. | ENABLED (OPT-IN) | IMPLEMENTED |
| Buyback executed from captured fees Routing captured value back into $RUNTIME. | ENABLED (OPT-IN) | IMPLEMENTED |
| Permanent burn / supply reduction Measured directly from transfers into the configured burn sink. | ENABLED (OPT-IN) | IMPLEMENTED |
| Custom accounting via the singleton PoolManager Available at the platform level. Not part of EXPERIMENT #001. | ENABLED | NOT IMPLEMENTED |
| Custom curves / alternative pricing logic Out of scope. RUNTIME does not modify the pricing curve. | ENABLED (OPT-IN) | NOT IMPLEMENTED |
| Permissioned or gated swap access The pool is open. No access rule is attached. | ENABLED (OPT-IN) | NOT IMPLEMENTED |
§ 02
PROGRAMMABLE LIQUIDITY
The central claim of this experiment: liquidity is not only capital sitting in a pool. It is capital wrapped in code that runs.
LIQUIDITY
CAN BE
PROGRAMMED.
CODE → HOOK → EXECUTION → STATE
THE POOL CAN RUN RULES.PROGRAMMABLE INFRASTRUCTURE.CODE BECOMES EXECUTION.
THE PROGRAMMABLE CHAINFIG. 2
POOLreserves + curve
PROGRAMMABLE HOOKthe programmable layer
CUSTOM LOGICthe rule, as code
EXECUTIONsame transaction
STATEthe record
Custom logic attaches to activity
Instead of liquidity being only a passive pool of assets, the system attaches custom logic to pool activity. Every swap becomes a trigger for whatever rule the protocol has chosen to encode.
Execution produces state
The rule does not describe an intention to act. It acts — atomically, inside the transaction that triggered it. What comes out the other side is new on-chain state, and state is the only thing that counts.
LEXICON —PROGRAMMABLE LIQUIDITYPROGRAMMABLE HOOKPROGRAMMABLE ECONOMICSPROGRAMMABLE FEE FLOWPROGRAMMABLE STATE