Price monitor and log for backtest - Failed to get curve state: is it because of slow RPC or just a technical delay?

[VeryBoredPanda]

Hi,
Thank you for keeping this project updated.
I'm creating a script to monitor and log prices of tokens found with logsubscribe so I can do some backtest with entry and exit strategies.
At the moment i'm using RPC call to buy but PumpPortal Lightning Transaction API to sell because it allows me to sell the second after I buy when with RPC call I need to wait at least 13 seconds (could be the free plan rpc problem but with old version of the bot even with Chainstack Growth plan + Trader node there was 10-15 sec delay before RPC could see tokens in the ATA).
Anyway when I try to monitor the prices, for the first ~13secs I get error:

"Failed to get curve state: Account Bonding curve adress here not found"

and then after that time I finally see the prices.
Is it because I use a free rpc at the moment or is it a technical delay from pump.fun?
With old version using blocksubscribe I could monitor prices from the moment token was found, but I was using paid Chainstack plans at that time.
I'm almost sure it's RPC related but wanted to double check with you and be 100% sure before buying a paid plan.

Thank you

[AidHamza]

For new tokens, usually create or even migrate instructions alters and creates multiple accounts, it takes time for propagation across the network, are you using the same RPC for discovery ? also try to set commitment to proceed. If none is working, then implement a manual retry mechanism with timeout, and try to test multiple RPCs at the same time.

For my case, I built my bot and currently final tests, I have my own RPC with Geyser, once I get new token on the stream, I keep trying to fetch the bonding curve, usually It succeed within 150-350ms, the connection to the RPC is private network

With this currently, hundreds of buy transactions landed 400-2000 ms after the detection, depends on the network fees and if its busy

[smypmsa]

@VeryBoredPanda please try EXTREME_MODE. When it's turned on, you don't need to wait at all, just send a buy transaction right after a new token is detected.

As @AidHamza mentioned, there are Solana network propagation issues with that. RPC node may not know about a bonding curve account.

A bit more about EXTREME_MODE and why we added it. You need bonding curve data just to calculate the price of a token. But if it's a new token and your main goal is to snipe - it doesn't make sense to waste time on that step. You can simply put desired amount of tokens you wish to buy and there will be no extra steps or RPC calls between token detection and buy transaction, just a few ms.

[smypmsa]

Sorry for the confusion 😄 I see that you need to monitor prices.

Then I'd try to check the first transaction within which a token is detected and if there are any buy instructions ... Then, knowing default values for reserves, we could calculate some price ... What do you think?

[VeryBoredPanda]

Thanks for reply.
Yeah I have no problem in buy and sell transactions.

Do you mean check the mint adress for any buy transaction? Wouldn't this be affected by RPC propagation delay too?

[AidHamza]

@VeryBoredPanda please try EXTREME_MODE. When it's turned on, you don't need to wait at all, just send a buy transaction right after a new token is detected.

As @AidHamza mentioned, there are Solana network propagation issues with that. RPC node may not know about a bonding curve account.

A bit more about EXTREME_MODE and why we added it. You need bonding curve data just to calculate the price of a token. But if it's a new token and your main goal is to snipe - it doesn't make sense to waste time on that step. You can simply put desired amount of tokens you wish to buy and there will be no extra steps or RPC calls between token detection and buy transaction, just a few ms.

@smypmsa For the token snipping buy, currently in my bot, I do the same, I'm listening to pumpswap migrations, and also fresh deployed pumpfun ones, I do fetch the bonding curve in order to calculate the initial quote price. How can you do so without fetching it ? using the event bonding curve initial data serves in that case ?

[smypmsa]

Thanks for reply. Yeah I have no problem in buy and sell transactions.

Do you mean check the mint adress for any buy transaction? Wouldn't this be affected by RPC propagation delay too?

Maybe I misunderstood your case, but if you detect new tokens using a subscription to transactions - you can parse other instruction in it and check if it's bundled with buy/sell instructions. If there are no any of them, then the price is default for a new pump fun token. Else, you can check how many tokens were bought just right after the mint ... I mean within the very same transaction.

@smypmsa For the token snipping buy, currently in my bot, I do the same, I'm listening to pumpswap migrations, and also fresh deployed pumpfun ones, I do fetch the bonding curve in order to calculate the initial quote price. How can you do so without fetching it ? using the event bonding curve initial data serves in that case ?

For new tokens, you can roughly estimate how much SOL you need to buy N tokens. In our implementation, you can specify how many tokens you wish to buy and max amount of SOL to spend.

I guess a similar approach could be applied to just migrated tokens (all tokens from bonding curves have the same amount of reserves).

[VeryBoredPanda]

Maybe I misunderstood your case, but if you detect new tokens using a subscription to transactions - you can parse other instruction in it and check if it's bundled with buy/sell instructions. If there are no any of them, then the price is default for a new pump fun token. Else, you can check how many tokens were bought just right after the mint ... I mean within the very same transaction.

I feel logsubscribe on my RPC is pretty inconsistent even with 49$ paid plan, I guess I need much more expensive nodes.
So for now I'm using Pumpportal subscribeNewToken to detect tokens and subscribeTokenTrade to detect trades on that token.
For each buy/sell I calculate the price per token of the transaction. by dividing amount of sol and tokens
I monitor each token for 30sec and log for each second the price, number of buy tx and sell tx.
Do you think it makes sense?