RUNTIME

PROGRAMMABLE LIQUIDITY.

CODE BECOMES EXECUTION.

EXPERIMENT#001

SUBSTRATEUNISWAP V4

CLASSIFICATIONPROGRAMMABLE SYSTEM

NETWORKEthereum

Liquidity has been treated as passive infrastructure: capital that sits in a pool and waits. Uniswap v4 changes what can be attached to that pool. Code can now run at the moments a pool changes state — and once code runs, a rule stops being documentation and becomes an event.

RUNTIME is the study of that shift: what happens when liquidity becomes PROGRAMMABLE.

ENTER RUNTIME READ THE THEORY

WHAT IF THE POOL COULD RUN THE RULE?PROGRAMMABLE ≠ PASSIVE

the rule is not
a description

CONCEPTUAL FLOWFIG. 1

CODEthe rule, written

PROGRAMMABLE HOOKthe layer around the pool

POOLuniswap v4

EXECUTIONatomic, in-transaction

STATEwhat remains on-chain

CODE → HOOK → EXECUTION → STATETHE POOL RUNS THE RULE

liquidity
can be programmed

§ 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

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.

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

§ 03

THE PROGRAMMABLE HOOK

Why Hooks matter: they are the point at which a pool stops being a container and starts being a host for code.

In Uniswap v4 every pool lives inside a single settlement contract, and each pool may be created with a Hook attached. The Hook's address itself encodes which lifecycle points it subscribes to — the permissions are structural, not a runtime setting. From deployment onward, the pool calls that contract at exactly those points.

This is what makes the layer PROGRAMMABLE in a technical sense rather than a marketing one. The logic is not observing the pool from outside and reacting later. It is invoked by the pool, inside the same transaction, before the state transition is final. There is no window in which someone could decide not to run it.

RUNTIME uses that property for one purpose: to make an economic rule — capture, buy back, burn — inseparable from the activity that triggers it.

CONCEPTUAL LIFECYCLE SURFACE

beforeSwap()Runs before the pool applies the swap. The programmable pre-condition.CONCEPTUAL

afterSwap()Runs after the swap settles. Where fee accounting and state updates land.CONCEPTUAL

CONTRACT ABI NOT CONFIGUREDthese callbacks are shown as concepts only — nothing is claimed about the deployed contract until its ABI is supplied

DEPLOYMENT

HOOKNOT CONFIGURED

POOL MANAGERNOT CONFIGURED

ABINOT CONFIGURED

FIG. 3 — WHERE THE LOGIC LIVES

UNISWAP V4POOL

PROGRAMMABLE HOOK

CUSTOM LOGIC

EXECUTION

“THE LOGIC LIVES HERE.”

§ 04

PROGRAMMABLE ECONOMICS

If logic can attach to liquidity, then economic behaviour can be expressed as logic. That is the entire subject of this section.

FIG. 4 — RULE TO STATE

RULE

CODE

HOOK

EXECUTION

ECONOMIC STATE

an economy written as a call stack

Most token economics are policy: a document describing what a team intends to do with revenue, executed later by people. RUNTIME asks what the same idea looks like when it is compiled — when the rule is a function the pool calls rather than a paragraph someone honours.

The mechanisms below are the vocabulary of that compiled economy. Each is labelled with its actual status in this experiment. Nothing is described as implemented unless it is.

FEE LOGICPENDING VERIFICATION

The rule that decides what a swap contributes. Uniswap v4 permits custom and dynamic fee behaviour; what RUNTIME applies is read from chain, not asserted here.

ACCOUNTINGIMPLEMENTED

Captured value is attributed to the protocol rather than distributed back into the curve. Accounting is the bridge between a swap and an economic consequence.

BUYBACKIMPLEMENTED

Captured value is routed back into $RUNTIME. The protocol becomes a buyer of its own token as a function of activity, not of discretion.

BURNIMPLEMENTED

Acquired tokens are sent to an irreversible sink. There is no recovery path and no administrative key that reverses it.

