RUNTIME is an experiment in programmable liquidity built around Uniswap v4 Hooks. It asks a narrow question and tries to answer it in public: if a pool can call code at the moments its state changes, what does an economic rule look like when it is written as that code instead of as a policy document?

The answer this experiment implements is a loop. A swap happens. The Hook runs. A fee is captured. The captured value is used to buy back $RUNTIME. Those tokens are burned. The supply is permanently smaller. Nothing in that sequence requires a person to act.

Liquidity is usually passive: assets in a pool, priced by a fixed curve, with no behaviour of their own. Programmable liquidity means attaching executable logic to that pool's lifecycle, so activity in the pool can trigger arbitrary contract behaviour in the same transaction.

The word programmable is used here in its literal sense. Not “configurable”, not “flexible” — programmable, as in: there is a program, it is deployed, and the pool runs it.

• Passive liquidity: a pool of assets that responds only through its curve.
• Programmable liquidity: the same pool, plus code the pool itself invokes.
• The difference is not capability at the margin. It is where the logic lives.

In Uniswap v4, pools are accounted for inside a single settlement contract rather than deployed as separate contracts per pair. When a pool is created it can be bound to a Hook: an external contract that the pool calls at defined points in its lifecycle.

Which points a Hook subscribes to is encoded in the Hook contract's own address. The permission bits are structural — they are fixed at deployment, and a pool created with that Hook cannot be made to call points the address does not claim.

For the authoritative specification, read the Uniswap v4 documentation directly rather than relying on this summary.

RUNTIME's Hook exists to make one economic rule inseparable from pool activity: capture a portion of swap value, route it into $RUNTIME, and burn the result.

This site presents the v4 lifecycle callbacks — beforeSwap() and afterSwap() — as the conceptual surface where such a rule would attach. It does not assert that the deployed RUNTIME Hook implements those exact callbacks. That claim requires the contract ABI, and the interface marks each callback VERIFIED IN ABI only when the configured ABI actually contains it.

A swap pays a fee. In a conventional pool that fee accrues to liquidity providers and the story ends. Under a programmable arrangement, a portion can instead be accounted to the protocol at the moment of the swap and made available to logic that runs immediately afterwards.

The sequence the interface documents is:

• SWAP — an input enters the pool.
• PROGRAMMABLE HOOK — the pool calls attached code.
• FEE LOGIC — the rule determines what is taken.
• FEE CAPTURE — value is attributed to the protocol.
• BUYBACK — captured value is routed back into $RUNTIME.

Fee parameters — base fee, hook fee, totals — are properties of the deployed contract. Until the Hook ABI is configured, this site shows them as —. It will not print a plausible number in place of a measured one.

Burning means sending tokens to an address from which they cannot be recovered. There is no administrative function that reverses it and no key that unlocks it. Once a token reaches the sink it is out of the supply permanently.

RUNTIME measures burns from the ERC-20 Transfer log whose destination is the configured burn sink. This is deliberate: Transfer is part of the ERC-20 standard, so the measurement needs no project-specific ABI and cannot drift from what actually happened on-chain.

The conceptual model is one line: S(t+1) = S(t) − B(t), where B(t) = f(F(t)). Supply at the next step is supply now minus what was burned, and what was burned is a function of the fee flow captured.

The model has a single direction. Fee flow drives burn, burn reduces supply, and this loop never increases supply. That monotonicity is the property being tested.

Three layers, in strict priority order, with the chain always authoritative:

• Chain (viem + wagmi) — direct reads for supply, balances and block height. Always the source of truth.
• Indexer (Alchemy) — historical transfers, burn events and hook activity. Used only where the SDK supports the configured network; otherwise the interface reports INDEXER UNAVAILABLE.
• Cache (Supabase, optional) — an acceleration layer for the ledger and the live system log, including Realtime subscriptions. It never overrides the chain.

Polling intervals are deliberately conservative and requests are deduplicated through React Query, because RPC endpoints are metered and a research document does not need sub-second refresh.

Every address is read from environment variables through src/config/project.ts. No address is hardcoded in a component, and no chain is assumed. If a binding is missing, the corresponding surface renders a NOT CONFIGURED state.

ABIs live in src/lib/contracts/. The Hook, burn and pool manager ABIs ship empty on purpose — no fragment is invented. Paste your compiled ABI in and the dependent surfaces come online without further changes.

What this front end does and does not do:

• It never holds, requests or transmits a private key or seed phrase.
• It reads chain state. It does not, in this build, send transactions on your behalf.
• Only NEXT_PUBLIC_* variables are used client-side, and all of them are — by definition — public. Server secrets must never be given a NEXT_PUBLIC_ prefix.
• The Supabase anon key is a public key. Row-level security is enabled in the provided schema, with writes reserved for the service role.
• Wallet connection state is checked against the configured chain id; a mismatch surfaces an explicit WRONG NETWORK state rather than silently reading the wrong chain.

RUNTIME is experimental software interacting with experimental infrastructure. The honest summary is that you can lose everything you put into it.

• Smart contract risk. Hooks are new. Bugs in a Hook, in the pool manager, or in the token can result in total, irreversible loss.
• Mechanism risk. Fee capture, buyback and burn are mechanisms. They are not a promise about price, and supply reduction does not imply appreciation.
• Liquidity risk. An experimental pool may be thin. Entering or exiting can move the price against you.
• Data risk. Indexers lag and RPC endpoints fail. When that happens this interface says so; it does not fill the gap with an estimate.
• Regulatory risk. The treatment of tokens varies by jurisdiction and changes.