Pump.fun volume bot mistakes that quietly waste your SOL
Most wasted campaign budget does not go to anything dramatic. It goes to failed transactions that paid their fee and produced nothing, to activity spent in the phase where it buys the least, and to patterns that made the whole thing legible to exactly the people it was meant to impress. None of these announce themselves. They show up as a campaign that cost what it was supposed to and achieved less than expected, and every one of them is avoidable in advance.
Spending the budget in the phase where it buys least
For scale: in the current measurement window a landed swap on the bonding curve cost roughly 45,000 lamports against about 7,296 lamports in the post-graduation pool, almost entirely because of the difference in failure rates.
This is not an argument against curve campaigns. If a token is close to graduating and completing the curve is the goal, that spend buys something nothing else can. The mistake is spending there because that is where the token happens to be today, while wanting an outcome that pool trading delivers far more cheaply.
The two objectives are set out side by side in Pump.fun vs PumpSwap campaigns.
Letting your own wallets race each other
This is the most common source of avoidable failures at scale, and it is entirely self-inflicted. The balance was sufficient when each transaction was built and consumed by a sibling before the others landed. Nothing about the market caused it.
Two related errors travel with it. Sizing trades from total balance rather than spendable balance guarantees the last trade of every wallet fails, because fees and rent exemption have to remain. And sweeping a wallet to zero before a swap leaves nothing to pay the fee with, which fails for the same underlying reason.
Retrying a failed swap without re-quoting
Aggressive retry logic amplifies this into real money. A campaign that retries five times against a price that has genuinely moved has paid five fees to learn what the first failure already told it.
The correct behaviour is to back off, re-quote, and only then resend. On concentrated liquidity venues this matters even more, because a failure caused by price leaving the active range will persist until the range is rebalanced, which is not a condition retrying can resolve.
Carrying settings across tokens and venues
Slippage in particular deserves deriving rather than defaulting. Set too tight, ordinary movement rejects a large share of transactions and each rejection pays. Set too wide, the tolerance becomes a window for someone else to profit inside, as covered in sandwich MEV protection. The right value comes from how much the pair actually moves between blocks.
Trade size has the same problem in a different form. On a Meteora bin there is a threshold below which impact is zero; on a Raydium pool there is no such line. Applying one venue's rule to the other means managing the wrong risk, as set out in Meteora vs Raydium.
Leaving curve settings running after graduation
The specific overpayments are priority fees bid up for a race that no longer exists, retry aggression against failures that are no longer routine, and slippage left wide to survive unpredictable curve fill positions when pool pricing is now calculable in advance.
The full list of what should change is in what changes the day your token migrates.
Producing a pattern anyone can read
The three signatures are independent, so fixing one while leaving the others does little. Varied timing with identical amounts is still legible. Varied amounts on a fixed clock is still legible. Both, from a fleet funded identically at the same moment, is legible from the funding pattern alone regardless of how the trading looks.
Funding practice is the part that cannot be corrected later, since it is already on chain by the time trading starts. The detail is in wallet clustering risk.
Stopping dead instead of tapering
Tapering over hours produces a decline that resembles fading interest, which is what ordinary activity actually looks like when it ends. It costs very little to do, because the tail is by definition the low-intensity part of the campaign.
The related mistake is having no stop condition at all, which means the campaign ends when the budget does. That is a decision made by default rather than on purpose, and it is usually made in the phase where the money was buying least.
Continuing after the answer is already clear
The signal is easy to read and easy to ignore: count transactions from wallets outside your fleet. If organic activity is appearing, the campaign is working and the question is duration. If it is not, the token is telling you something a larger budget cannot argue with.
This is uncomfortable advice from anyone who sells campaigns, which is why it is worth saying plainly. The realistic limits are covered in is a volume bot safe, and the ways this gap gets exploited by other operators are in how volume bot scams work.
Measuring transactions sent instead of transactions landed
This is worth checking on any campaign, including one you run yourself. Divide the total SOL spent by the number of successful swaps, not by the number attempted. That is cost per landed swap, and it is the figure that connects a budget to an outcome.
It is also the figure an operator has the least incentive to publish, which is why we measure and publish per-venue failure rates rather than quoting a single cost per swap. The method is on the measured transaction costs page, and the reasoning behind that choice is on the page for our Pump.fun volume bot service.
To model what a plan should cost before running it, the calculator uses those measured rates, and campaigns are configured in the dashboard.