initialize2 log is received too late from actual trades on token

[Semrubo]

Hello,

No matter what Websocket I use (mainnet, free or paid) the transaction with initialize2 instruction is received in 14-15 seconds after trades started on Raydium. When I see the initialize2 instruction output and compare with trading websites, the trades are already started for 14-15 seconds. My network should not be an issue, because if I then buy token programmatically it takes 1-2 seconds, but I am being late for 17-18 seconds from trades on Raydium.
When I print all incoming messages for blockSubscribe I can see that before receiving the log with "initialize2" string there are other messages received with that same token address. Those early logs contain same Token Address (which is then acquired from account_keys[18] key of initialize2 transaction), but do not contain the Liquidity Address (account_keys[2]). So even if we catch those prior to initialize2 instruction logs it's not clear how we can buy token.

Is there another way to get the Raydium migration event right when that happens and trades are started, so that we can be one of the first traders?
If we catch logs prior to initialize2 instruction, can we find the Liquidity Address to use that for trades?

Thanks.

[akegaviar]

@Semrubo so to drill into this a little bit:

• You are using Raydium migration script as outlined here Solana: Listening to pump.fun migrations to Raydium that's using the blockSubcribe method.
• Using this method, you see there's a 14-15 seconds delay.
• But looking into the logs, you see that they come earlier and if we were able to get the token address & liquidity address purely from the logs, that'd be an advantage and let us have the edge of shedding the 14-15 seconds delay and be early for the trades on Raydium

Correct?

I recently implemented a way of being able to use logsSubcribe instead of blockSubscribe for this same reason for sniping the initial mints on pump.fun—Solana: Listening to pump.fun token mint using only logsSubscribe. I haven't implemented this into the main bot yet. (That'll be a future iteration).

So I had the same idea for the token migrations to Raydium and try to extract the liquidity address purely from logsSubscribe, but I wasn't able to. I spent just a little bit of time on that and remember being able to extract from the logs some openbook DEX address (which is interesting, but idk for what purpose it's there), but not the liquidity address. And at that point I stopped.

I still have it on my list to come back and look into, just not sure when. I do think being able to extract/compute the liquidity address from the logs alone would be nice, but at this point I am not sure if it'll work. But I'll look if there's a way.

[Semrubo]

Thanks for reply.

So my goal is to catch the token migration completion event, monitor the trades for 1-2 seconds, and if the trades of this 1-2 seconds match to some conditions decide to buy at the 3-4 seconds after it's launch on Raydium.

• You are using Raydium migration script as outlined here Solana: Listening to pump.fun migrations to Raydium that's using the blockSubcribe method.
• Using this method, you see there's a 14-15 seconds delay.
• But looking into the logs, you see that they come earlier and if we were able to get the token address & liquidity address purely from the logs, that'd be an advantage and let us have the edge of shedding the 14-15 seconds delay and be early for the trades on Raydium

Correct?

Correct. I saw that there are earlier logs related to that token before initialize2 instruction, and when initialize2 is received it is already 14-15 seconds others are already trading with that token on Raydium.

I recently implemented a way of being able to use logsSubcribe instead of blockSubscribe for this same reason for sniping the initial mints on pump.fun—Solana: Listening to pump.fun token mint using only logsSubscribe. I haven't implemented this into the main bot yet. (That'll be a future iteration).

I saw that. That is great addition for getting data directly from RPC, especially the parsing and decoding of received data saves me a lot of time. Thank's for that.

So I had the same idea for the token migrations to Raydium and try to extract the liquidity address purely from logsSubscribe, but I wasn't able to. I spent just a little bit of time on that and remember being able to extract from the logs some openbook DEX address (which is interesting, but idk for what purpose it's there), but not the liquidity address. And at that point I stopped.

I had the same purpose, looked at couple prior logs but haven't found liquidity address that's needed for buy transaction. I am thinking that probably there should be some other RPC call that we can use for getting liquidity address from MINT or DEX or other addresses that we have from earlier logs. But haven't found it yet.

I still have it on my list to come back and look into, just not sure when. I do think being able to extract/compute the liquidity address from the logs alone would be nice, but at this point I am not sure if it'll work. But I'll look if there's a way.

Thanks, I will also continue researches to see where from we can get liquidity address earlier. By the way, I haven't looked at logsSubscribe of pumpfun program address yet, it may contain some additional info in logs during this Raydium migration process.

[akegaviar]

Hey there, starting from the next week (week of March 10) we'll be rolling out updates to the bot v2 based on the feedback and the reported issues, including updating to the latest libs, better error handling etc. We are already actively working on it.

That'll be in a separate branch.

Check out the readme for the roadmap that I just added in the README file for the full overview.

I'll try and look into it as part of Stage 2.

[nesh325]

Hey there, starting from the next week (week of March 10) we'll be rolling out updates to the bot v2 based on the feedback and the reported issues, including updating to the latest libs, better error handling etc. We are already actively working on it.

That'll be in a separate branch.

Check out the readme for the roadmap that I just added in the README file for the full overview.

I'll try and look into it as part of Stage 2.

@akegaviar Just wondering if you had implemented this into the new branch. I saw the ReadMe with logSubscribe update with a check mark beside it, but the file in the branch didn't seem to have been updated. Maybe I'm confusing it with some other thing

On another note, do you think it would be possible to get tokens right before they bond? The 1-minute bonding time would make it easier to research the coin before committing to buy the token

[akegaviar]

@smypmsa please have a look

[smypmsa]

Hi @nesh325! Listening to migrations has been implemented in the refactored branch. Besides that, there are examples of getting addresses of a market and pools. I think they will definitely help you. An example for the buy transaction will be shipped soon as well.

https://github.com/chainstacklabs/pump-fun-bot/tree/refactored/main-v2

[smypmsa]

⚠ The completely refactored bot has been merged into the main branch. Please use the updated bot.

Among others, the updated bot has so-called extreme fast mode - there are no additional RPC calls between token detection (Geyser or logsSubscribe are much faster than blockSubscribe) and sending a buy transaction. Creating ATA is incorporated into the buy transaction. Feel free to test it.

Closing this issue since it refers to the outdated code.