Earlier this year, we proposed & started the adventure of developing the V2, after 5 months of work we are happy to reveal the final release candidate for Keep3r V2 that has been audited by Peckshield.
Time based credit minting
In the first version, jobs were funded by providing liquidity to the protocol, bonded for a period of 2 weeks, ensuring that all the credits minted were always backed by underlying liquidity. This setup, required the job to bond and unbond the liquidity every 14 days to keep on minting credits, incurring in unnecessary transaction costs, and requiring the provider to be aware and trigger those transactions when the time comes.
In Keep3rV2, we kept the same minting principle, every minted KP3R is backed by an underlying KP3R bonded to the protocol to ensure its value. The difference is that KP3Rs are minted gradually with time, and require no further transactions from the liquidity provider.
Each period, a job should be rewarded an amount of credits equal to the underlying
KP3Rs of the
KP3R LPs provided, multiplied by the proportion between the period length and the configurable
underlying KP3R of the kLPs * rewardPeriod / inflationPeriod
To avoid KP3R honeypotting, minted credits are only to be used within a reward period, and old unused credits burnt.
Updating a v2 job requires only deploying a new job contract, registering the new job address, and triggering a migration from the older job contract address to the new one. Credits and
kLPs will be seamlessly migrated, and the new job ready to be worked.
Uniswap V3 Pair Manager Factory
UniV3PairManagerFactory is a factory that allows anyone to create a full range position on any Uniswap V3 pool and tokenize the
ERC721 full range position into
To tokenize the liquidity into
ERC20 kLPs, a Pair Manager contract is deployed, allowing providers to deposit
TOKEN A and
TOKEN B, and it will handle the funds into the Pair Manager’s full range position.
KP3R liquidity, a set of approved
kLP liquidities will be accepted as collateral in Keep3r V2 to mint new Keep3r credits, as a requirement, one of the 2 tokens must be
Uniswap V3 TWAP Oracle
To efficiently calculate how many
KP3R are bonded to a certain
kLP, Keep3rV2 observes and stores the
tickCummulative value of the underlying
Uniswap V3 Pool at the timestamp of the last period start. When the first job of the period gets worked, its keeper will also perform this pool observation, then calculate job credits, and finally get rewarded for the gas cost of the whole transaction.
Since jobs are rewarded for the
gas * baseFee costs in
KP3R/WETH pair is natively quoted using the
KP3R/WETH 1% UniV3Pool: 0x11B7a6bc0259ed6Cf9DB8F499988F9eCc7167bf5
To reduce the impact of KP3R spot price on the speculation of a job’s profitability, rewards and credits are quoted at the same time, under the same principles. This means that within a certain period, both quotings will remain stable, ensuring the job a certain available amount of
gas * baseFee to reward to the keepers.
As we stated on the proposal and while working on the infrastructure of Keep3r V2, we realized that there was a huge lack of adoption from the keepers’ side, so we decided to develop a client so anyone can run their own keeper with little to no technical knowledge.
Keep3r-CLI provides an easy-to-use CLI along with all the necessary code required to run your own keeper and start working on jobs. This is a beta release, proceed with caution.
A job board will be curated on the Keep3r-CLI repository, with description and the required information for each job, so the protocols have a way of broadcasting their jobs through pull requests to the public repository (in a similar fashion as MEV Job Board).
Looking into the short-term future, we want to expand support of the Keep3r Network to as many blockchains as feasible. While our design of V2 has in mind the multi-chain approach, we have to standardize the approach of how we expand to different ecosystems. This is currently a work in progress but once the framework has been finalized, its a matter of working on the specifics for any chain that we want to expand towards (including but not limited to oracles, incentives & adoption)