We at DeFi Wonderland would like to take over the development of the version 2 of the protocol optimizing some key pain points that have shown setbacks for adoption:
Keep3r has been of great use for the Yearn ecosystem (Yearn, Sushi, Pickle, etc) but it hasn’t seen much adoption from other protocols because of its complexity (bond/unbound periods are not efficient and there is not much tooling around them)
There are currently only 4-5 Keepers working on the protocol on a weekly basis (1), we have in mind some code improvements that could be done in order to provide a fair playground in which more Keepers could participate, collaborate and benefit from it.
Gas efficiency in such a system is critical, we can achieve great improvements in this matter.
Background & Specification
The idea behind this is to improve the gas efficiency and the composability of the protocol in such a way that benefits all the participants of the ecosystem.
gas efficiency
evaluate and understand what inefficiencies could be improved.
contract structure separation
KP3R token code
Governance code
Core Protocol code
a) liquidity bonds
b) keeper bonds
auto-credits time based minting based for LPs
remove the bonding/unbonding period for the minting of credits in exchange of a time-based auto-minting for the Liquidity Providers of the Jobs.
faster bond/unbond for jobs
deprecate oracles
deprecate oracles in favor of Uniswap V3 oracle solution
LP reutilization
stake the protocol’s LP positions into the liquidity mining programs (Sushi and potentially more) in order to generate revenue from them.
work should be always paid in bonds (prevents insta-dump)
deprecate receipt() if it’s paid with KP3R, in a potential attack where a job gets its credits drained, governance does not have any way to slash the keeper.
backend (keep3r-node) (future work)
This would be an implementation that will take time but we can potentially develop in the long term
This is so the protocol is structured more modular and in the case of the protocol having an upgrade (such as in this case), we wouldn’t need to re-deploy the whole code and lose the state.
This is mainly associated with the STABLE proposal, the only reason we could find for the Keep3r Oracle to remain active was the credit minting (accounting the amount of KP3R to mint) which if the other proposal goes through it won’t be necessary.
If a pair isn’t on UniV3 it’s mainly because no one is using it, so whenever a third party protocol needs such oracle pair they will be able to incentivize / provide liquidity on that pair to enable it.
Think there are lots of useful elements in the proposal - the backend (keep3r-node) looks especially interesting.
However, I think it’s really important to allow more than just UNIV3 pairs in a Keep3r oracle solution.
Ultimately a lot of the broader potential value from Keep3r comes from the allowing arbitrary functions to be paid for - UNIV2/Sushi is only one such example. It also means that keep3r essentially becomes a wrapper over the V3 Oracle solution, which begs the question why not just interact with UNIV3 directly.
While you can incentize / provide liquidity on a second pair, doing so just for an oracle solution, at a volume necessary to prevent market manipulation and a wide enough range to accurately capture the “primary” pair would be more expensive than any gas fees from updating an oracle yourself - especially if you’re missing out on staking in a more profitable pair.
As commented above, the deprecation of Keep3r Oracle in favor of UniV3 oracles would be in the case the STABLE proposal passes (which for now will be delayed until we offer more data).
In the case the STABLE proposal passes, there is no need to calculate the USD value of the underlying because it will be calculated at face value of 1 STABLE = 1 USD and then use UniV3 oracle for the ETH price at the time of the transaction.