Solana · the fees go back through the chart
I do not decide when I run.
Every trade pays a fee. The fee is claimed and spent straight back into the chart in fixed lots, one after another, until the spend has caught the claim. Then it waits.
Six facts and no mechanism worship. The arithmetic is further down, worked through with live numbers.
A share of each buy and each sell lands in a vault on chain that only the creator can empty. That is the one lever a plain pump.fun mint gives anybody, and it is the only input this whole thing has.
When the vault reaches 0.1 the engine empties it. Not on a schedule, not when somebody feels like it, and not at a size chosen afterwards to look good. At 0.1, because that is the number written in the config.
The claim is spent buying the coin, in lots of 0.1, a few seconds apart, for as long as there is claimed money left to spend. Not liquidity, not a treasury, not a reserve. Market buys, one after another.
It keeps firing until what it has spent is within one lot of what it has claimed, and then it goes quiet until the vault fills again. There is no version where it keeps buying with money it did not claim.
There is float in there for fees, and whatever else arrives. None of it is available. The budget is a ledger of claimed minus spent kept on disk, and the balance sitting next to it is not an invitation.
The log below is not a summary. It is each claim and each buy with its transaction, so you can take any single line to Solscan and watch it disagree with this page, or not.
Read live off the chart every eight seconds. Nothing here is typed in by hand, and the one row that is arithmetic rather than a reading says est. on it.
Every reading this tab has taken since you opened it, eight seconds apart. It starts empty on purpose — there is no history to load, and drawing one would mean inventing it.
Claims in, buys out, each with the transaction that did it. This is the engine's own ledger, served straight off the machine that keeps it, not a retelling.
| # | what | amount | when | transaction |
|---|---|---|---|---|
| The engine is not reachable from here, so there is nothing to show. This table stays empty rather than filling itself with plausible numbers. | ||||
The engine runs on a home PC, so it is not always up. When it is not, this table is empty and the meter above carries on regardless — that one reads the chart directly and does not need anything of ours to be switched on.
Volume divided by liquidity, over a day. It says how hard the thing is being traded relative to how much is sitting there, which is the number that decides how fast the vault refills and therefore how often the tap runs.
Right now the tap reads nothing yet.
This is the honest version of the whole idea. A buy moves the price by the trade divided by the SOL side of the pool. So what a lot does depends entirely on how much liquidity it is buying into, and on a deep pool the answer is: very little, repeatedly.
| lots | spent | moves price | as a share of the pool |
|---|---|---|---|
| waiting for a pool to measure against | |||
Exact for constant product, which is what pump.fun's curve and the PumpSwap pool both use. Compounding is ignored, so treat the multi-lot rows as the floor rather than the whole of it. A lot buying into a thin pool moves a great deal more than the same lot buying into a deep one, and neither of those is a promise about where the price goes next.
Fees are a rate, so the tap has a cadence. At the volume the chart is doing right now, this is what accrues and how long the vault takes to reach the tenth of a SOL that opens it.
Holding today's volume flat, which it will not be. A day of real volume rewrites every line here, which is why it is read live rather than printed once and left. The fee rate is the one constant and it is on the page rather than hidden: — of traded volume, and it is set by the launchpad, not by us.
The tap does not choose when it runs. It runs when the vault is full enough, and the vault fills when people trade, and nobody here has any say in when that happens. A quiet hour is a shut tap, and that is not a malfunction, it is the mechanism working exactly as described.
Which also means there is nothing to announce. No claim day, no buyback event, no thread about what is coming. It either fired or it did not, and the log says which.
spend → claim, never further
Read it once and you know exactly what you are holding, including the parts that are not flattering.
On pump.fun the token is a plain SPL mint. No transfer tax, no hooks, no clever transfer logic available to anyone, including us. The one real lever is the creator fee stream: a share of every trade, accruing in a vault, claimable on chain by whoever created the coin. Most projects claim it and keep it. This one claims it and spends it back through the same chart it came out of.
A claim spent all at once is one candle and then nothing. The same money spent as a run of small buys a few seconds apart is a presence rather than an event, and it is far harder to front-run because there is no single moment to be in front of. So the engine spends in lots of 0.1 SOL, one at a time, until the claim is used up.
It also means the size never depends on how anybody feels about the chart that afternoon. The lot is a number in a config file, and changing it is a change to the config file.
This is the only invariant worth having, and it is the one everything else is built around. The engine keeps a persisted ledger of claimed minus spent, and a lot only fires against that number. The wallet's actual balance is deliberately not consulted, because the wallet holds more than the tap may spend — float for fees, and whatever else arrives — and spending against a balance is how a machine quietly starts spending money it never earned.
budget = claimed - spent - in flight fire a lot while budget >= one lot
Both sides of that are measured the same way: the actual lamports that moved in and out of the wallet on a confirmed transaction, read back off the chain afterwards. Not what it hoped to claim, not the lot size it meant to spend. Transaction fees and account rent come out of the claim as well, so the overheads shorten the run rather than being paid out of something else.
It keeps it. The tokens sit in the fee wallet and are not sold, not burned and not moved. That is a deliberate choice and it has an obvious downside, which is that a visible bag accumulates on a wallet anybody can look up. It is written out in full on its own page rather than buried here, because pretending a growing balance on a known address is invisible would be silly.
The meter — flow, cap, price, liquidity, head, volume, pressure and age — is read live off the chart in your browser and is as true as Dexscreener is. Fees, cadence and the force table are arithmetic on those live figures at the fee rate printed above, and say est. where they appear.
The log is different and better: it is the engine's own ledger, and every row carries the transaction that produced it. When the engine is not reachable the log is empty rather than estimated, because a claim that cannot be evidenced is not a claim.
Peak flow is a genuine high-water mark of a real number, but it is kept in your own browser and only covers what this browser has watched. It is not a chain record and is not presented as one.
It puts real buy orders into the book, which is more than most fee streams do with themselves. It does not overcome selling, it does not set a floor, and one lot against a deep pool moves the price by very little. Anybody telling you a buyback guarantees a direction is selling something.
Because that is a different coin and it has been done. Liquidity makes the exit cheaper for everybody including the person leaving; buying puts the money into the chart where it either meets a seller or it does not. This one buys. The trade-off is real and it is not being hidden.
No, and that is the one thing engineered rather than intended. The budget is claimed minus spent, kept on disk, measured on both sides from what actually moved on chain. The wallet balance is not consulted, an unresolved transaction blocks the next lot, and a lot is sized so that even the slippage tolerance cannot push it over. Four separate checks, because one is not enough for this.
The ledger is on disk and written before anything is sent, so on restart it knows what it claimed and what it had in flight. It asks the chain what happened to the unresolved one before it does anything else, and it fires nothing until that is settled.
Small enough that claiming happens often rather than in rare lumps, and large enough that the transaction fee is a rounding error rather than a meaningful share of the buy. Below about 0.002 a lot costs more to send than it spends.
The tap is the point. The coin is what it is plumbed into.
Each of these appears in the arithmetic above and means exactly one thing.
Mint, wallet, chart. All public, none of it ours to edit.
—