How it works

When the token goes up, the program sells a small fraction of the net buy flow. The proceeds go to the treasury for buybacks; holders are paid from the pump.fun creator fee, up to 3% of every trade, set aside for them directly. (A launch can also route 40% of the bot's sales to holders.) When the token goes down, the program stops selling and the treasury bids: the further the price falls under the bot's own average selling price, the larger the buyback, and never more than half the treasury at once.

Additional liquidity, paid for by the creator, is deposited into the PumpSwap pool at graduation and locked. The pump.fun creator fee funds buyback and burn, minus the platform's share.

Everything is locked inside the program, forever or for a publicly displayed period. Nobody, neither the creator nor PUMPMAKER, can bypass these rules: the program enforces them, and anyone can verify it on-chain. That is the difference from the volume bots that already exist on pump.fun.

The animation at the top of this page plays one full cycle with the program's own sizing rule. In words:

1. 1
   The token goes up. Buys exceed sells, the pool's SOL reserve grows. The program sells a fixed fraction of that net rise. The SOL obtained goes to the treasury (or, if the launch chose it, 60% to the treasury and 40% to the holders' rewards vault).
2. 2
   The token goes down. Sells exceed buys, the reserve shrinks. The program stops selling and buys back with the treasury. The buyback is sized on the discount: how far the price sits under the average price the bot itself sold at. A shallow dip gets a small bid; a deep one commits up to half the treasury.
3. 3
   A reserve is always kept. No single buyback takes more than half the treasury, so a second leg down still finds a bid. Sells resume on the next net rise, which refills the treasury.
4. 4
   Over a full cycle, the market maker has sold higher than it bought back: its token inventory grows. Those tokens stay in the program, locked. The only money leaving the system is the holders' share.

On every rebalance call:

1. 1
   The program reads R from the pool accounts, within the same transaction. It computes Δ = R − R_ref.
2. 2
   If Δ > 0: net rise. It sells inventory tokens to obtain s·Δ in SOL, computed with the pool's formula, and sends it to the treasury (or splits it 60% treasury, 40% rewards). The sale updates P̄.
3. 3
   If Δ < 0: net drop. It measures the discount d = 1 − price / P̄ and commits the larger of the floor b·|Δ| and a share of the treasury set by d — 10% of T from 4% under, 20% from 8%, 35% from 15%, 50% from 25% — capped at T / 2. The tokens go into the inventory.
4. 4
   After the operation, R_ref takes the value of R after the program's own trade. Its own trades never count as flow.
5. 5
   If the computed operation is below the minimum (0.01 SOL, configurable), the program does nothing and leaves R_ref untouched: the flow accumulates until the next call.

Between two calls, the public bought 10 SOL and sold 2 SOL: R rose by 8 SOL, so the program sells 0.40 SOL worth of tokens, all of it to the treasury (a launch that chose the 60/40 split would send 0.16 SOL of it to holders). On the next call, sells of 10 SOL and buys of 3 SOL: R dropped by 7 SOL. If the price is still close to what the bot sold at, only the floor answers: 0.21 SOL worth of tokens. If instead the price has fallen 25% under the bot's own sales and the treasury holds 2 SOL, the program commits 1 SOL — half the treasury, and never more, so the next leg down still finds a bid.

• Nobody can make it sell more than s times the net buys, nor spend the treasury on anything but buybacks. Call timing does not change these bounds.
• “Sells reduce or stop when the chart drops” is automatic: no net rise, no sell.
• The computation and the trade happen in the same transaction: no slippage between reading the price and executing.
• A sandwich loses money for the attacker: selling before the call reduces the net flow and therefore the program's sell; buying before the call makes the program sell at a higher price to an attacker who then has to sell back.

Before graduation, the program trades against the pump.fun bonding curve. When the curve completes, pump.fun migrates the liquidity to PumpSwap. The program then switches to pool mode, an instruction anyone can call as soon as the migration is observable on-chain: R_ref is reset to the new pool's reserve, and subsequent trades go through PumpSwap.

At launch, the program also buys the additional liquidity (10% of the supply by default, any share up to 20% chosen at launch) and keeps it in a dedicated reserve, with the SOL paid by the creator in a dedicated vault. As soon as graduation happens, anyone can trigger the deposit of both into the token's canonical PumpSwap pool at the current ratio. If the price has risen since graduation, tokens are left over and join the inventory; if it has fallen, SOL is left over and joins the treasury. The liquidity shares are held by the program and follow the lock rule.

The program is the token's creator in pump.fun's sense, so the creator fee (0.30% of volume on the bonding curve, a market-cap schedule on PumpSwap) accrues in the creator vault attached to the program. Anyone can call the collection: it sends PUMPMAKER's share to the platform wallet (20% as a working value), buys tokens on the pool with the rest, and burns them immediately.

The token is created as a “Creator Fee” token, not “Holder Rewards”: the two are mutually exclusive on pump.fun, and the holder distribution is done by our own program instead.

The rewards vault accumulates the creator fee routed to holders (and 40% of the sell proceeds when the launch chose that split). A Solana program cannot read holders' past balances, so the distribution relies on snapshots:

1. 1
   Every 30 minutes, if the vault holds at least 0.2 SOL, the keeper takes a snapshot of the token's holders at a given slot.
2. 2
   Excluded: the program's vaults, the bonding curve, the PumpSwap pool, burn addresses, and wallets below the minimum threshold (the equivalent of 0.1 SOL in tokens by default).
3. 3
   Each eligible holder receives a share proportional to their balance. The keeper publishes the snapshot file with its hash, and records the Merkle root and the total in the program. The program refuses a total above the vault balance.
4. 4
   The keeper then pushes the payments: each claim verifies the Merkle proof and sends the SOL straight to the holder's wallet. Holders have nothing to do; the SOL just arrives. A holder can also claim from the token page.
5. 5
   An unclaimed epoch expires after 90 days; the remainder returns to the rewards vault.

What remains a matter of trust here is the accuracy of the snapshot computed by the keeper. It is public, reproducible by anyone from on-chain data, and the program only accepts a root for the amount actually present in the vault. A false root would be visible immediately.

The lock is set at launch and can never change: forever, or a date 24, 12 or 6 months out, displayed on the token page. Before that date, no instruction allows taking tokens out of the inventory, the treasury, the liquidity reserve or the liquidity shares. After that date, only the creator wallet recorded at launch can withdraw what remains. The rewards vault is never withdrawable: it belongs to the holders and is distributed before any closure.

No emergency instruction moves funds. A possible pause can only stop the rebalance, never touch the vaults.

The launch price is the cost of the tokens on the curve for the tier's share plus the additional liquidity, read live, plus pump.fun's 1.25% fee on that buy, plus the SOL side of the liquidity at the graduation price, plus the PUMPMAKER fee (1% of the subtotal), plus the rent of the created accounts. The graduation price is fixed by the curve parameters, so the SOL side is known in advance: every token graduates at about 411 SOL of market cap, after 85.0 SOL of public buys on a fresh curve.

Token cost includes pump.fun's fee. Total includes about 0.02 SOL of account rent. Computed from the curve parameters read on September 13, 2026; the real quote is computed live at launch and the transaction refuses to execute if the real cost exceeds it by more than 1%.

The plan, in order: an independent audit, then moving the authority to a multisig with a public delay before any upgrade, then renouncing it after a period of incident-free operation, which makes the rules permanently immutable. Once renounced, a bug is permanent too — which is why the audit comes first. This page will state each step when it is done, not before.