A Keeper is the term used to refer to an external person and/or team that executes a job. This can be as simplistic as calling a transaction, or as complex as requiring extensive off-chain logic. The scope of Keep3r network is not to manage these jobs themselves, but to allow contracts to register as jobs for keepers, and keepers to register themselves as available to perform jobs. It is up to the individual keeper to set up their devops and infrastructure and create their own rules based on what transactions they deem profitable.
Jobs
A Job is the term used to refer to a smart contract that wishes an external entity to perform an action. They would like the action to be performed in "good will" and not have a malicious result. For this reason they register as a job, and keepers can then execute on their contract.
Becoming a KeeperTo join as a Keeper you call bond(uint) on the Keep3r contract. You do not need to have KPR tokens to join as a Keeper, so you can join with bond(0). There is a 3 day bonding delay before you can activate as a Keeper. Once the 3 days have passed, you can call activate(). Once activated you lastJob timestamp will be set to the current block timestamp.
Registering a JobA job can be any system that requires external execution, the scope of Keep3r is not to define or restrict the action taken, but to create an incentive mechanism for all parties involved. There are two cores ways to create a Job;
Registering a Job via GovernanceIf you prefer, you can register as a job by simply submitting a proposal via Governance, to include the contract as a job. If governance approves, no further steps are required.
Some contracts require external event execution, an example for this is the harvest() function in the yearn ecosystem, or the update(address,address) function in the uniquote ecosystem. These normally require a restricted access control list, however these can be difficult for fully decentralized projects to manage, as they lack devops infrastructure.
These interfaces can be broken down into two types, no risk delta (something like update(address,address) in uniquote, which needs to be executed, but not risk to execution), and harvest() in yearn, which can be exploited by malicious actors by front-running deposits.
For no, or low risk executions, you can simply call Keep3r.isKeeper(msg.sender) which will let you know if the given actor is a keeper in the network.
For high, sensitive, or critical risk executions, you can specify a minimum bond, minimum jobs completed, and minimum Keeper age required to execute this function. Based on these 3 limits you can define your own trust ratio on these keepers.
So a function definition would look as follows;
function execute() external { require(Keep3r.isKeeper(msg.sender), "Keep3r not allowed"); }At the end of the call, you simply need to call workReceipt(address,uint) to finalize the execution for the keeper network. In the call you specify the keeper being rewarded, and the amount of KPR you would like to award them with. This is variable based on what you deem is a fair reward for the work executed.
Example Keep3rJob
interface UniOracleFactory { function update(address tokenA, address tokenB) external; } interface Keep3r { function isKeeper(address) external view returns (bool); function workReceipt(address keeper, uint amount) external; } contract Keep3rJob { UniOracleFactory constant JOB = UniOracleFactory(0x61da8b0808CEA5281A912Cd85421A6D12261D136); Keep3r constant KPR = Keep3r(0x1cEB5cB57C4D4E2b2433641b95Dd330A33185A44); function update(address tokenA, address tokenB) external { require(KPR.isKeeper(msg.sender), "Keep3rJob::update: not a valid keeper"); JOB.update(tokenA, tokenB); KPR.workReceipt(msg.sender, 1e18);Dieses Angebot basiert auf Informationen, die ausschließlich vom Anbieter und anderen öffentlich zugänglichen Informationen bereitgestellt werden. Das Token-Verkaufs- oder Tausch-Ereignis steht in keinem Zusammenhang mit ICOholder, und ICOholder ist nicht daran beteiligt (einschließlich technischer Unterstützung oder Werbung). Tokenverkäufe, die von Personen aufgeführt sind, mit denen ICOholder keine Beziehung hat, werden nur gezeigt, um den Kunden zu helfen, die Aktivitäten innerhalb des gesamten Token-Sektors zu verfolgen. Diese Information ist nicht als Ratschlag gedacht, auf den Sie sich verlassen sollten. Sie müssen sich fachlich oder fachlich beraten lassen oder Ihre eigene Due Diligence durchführen, bevor Sie auf der Grundlage der Inhalte unserer Website Maßnahmen ergreifen oder unterlassen. Alle Bedingungen, die von Mitwirkenden in Bezug auf den Erwerb von Token eingegangen werden, liegen zwischen ihnen und der Aussteller des Token und ICOholder ist nicht der Verkäufer solcher Token. ICOholder ist rechtlich nicht verantwortlich für jegliche von Dritten im Zusammenhang mit einem Token-Verkauf abgegebenen Zusicherungen, und jeder Anspruch auf Vertragsbruch muss auch direkt gegen die hier genannte Token-ausstellende Einheit geltend gemacht werden.
Wenn Sie Bedenken hinsichtlich der Art, Angemessenheit oder Rechtmäßigkeit dieses Token-Verkaufs oder der daran beteiligten Personen haben, wenden Sie sich bitte an info@icoholder.com mit detaillierten Informationen zu Ihren Anliegen.