Pump.fun volume bot, with the failure rate included
A Pump.fun volume bot coordinates many wallets to trade your token on Pump.fun so the activity registers on the platform feed and on DexScreener. That much every vendor will tell you. What almost none of them mention is that bonding curve transactions fail at a rate several times the network average, that every failure is still charged, and that this single fact can double the real cost of a campaign. This page includes those measurements.
What a Pump.fun volume bot is
Mechanically there is nothing exotic here. The tool derives wallets, funds them, builds swap instructions against your token's bonding curve or pool, signs them, and submits them to the network, usually as bundles to avoid being front-run. Everything difficult about running one well is operational rather than clever: keeping the transactions landing, keeping the fee spend predictable, and keeping the pattern of trades from looking like a single script running on a timer.
The reason this page leads with failure rates instead of features is that the features are commodity. Every vendor in this market builds the same four things. What separates a campaign that spends its budget on volume from one that spends it on rejected transactions is whether anyone measured the difference.
The bonding curve and the AMM are two different problems
On the curve, every buy moves price along a fixed mathematical path. There is no slippage in the pool sense because there is no pool, but there is fierce contention: sniper bots race for early position on new launches, and they all write to the same accounts in the same slots. Contention on Solana means failed transactions, because a transaction that cannot lock the accounts it needs is dropped rather than queued.
In our most recent sample of finalized mainnet blocks, 92.4% of transactions touching the Pump.fun bonding curve program failed, against 23.3% on the Pump.fun AMM, while the network-wide failure rate was 27.9%. That gap is not noise, it is the cost of competing for the same handful of accounts. See the measurement page for the sampling method and the full per-program tables.
After migration the picture changes. The token sits in a pool, swaps route normally, contention drops toward ordinary levels, and price impact replaces curve mechanics as the thing you have to manage. A campaign configured for curve conditions and left running unchanged through graduation will typically overpay on fees and underdeliver on volume, which is why automatic handoff at graduation is a routing requirement rather than a convenience feature.
What a Pump.fun volume campaign actually costs
The arithmetic that matters is a division, not a sum. If your routing target fails a third of its transactions, then landing 3,000 swaps means attempting roughly 4,500, and your fee spend is 50% higher than a naive estimate. Vendors quoting "0.025 SOL per 100 makers" are quoting attempts, and the distinction is rarely spelled out.
| Cost component | Set by | Behaviour |
|---|---|---|
| Service fee | Your vendor | Fixed percentage. Volion charges a flat 2% of target volume. |
| Base fee | Solana protocol | 5,000 lamports per signature. Never changes. |
| Priority fee | You, by bidding | Rises with contention. Median network transaction pays little or nothing. |
| Jito tip | You, by bidding | Per bundle. A bid, so it climbs when others bid harder. |
| Account rent | Solana protocol | Charged once when a swap creates an account that did not exist. |
| Failed transactions | Nobody | Pure waste. Charged in full, produces no volume. |
Measured against the Pump.fun AMM in our most recent sample, the median transaction fee was 8,243 lamports (0.000008 SOL), and with a 23.3% failure rate the cost per landed swap works out to roughly 10,747 lamports. On the bonding curve the same calculation lands higher, around 81,487 lamports per landed swap.
These are network costs only. They exclude price impact, which on a thin curve can dwarf every fee in the table, and they exclude the service fee. The full cost breakdown walks through a complete campaign budget.
What volume does and does not do for trending
Practically, this means the shape of your activity matters more than its size. Five hundred wallets each trading once produces a very different maker count than one wallet trading five hundred times, even though the volume figure is identical. Feeds that weight unique participants separately from volume will score those two campaigns very differently, which is covered in makers versus volume.
Timing matters as much as distribution. Activity concentrated into a fifteen-minute spike ranks briefly and decays fast; the same volume spread across several hours holds a position through more of the feed's rolling window. Neither is universally right, but choosing between them deliberately beats accepting whatever a vendor's default happens to be. The trending signals reference goes through each input.
What we will not tell you is that volume gets you trending. It contributes to inputs that feed a ranking whose weights change without announcement, competing against every other token launching in the same hour. Anyone offering a guarantee is either misunderstanding the system or misrepresenting it.
Running a campaign, step by step
- Identify the token. Paste the contract address. This reads public on-chain metadata only, which is why no signing or key access is involved at this stage or any later one.
- Size the fleet. 500 to 10,000 wallets. Higher counts raise maker signals and account-creation rent together, so the useful question is which signal you are actually buying. See wallet count.
- Set the trade range. A minimum and maximum in SOL from 0.1 upward. Every swap draws a value inside it rather than repeating a fixed size.
- Choose direction and duration. Buy/sell weighting and a window from fifteen minutes to ten hours.
- Review the estimate. Target volume, service fee, and projected network cost including the failure allowance, before anything is committed.
- Fund and launch. Funding happens at launch. The console tracks landed swaps, volume routed and time remaining while the campaign runs.
If the token is still on the curve, enable the Raydium handoff before launching rather than after. Graduation is not something you want to be reacting to while a campaign is mid-flight.
The risks, stated plainly
Taking those one at a time. Detectability: funding patterns, timing regularity and wallet ages cluster in ways that anyone reading the chain properly can identify. Randomised trade sizes and spread timing raise the effort required; they do not make a fleet invisible. We treat that as a fact to design around rather than a secret to keep, and it is examined in clustering risk.
No demand creation: volume makes real activity legible. It cannot manufacture people who want to hold your token. If the underlying project is empty, visibility shortens the time until that becomes obvious to everyone.
Legal exposure: rules on promotional trading and market activity differ significantly between jurisdictions. Whether running a campaign is lawful where you are is a question for you, and we are not in a position to clear it.
Phishing: copycat domains and fake wallet-connect pages exist specifically to steal seed phrases. Volion never asks for a private key or seed phrase at any point. Any page that does is not us, regardless of how closely it resembles this one. More on custody in safety.
Once a token graduates, the routing target and the arithmetic both change. That half is covered on PumpSwap routing, and the venue-by-venue picture for a general Solana volume bot campaign is on the overview. Not every token stays inside the Pump.fun ecosystem either: liquidity often ends up in a Raydium pool, a Meteora DLMM bin set or an Orca Whirlpool, each of which we measure separately, and routing through Jupiter instead of directly is the single most expensive default in this category.