Hey Keep3rs!
I’ve been calling UniswapV2SlidingOracle on and off for a while now. I just can’t get the darn thing to work. Is there a bug in this job? Some folks have had success. Not sure what the secret sauce is on this one.
Here’s an example from a recent transaction (not mine).
Appreciate any help.
This job is workable every 30 minutes. The example you send was confirmed 2 blocks after a successful transaction of someone else so in the meantime workable has been set to false again and this is why following transactions are failing.
It’s very difficult to get between, because currently it’s dominated by 2 or 3 bots sending out transactions very quickly when the job is workable.
Thanks for the response @Voorsie. That makes sense, and looking at the tx history on the contract I was thinking the same thing.
I don’t suppose there is a way around that in the current design? I ask mainly because I want to avoid tx errors when competing against multiple bots. Even with an off-chain workable() option, how many blocks do you need to wait to confirm the job is done? At least one, but perhaps even more since transactions can be rolled back for finalization.
Suggest a 2 minute sleep after sending work
while(true) {
if (!contract.workable()) {
sleep(1000)
continue
}
contract.work()
sleep(120000) //2 minute
}
The suggestion of @marsW is a good one to prevent your script to send multiple failing transactions.
However, it’s currently a matter who is sending their tx in the first block that is timestamped 1800 seconds after the last successful work, with the highest gas.
I have just described the situation in another topic: Bot war: Failing txs
yesterday non0 and I were able to get some jobs with the code provided form OpenZepplin’s team