Why Later Bundle Wallets Get Fewer Tokens on pump.fun

Here is a real quote from DevBundler for a small mainnet launch, buying by percentage of supply:

Three wallets, the same 2% target, three different prices. Buyer 3 pays about 8% more SOL than buyer 1 for exactly the same share. Nothing is wrong with the quote. That is the bonding curve doing what it is built to do.

#The one-line reason

Every buy on a pump.fun bonding curve raises the price for the next buy, and a bundle runs its buys in a fixed order. So the wallets later in the bundle buy at a price the earlier wallets have already pushed up.

The curve keeps SOL reserve times token reserve constant. Each buy puts SOL in and takes tokens out, which leaves less token reserve against more SOL. The next buyer's SOL is measured against that new ratio, and gets fewer tokens per SOL.

1. Dev buy

   buys at the starting price, about 28 SOL market cap

2. Buyer 1

   buys at the price the dev left

3. Buyer 2

   buys at the price buyer 1 left

4. Buyer 10

   buys at the highest price in the bundle

#How big does the gap get?

With a few wallets it is small. With a full bundle it adds up. Here is what happens with DevBundler's suggested defaults, a 1 SOL dev buy and 0.5 SOL for each of 10 buyers, on a fresh mainnet curve. These per-wallet figures are our estimates from the curve formula, so treat them as approximate; the exact numbers vary slightly with fees.

The first three buyers match a real DevBundler quote: a 1 SOL dev buy plus three 0.5 SOL buyers hold 8.18% of supply together, with the curve about 10% sold. The rest continues the same math.

#Equal SOL or equal share: pick one

You cannot give every wallet the same SOL and the same share at once. The curve makes you choose.

Neither is wrong. If you have a fixed budget and you mostly want the total share to land somewhere sensible, SOL is simpler. If you want each wallet to hold a specific, even share (for example, so no single wallet stands out as a top holder), percentage is cleaner. DevBundler offers both modes on the launch page, the same for every wallet or custom per wallet. How to split supply across bundle wallets goes through the planning.

#Why the quote order matters

A quote is only as good as the price it is based on. If a tool priced every wallet against the fresh curve, wallet 10 would be told it gets about 1.7% for 0.5 SOL, when in reality it lands about 1.25%. In percent mode it would be worse: wallet 10 would be funded for a price that no longer exists when its turn comes, and the buy would fail pump.fun's slippage check (error 6002 TooMuchSolRequired). In a bundle, one failed buy means the whole launch is dropped.

DevBundler avoids this by quoting each wallet after the ones before it, in the exact order the bundle will send them. The live table on the launch page shows each wallet's buy, its estimated share and the SOL it needs on that basis, so the numbers you approve match what lands.

#Does wallet order affect anything else?

Only the price each wallet pays, and therefore its share and its entry market cap. On the project dashboard, DevBundler shows entry market cap per wallet, so you will see the later wallets with slightly higher entries. When you sell, the same logic runs in reverse: each sell lowers the price for the next one, which is why batch sells are also quoted in order.

What order does not change is the total. A bundle that ends up holding a large share holds it whichever wallet is first.

#Putting it to use

When you set up your next launch, decide first whether you want equal spend or equal share, then look at the last wallet's numbers before you approve. If the gap between your first and last buyer is bigger than you like, use fewer wallets or smaller buys. For the curve math behind all of this, see the pump.fun bonding curve explained.