Sniper bot failing - node speeds lag?

Moralis General
#22

I have been seeing that it is MEV. But in my case I donā€™t think itā€™s a determining factor. Since by the looks of it the MEV is how they order the transactions in the block to resolve them.

They do this in order to make a profit, talk about trades with the price of ETH, buy cheaper and sell more expensive positioning the transaction behind (the one that buys). In my case, it is a buy and sell of one nft.

If I compare the trades, I use the same gas limit and the same gas price. For a miner, this is not something usable since both transactions should be the same. Neither buys or sells the token. So I donā€™t know if MEV is really something to value here.

Anyway thanks for the info, it never hurts to learn new things.

#23

can you actually know if it was 5-6 milliseconds or 1 second between those 2 transactions?
the transaction length is the same in both cases?
what is the geographical location of your server that sends the transactions?

#24

I look at the timestamp that appears in the transaction, I understand that this is the correct time at which the transaction appears, isnā€™t it?

image
image822Ɨ67 2.46 KB

What do you mean by the duration of the transaction? Both send the same information.

I donā€™t use a server, I use my personal computer at home. I live in Spain.

#25

that timestamp is in seconds, and I think that it should be the timestamp of the block and not of the transaction

the speedy nodes are located in New York, if you would have a system closer to speedy nodes, maybe it would be faster to send the data if the problem would be of 5-6 milliseconds delay

#26

How can I see the mark of the block? I made a mistake putting it yes, it is seconds not milliseconds.

Maybe if I hosted my bot on a Newyork server it would improve the speed?

Thank you very much for your time.

#27

Every transaction also has a block number where is was included. And ~every 3 seconds a new block is mined on bsc. If your transaction is in a different block number than the transaction that succeeded, then you may have a delay in seconds.

#28

I know what you mean, but there is little I can do about it, right? Thatā€™s why Iā€™m looking to improve the speed at which it is sent because as the nft appears on the blockchain I try to buy it. The faster the speed, the earlier I get the information and the earlier I send the transaction.

#29

Iā€™m curious now if your transactions were in same block as the successful ones or in a separate block at seconds apart. If there is a problem of milliseconds then you could solve it with a closer server location, but if the delay is in seconds then it may be a different problem.
You could also log the time when you send the transaction to see how fast will make it to blockchain.

#30

If the ones that fail are in another block, 2-3 blocks ahead. For a difference of 6-9 seconds, is there a way to solve this?

#31

Now the question is when did you send that transaction that has that delay of 6-9 seconds. If you sent it too late or you sent it at time relative to the time when that successful transaction was mined.

1 Like
#32

I usually send it 1-2 seconds after the transaction (the purchase) is confirmed. And then the return time, until mine is confirmed. In total it is usually between 5-8 seconds difference between the time the purchase is confirmed until my bid (transaction) is confirmed.
Maybe I should anticipate and look at the txpool? I was listening to the event that is created when the purchase transaction is confirmed.

#33

Looking in txpool transactions could help you, but you may not find all the transactions there, you could do some tests.

#34

I will continue to investigate how to improve my speed, but something has happened to the node, even if they tell me it hasnā€™t xD