Our BSC non-archive should be working as before
They should as fast as before
Therefore I suggest you try some other node provider so we know if it’s your strategy that doesn’t work anymore or if it’s something with the nodes
I use the same program as before. I haven’t modified anything, so I think it’s up to you. I have already tried others like getblock, chainstack… And you guys had the best speed, until a few days ago. Are you sure you haven’t changed anything? How could I improve the speed? You don’t have any plan for it, do you?
The same program can work today and not tomorrow because market changes, more people use same strategy etc
That’s why you always have to evolve your bot to stay ahead
I don’t think its the speed as our nodes are as before
But the market always changes
Arbitrage opportunities like sniping bots need to be evolved to keep working
few days ago, when you were winning, do you know what was the time interval until the next transaction that failed and had a bid on same NFT?
I know that. The bot is made by me and nothing has changed, there may be more competitors. As I said before, it’s normal that I don’t take many of them, but not all… I tell you, I have used the bot for 2 weeks with moralis and it was fine. Now I lose money xd
Try another node provider and let us know if it starts working - maybe some node provider became faster than us
our nodes are same as before
I don’t quite understand what you want to ask me. Excuse me, I’m not a native English speaker, do you mean how much time difference did you have with the others? I can’t know that, because there may have been 200 bidders for the same NFT, I would have to go to the contract history and look at the failed bids one by one and take the ones for the same NFT that I won.
But if it would help me, I could do it…
Right now, as I told you you were the fastest. I tried all the ones suggested by binance smart chain.
okok we are always looking into making nodes faster
Check out MEV: https://www.youtube.com/watch?v=lfO5deaBWCY https://ethereum.org/en/developers/docs/mev/
MEV is when a miner sees that you find an arbitrage opportunity and steals it - could be a factor also
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.
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?
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?
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.
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
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.
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.
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.
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.
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?
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
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.