PumpFun Bonding Curve Error 6024 (Overflow) - Occurs when min_sol_output exceeds realSolReserves?
PumpFun Bonding Curve Error 6024 (Overflow) - Occurs when min_sol_output exceeds realSolReserves?
Loading saved threads...
Misterknow · External communityPost link
External question — Solana Stack Exchange
Author: Misterknow
Original post: https://solana.stackexchange.com/questions/23834
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
I'm building a Solana trading bot that interacts with PumpFun's bonding curve program (
6EF8rrecthR5Dkzon8Nwu78hRvfCKubJ14M5uBEwF6P
) and encountering
InstructionError: [2, {"Custom": 6024}]
when selling 100% of my token holdings.
The Problem
Selling 25%, 50%, 75% → ✅ Works
Selling 100% → ❌ Fails with error 6024
Curve State at Time of Failure
virtualTokenReserves: 1,072,974,833,270,144
virtualSolReserves: 30,000,703,670
realTokenReserves: 793,074,833,270,144
realSolReserves: 703,670 (0.0007 SOL)
My Sell Parameters
amountInTokens: 41,016,010,856 (exact raw balance from ATA)
min_sol_output: 1,112,372 lamports (0.00111 SOL after 3% slippage)
The Pattern I Noticed
My
min_sol_output
(0.00111 SOL) is
greater than
realSolReserves
(0.0007 SOL).
When I compared against a successful 100% sell from another bot (Trojan) on the same token at a different time:
Their realSolReserves: 2,703,671 (0.0027 SOL)
Their min_sol_output: 1,920,725 (0.00192 SOL)
Result: ✅ Success (min_sol_output < realSolReserves)
My Sell Instruction Encoding
function encodeSellData(tokenAmount: BN, minSolOutput: BN): Buffer {
const buffer = Buffer.alloc(24); // 8 + 8 + 8
SELL_DISCRIMINATOR.copy(buffer, 0);
buffer.writeBigUInt64LE(BigInt(tokenAmount.toString()), 8);
buffer.writeBigUInt64LE(BigInt(minSolOutput.toString()), 16);
return buffer;
}
Account Order (14 accounts)
0. global (readonly)
1. fee_recipient (writable)
2. mint (readonly)
3. bonding_curve (writable)
4. associated_bonding_curve (writable)
5. user_token_account (writable)
6. user (signer, writable)
7. system_program (readonly)
8. creator_vault (writable)
9. token_program (readonly)
10. event_authority (readonly)
11. program (readonly)
12. fee_config (readonly)
13. fee_program (readonly)
Failed Transaction
Solscan Link
Solscan shows:
Program Error: "Instruction #3 Failed"
(the sell instruction)
My Questions
Is error 6024 triggered when min_sol_output > realSolReserves?
The error is named "Overflow" but the actual cause seems to be the curve lacking sufficient real SOL liquidity to fulfill the minimum output requirement.
What is the correct way to handle this?
Set
min_sol_output = 0
to accept any amount?
Pre-check
realSolReserves >= expectedSolOut
before submitting?
Calculate maximum sellable tokens based on available
realSolReserves
?
Is there official documentation mapping PumpFun's custom error codes to their causes?
What I've Already Verified
✅ Using exact raw balance from ATA (no floating point issues)
✅ Instruction data is 24 bytes (matches successful transactions)
✅ Account order matches the IDL
✅ Same token, same wallet - only difference is sell percentage
✅ Partial sells (25-75%) work on the same token
Any clarification on error 6024's actual trigger condition would be greatly appreciated.
Quote
Report
Eric · External communityPost link
External answer — Solana Stack Exchange
Author: Eric
Original post: https://solana.stackexchange.com/a/24290
License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/
Adaptation: HTML converted to plain text; contact email addresses removed.
Pump Fun is a closed-source project, so nobody can point you to the exact cause in their source code for which conditions cause this exact error.
However, for any CPAMM, you, by definition, cannot demand to receive more SOL than the program has, which is what the condition
min_sol_output > realSolReserves
would mean. This must result in an error.
The most likely cause for why Pump Fun returns an "Overflow" error instead of something more informative, is that they simply haven't handled this exact error case. In Rust, if you subtract a larger uint from a smaller uint, that is still called an "Overflow", and that's what would happen in a CPAMM when you try to take out more funds than there are present.
It is a bad practice to set
min_sol_output = 0
. How you handle these cases is part of your bot logic, which should reflect your intent with what you are doing with it. The reality is that you are selling your token through a bonding curve with very low reserves, for a price which is higher than it is willing to give you.
This is not a very pleasant case, but one which a bot should know how to handle.
Practical suggestions:
If you think that reserves will grow, and you are willing to wait: Check whether
min_sol_output
is greater than actual reserves and don't sell if it is.
If you think that reserves won't grow, or you are unwilling to wait and are willing to take a loss:
min_sol_output=min(min_sol_output, realSolReserves)
.
Quote
Report
Post Reply
Quoted from Forex.com.bd-Editorial External answer — Solana Stack Exchange Author: Eric Source score (net votes, not local likes): 0 Original post: https://solana.stackexchange.com/a/24290 License: CC BY-SA 4.0 — https://creativecommons.org/licenses/by-sa/4.0/ Adaptation: HTML converted to plain text; contact email addresses removed. Pump Fun is a closed-source project, so nobody can point you to the exact cause in their source code for which conditions cause this exact error. However, for any CPAMM, you, by definition, cannot demand to receive more SOL than the program has, which is what the condition min_sol_output > realSolReserves would mean. This must result in an error. The most likely cause for why Pump Fun returns an "Overflow" error instead of something more informative, is that they simply haven't handled this exact error case. In Rust, if you subtract a larger uint from a smaller uint, that is still called an "Overflow", and that's what would happen in a CPAMM when you try to take out more funds than there are present. It is a bad practice to set min_sol_output = 0 . How you handle these cases is part of your bot logic, which should reflect your intent with what you are doing with it. The reality is that you are selling your token through a bonding curve with very low reserves, for a price which is higher than it is willing to give you. This is not a very pleasant case, but one which a bot should know how to handle. Practical suggestions: If you think that reserves will grow, and you are willing to wait: Check whether min_sol_output is greater than actual reserves and don't sell if it is. If you think that reserves won't grow, or you are unwilling to wait and are willing to take a loss: min_sol_output=min(min_sol_output, realSolReserves) .
Checking account access…