rckprtr
bondingcurve complete so soon
hi how come
realTokenReserves: 41232231404959n
depletes so fast? i have the createAndBuy buying 0.1 SOL and 10-12 wallets buying 0.15 SOL and it completes bonding curve by the 6th wallet is done buying.
Selling too early, you mean?
no actually what i meant was the token reserves was all bought out with like around 2 SOL. This was on devnet. I then did a test to fetch bondingcurveaccount on mainnet. This was the result:
Devnet beginning boundingcurveaccount with 0.1 devbuy
{ "discriminator": "6966180631402821399", "virtualTokenReserves": "1069435215946844", "virtualSolReserves": "30100000000", "realTokenReserves": "46535215946844", "realSolReserves": "100000000", "tokenTotalSupply": "1000000000000000", "complete": false }
Mainnet
{ "discriminator": "6966180631402821399", "virtualTokenReserves": "988522282720529", "virtualSolReserves": "32563757607", "realTokenReserves": "708622282720529", "realSolReserves": "2563757607", "tokenTotalSupply": "1000000000000000", "complete": false }
Turns out that devnet and mainnet pumpfun has two different bondingcurveaccount math? For a whole day I thought it was a slippage issue, because I am batching the transactions. I thought that it was sending the wrong price/token instruction because the later buy instruction batches would fail even after I set slippage to 100%. I even set up a local AMM bonding curve simulator with amm.ts to sequentially calculate the price/token after taking into account the previous buys.
But turns out its just because on pumpfun devnet, the realTokenReserves was just all bought out. The program failing error was due to the batched transactions, I know this for sure because I did a test with just single buy transactions, and it would fail with "curve complete"--- because I already bought out the whole supply.
Conclusion: devnet and mainnet pumpfun has different bonding curve tokenomics.
No, the calculation here is wrong, but this problem has not been fixed yet.
@rckprtr From the result point of view, the number of tokens obtained is indeed wrong. This problem should be encountered by everyone. For example, 1SOL may be exchanged in Jupiter for 1M, but the number obtained by using getBuyPrice is wrong and cannot be completed. It will prompt that the current SOL is too much.
@rckprtr From the result point of view, the number of tokens obtained is indeed wrong. This problem should be encountered by everyone. For example, 1SOL may be exchanged in Jupiter for 1M, but the number obtained by using getBuyPrice is wrong and cannot be completed. It will prompt that the current SOL is too much.
Can you confirm you are using mainnet vs devnet?