What is Keep3r?

This article is from Blue Fox Notes.

Keep3r has shown some performance in recent days, attracting attention from the crypto community. What is Keep3r? It is a new project by Andre Cronje. It is a decentralized Keeper task network, where some smart contract projects need external entities to help solve devops-related tasks, while some external entities (individuals or teams) can earn rewards by completing corresponding tasks. Keep3r builds a decentralized task service network for this group of people.
A Keeper refers to external personnel or teams that perform the work. These tasks can be simple (such as calling transactions) or complex (requiring off-chain logic). Keep3r is not strictly a task service platform; it does not manage these tasks itself. It allows project parties (contracts) to register tasks, and Keepers also need to register, so both parties can choose each other. In this process, Keepers set up their devops and infrastructure and can create rules (based on profitable transactions).
According to Andre Cronje, the current core of Keep3r aims to solve the problem of smart contracts needing external triggers. Some contracts require transactions to be submitted by external entities (bots, scripts, EOAs) to trigger responses. Keep3r attempts to address this issue by building a collaborative system in a decentralized manner, helping these projects find Keepers to trigger contracts externally to keep them running. From this perspective, Keep3r is not a project aimed at ordinary users; it primarily serves dApp developers.
So, how does Keep3r organize the collaboration between project parties and external entities in a decentralized way? Project parties need to submit their contracts to the Keep3r network, where contracts will be reviewed and approved by Keepers who have bonded KP3R as collateral, after which Keepers can execute tasks in the market.

1. Tasks in Keep3r

In Keep3r, current tasks mainly refer to operations that smart contracts wish external personnel to perform. At the same time, project parties hope that the execution by Keepers is benevolent rather than malicious, especially since smart contracts may involve financial risks.
In Keep3r, any system that requires external execution can become a task. Keep3r does not define or limit the scope of task execution; it mainly provides an incentive mechanism between Keepers and contracts.
Current tasks mainly involve contracts that require external entities to submit transactions to trigger responses. For example, calling update() on an oracle to update its base value; calling Harvest() on a yield farming protocol to implement a fund swapping strategy; calling vote() on a governance contract to represent users in using permission/approval mechanisms; triggering limit orders during price matching in decentralized trading; triggering liquidation in debt-based systems; and having external systems batch submit transactions on layer 2 on behalf of users. Currently, each project addresses these issues independently, such as Aave's liquidations, Synthetix's cache updates, YFI's mining, etc. This is also the main concept of tasks that Andre Cronje envisioned when building Keep3r.
Tasks in Keep3r need to be registered, and currently, there are two ways to create tasks:

• Register tasks through governance
  Submit a proposal through governance to register a task; if governance is approved, no further action is required.
• Register tasks through the contract interface
  Users can register tasks by calling addLiquidityToJob(address, uint) on the Keep3r contract. Calling addLiquidityToJob(address, uint) will create a pending governance vote. Users can submit new task applications every 14 days through this address.
  
  Additionally, tasks also have security levels, and project parties choose Keepers based on their security needs, such as the required amount of collateral from Keepers, task completion status, the duration of being a Keeper, and the amount of staked tokens by Keepers, etc. For contracts that have no risk and only need execution, the default isKeeper(address) call can be used.

Smart contracts will provide tasks, and Keepers can execute contract tasks. To become a Keeper, one can call bond(unit) on the Keep3r contract. If the user does not have KP3R tokens, they can join by using bond(0). Bonding has a three-day delay, and after three days, Activate() can be called.
2. Token Economic Mechanism of Keep3r

KP3R is the token of the Keep3r network, but it is not a mandatory payment medium for transactions. Because in Keep3r, project parties can pay Keepers with ETH or project tokens. To incentivize Keepers to complete tasks, project parties need to reward Keepers. Currently, project parties can choose three ways to reward Keepers:

• Directly pay in ETH
• Directly pay in tokens
• Indirectly pay Keepers by providing liquidity
  Of course, these tasks can also be rewarded with KP3R tokens. By becoming a liquidity provider, one can earn Credit, which can be used to obtain corresponding amounts of KP3R tokens. Each time a task is executed, Keepers will be provided with (at most) gasUsed * fastGasPrice + premium%, which will be deducted from the project party's credit (not deducted from liquidity). Project parties can add and remove all liquidity at any time.
  If KP3R is not used as a payment token, then what is its purpose?
• Collateral
  Since some contracts' external trigger work is related to financial risks, external Keepers executing trigger tasks need a minimum collateral to qualify for executing related tasks. This collateral uses KP3R tokens. In other words, Keepers wishing to execute these tasks must deposit the corresponding minimum amount of KP3R as collateral.
• Governance
  The governance of the Keep3r network is managed by Keepers who have bonded KP3R as collateral.
• Capture transaction fees
  Although transactions may not necessarily be paid with KP3R, all transactions still incur fees. For any non-KP3R transaction (transactions paid with ETH or tokens), the repository receives a 0.3% fee.
  In summary, KP3R can be used for governance, as collateral for high-risk tasks, and to capture transaction fees. Additionally, liquidity providers can pay Keepers with KP3R credits.
  According to Andre Cronje's design, the main tasks of Keep3r governance include:
• Adding liquidity pools that accept task credits
• Approving/revoking tasks
• Addressing disputes/reducing/resolving/revoking Keepers
• Setting KP3R reward amounts