Method

How this is measured

Three kinds of number appear on this site and they are not interchangeable. Keeping them apart is most of the work, because the sector's published tables routinely add them together and then disagree with each other by a factor of eighty.

Three tiers, never merged

measured

Read from a chain

Total supply from the mint account, and whether the mint authority is revoked. Exact, reproducible, and independent of any vendor. Available for the Solana tokens here ( of ).

published

A stated commitment

"50% of net revenue goes to buybacks." This is intent, not a measured flow. NetBurn uses the published share, links the source, and never claims the money arrived.

vendor

A third party's estimate

Circulating supply, prices, protocol revenue. Useful, and maintained by hand — which means it gets restated, and sometimes contradicts itself.

Instrument bug #1 · caught before publishing

A vendor changing its mind looks exactly like a burn

There is no public feed of "circulating supply over time". The series everyone uses is market cap divided by price, and market cap is computed from a circulating-supply figure a data vendor maintains by hand. When the vendor reclassifies — decides some treasury or foundation allocation should no longer count — the series takes a step down that is arithmetically identical to a burn.

One token here is the worked example. Read naively, its float shrank sharply over the window, which would make it among the most deflationary tokens in the set. It did nothing of the kind.

DateOne-day moveLevel a week laterDiagnosis

Instrument bug #2 · the fix for #1 was wrong too

Most "steps" are not steps

The first restatement detector simply flagged any one-day move above 2%. It put series in the restated bucket — a striking number, and a false one. Inspecting the flagged moves showed them arriving in pairs that reverted within a day or two, and landing on the same dates across unrelated tokens:

No token-specific supply event can land on the same two days for two unrelated tokens. These are the price and market-cap arrays being momentarily inconsistent with each other, and dividing one by the other manufactures a spike. A step now only counts if the level either side of it actually moved — median of the week before against the week after. That reclassified spikes across series as artefacts and left tokens with a genuine unexplained drop.

Both versions of this bug pointed the same way. The loose detector made the data look dirtier than it is, which flattered the site's own thesis that nobody should trust vendor supply figures. That is the tell this family has learned to watch for: when a measurement flatters the argument it was built to make, audit the instrument first.

Instrument bug #3 · a factor of

"Percent of fees" and "percent of revenue" are different numbers

DefiLlama publishes two lines per protocol: fees, everything users paid, and revenue, the protocol's own take. For Raydium over 30 days these are and — a factor of . Raydium's published commitment is "12% of trading fees", so applying 12% to the revenue line understates its buyback by that factor.

The first build did exactly that and reported Raydium taking over 99 years to absorb its overhang. Corrected, it is about twenty. Every token here now declares which line its policy is a share of, matched to the wording of its own announcement.

ProtocolPolicy is a share of 30d, line used30d, other lineFold difference

Instrument bug #4 · a quantity that cannot be negative

The vendor contradicts itself, and the arithmetic goes quietly on

It printed as "−1.1 yr" without complaint. Absorption time is a duration; it cannot be negative. The build now rejects any overhang built from a circulating figure that exceeds its own total or max supply, and the token is shown with a dash rather than a plausible-looking number.

Instrument bug #5 · the estimator was fine, the copy was wrong

The method does not cry wolf, and that was a surprise

The interactive page was written expecting to demonstrate that post-hoc event studies find effects wherever you point them. Sweeping the treatment date across every week in the window and recording how often the estimator calls an arbitrary date significant says otherwise — the false-positive rate sits near the nominal level.

The reason is the placebo bundle. A market-wide move lifts the treated token and all twenty donors together, so it inflates every placebo ratio by the same amount and cancels out of the rank. A single-token event study has nothing to cancel against, which is why it over-rejects and this does not. The draft copy claiming otherwise was deleted rather than softened.

That makes the nulls on that page informative. When the estimator reports nothing at a real policy date, it is not because the instrument is too blunt to see anything.

The estimator

Synthetic control, and three choices that moved the answer

Minimise ‖y_pre − X_pre w‖² subject to w ≥ 0 and Σw = 1, by projected gradient with Nesterov momentum and an exact projection onto the probability simplex. Inference is a rank test over in-space placebos.

Demeaning

Each unit is centred on its own pre-treatment mean before fitting. Without it the weights must reproduce the treated token's absolute level as well as its shape, and the fit collapses toward a corner. No unit fits worse for it, and the mean uses no post-treatment data.

Stopping rule

Stop on relative objective change, capped at 400 iterations. Chasing a 1e-7 tolerance on the weights took ~2,000 iterations to move the pre-fit RMSPE by nothing at all and the effect ratio by a quarter of a percent — into a rank statistic that cannot resolve finer than 1/21. Ten times the work for precision the test cannot express.

Sweep by unit, not by date

The obvious loop — for each date, fit everything — refits all twenty placebos cold at every date. Sweeping one unit across all its dates lets each solve warm-start from the last. Same 3,045 solves, 16,462 ms → 1,343 ms, every reported figure identical.

Why there is no WebAssembly here. The honest reason to reach for it would be that JavaScript could not keep up. It can: the grid runs in about a second across a worker pool, inside the interaction budget, and the two changes that actually mattered were algorithmic rather than about the runtime. Hand-emitting bytecode — there is no WASM toolchain on this machine — would have bought perhaps another 1.5–2× on top of a 12× already won for free, while adding a build step to a site that deliberately has none. Shipping it would have been decoration.

Limits

What would change the answers

An unlock is not a sale. The overhang counts supply that becomes able to trade. Proving that a given locked token was actually sold means following recipient wallets forward on-chain, which the public RPC rate limits far below what a full pass needs. The coverage figures here are a bound on what a buyback could absorb, never a claim about what does hit the market.

365 days is the ceiling. The free price tier reaches back one year, which puts most of these programmes' start dates outside the window. Only policy changes inside it can be tested; the estimator page marks which tokens have one and which do not.

Policy shares are not audited. If a protocol announces 50% and routes 30%, NetBurn reports the 50% and is wrong by that much. Verifying it means identifying and following the buyback wallet for each protocol across four chains.

Buy-and-hold is counted as a bid, not as a burn. Tokens bought into a treasury can return to the float. They reduce supply by nothing and the table says so, but they are real buying pressure and the price estimator treats them as such.