Pump.fun October 2026 update: v3 trades, fee sweeps, negative virtual reserves and synthetic migration

On October 8, 2026 Pump published docs and IDLs for six changes to the Pump and PumpSwap programs. Trades got smaller (17 accounts), protocol and creator fees now wait on the curve or in the pool until someone sweeps them, and that waiting money is the reason virtual_quote_reserves goes negative. The last buy on a bonding curve no longer has a max size, one instruction can trade through several coins, and a new coin can be paired with another pump coin.

Everything below comes from Pump's public docs repository and its IDLs, so you can check each line. Start with the change that breaks the most quotes.

Quote vault balance: 110.00 SOL
virtual_quote_reserves · signed: -0.03 SOL
Effective quote reserves · the price uses this: 109.97 SOL

Try it · PumpSwap quote reserves

0.03 SOL waiting

The vault holds 110.00 SOL, but 0.03 of it is fees waiting for a sweep. The price uses 109.97. A decoder that reads the field as unsigned gets 340,282,366,920,938,463,463,374,607,431,738,211,456 lamports.

Effective reserves are the vault plus virtual_quote_reserves, added as a signed number. A v2 trade puts its fee in the vault and takes the same amount off the virtual reserve. A sweep does the reverse. The sum, and the price, never see the fee. Numbers follow the example in Pump's docs.

What changed in Pump and PumpSwap in October 2026?

Change	In one line	Act?
v3 and v2 trades	Same trades, 17 accounts	Optional
Fees kept, then swept	Protocol and creator fees wait on the curve or pool	If you claim creator fees
Negative virtual reserves	Waiting fees are taken off the virtual reserve	If you read the vault as liquidity
Synthetic migration	The completing v3 buy has no max size	If you index trades
Multi-hop swap	SOL to coin A to coin B in one instruction	To trade coin-paired coins
Pump coins as quote	A new coin can be paired with a pump coin	To launch one

Why is virtual_quote_reserves negative on PumpSwap?

Because the new trades keep their protocol and creator fees inside the pool's quote vault. That money is not liquidity, so the program subtracts it from virtual_quote_reserves when the fee is kept and adds it back when a sweep pays it out. The vault and the virtual reserve move in opposite directions by the same amount.

effective_quote_reserves = pool_quote_token_account.amount + Pool::virtual_quote_reserves

Both buys and sells are priced on the effective reserves. The base side is still the raw base vault. Pump's example is the one in the playground above: a 100 SOL pool, a 10 SOL buy that keeps 0.03 SOL of fees, a vault of 110.00 and effective reserves of 109.97.

Three rules follow. The field is an i128, so decode it signed and store it in a signed column. Do not read the raw vault balance as liquidity. And a pool is boosted when the virtual reserve plus the waiting fees is not zero, not when the stored field is not zero. Pump says the field can be negative from September 30, 2026, and that the sum never overflows and never goes below zero.

What are buy_v3 and sell_v3?

They are the same trades as the v2 instructions with fewer accounts, so more fits in one transaction. Prices, slippage checks and fee amounts are identical. The account counts below are from the published IDLs.

Bonding curve buy

buy_v2

27 accounts

buy_v3

17 accounts

Bonding curve sell

sell_v2

26 accounts

sell_v3

17 accounts

PumpSwap buy

buy

23 accounts

buy_v2

17 accounts

PumpSwap sell

sell

21 accounts

sell_v2

17 accounts

Accounts in the instruction Accounts no longer passed

Explainer · Accounts per trade instruction

Case 01Bonding curve buy
buy_v2 takes 27 accounts. buy_v3 and buy_exact_quote_in_v3 take 17. The fee recipient, creator vault, sharing config and volume accumulator accounts are gone.
Case 02Bonding curve sell
sell_v2 takes 26 accounts, sell_v3 takes 17.
Case 03PumpSwap buy
buy takes 23 accounts. buy_v2 and buy_exact_quote_in_v2 take 17 and no remaining accounts. The protocol fee recipient and creator vault accounts are gone.
Case 04PumpSwap sell
sell takes 21 accounts, sell_v2 takes 17.

The accounts could go because the fee no longer has to be delivered during the trade. One exception: cashback coins. A v3 trade on a cashback coin fails with CashbackCoinNotSupported (6094 on Pump, 6079 on PumpSwap), so keep the older instruction for those. Old and new trades can be mixed on the same coin.

Where do the fees go now, and who sweeps them?

A new-style trade charges the same fee and writes down how much is waiting: BondingCurve.protocol_fees and BondingCurve.creator_fee on the curve, Pool.protocol_fees and Pool.creator_fees on the pool. The buyback part of the protocol fee is still paid in the trade, and the LP fee still goes into the pool reserves.

Four permissionless instructions pay the waiting fees out: sweep_protocol_fee and sweep_creator_fee on each program. The destination is fixed, so a sweep can only send money where an older trade would have sent it. Pump runs the protocol sweep itself.

The creator sweep is yours to run. A creator's fee is in the creator vault only after sweep_creator_fee, so call it right before the claim, in the same transaction, on the curve and on the pool if the coin has migrated. Several instructions refuse to run while a creator fee is waiting, such as distributing shared fees or changing who the creator is. They fail with CreatorFeesNotSwept (6095 on Pump, 6081 on PumpSwap).

