A dependency-free implementation of the full CLMM machine — tick math,
ranged positions, cross-tick swaps, fee accrual. This page embeds it: every figure below
is the engine running live, and its test suite executes in your browser.
zero dependencies12 tested invariantsMITruns in your browser
// the engine on this page
const pool = newClmmPool({ initialPrice: 100, feeBps: 30 });
pool.addLiquidity(tick - 1000, tick + 1000, 1_000_000) // LP: ±10% range
pool.swapExactIn(10_000, "Y") // trader: walks the ticks
pool.removeLiquidity(1) // close: principal + fees
The engine's base pool enforces one rule: x · y = k. Price is
the ratio of reserves; slippage is the curve defending itself as one side drains.
Drag the trade size:
Why big trades hurt: slippage isn't a fee anyone charges — it's the curve
steepening as reserves drain. Deeper pools (bigger k) bend less. And when a token "rugs,"
what literally happens is the reserves get pulled from exactly this structure, and the
curve you're selling into collapses to nothing.
02 / CONCENTRATION
Most liquidity was dead capital. CLMMs fixed that.
ClmmPool deploys liquidity between two prices — the same capital
packed where trading actually happens, for multiplied fees. The trade-off is honest:
drift out of range and you earn nothing, left holding one token. Tighten the range
and watch both numbers move:
fig. 2 — range explorer · pair trading near $100 · computed by the enginelive
capital efficiency
20x
vs full-range
position status
in range
earning fees
$1,000 works like
$20,400
of full-range capital
The number to remember: a ±10% range concentrates roughly 20x;
±2% is over 100x. Professional LPs live in this tension — tighter ranges earn more and
fall out of range faster. Managing that automatically is an entire industry.
03 / TICKS
Ranges snap to a grid called ticks
Price space snaps to a multiplicative grid: tick i is price
1.0001^i. Positions start and end on ticks, and a swap is a walk across
boundaries — consuming liquidity bucket by bucket, shedding and gaining it as ranges
switch on and off:
fig. 3 — liquidity depth by tick · many overlapping positionslive
Read the shape: the tall region near current price is everyone
concentrating where fees are. Slide the price line into the thin tails and imagine being
a trader there — little liquidity means every trade moves the price violently. Depth charts
like this are the honest X-ray of any pool.
04 / HOOKS
Hooks: the pool learns to call your code
A hook is custom logic the pool invokes at fixed moments in a swap's lifecycle.
That's the whole idea — pioneered by Uniswap v4, and the concept every "programmable liquidity"
pitch you'll ever see is built on. Instead of forking a DEX to change its behavior, you attach
a small program at the extension points:
beforeSwap()
Runs first. Can adjust fees, gate access, or reroute — e.g. raise the
fee during volatility spikes so LPs get paid for the risk.
core swap
The pool does its normal work: walk the ticks, consume liquidity,
move the price. Untouched and audited.
afterSwap()
Runs last. Can settle side effects — fill a resting limit order,
update an oracle, trigger a rebalance.
The same pattern wraps liquidity events
(beforeAddLiquidity, afterRemoveLiquidity…). What people build with it:
limit_orders — a position at a single tick that a hook closes when price crosses it.
auto_rebalance — out-of-range positions get recentered without the LP lifting a finger.
twamm — huge orders dripped over hours so they don't crater the curve from fig. 1.
The security catch: hooks are third-party code running inside money
infrastructure. Every extension point is attack surface — reentrancy, fee theft, poisoned
pools. This is why serious hook frameworks live or die on their guardrails, and why auditors
who understand this layer are paid extremely well.
05 / TOKEN BURNS
Burning: real mechanism, favorite costume
A burn sends tokens to an address nobody can spend from — provably destroying
them forever. The mechanism is real and sometimes excellent engineering: Ethereum burns a slice
of every transaction fee (EIP-1559) and Solana burns part of its fees too. Notice what's
being burned there: a neutral resource everyone must spend to use the network. The burn
meters usage and fights spam. Nobody is pressured to stockpile anything.
Set a burn rate and watch supply drain:
fig. 4 — supply under burn · 1,000,000,000 starting supplylive
burned per day
2,500,000
destroyed in year 1
91%
supply hits zero
day 400
Now the costume version. Some projects make you burn
their own token to use their product — and charge you a wildly different rate depending
on how much of the token you already hold. Below is a real tier table from a live Solana
project, reproduced exactly. Drag your holder share and watch what happens to your price:
fig. 5 — the tier trick · a real project's published burn tablelive
your burn per use
50,000
tokens destroyed each install
penalty vs whale
500x
whales pay 100 per use
to reach next tier
buy 0.1% of supply
the "discount" is the sales funnel
The one-question test: what is being burned — a neutral fee everyone
pays to use shared infrastructure, or the project's own token at rates designed to punish
non-holders? The first meters usage. The second manufactures buyers: the project this table
comes from describes it, in its own documentation, as forcing "a buy → install → buy loop"
for "supply-side pressure." When the burn is the business model, you're not the user —
you're the demand.
06 / BUILD IT FOR REAL
The path from this page to shipping on mainnet
Everything above is learnable, and the road is well-marked. Honest scope: months,
not days — and worth it, because people who can build and audit this layer get paid in the open.
01 · Rust fundamentals — weeks 1–4
Solana programs are Rust. Work through Rustlings daily; ownership and borrowing
are the hard part, and they're exactly what keeps DeFi code from losing money.
02 · The Solana account model — weeks 3–6
Accounts, program-derived addresses, cross-program invocations. This is the
mental shift that breaks web developers — and the layer where most exploits live.
03 · Anchor framework — weeks 5–10
Ship real programs to devnet: a counter, then an escrow, then a toy token swap.
Each one is small; together they're the whole vocabulary.
04 · Read a production CLMM — months 3–5
Orca's Whirlpools is open source. Read it with fig. 2 and fig. 3 in your head
and it stops being magic. Now you're qualified to reason about hook frameworks.
05 · Get paid in the open
Ecosystem grants for useful tooling, protocol engineering roles, and audit
contests where one real finding pays four or five figures. No token required — the skill is the asset.
07 / PROOF
Don't believe the page. Run it.
Everything above is powered by tickwork-engine — an open-source CLMM
implementation embedded in this very page. fig. 2's numbers come straight from the engine's
liquidity functions, fig. 1 cross-checks itself against the engine on every render, and the
button below executes the engine's invariant test suite locally in your browser, right now.
No server. No API. If the math were wrong, you'd watch it fail.
fig. 6 — engine test suite · executes on your machinelive
$ 12 invariants loaded · click run
And for anyone doing their diligence — good instinct.
Here's exactly what this project is:
no_wallet — this site never asks you to connect a wallet. There's nothing to connect it to.
zero_cost — free to use, free to fork. MIT license, no signups, no paywall.
open_source — site and engine are MIT-licensed. View source: every equation is inspectable.
runs_locally — the tests above executed on your machine, not on trust.
Honest scope: the engine is a reference implementation for learning
and prototyping — floating point, unaudited, and it says so plainly, because overclaiming is
how projects end badly. Everything on this page runs locally and every equation is inspectable.
Verify, don't trust.