standing instruction · not revised
The tap does not
decide when it runs.
Every trade on this coin pays the creator. That fee accrues in a vault on chain that anyone can read and only the creator can empty. Emptying it is the one lever a plain pump.fun mint gives anybody, and it is the only input this whole arrangement has.
a cutaway. there is no treasury at the end of it, and no wallet quietly filling up with what the lots bought.
What it does, in order
In the order they happen. Nothing here is a plan or an intention; it is what the engine does on every tick, and the ledger carries a signature for each one.
-
every trade pays the creator
A share of each buy and each sell lands in a vault on chain. Not a promise, not a treasury I control the rules of: a program-owned account with a balance, which you can read without asking me anything.
-
at a tenth of a SOL it is claimed
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 impressive. At 0.1, because that is the number in the config file, and changing it is a change to the config file.
-
the claim is spent buying the coin, in lots
A claim spent all at once is one candle and then an afternoon of nothing, which is what everybody else does and it is why you can name none of them. The same money spent as a run of 0.1 lots seconds apart is a presence rather than an event, and there is no single moment to stand in front of.
-
what the lot buys is destroyed in the same transaction
This is the part that changed. The tokens are not kept, not held, not parked in a wallet you have to trust me about. The buy instruction and the burn instruction are in one transaction, so either both happened or neither did, and there is never a window in which bought tokens are sitting somewhere waiting to be sold by anybody, including me.
-
it stops when the spend catches the claim
It fires until what it has spent is within one lot of what it has claimed, and then it is quiet until the vault fills again. There is no version of this where it keeps buying with money it did not claim. The budget is claimed minus spent, kept on a disk, and the wallet balance sitting next to it is not an invitation.
-
every claim, every lot, every burn has a signature
The ledger is not a summary. It is each row with the transaction that produced it, so you can take any single line to Solscan and watch it disagree with this page, or not.
The budget, which is the only thing stopping it
Both sides measured the same way: lamports that actually moved, read back off the chain after the fact, never the amount that was intended.
fees and rent come out of the claim too, so the overheads shorten the run rather than being paid out of something else.
Deriving how much to spend from the wallet's balance is the trap, and it is the one that costs real money. If a claim lands in the same wallet you are reading, the next cycle counts it again; if somebody deposits, the engine spends their deposit. So the spend comes off a persisted ledger and nothing else. The wallet is expected to hold more than the budget at all times, and everything above the budget belongs to somebody who is not me.
What one lot actually moves
Persistent, not large. Anybody can work the size of it out, so it may as well be here with the arithmetic printed next to it.
exact for a constant product curve, which is what both the bonding curve and the graduated pool are.
read live off the chart every eight seconds. the one row that is arithmetic rather than a reading says est. on it. the destroyed figures come off the engine's own ledger and are em dashes when it is not connected.
Pressure
Volume against liquidity. It is the only input that decides the cadence, and nobody here has any say in it.
| band | volume ÷ liquidity, daily | what that looks like |
|---|---|---|
| DRIP | under 1× | shut. no fees, no claim, nothing to spend |
| RUNNING | 1× to 6× | a claim every so often, a short run of lots |
| MAINS | 6× to 20× | claiming faster than it can spend it down |
| BURST | over 20× | wide open, and the burn counter is the thing to watch |
What is not proven
Kept here rather than in the small print, because it is about the machine rather than about you.
The claim path and the buy path have both moved real money on a live chart before. Thirty-six confirmed buys on a previous coin, 3.3871 SOL spent against 3.5314 claimed, and six that failed at simulation and cost nothing. The small print carries the full record, including the earlier run that failed all hundred and one of its buys.
The burn is newer than that. Buy-and-burn in a single transaction is the shape that survives a failure, because either the whole thing lands or none of it does, and a reverted lot costs a fee and nothing else. But this coin is a new mint with a new dev wallet, so a new creator vault, and none of that wiring has been exercised. It gets checked against this coin before the first announcement. If the first lots do not land you will see it in the ledger, because a failed row is written as a failed row.