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 buys back with the treasury until it is empty.

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.

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% treasury and 40% to the holders' rewards vault.
2. The token goes down. Sells exceed buys, the reserve shrinks. The program stops selling. It buys back a fixed fraction of the net drop with the treasury, until the treasury is empty.
3. Empty treasury. Buybacks stop. Sells resume on the next net rise, which refills the treasury.
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.

Notation: R is the SOL reserve of the trading venue (the bonding curve's real reserves before graduation, the PumpSwap pool's SOL vault after). R_ref is the reference reserve recorded by the program after its last operation. s is the tier's sell rate (5% for Titan), b the buyback rate (3% for Titan), T the treasury balance.

On every rebalance call:

1. The program reads R from the pool accounts, within the same transaction. It computes Δ = R − R_ref.
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.
3. If Δ < 0: net drop. It buys tokens for min(b·|Δ|, T) in SOL. The tokens go into the inventory.
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. 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, 0.24 SOL to the treasury and 0.16 SOL for holders. On the next call, sells of 10 SOL and buys of 3 SOL: R dropped by 7 SOL, so the program buys back 0.21 SOL worth of tokens. If the treasury only held 0.10 SOL, it buys back 0.10 SOL worth and stops.

• 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. 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. 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. 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. 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. 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%.

At launch the program's upgrade authority is a Squads 2-of-3 multisig with a publicly displayed 72-hour delay, so that a bug found after the audit can be fixed. The announced goal is to renounce the upgrade authority after three months of incident-free operation, which makes the rules permanently immutable. Once renounced, a bug is permanent too: hence the audit, the internal mainnet tests and the three-month multisig period.