I have a use case where after cloning a contract I would need in m-time to do a function call, the task to be automated would be in the future. but only the function has to be called one time, does keep3r network fit for purpose in this use case?
Is the keep3r-network deployed on testnets (ropsten, Mumbai, etc…)?
I am writing a blog comparing different automation solution
2 Likes
ey!
but only the function has to be called one time
do you mean that you’d automate something for only 1 tx?
if there are multiple instances of this contract that has to be called by the keeper, i’d suggest making a whitelisted address to call that function, and deploy in that address the keep3r job (the contract with which the keeper will interact)
there’s an unofficial Keep3r clone in Goerli:
TestKeep3r 0xed05bcb3b77f6ef70b12be931f98b6eff2ef6e1c
TokenA: 0xce60677e8a0471e51c2e32424ce8d0aa51030b54
TokenB: 0x47deba3280fc19643d63ab1cd6a2572465ae6562
PairManager: 0xed1f45c914a40bbe516601f5e2aa5ab96617e85c
Job example: 0xd50345ca88e0b2cf9a6f5ed29c1f1f9d76a16c3c
thks!!
Yes only one tx that has to be executed at a precise time. Only one contract.
Are the keepers checking the conditions on every block?
@wei3erHase is there a tutorial/guide to help me through creating a job on Goerli?
Thank you very much!!
theoretically you could, keepers are checking every block, but you’d have to convince them to install a job (and use their dev-ops infrastructure) for a job opportunity that would possible reward them once, or maybe never (because another keeper has worked it).
if it’s a one case situation, i don’t see the point of automatizing it. if it’s very needed, i’d suggest using a manual payment settings, so that you can provide a big reward for the job (not just gas cost + 20%)
Hi @wei3erHase I’ve been digging a bit and trying to reproduce a sample test case, I’ve deployed a contract with the work() and modifier as expected, and have verified at K3rIncreaseContract | Address 0x8d9433C1305F5Ca8499688A15e3815F92ed10230 | Etherscan
I’ve added the job to the keep3test TestKeep3r | Address 0xed05bcb3b77f6ef70b12be931f98b6eff2ef6e1c | Etherscan
The addjob() method has succeeded, the job has been added to the jobs array (not so many tests, only three jobs with mine)
I’ve also funded with 0.1 ETH for paying the keepers. Using: IKeep3rV1(keep3r).worked(_keeper);
I’ve seen at the example test contract (0xd50345ca88e0b2cf9a6f5ed29c1f1f9d76a16c3c) that the work method was called from the address 0x93f7e117835003AD50F537520DF27A22f8524AD0, which is one of the keepers of the TestKeep3r 0xed05bcb3b77f6ef70b12be931f98b6eff2ef6e1c.
Now, the question, how do I achieve that the test keeper performs the work() method call?
On the other hand, when in mainnet, can we see the logs and balance of our job? (in goerli can only be done through etherscan I suppose).
And finally, is there a public roadmap of the product to understand any further developments?
Again, thank you very much!!
ey @donoso_eth,
letme get into your questions and hope that it answers all the doubts…
i understand that you have registered the job, now there are a few steps to complete:
- mint both TokenA and TokenB tokens (permissionless)
- mint a kLP with those tokens (calling mint in the PairManager)
- add those kLPs to the job (
TestKeep3r.addLiquidityToJob(job, kLP address, amount))
Now, the job is generating credits that can be used to pay for keepers (they pay for the gas, they receive credits in exchange). Keep in mind that adding kLPs is a one time only thing, as they are not consumed when paying the keepers (but their yield is).
The on-chain setup should be ready now.
As for making the keepers run the job, we made this boilerplate to create a Keep3r-CLI package (a one-command installation module for keepers to decide to run your job and earn rewards coming from it). GitHub - defi-wonderland/keep3r-cli-job-boilerplate
If i’m not mistaken, your example job could be executed with the job-a example, since it’s only calling to a work() method. You should then only change the address of job-a to be pointing to your contract, create a repo, publish, and test with the Keep3r-CLI tool. Notice that you should be a registered keeper to be able to work it ( Keep3r.bond( tokenA, 0 ), wait 5 minutes, Keep3r.activate( tokenA ) )
As an explainer, Keep3r is not something that just runs and hits every possible job, but a way of job-providers to easily give the keeper-runners what they need to run the job, and to reward them (without losing money for doing so, more than having exposure to KP3R/WETH pair).
Keep3r is the on-chain payment mechanism
Keep3r-CLI is the off-chain program to run a keeper
Job-package is the add-on for Keep3r-CLI that will run your job
Job status can be tracked here: Dune
Or through the frontend: https://keep3r.network/
Let me know if we can be of any help,
Bests!
WH
Thank you very much @wei3erHase, your support is awesome.
I’ve been trying to reproduce the above steps, I mint the A token and B token, but when trying to call the mint function within the PairManager, it fails with error ’ Fail with Custom Error ‘UnsuccessfulTransfer ()’, I’ve exactly reproduce the same amount that the previous transaction.
However I’ve already the major building blocks for my blog. I understand the effort and how it works (almost)
I have some questions/comments:
a) The only way for the keepers to pick up my job is to publish the npm through the Keep3r-CLI?
b) If so, then the Keep3r network can not be used for dynamically created (from smart contracts) tasks, as the infrastructure (npm package has to be published offline)
c) As I am analyzing other solutions (autotaks by Open Zepellin, Gelato, Chainlink Upkeep), I don’t see how to convince someone to use Keep3r Network?, What are the strong points I am missing (i can see that forget to fund the keeper as a stoing point, as the yield of the liquidity will be paid for)?
Would you like that I share with you the draft of the blog (once is more advanced) to check if my comments are plausible?
Eyy @donoso_eth thank u for reaching, i believe the approve( PairManager, 100 ) tx would be missing for both tokenA and tokenB, wasn’t included on the step-by-step.
As for the questions, glad to answer, (a) using the CLI is not the only way of getting your job worked, but rather a condition to having your job listed on the front end. A job can be unverified and still participate on the network, the condition is that there has not to be any preference por keepers, but to be open to every keeper to participate.
(b) The CLI provides a template of how to fork the latest network state, read it, build a tx and simulate it. In such way, it could be programmed to trigger when data from smart-contracts indicates so. An important thing to consider is that, as jobs are open for keepers, sensitive call parameters should be checked on-chain to prevent keepers misbehaviours. Recommended behaviours are:
- just simulate
work() - read an registry of addresses and simulate
work(address)for each in registry
When such transactions are successful, then keeper submits them through flashbots (so tx wont collide and revert). API methods could also be implemented in the CLI package, to read for example through a request signed data and submit the transaction.
(c) I believe a strong point for Keep3r is the liquidity mechanism, a setup of one-time transactions can leave a maintenance task running indeterminably without further interaction. Also it’s effects on how transactions are executed is interesting: for instance, one could have an over-budgeted job, that runs every time is needed (reaction is needed, usually can be worked 1-10 blocks after being workable), or one can have an under-budgeted job, that runs every time it can, because of maintenance tasks maybe should be run only periodically. On the 2nd scenario, a very low liquidity can ensure that the tasks will be run, and that they are going to be run at low gas-costs (as they’ll be run when accumulated credits so far and the baseFee at the moment make the transaction executable). Ex. Under-budgeted job: was run over the last week around 10gwei, consuming around ~10M gas.
I also believe that decentralization of sensitive maintenance tasks should not be overlooked. The trustless interaction between job providers and keepers avoids any kind of censorship in task maintenance, being exposed only to the liquidity value. As long as job generates MEV, MEV will transact it.
Sure, would like to read that draft 
Bests!
WH
@wei3erHase awesome^3. I will digest slowly your reply to understand it properly.
Thks for pointing out the error (I could have thought about it 
.
I have minted the klp tokens and approved too. However, I receive a ‘fail error’.
I’ve been looking at the other test jobs of the TestKeep3r contract and in both cases, the liquidity was added using forceLiquidityCreditstoJob(), which only can be called by governance 0x7D4BF49D39374BdDeB2aa70511c2b772a0Bcf91e (I imagine yours). would it be possible to try this way?
Thks
1 Like
my bad! is TestKeep3r.addLiquidityToJob(kLP, job, amount)
I had already tried all possibilities as the logs were confusing, however, the contract looks like:
I’m calling the method from etherscan, maybe could be something wrong with the contract job. The job seems to be registered properly in the array of jobs.
Sorry for disturbing you again and thks again.
yo @donoso_eth, thanks, it was really _job, _liquidity, _amount in the end, idk why etherscan encodes it as liquidity, job, amount (only on testnet, on mainnet is ok).
The error that you were getting is an unfortunate one, you were providing 2 LPs, while the minimum amount corresponds to having a minimum amount of 3 underlying KP3Rs. As quote is 1-1 on the testnet, the minimum amount of LPs would be 3.
I’ve force-pushed some credits, and also managed to add some liquidity to the job:
0xd412b8e7f878c3f080de9ab26ab6d4610faad26b87964252645750995b0ea0be
Hope it solves what you need for testing!
Bests,
Wh
1 Like
thks again @wei3erHase , I did achieve to add liquidity, bond, activate and execute, also published a npm and simulate the task with the cli… uffff. Thks again!!
I’ll paste here the draft of the post I am about to finish, if you would like to comment something will be highly appreciated!!
https://medium.com/@javier_donoso/smart-contract-automation-state-of-the-art-hack-view-c153944b1a02
1 Like
Yoo @donoso_eth, thanks for the reference, there’s a typo in the name tho
As for on the fly tasks, they’re available to be performed as long as there’s a smart contract coordinating them. I’d invite you to check on MakerDAOUpkeep job (0x5D469E1ef75507b0E0439667ae45e280b9D81B9C) , it queries a sequencer that replies, not only who’s network turn is it to upkeep the task, but the task itself is needed to be upkept.
Fair review overall! Happy that you managed to understand the system! 
And sorry about lack of docs 
Or PhutureRebalance (0x133A4273589c2eE5F9Fe28898B68aC1B4B1BA9B0), that coordinates it all via signed messages and an API call on the CLI.
It’s flexible…
Last but not least, under the recent context, I believe having an upgradeable contract check could be of interest for the users 
Cool piece of work, would be great if you could tag the Keep3r twitter account when you post it.
BTW, there is also an official discord & telegram group
Hey @SeaSaltyFunk , thank you very much, I will do it!, still waiting feed back from other solutions.
1 Like