What is synthetic migration on a bonding curve?

Before, a buy could not take more than the curve had left. With buy_v3, buy_exact_quote_in_v3 and a curve hop of multi_hop_swap, the buy that empties the curve has no max size. It takes what is left at the curve's price, completes the curve, then buys the rest from the tokens that would have gone into the PumpSwap pool, at the price that pool would charge.

Left on the curveTokens kept for the pool

20M206.9M

Curve part: 7.67 SOL for 20M
Pool part · before the pool exists: 14.42 SOL for 30M
Total: 22.09 SOL for 50M

Try it · The last buy on a curve50M

Crosses into the pool

buy_v3 takes the last 20M from the curve for 7.67 SOL, then 30M more at the future pool's price for 14.42 SOL. It emits TradeEvent, CompleteEvent and PostCompleteBuyEvent. The older buy and buy_v2 fail here with NotEnoughTokensToBuy, or stop at 20M with partial_fill.

The price is continuous: the first token of the pool part costs what the last token of the curve cost. Example for a SOL-paired coin with 20M tokens left, using the starting reserves in Pump's docs. Fees and the migration fee are left out.

Then migrate_v2 creates the pool with the reserves that buy left behind, so the pool opens where the buy stopped. Only the buy that crosses the limit gets this. After it, every trade on the curve fails with BondingCurveComplete until the migration runs. Mayhem coins keep the old behaviour.

A completing v3 buy emits three events in order: TradeEvent for the curve part, CompleteEvent, then PostCompleteBuyEvent for the pool part. The buyer's total is the first plus the third.

What are multi_hop_swap and pump coins as quote mints?

create_v2 can now pair a new coin with an existing pump coin instead of SOL or USDC. The quote coin must itself be paired with SOL or USDC. One level deeper fails with CurveDepthExceeded (6105).

Buying such a coin with SOL used to take two trades and a token account for the coin in the middle. multi_hop_swap does it in one PumpSwap instruction: 16 fixed accounts plus 5 per hop, each hop a pool or a bonding curve. The middle coin never touches your wallet. There is one slippage check on the final amount, which is the same idea as amountOutMin on an EVM swap. Fees are charged once per route, not once per hop. Every hop must go the same way, all buys or all sells.

What does a bot or an indexer have to change?

Quotes. Price pools on vault plus virtual_quote_reserves, signed. If you already did, nothing changes.
Event layouts. TradeEvent, BuyEvent and SellEvent have one more field, creator_fee_unclaimed. Pool and BondingCurve have appended fields too. Read a missing appended field as 0 on accounts written before the upgrade.
New events. PostCompleteBuyEvent, SweepBondingCurveFeeEvent and SweepPoolFeeEvent. If you saw an unknown event with discriminator 742b4dbd117a482b this month, it is the first 8 bytes of sha256 of event:SweepBondingCurveFeeEvent.
Creator fee totals. Fees earned and fees paid are now different moments. Count the trade's fee fields as earned and the sweep events as paid.
Completing buys. Add the PostCompleteBuyEvent amounts to the trade, or the last buyer of every v3 curve looks smaller than they were.
Sending trades. Moving to v3 is optional. Fewer accounts leaves more room in a transaction, which matters for how a transaction lands.
SDKs. @pump-fun/pump-sdk 4.0.0, @pump-fun/pump-swap-sdk 2.1.0 and pump-rust-client 0.4.0 have builders and quote functions for all of it.

What do the terms mean?

Bonding curve: the Pump account a new coin trades against until its tokens for sale run out.
Migration: moving a completed curve's liquidity into a PumpSwap pool with migrate_v2.
Quote vault: the pool's token account for the quote side, usually wrapped SOL.
virtual_quote_reserves: a signed number added to the quote vault to get the reserves the price uses.
Sweep: a permissionless instruction that pays waiting fees out to their fixed destination.
Hop: one pool or curve in a multi_hop_swap route.

FAQ

Why is virtual_quote_reserves negative on a PumpSwap pool?

The newer trades keep protocol and creator fees in the pool's quote vault and subtract the same amount from virtual_quote_reserves, so the waiting fees do not count as liquidity. On a pool that is not boosted, the field is minus the fees waiting to be swept.

How do I calculate the price of a PumpSwap pool?

Add the quote vault balance and virtual_quote_reserves as a signed i128 to get the effective quote reserves, then use the raw base vault as the base reserves. Buys and sells are both priced on those two numbers.

Do I have to switch to buy_v3 and sell_v3?

No. The older instructions keep working with the same accounts and arguments, and old and new trades can be mixed on one coin. The new ones use 17 accounts. Cashback coins are not supported by them.

Why did my Pump creator fee claim pay nothing or fail?

Fees from the newer trades wait on the curve or in the pool. Call sweep_creator_fee before the claim in the same transaction. Some instructions fail with CreatorFeesNotSwept until you do.

What happens if I buy more tokens than a Pump bonding curve has left?

With buy_v3 the buy takes what is left, completes the curve, and buys the rest at the price the future PumpSwap pool would charge. With the older buy and buy_v2 it fails with NotEnoughTokensToBuy, or stops at what is left when partial fill is on.