STATE UPDATEIMPLEMENTED

The result is written. Supply after the transaction is smaller than supply before it, and the difference is publicly verifiable.

§ 05

PROGRAMMABLE FEE FLOW

One swap, followed all the way through to a smaller supply. Each arrow is a step that happens on-chain, not an intention.

SWAP → SUPPLY REDUCTIONFIG. 6

SWAP

PROGRAMMABLE HOOK

FEE LOGIC

FEE CAPTURE

BUYBACK

BURN

SUPPLY REDUCTION

“THE FEE IS PROGRAMMABLE INPUT.”

STEP BY STEP

SWAPinput enters the pool

PROGRAMMABLE HOOKthe pool calls attached code

FEE LOGICthe rule decides what is taken

FEE CAPTUREvalue is accounted to the protocol

BUYBACKcaptured value is routed back into the token

BURNtokens are sent to an irreversible sink

SUPPLY REDUCTIONS(t+1) < S(t)

A fee, in this arrangement, is not overhead. It is the input to a program. The programmable layer decides what happens to it, and what happens to it is a permanent, measurable change in the token's supply.

§ 06

THE RUNTIME MODEL

Four stages. Each one is a binding between something abstract and something that actually exists on-chain. Hover a stage to expand it.

hover, focus or tap a stage — the readout follows

§ 07

EXECUTION

A program is not a document about what should happen. Once it is deployed, running it is the happening.

CONCEPTUAL SHAPE OF A RUN

function execute() {
    hook();
    captureFee();
    updateState();
}

CONCEPTUAL UI ONLY — NOT THE DEPLOYED CONTRACT SOURCE

READ THIS AS A DIAGRAM, NOT AS SOURCEthe three lines above name the order of concerns — call the hook, account for the fee, write the state. They are not an extract from the contract, and nothing on this page asserts that these exact functions exist.

“CODE IS NOT THE DESCRIPTION.”“CODE IS THE EVENT.”

FIG. 5 — TRANSFORMATION

CODE

RUNTIME

EXECUTION

STATE

In an ordinary system, a rule is written down and something else carries it out — a job, an operator, a multisig. The gap between the two is where discretion lives, and discretion is where systems drift from their own descriptions.

A Hook removes the gap. The rule and its execution occupy the same transaction. What the code says is what the chain does, in the same block, without an intermediary step in which anyone could choose otherwise.

§ 08

FEE ENGINE

The parameters of the rule, and what the rule has actually moved. Values are read from the configured network — never estimated.

PARAMETERS

BASE FEE—

HOOK FEE—

TOTAL FEES—

CONTRACT ABI NOT CONFIGUREDfee parameters live in the Hook. Supply src/lib/contracts/hookAbi.ts and these fields populate from chain state.

FLOW

—RUNTIME RETIRED VIA THE LOOP

FEES CAPTURED—

FEES USED—

MEASUREMENTTRANSFERS INTO SINK

HOOKNOT CONFIGURED

DATA UNAVAILABLEno figure is shown rather than a guessed one

SYNTHETIC DATA

a fee that does nothing is a cost. a fee that runs is an input.

§ 09

BURN ENGINE

What the loop removes and does not give back. Supply reduction is the only output of this experiment that cannot be undone.

MEASUREMENT

232,400$RUNTIME BURNED

CURRENT SUPPLY999,767,600

SUPPLY REMOVED0.02%

BURN EVENTS—

LAST BURN—

S(0)0.02% REMOVEDS(t)

SYNTHETIC DATA

FIG. 7 — IRREVERSIBLE REMOVALSYNTHETIC

PROGRAMMABLE BURN

S(t+1) = S(t) − B(t)NO RECOVERY PATH

what leaves the supply does not come back.

§ 10

SUPPLY MODEL

Three terms, one relation. Written as it would appear in the margin of a notebook, because that is what it is.

CONCEPTUAL MODEL

RELATION

