How it works
Rewards is the quote coin for cashback coins: a pump.fun coin that deployers pick as the pair so their holders are paid in it, and that pays its own creator fee to its holders every 15 minutes, in SOL. The rules run in a program on Solana, every payout is published before it's paid, and anyone can recompute it. This page explains where the money comes from, how it's split, and what can and can't be changed.
Where the money comes from
pump.fun charges a creator fee on every Rewards trade. That fee is routed, permanently, to the Rewards treasury: an account only the program can sign for, with no withdraw instruction. Nothing else funds it. Coins paired with Rewards pay their own creator fees to their own holders, through pump.fun, not into this pool; when those holders trade the Rewards they were paid, that's a Rewards trade and it pays the fee like any other. The treasury's own epoch buy pays the fee too; that's a rebate of under 1% of the buy, not a loop.
What a holder gets
Every 15 minutes the program sets an epoch total: 80% of the fees that arrived since the last epoch, plus 1% of the reserve (everything the treasury kept back from earlier epochs). Five percent of that total buys Rewards and burns it, five percent goes to the platform wallet as a line in the same published list, and the other 90% is split among every wallet that held more than $20 of Rewards over the trailing hour, in proportion to weight:
weight = Rewards held × exposure (1–3x) × streak (1–2x) × developer boost (1–1.5x) × payout mode (1–1.25x)Rewards held is your time-weighted average over the trailing hour (four 15-minute windows), not a snapshot. Four multipliers, nothing else:
Exposure, 1x–3x
Hold coins paired with Rewards. The multiplier rises with the value of the live children you hold, reaching 3x when they're worth as much as your Rewards. No single child counts for more than half of your total child value, so one child worth as much as your Rewards gets you 2x. Two equal children worth as much as your Rewards together get you the full 3x; unequal ones get less, because the larger one is capped at half. A child counts only if it traded in the last 24 hours and you hold more than $20 of it, and never for more than half of what its pool actually holds.
Streak, 1x–2x
Rises a little every day you keep holding, reaching 2x after 30 straight days. A day where your average balance drops by more than 10%, or where you were under $20 of Rewards for part of it, steps the streak back three days; ending a day under $20 resets it.
Developer boost, 1x–1.5x
If the deployer of a child you hold has burned Rewards, your weight rises: 1.1x at $250 burned, 1.25x at $1,000, 1.5x at $5,000, permanently. A deployer who instead holds $1,000 of Rewards for seven straight days gets the 1.1x tier for as long as they keep holding. You get the highest tier among the live children you hold.
Payout mode, 1x–1.25x
Payouts are SOL by default. Opt in to be paid in market-bought Rewards instead and your weight counts 1.25x. Until Rewards graduates to its PumpSwap pool, opted-in wallets are paid in SOL, but the 1.25x already counts. The authority can set this between 1x and 1.5x, and any change waits seven days on-chain before it applies.
What that adds up to, in payout weight
- Rewards only, taking SOL: 1x
- Plus two equal live children worth as much as your Rewards together: 3x
- The same, after a 30-day streak: 6x
- The same, when one of those children's deployers has burned $5,000 or more: 9x
- The same, taking payouts in Rewards: 11.25x
Payouts under the floor (at least 0.0001 SOL, higher when network fees spike) aren't sent on their own; they carry over and go out when they cross the line. Nothing is lost. Weight is linear in balance, so splitting a bag across wallets changes nothing.
The 15-minute cycle
Fees arrive
pump.fun collects the creator fee on every Rewards trade. A job anyone can run sweeps it into the treasury every five minutes.
Snapshot
When the window closes, every holder's time-weighted balance, children, streak and payout mode are read from a balance ledger and turned into a weight.
Commit
The payout list is hashed into a Merkle root and written on-chain, together with the hash of the input file, before anyone is paid.
Pay
A job anyone can run pays every entry on the list, in SOL or Rewards. Each payment is checked against the root; nothing outside the list can be paid, and nothing can be paid twice.
Buy and burn
Five percent of the epoch total buys Rewards from its PumpSwap pool and burns it, in the same transaction as the buy for wallets taking Rewards; before graduation it accrues on-chain so nothing is skipped. Five percent goes to the platform wallet, listed in every epoch file.
The treasury
The treasury is a plain system account at an address only the program can sign for, with no data of its own. SOL leaves it in exactly two ways: a holder payout, and the epoch buy that funds Rewards-mode payouts and the burn. There is no withdraw, sweep or admin instruction. Until the program's upgrade authority is burned, upgrades will need the 2-of-3 multisig; a date to burn it will be announced after an audit or 60 days of clean operation.
The treasury address is derived from the program id.
Fee-sharing, locked at launch
pump.fun lets a coin's creator fee be shared with a list of addresses that can be set once. At launch, Rewards' list is set to a single entry (the treasury, 100%), and the admin is revoked in the same step. After that it can't be changed, by us or by anyone. The decoded config will be published here:
- Expected
shareholders = [treasury: 10000] - Expected
admin_revoked = true
Every lamport of Rewards' creator fee lands in the treasury, and only a payout or the epoch buy can move it out.
Only what the list says
Before any payout, the full list of who gets what is hashed into a Merkle root and committed on-chain with the hash of the input file. The pay instruction checks each payment against that root and marks it paid, so no wallet can be paid twice and no amount outside the list can be paid at all. The program also enforces the epoch cap: payouts (the platform line included) plus the buy plus the burn can never exceed 80% of new fees plus 1% of the reserve, even if the job that builds the list is wrong or compromised. The multiplier parameters live on-chain, and the public verifier reads them from the program, not from a config file.
The buy and burn
Each epoch the program buys Rewards with the SOL owed to Rewards-mode wallets plus the 5% burn share, in one transaction. A trade that pushes the price more than 10% doesn't get front-run, it gets cancelled: the buy fails and the epoch pays SOL, with the burn share accruing for later. The buy can only go to the canonical Rewards pool, only into the program's own vault, only within the epoch cap, with an on-chain slippage limit of 10% against the reserves it was quoted on. Every token it buys is either paid out in that epoch's list or burned. It's submitted as a private bundle at a random offset after the window closes, so there's no public transaction to sandwich. If it doesn't land, that epoch is paid in SOL. Before Rewards graduates to its PumpSwap pool every payout is in SOL and each epoch's burn share accrues in an on-chain counter; from graduation the buy burns the current share plus that accrued pot, so no epoch's burn is ever skipped. The authority can set the burn share between 0% and 15%; any change is announced a week ahead.
No snapshot to snipe
Weight uses your exact time-weighted balance over the full 15-minute window, built from a stream of every balance change. Buying just before the window ends counts for a sliver of that window; holding for a few seconds counts for nothing. There is no moment to time.
Who holds the keys
The authority will be a 2-of-3 multisig. It can pause new epochs, adjust the pass-through, reserve and burn shares within bounds written into the program, and change the Rewards-mode multiplier with a seven-day delay. It cannot change the exposure, streak or developer-boost multipliers once they're locked, and it cannot withdraw from the treasury. Pausing stops new epochs only; already-committed payouts stay payable. The crank key pays transaction fees and nothing else; it never holds payout funds.
Compared with pump.fun's own holder rewards
A pump.fun coin in Holders mode pays 100% of its creator fee to holders, in SOL, as it accrues, and nothing when trading stops. Rewards pays about 80–85% of its fee in the first days while the reserve builds; at steady state the epoch total equals what comes in, with 90% paid to holders, 5% to the buy-and-burn and 5% to the platform wallet, disclosed as a line in every epoch file. We don't claim more SOL per fee than native. What native can't do: keep paying through quiet hours from the reserve, buy and burn every 15 minutes, price every child in Rewards so child buys go through Rewards' pool, and pay up to 3x for holding children.
Paying through the quiet hours
Day 3 of the profile has 12 hours with no fees at all. Fees-as-they-arrive stops; the reserve keeps the pool paying every epoch. The rule pays from fees collected earlier: while the reserve builds, it pays less than fees arrive. Figures are total pool payouts per hour, not one holder's share.
Simulated with the stated assumptions. Actual value depends on trading, fees, pool weight and prices.
The weight ladder, in first-day dollars
What the holder pool paid each tier in the first 24 hours of the launch profile, on a $1,000 Rewards stake. Weight shapes the share of each epoch's pool.
- 1x · Rewards only, taking SOL$97.06
- 3x · Plus two equal live children worth as much as your Rewards together$290.03
- 6x · The same, after a 30-day streak$576.62
- 9x · The same, when one of those children's deployers has burned $5,000 or more$859.83
- 11.25x · The same, taking payouts in Rewards$1,070.05
Multipliers affect relative payout weight, not token-price returns. The amount distributed depends on available fees and total eligible weight. Simulated with the stated assumptions. Actual value depends on trading, fees, pool weight and prices. The Rewards-side holder also keeps $1,000 of Rewards; the pool pays that stake, not the coin position.
Every assumption behind the simulated charts
- The child coin trades $50,000 on day 1 with a 3% creator fee routed to holders; the holder keeps 1% of its supply.
- Rewards' own fee inflow follows the published launch profile: $57k on day 1 with a 6-hour half-life, decaying through day 2, a 12-hour quiet lull on day 3, then $8k/day.
- Each 15-minute epoch pays 80% of new inflow plus 1% of the reserve (the on-chain cap rule); 5% of every payout buys and burns Rewards every 15 minutes (before graduation it accrues on-chain and burns with the first post-graduation buy) and 5% goes to the platform wallet.
- The rest of the pool holds $500,000 of eligible weight; a holder's share is their weight against everyone's.
Simulated with the stated assumptions. Actual value depends on trading, fees, pool weight and prices.
Verify an epoch yourself
Each epoch publishes a file, snapshot_<n>.json, with every input needed to recompute every payout: the window, prices, each wallet's balance changes, children, streaks, modes, weights, carry and amounts. The verifier rebuilds the list from the file, reruns the rule with the multiplier parameters read from the on-chain config, and checks the result against the on-chain root, the file hash and the on-chain cap. If anything was changed, it fails.
pnpm verify:epoch snapshot_<n>.jsonRewards makes no promise about its price. Payouts come from trading fees, so they rise and fall with trading; if trading stopped, the reserve would keep paying 1% per epoch and shrink. The only promises here are the ones the program enforces, and you can check every one of them.
Verification status
Each part of the system and where it stands today. A status changes only when there's a public transaction or document to point to.
- Token mint
- Not deployed
- The Rewards mint is created on pump.fun at launch.
- Program
- Not deployed
- The program id above is a development key until the mainnet deployment.
- Treasury
- Not deployed
- A system account only the program can sign for; created when the program is initialised.
- Fee routing
- Planned
- Set once to the treasury at launch, with the admin revoked in the same step.
- Upgrade authority
- Planned
- A 2-of-3 multisig; a burn date will be announced after an audit or 60 days of clean operation.
- Withdrawals
- None in the program
- The program has no withdraw, sweep or admin instruction.
- Independent audit
- None yet
- Nothing on this site says "audited" until a report is published.
- Payout records
- Sample only
- One real published epoch file; live records start with the first mainnet epoch.
Limits, and where value leaves
- SOL payouts leave the system.
- Holders who sell the Rewards they're paid add sell pressure.
- Selling a child for SOL routes back through Rewards and sells Rewards.
- Buying and burning executes from graduation; every earlier epoch's 5% share accrues on-chain and is burned then.
- The 5% burn and the 5% platform share come out of the holders' share, not on top of it.
- Trading fees, spread, slippage and price moves all affect what a payout is worth.
- More participation doesn't mean a higher price.
- More eligible holders means a smaller share each.
- A higher multiplier doesn't make a small pool bigger.
- Liquidity, trading activity and balances change all the time.