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?

Manage alerts

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) .

Cancel quote

Checking account access…