S(t+1) = S(t) − B(t)

B(t) = f( F(t) )

Stoken supply — what exists at time t

Bburned supply — what has been removed and cannot return

Fcaptured fee flow — the input the programmable layer receives

THIS IS A MODEL, NOT A DECOMPILATIONthe relation describes intent. The authoritative behaviour is whatever the deployed contract does, and every number on this site is read from chain rather than computed from these equations.

MEASURED TERMS

S(t)SUPPLY999.77M

B(t)BURNED232.4K

F(t)FEE FLOW—

The model has one direction. F drives B, B reduces S, and S never increases as a result of this loop. That monotonicity is the whole point: an economic rule whose only permitted effect on supply is subtraction.

F(t) is displayed as — until fee accounting can be read from the Hook. An unmeasured term is left unmeasured.

the equation is small. the property is not.

§ 11

SUPPLY GRAPH

S plotted against t. One axis is time; the other is how much of the token still exists.

FIG. 8 — S(t)SYNTHETIC SERIES

SUPPLYTIME999.74M999.81M999.88M999.95M1B08-1208-1308-1308-1408-14

X — TIME · Y — SUPPLY40 MEASURED POINTSSYNTHETIC DATA

§ 12

BURN LEDGER

Each row is one irreversible event. Nothing is summarised away; the log is the primary record.

LOG — SUPPLY REMOVALNO ENTRIES · MEASURED

NO BURN EVENTS RECORDEDthe ledger is empty. When the loop runs, entries appear here.

EXPLORER: https://etherscan.ioSYNTHETIC ROWS

§ 13

RUNTIME MONITOR

The instrument panel. Configuration on the left, chain readings on the right, and an honest status line at the top.

RUNTIME STATUSNOT CONFIGUREDHOOK ADDRESS NOT CONFIGURED

BINDINGS

HOOKNOT CONFIGURED

POOLNOT CONFIGURED

TOKENNOT CONFIGURED

NETWORKEthereum · 1

READINGS

CURRENT SUPPLY999,767,600

TOTAL BURNED232,400

LAST BLOCK—

LAST EVENT—

LAST UPDATE—

RPC CONFIGUREDINDEXER UNAVAILABLECACHE ONLINEHOOK ABI NOT CONFIGURED

SYNTHETIC MODE

§ 14

SYSTEM LOG

The experiment, narrating itself. Each line corresponds to something that happened on-chain.

EVENT STREAMREALTIME SUBSCRIBED

NO EVENTS RECORDEDthe stream is quiet. Nothing is simulated in its place.

SEQUENCE — SWAP · HOOK · FEE · BUYBACK · BURN · STATESYNTHETIC STREAM

§ 15

EXPERIMENT #001

The whole protocol restated as a single observation: what goes in, what runs, and what is different afterwards.

OBSERVATION SHEET — EXPERIMENT #001v0.1.0 · STATUS NOT CONFIGURED

INPUTSWAP↓

PROCESSPROGRAMMABLE HOOK↓

EXECUTIONCUSTOM LOGIC↓

OUTPUTSTATE CHANGE

FEE—

BURN232.4K

SUPPLY999.77M

HOOK STATENOT CONFIGURED

“OBSERVE WHAT HAPPENS WHEN LIQUIDITY BECOMES PROGRAMMABLE.”variables left blank are variables not yet measured.

§ 16

RUNTIME TOKEN

The unit the loop acts on. Everything here is either read from the contract or left blank.

$RUNTIMECONTRACT NOT CONFIGURED

OBSERVER

WALLET DISCONNECTEDconnect to read your position in the experiment

CONTRACT

CONTRACT—

NETWORKEthereum

DECIMALS18

TOTAL SUPPLY999,767,600

CIRCULATING SUPPLY999,767,600

BURNED232,400

Circulating supply is derived, not asserted: it is total supply as reported by the contract, with tokens sitting at the burn sink treated as removed. Where that derivation is not possible, the field stays empty.