LACUNARY
A chain schedules a block for every slot and does not always get one, so the record of blocks that exist carries gaps in it. A series with gaps in it is lacunary, and those gaps are readable directly, without an oracle and without anyone reporting them. The program holds three numbers and accepts one instruction. Its state is a cycle index, the skip rate measured at the last settlement, and the running total of liquidity it has locked. At settlement the program reads a window of that record, counts what is missing from it, and divides the accumulated trading fee in two: coin bought and destroyed, and coin bought and paired into liquidity that is never withdrawn. The ratio is the skip rate scaled against a fixed reference. A window with no gaps in it locks everything and burns nothing. A window at or above the reference burns everything and locks nothing. Everything between is linear. No participant is required at any point, no work is submitted, no reward is paid out, and the one instruction that advances the state is permissionless and returns nothing to whoever calls it. What the chain failed to produce is converted into destruction. What it produced is converted into depth. The program has no opinion about which of those is better and neither leg leaves the coin.
PROVENANCE
The mint is deliberately inert. It carries no transfer hook, no transfer fee, no permanent delegate and no freeze authority, its mint authority has been null since before the first trade, and its supply is fixed and will not change. Nothing about holding it is programmable by anyone, including us, and the whole of that claim is verifiable in a single account read rather than in a promise made on a website.
That leaves the revenue as the only thing left to design. A trading fee accrues whether or not anyone is paying attention to it, and the question is what decides where it goes. Most designs answer with a schedule someone typed before launch. This one answers with a number the network produces on its own, and the rest of this document is about which number and why that one.
Why the signal is the chain's own failure
Most schedules are written by whoever deploys them. A share halves, a rate decays, a target doubles, and the curve is whatever was typed into the config before launch. This is defensible and it is what Bitcoin does, but it means the interesting number in the system was chosen rather than measured, and a reader is being asked to accept that the choice was a good one.
The alternative is to find a number the chain already produces, that nobody controls, that costs nothing to read, and that cannot be reported falsely. Skipped slots satisfy all four. Solana assigns every slot to a leader and expects a block from each one. Leaders miss, for reasons that range from ordinary network conditions to hardware failure to congestion, and a slot that produced nothing is not recorded anywhere as having existed. The record of recent slots is therefore not a contiguous run of numbers. It has holes in it, the holes correspond exactly to blocks the network owed and did not deliver, and counting them requires reading one account and subtracting. Nobody submits the number, nobody attests to it, and nobody can inflate it without persuading validators across the network to fail on cue.
The window
The SlotHashes sysvar retains the five hundred and twelve most recent slots that produced a block, each paired with its hash, ordered newest first. It is written by the runtime, it is readable by any program, and it costs nothing beyond the account load to inspect.
Because it retains only slots that produced, the span it covers is longer than the number of entries it holds whenever anything was missed. The newest entry and the oldest entry give the span, the entry count is fixed at five hundred and twelve, and the difference between them is the number of slots inside that span for which no block exists. At four hundred milliseconds a slot, five hundred and twelve entries reach back somewhere between three and four minutes depending on how bad the interval was, which means the window is short enough to reflect current conditions and long enough that a single unlucky leader does not dominate it.
The count
Let the newest recorded slot in the window be h and the oldest be l. The span is h minus l plus one. The window holds five hundred and twelve entries. The skipped count is the span less the entries, and the skip rate is the skipped count over the span:
A perfect interval gives a span of exactly five hundred and twelve, a skipped count of zero, and a skip rate of zero. Every missed block widens the span without adding an entry, so the rate rises. There is no configuration in which the number is negative and no configuration in which it exceeds one. It is a ratio of two integers the runtime maintains and it is the same number for every program that reads it in the same slot.
The split
The accumulated fee is divided in two. Write b for the burn share and l for the liquidity share:
At a skip rate of zero the entire sweep is spent buying coin and pairing it into liquidity that is never withdrawn. At a skip rate of ten percent or worse the entire sweep is spent buying coin and destroying it. Between the two the split moves linearly, so a two and a half percent interval burns a quarter and locks three quarters. The reference is set at ten percent because intervals that bad occur and intervals materially worse than that are rare enough that treating them as saturation loses nothing.
The two shares sum to one at every value of s and neither can be negative, so nothing is retained and nothing is stranded. There is no third leg, no operator share, and no instruction anywhere in the program that would create one.
Proof. Adding a skip increases both the skipped count and the span by one. At a skipped count of k the rate moves from k/(512+k) to (k+1)/(513+k), a difference bounded above by 1/512. Scaled by the reference of one tenth, the burn share moves by at most 1/51.2, which is under two percent.
The bound matters because it is what prevents a single validator from moving the split. Anyone wanting to shift the ratio meaningfully needs the network to fail repeatedly across a window they do not control, which is not a thing that can be bought.
Settlement
The revenue is the trading fee. The config sets a flat two hundred basis point base fee with a creator share of one half, so one hundred basis points of volume accrues to the creator vault. It is paid by buyer and seller alike, it does not decay with market capitalisation, and it does not stop at migration.
settle sweeps that vault, reads the window, computes the split, and executes two separate swaps against the pool. The burn leg is destroyed with a Token 2022 burn instruction and the program reloads supply from the mint afterwards rather than decrementing its own copy, so its idea of supply is the chain's idea of supply. The liquidity leg is paired with its quote and added to a position locked by Meteora's own program, which has no unlock path to call and no timer to wait out. Coin is never minted after genesis and no coin is ever paid to a person. Both legs end inside the asset.
The interface
| instruction | signer | effect |
|---|---|---|
| settle | anyone | reads the window, computes the split, buys, burns, locks, advances the cycle |
| field | type | meaning |
|---|---|---|
| cycle | u64 | number of settlements executed |
| skip_rate | u32 | rate measured at the last settlement, in basis points |
| locked | u64 | cumulative quote paired into permanent liquidity |
| settled_at | i64 | unix timestamp of the last settlement |
The interesting part of an interface is what is missing from it. There is no instruction that sets the reference, so the point at which burning saturates cannot be moved after deployment. There is no instruction that writes the skip rate, so the number cannot be supplied from outside. There is no withdrawal path for the locked position, so the liquidity leg is one way by construction rather than by promise. There is no pause, no migrate, and no upgrade authority retained past deployment. A rule that can be amended is a preference. A rule with no amending instruction is a constraint, and only the second kind is worth describing at length.
The still
If nobody calls settle, the fee accumulates in the vault and the cycle does not advance. If the network runs a perfect interval for a long stretch, every settlement locks and nothing is destroyed. If it runs badly for a long stretch, every settlement destroys and nothing is locked.
Only the first of those is idleness, and idleness is a pause. Nothing is lost, nothing reverses, no position is unwound, and the accumulated fee is still sitting in the vault when someone returns. The other two are not failures at all. They are the mechanism doing exactly one of the two things it was built to do, and neither of them removes anything from the coin. The field on this site shows the whole range: the wave stutters when the window carries gaps and runs smooth when it does not, and when nothing has been settled for a long time the bodies slow and drift. This is what the system looks like from outside, and it was easier to show it than to hide it.
1. The window is five hundred and twelve entries because that is what the runtime retains. It is not a parameter.
2. Meteora takes a protocol share before the partner and creator legs are separated. That share is not ours and is nowhere counted.
3. The caller of settle receives nothing. There is no crank reward and no instruction that would pay one.
4. A skip rate above the reference saturates rather than overflowing. There is no configuration in which more than the sweep is spent.