I take a look to the interaction with the diferents Jobs Contract on etherscan, and a lot of address which realise the jobs use a very high amount of transaction fee and Gas fee. You can see it for all interaction with the contract :
There is always transactions canceled, always with an amount of fee realy low (2$ or 3$) and the address which win the transaction put between 25$ and 30$ of transaction.
It is often the same addresses that manage to carry out the jobs, with high transaction costs and very often one transaction launched before the others. So, is the usefulness of Open Defender and of running Autotask once every 2 minutes really useful in diversifying the realization of Jobs? or is it better to have your house code which runs every 5 seconds (or 1 second, or 0.1 second) and which allows you to earn KP3R?
Because if the solution to realize job is just put 0.08 ETH in transaction fee, is easy to make, but not really usefull for the community in my mind.
Thanks for raising this. It is a challenge for how the Keeper economy might evolve to avoid a small number of Keepers winning the majority of Jobs.
This may also be worth posting in https://gov.yearn.finance/c/projects/keep3r/20.
Some potential ecosystem solutions could be to throttle the frequency of keepers (a Keeper that wins a job can’t do work for X amount of time), or a cap on gas to reduce front-running.
As for the frequency of autotasks, currently the minimum is set to one minute. There could be potential to increase this frequency, though this comes with higher infrastructure costs, some of which may need to be passed on to users.
Keeper and Defender are both evolving, and the team are watching closely. Input and feedback is very welcome.
Thank you for your reply.
a Hard-gas cap coupled with a thrttle of the frequency look like to be a very good solution to avoid front running. We will see if it's efficient with practice.
Yes it's true. But if we put in place a limitation of the Job execution, there is no need to improve the frequency of autotask (I think) .
In practice, It can be studied to put in place a limitation of the Job execution, but only for the job executed (ex : UniswapV2SlidingOracle not workable for XXXX seconds, but it still possible to do HegicPoolKeep3r and YearnV1EarnKeep3r), not for all the list of jobs.
We will continue to write feedbakc, and thank you for your reactivity and availability
It's great to see the community actively involved. I totally get that the job competition and Autotask frequency can be challenging. Hang in there, adaptability is the key! If you're looking for additional insights or opportunities, you might find some useful resources at https://huntly.ai/. Keep up the good work, and here's to smoother and more profitable keeper runs!
Environment
Details
Code to reproduce
