how fee routing works
every coin on swipe is a pump.fun coin: same bonding curve, same trading, same graduation to pumpswap. what swipe adds is what happens to a coin's creator fees. each coin is treated as a profile on a dating app, and its trades as swipes:
buy of d sol → a swipe right, weight d sell of d sol → a swipe left, weight d m = X / (X + Y) match rate: sol right over all sol, in the window lean = x[K−1] − y[K−1] newest swipes: which way the last bucket went
0 · whose fees
pump.fun pays a creator fee on every trade to the coin's creator. a coin launched on swipe sets that creator to a program address, ["creator", mint], so only the program can collect and move those fees. the launcher does not receive them. for every other pump.fun coin the page shows a simulation of the same rule on that coin's live trades, labelled "sim".
1 · observations
the program reads the coin's pump.fun curve. each time it is cranked, the change in the curve's virtual sol since the last crank is one swipe: sol in is a swipe right, sol out a swipe left. swipe cranks inside every trade it sends, and a keeper cranks after trades made anywhere else, so one swipe is about one trade. no trade, no swipe.
2 · the window and the phase
the last 100 swipes are split into 10 buckets of 10, aligned to the newest. time is counted in buckets, not seconds. per bucket, x is the sol of buys (right), y the sol of sells (left). the phase reads the match rate of the whole window against the lean of its newest bucket:
m = 10000·X / (X + Y) lean = x[K−1] − y[K−1] m > 50%, lean → → it's a match → fees buy the coin, then burn it m < 50%, lean ← → ghosted → fees move to the floor reserve they disagree → it's complicated → fees wait (also m = 50% exactly) lean = 0 → left on read → fees wait fewer than 2 buckets → no matches yet → fees wait
vaults under 0.001 sol wait for the next crank instead of paying for a tiny buyback.
3 · burn and floor
a burn is an ordinary pump.fun buy made by the program with the collected fees, followed by burning every token it bought. the floor reserve is a program-owned account, ["floor", mint]. the program has no instruction that moves lamports out of it: no withdraw, no close, no admin path, no redemption. the test suite proves this by scanning the source and the idl and by checking the balance never decreases across random crank sequences.
outstanding supply = total supply − total burned floor backing per token = floor reserve ÷ outstanding supply
floor backing per token can only rise. it is not a claim, not a promise and not a price support: the price can fall below it. nobody can withdraw the floor.
4 · the trend estimate
when at least 3 buckets exist, a line is fitted through the per-bucket match rates by least squares: m_k = a + s·k. s is the trend (positive when the profile warmed up across the window, negative when it cooled), a the opening rate at the start of the window. the streak counts how many of the newest buckets lean the way the newest one does. on each coin's page the fitted line is drawn over the window it came from, never beyond it.
S₁ = Σ k S₂ = Σ k² Sm = Σ m_k Skm = Σ k·m_k k = 0 … K−1 D = K·S₂ − S₁² s = (K·Skm − S₁·Sm) / D a = (S₂·Sm − S₁·Skm) / D
s, a and the streak describe the recent past of one market, they are not used by the routing, and they forecast nothing. the program computes them in 128-bit integers; this app runs the same integer arithmetic, and its test suite replays 300 cases generated by the program's own tests. full spec in docs/MECHANISM.md.
5 · after graduation
when a coin completes its curve and moves to pumpswap, the curve stops changing: no new swipes, no more buybacks on the curve. a ghosted phase still moves collected fees to the floor.
the dating words are a way to read past trade flow, not a model of what comes next. nothing on this page is advice or a prediction. memecoins are highly speculative and most go to zero. paper mode is a simulation.