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.