Why Batch Sells Fail on pump.fun (and How to Fix Them)

You tick eight wallets, press "sell 50%", and watch the results come in. Wallet one: sold. Wallet two: sold, barely. Wallets three to eight: failed, every one of them with the same message, custom program error 6003.

Your slippage was not unusually tight. The network was fine. The wallets had SOL for fees. So what happened?

The short version: every wallet was priced as if it were the only seller. It was not.

#The cause: quotes against an unmoved price

A pump.fun sell does not just say "sell these tokens". It says "sell these tokens, and I want at least X SOL back". X comes from a quote: the tool asks the bonding curve what those tokens are worth right now, then takes off your slippage allowance. That minimum is written into the transaction, and the program enforces it.

Now run that for a batch. If the tool asks for all eight quotes at once, all eight are priced against the same curve state, the one before any of your sells.

1. Eight quotes

   all priced against the same starting curve

2. Sell 1 lands

   the price drops, as every sell makes it do

3. Sell 2 lands

   the price drops again, now near its limit

4. Sells 3 to 8

   their minimum SOL is above what the curve now pays: error 6003

Each sell on a bonding curve lowers the price for the next one. That is how the curve works. Wallet four's quote assumed wallets one to three had not sold yet. By the time it executes, they have. The curve can no longer pay what wallet four asked for, so the program rejects it with 6003 TooLittleSolReceived.

The bigger each sell and the more wallets in the batch, the worse it gets. Two small sells may squeeze inside your slippage allowance. Eight large ones will not.

#Why raising slippage is the wrong fix

The obvious reaction is to widen slippage until the errors stop. For a small batch, that can appear to work. But think about what you have done: you have told every wallet it is fine to sell for much less than its quote, to make room for a price drop you caused yourself.

Slippage is there to protect you from other people's trades landing before yours. It should not have to absorb the effect of your own.

#The fix: quote each wallet in send order

The correct approach is simple to describe. Quote wallet one against the current curve. Then work out what the curve looks like after wallet one's sell, and quote wallet two against that. Then wallet three against the curve after one and two. And so on down the list, in exactly the order the transactions will be sent.

Now every wallet's minimum SOL out matches the price it will actually meet, give or take whatever outside trades land in between, which is what your slippage setting is for.

This is a failure mode we fixed in DevBundler: every wallet in a batch is now quoted in the order it will be sent, for sells and for buys. It is the same approach the launch form uses, which is why later buyer wallets in a bundled launch show a higher SOL cost for the same percentage of supply.

#Fast mode vs Bundle mode: what a failure costs

How a bad quote hurts you depends on how the batch is sent. In DevBundler on mainnet there are two modes.

In Fast mode, a bad quote costs you that one wallet's sale and its fee. In Bundle mode, one bad quote sinks everything, because a Jito bundle is all or nothing. That makes in-order quoting more important, not less, when you bundle sells. Jito bundle vs parallel trades compares the two approaches in more depth.

#Other reasons a batch can fail

Not every failure is 6003. Read the error before you change anything.

1. 1

   Error 6003 or 6002 on later wallets only

   Classic stale quotes. Use a tool that quotes in order, or sell in smaller steps.

2. 2

   Error 6003 on every wallet, including the first

   The price moved before any of your sells landed. Retry, or widen slippage slightly if the coin is very active.

3. 3

   Error 6005 BondingCurveComplete

   The curve finished and the coin migrated to PumpSwap. Trades must go to the pool now; DevBundler switches automatically.

4. 4

   Insufficient SOL

   A wallet cannot pay its own transaction fee. Keep a little SOL in every trading wallet.

5. 5

   Not confirmed in time

   The transaction never landed. A higher speed preset raises the priority fee when the network is busy.

#What to do next

If your batch sells fail from the second or third wallet onwards, the culprit is almost always quotes taken against an unmoved price. Do not paper over it with huge slippage. Quote in order, keep your slippage for the job it was meant to do, and if you want tighter timing, bundle the sells. For the basics of the setting itself, see slippage on pump.fun explained.