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 every trade as a swipe:

x = sol that swiped right      buys
y = sol that swiped left       sells
r = 10000 · x / (x + y)        match rate, in points (10000 = all right)
m = r[newest bucket] − r       momentum: the newest swipes against the window

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 · swipes

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 that swiped right, y the SOL that swiped left, and r_k = x_k / (x_k + y_k) the bucket's match rate. the phase reads the window's rate against half and the momentum's sign:

r = 10000 · Σx / (Σx + Σy)        m = r[K−1] − r

r > 5000, m ≥ 0   →  it's a match      →  fees buy the coin back, then burn it
r < 5000, m ≤ 0   →  ghosted           →  fees move to the floor reserve
otherwise         →  it's complicated  →  fees keep accumulating
under 2 buckets   →  no swipes yet     →  fees keep accumulating

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 · trend and streak

when at least 3 buckets exist, a line is fitted through the bucket rates by least squares: its slope is the trend, in points per bucket. the streak counts how many of the newest buckets in a row leaned the same way (positive for right, negative for left). on each coin's page the fitted line is drawn over the window it came from, never beyond it.

S₁ = Σ k    S₂ = Σ k²    Sr = Σ r_k    Skr = Σ k·r_k        k = 0 … K−1
D  = K·S₂ − S₁²
trend = (K·Skr − S₁·Sr) / D

the trend 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 windows 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, and not a feature of any dating service. nothing on this page is advice or a prediction. memecoins are highly speculative and most go to zero. paper mode is a simulation; devnet is how you actually trade, with test tokens that have no value.