How the curve works.

A fact that changes the meaning of a number sits beside that number. Not in a footer, not on page six, not behind a tooltip — beside it, in the same line of type.

That rule is why the settlement kind is a column on the market row rather than a constant somewhere: no query can return a price without also returning what kind of price it is. And it is why the only function that turns lamports into words takes the settlement as a required argument. A developer here cannot print a figure without having the fact that qualifies it in hand, because the compiler will not let them.

This is not a hypothetical failure. The product this one answers is documented carefully and honestly — and runs on devnet, a word that appears once, in the last line of its sixth page, while its front page shows thirty-four buy buttons and a reserve figure in SOL.

price(n) = n² ÷ 16000 SOL

n is the number of keys already outstanding, and the result is what the next key costs. Buying mints a key and moves n up; selling burns one and moves it down. There is no order book and no counterparty — the curve is both the bid and the ask.

It is drawn as bars and never as a line, everywhere it appears. The curve is defined only at whole numbers: there is no half key, and no price exists between two of them. A smooth line would draw values the product does not have.

Every figure is a BigInt of lamports and not one float touches a price, a fee or a reserve. A float book drifts by a lamport at a time, and six weeks later the drift is unfindable.

Key 0 costs zero, because n² at zero is zero. The first buyer on any curve takes a key for nothing. That is a property of the formula, said here rather than floored away quietly.

An order for more than one key pays the staircase — not the current price times the size. The difference grows with order size and is the most common way a curve interface misleads.

Buying 3 keys when 40 are outstanding pays price(40) + price(41) + price(42), and not three times price(40):

Selling 3 keys straight back at supply 43 returns exactly what the staircase charged, to the lamport — that equality is asserted by the tests — and then the same 7% comes off the other side.

A key bought and sold with no other trade in between loses 13.08% of what its buyer paid. The price has to move that far before the position is level, and nothing about this curve makes it back for you.

Elsewhere this site says a round trip costs about 14%, and that is the same cost stated against a different denominator: 7% is charged on each side of the staircase, so the two fees come to 13.99% of the staircase — but the buyer paid the staircase plus their own fee, so against the sum that actually left their wallet it is 13.08%. Both are true. Neither is printed anywhere here without the thing it is a percentage of.

The three cuts are integer division, which loses lamports. The remainder stays in the net — the reserve on a buy, the seller on a sell. The house never collects a rounding remainder, and the test suite asserts the four parts sum to the whole.

Not by looping over every holder on every trade. A running lamports-per-key accumulator goes up on each trade, each position stores the accumulator value when it last settled, and a holder is owed

keys × (acc_now − acc_at_their_checkpoint) ÷ 1,000,000,000,000

which pays them for exactly the trades that happened while they held. The scale factor exists so a thin curve does not round a holder's share down to nothing.

On the example buy above, against a supply of 40:

The buyer is paid nothing out of their own trade. Their position settles at the accumulator before this trade's cut is added, so the 2.5% they just paid reaches the people who were already holding. Crediting the buyer from their own fee is the quiet way these markets stop paying early holders anything at all.

On an empty curve there is nobody to pay, so that cut stays in the reserve rather than being credited to the buyer who caused it — the one case where a fee does not reach the pool, and the book records it as reserve rather than as a holder payout that never happened.

Three kinds exist, and the interface has different words for each. These are the exact strings printed beside figures elsewhere on the site — read from the same object, so this page cannot describe a settlement kind the interface labels differently.

Every market on this site is on the paper book today. No SOL has moved, nothing is custodied, and a balance here buys nothing. That sentence is on the top of every page that shows a figure, not only this one.

The 3% escrow accrues to a handle whether its owner has heard of this site or not. To take it, that owner puts a code we issue somewhere public on the account, and we request the page over ordinary HTTP and look for the code in what comes back.

The claim is recorded only if the code was in the response, and every attempt reports the URL requested, the status returned and the bytes seen — including the failures. Nothing is ever “pending review”: pending sounds like progress, and there is no queue and no reviewer.

The method has a hard limit and it is measured rather than guessed. Of the three platforms, only X serves a profile page this can read.

A code posted on TikTok or Instagram cannot be proved from here however long its owner waits, so the claim desk says so beside the buttons rather than letting each failure read as the user's mistake. The claim desk →