-
the data shows that some projects burn liquidity and dump straight afterwards, even when there is a lot of initial traction, the LP burn does not guarantee a good entry since it happens quite late for a lot of projects
-
using min amount out 0 is dangerous, as sometimes the pool is not going to be updated at the right time and you can send a swap to a rugpulled token, swapping with insta -100% pnl
-
filter out pump.fun tokens (mostly post-launch dumps)
-
get the pool details beforehand, wait for the amount out calculation for when jito leader is there
-
get the price of entry based on tx receipt, track the positions in another service
-
screen the liquidity burn before listening onto LP event in case the LP burn has already happened (JITO bundles, network delays)
-
track the slot of mint creation and the swap tx execution
-
verify the amount out param (slippage)
-
ensure re-connect when socket closes
-
move sniper configuration to an object, print on start
-
track the swaps, see if jupiter pricing api has the fresh tokens, otherwise track based on raydium (custom)
- save the new holdings into a key-value store like redis
- add self initial after a 2x
-
add maximum amount of slots of wait (edit: waiting for leader to be JITO is not required)
-
migrate the rpc_client to non-blocking
-
separate the listening and transactions so that it is non-blocking in case of multiple pairs in short span
-
compare entry to available total liquidity
-
benchmark the RPCs a bit more, so far https://api.mainnet-beta.solana.com/ provides best latency
-
check the liquidity on creation
-
check the top 10 holders balance (red-flag if already weird at launch)
-
check the circulating supply (similar check to previous point)
-
might need to work with larger slippage (20%, 10% does not land many), leaving
below is displayed sometimes but transaction lands
[2024-05-13T15:59:55Z WARN listen] swap tx: internal error Searcher service did not provide bundle status in time