What Is Keep3rV1 (KP3R)?

What Is Keep3rV1 (KP3R)? Complete Guide Review About Keep3rV1.

What Is Keep3rV1 (KP3R)?

Keep3rV1 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 need credit to be able to pay keepers, this credit can either be paid for directly, or by being a liquidity provider in the system. If you pay directly, this is a direct expense, if you are a liquidity provider, you get all your liquidity back after you are done being a provider. Step 1 is to provide LP tokens as credit. You receive all your LP tokens back when you no longer need to provide credit for a contract.

Keep3rV1 Storage Key Points

Coin BasicInformation
Coin NameKeep3rV1
Short NameKP3R
Circulating Supply200,001.00 KP3R
Total Supply200,001
Source CodeClick Here To View Source Code
ExplorersClick Here To View Explorers
Twitter PageClick Here To Visit Twitter Group
WhitepaperClick Here To View
Official Project WebsiteClick Here To Visit Project Website


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

This will give you an amount of credits equal to the amount of Keep3rV1 tokens in the liquidity you provide.You can remove your liquidity at any time, so you do not have to keep buying new credits. Your liquidity provided is never reduced and as such you can remove it whenever you no longer would like a job to be executed.

Becoming a Keeper

To join as a Keeper you call bond on the Keep3rV1 contract. You do not need to have KPR tokens to join as a Keeper, so you can join with bond. 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 last job timestamp will be set to the current block timestamp. 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.

Registering a Job

A job can be any system that requires external execution, the scope of Keep3rV1 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; if 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.

Quick Start Examples

The above will make sure the caller is a registered keeper as well as reward them with an amount of KPR equal to their gas spent + premium. Make sure to have credit assigned in the Keep3rV1 system for the relevant job. You will need to provide liquidity to one of the approved liquidity pairs (for example KPR-ETH). You put your LP tokens in escrow and receive credit. When the credit is used up, you can simply withdraw the LP tokens. You will receive 100% of the LP tokens back that you deposited.

Job Interface

Some contracts require external event execution, an example for this is the harvest function in the yearn ecosystem, or the function in the uni-quote 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 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.