Job competition and Autotask frequency

Hello everybody,

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.

Non0

:computer: Environment

:memo:Details

:1234: Code to reproduce

2 Likes

Hi @Non0,

Welcome to the community :wave:

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. :pray:

1 Like

Hi @abcoathup,

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 :slightly_smiling_face:

3 Likes

Hi @Non0,

There is also a discussion on the Keeper economy (Thanks @Bolo for sharing) that you may want to join:

Hi @Non0,

New in Defender is an example script for running a Keep3r at a faster rate.

Please see Defender Release 2020W49: Sokol testnet, Autotask examples repository, and faster Keep3rs.

Thanks for sharing your experience with Keeper and the shout out to @andre.cronje for the awesome work on keep3r.network!

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!