How to submit transaction speed

[yianabng]

First of all, thank you for your contribution. I made some modifications and attempts based on your contribution. It only takes 84 milliseconds for me to submit a pump token from creation to chain, but I found that it takes about 1 second for me to submit it to the chain, and it also takes a while for me to get the information of token creation, which makes me often 1~5 blocks slower than the block of token creation.

I found that some robots can buy transactions in the same block as the token creation. How can I do this?

thank you!

[smypmsa]

A few ideas:

• increase priority fee (just in case).
• optimize amount of CUs (src/core/client.py). In the current implementation, I've added default 100_000 CUs for each transaction. Apparently, this number for a buy tx is somewhere between 50_000 - 80_000 CUs.
• add explicit commitment level processed to getLatestBlockhash call (src/core/client.py).
• add warming up an endpoint.

My tests showed that further improvements would require using enhanced RPC endpoints (like trading node by Chainstack or other). In that case, I was able to achieve the first slot right after mint happened.

How to achieve the same slot - the question is still open. I'll try to do research.

The change added here 2ef1a09 and here 465e804.

[yianabng]

A few ideas:

• increase priority fee (just in case).
• optimize amount of CUs (src/core/client.py). In the current implementation, I've added default 100_000 CUs for each transaction. Apparently, this number for a buy tx is somewhere between 50_000 - 80_000 CUs.
• add explicit commitment level processed to getLatestBlockhash call (src/core/client.py).
• add warming up an endpoint.

My tests showed that further improvements would require using enhanced RPC endpoints (like trading node by Chainstack or other). In that case, I was able to achieve the first slot right after mint happened.

How to achieve the same slot - the question is still open. I'll try to do research.

The change added here 2ef1a09 and here 465e804.

Thank you very much for your reply. Let's explore together

[smypmsa]

My recent tests with an extremely high priority fee (like x10-50) didn't show any improvements - I still get the 1st or 2nd slot (using Chainstack trading node).

I also checked the performance of the Python flow itself (in yolo mode aka continuous trading). The delay between token detection and sending a transaction is up to 10 ms.

I believe the rest could be improved only by placing the bot as close as possible to a source of logs (or Geyser) and an RPC node for sending transactions. All my tests performed from US East.

[yianabng]

My recent tests with an extremely high priority fee (like x10-50) didn't show any improvements - I still get the 1st or 2nd slot (using Chainstack trading node).

I also checked the performance of the Python flow itself (in yolo mode aka continuous trading). The delay between token detection and sending a transaction is up to 10 ms.

I believe the rest could be improved only by placing the bot as close as possible to a source of logs (or Geyser) and an RPC node for sending transactions. All my tests performed from US East.

It has been a while since the token was discovered and a buy request was issued. I have tried testing it in Japan, the East and West of the United States, using nodes such as Sirius and Quick, but it is still 1-2 slots slow.
I'm wondering if it's because those robots that can achieve the same solt are able to cheat because they already have one machine as a validator or checker along the entire chain

[blinkenstephanie]

For same-block / near-block landing: (1) fresh blockhash at send time, (2) realistic CU limit + unit price, (3) Jito tip ≥ current floor on a tip account, (4) pre-create/fund WSOL ATA, (5) prefer a private/colocated RPC over public. Hosted launch queues often hide these knobs. A self-hosted PumpSwap launcher lets you tune tip+CU yourself — APEX is free to use / tiny fees to test, or ~3 SOL to download & run locally: https://apexlauncher.fun · @suntzuson