Keep3r V2: optimizing the protocol ability to grow

Summary & Motivation

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

    • round robin tx ordering & collaboration
    • 1 line/command setup
    • all jobs and parameters loaded
    • flashbots support to avoid reverted txs
    • support stealth transactions

Copyright

Copyright and related rights waived via CC0.

2 Likes

Good stuff!

contract structure separation

How necessary is that? Do you want to do this to have parts of the system upgradable?

deprecate oracles
deprecate oracles in favor of Uniswap V3 oracle solution

What would we do with pairs not available on uni v3?

LP reutilization

Good one.

1 Like

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.

While it was useful, it represents a ton of inflation for the protocol at this early stage, for reference: https://keep3r.live/job/0xaed599aadfee8e32cedb59db2b1120d33a7bacfd

1 Like

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.

@NUTELLA this should solve most of the problems that you commented on the STABLE proposal.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.