STABLE: improved Keep3r based tokenonomics system

Simple Summary

We at DeFi Wonderland would like to take over the development of a new economic design for the version 2 of the protocol looking further into the appreciation of KP3R and the inflation management of the protocol:

  • While Keep3r currently allows users (aka devs) to not spend $$$ to pay the fees on their jobs, the lack of liquidity and increasing volatility of KP3R continues to be an issue for adoption.

  • Such volatility and lack of liquidity in the market naturally generated by speculators, could potentially prevent the amount of jobs to increase & produce a high inflation period within the protocol that will further de-incentivize adoption within the early stages of the protocol.

  • This proposal looks further into the tokenomics of KP3R to enable a new mint/burn mechanism pegged to a stablecoin (name TBD).


Create a new stablecoin (STABLE) pegged with the mint/burn mechanism of KP3R and modify JobCredits to mint/burn STABLE instead of KP3R.


The idea behind this is to improve the incentive mechanism for every participant within the network.

The basic changes that come with this proposal would be as follows:

  • Maintain Keepers bond as KP3R
  • Enable STABLE as the only LP collateral (ex: STABLE/ETH or STABLE/3CRV)
  • Enable STABLE as a payment mechanism within the network (later to potentially be used on many use-cases such as MetaWallet)
  • STABLE’s enabled mint/burn mechanism of KP3R based on price oracles


The scope of this proposal is to provide a long term sustainability plan for the protocol and enable new possible markets to arise within the Keep3r Ecosystem.

As stated on the Keep3r documentation: “the scope of Keep3r is not to define or restrict the action taken (within a job), but to create an incentive mechanism for all parties involved”.

This incentive mechanism, as of today, is working as following:

  • Job creator = gets rewarded with JobCredits (KP3R expendable on the protocol) by providing liquidity on a KP3R based pair.

  • Keeper = gets rewarded with KP3R whenever they execute a task of a job within the protocol (as long as that job contains JobCredits).

While the incentive mechanism is working as intended, on a protocol level there is no economic system to back the value that could be provided and/or generated within the system; there is no tokenomics.

This proposal looks forward to providing a clear value proposition of KP3R as a value accruing token within the protocol and STABLE as a work token within the ecosystem.


This proposal comes as a potential addition/feature to the Keep3r V2 proposal.

The economic design chosen for this case is the same one as implemented in Terra’s UST (link) with an expansion/contraction of the underlying supply (in this case, KP3R) via the minting/burning mechanism of STABLE.

The rationale for this decision was the success behind the stabilization mechanism of UST, providing way more liquid and efficient markets to arise, and providing more stability for a clearer ground for adoption.


Copyright and related rights waived via CC0.


100% support this. Next would there be some snapshot vote or Onchain? Most my KP3R is in eth/kp3r with slp staked


We are currently gathering sentiment from people on these proposals.

If there are no comments or improvements proposed to our structure, we will deploy a Snapshot space and allow the community to vote.

Hey guys,

Sam from Frax here. For anyone not familiar, with FRAX, we’re a fractional stablecoin protocol that is partially backed by collateral. The collateral ratio (CR) changes dynamically as a function of FRAX price to always keep the peg tightly at $1. We’re the only algo stablecoin that has never broken their peg a single time in our lifetime.

What if you guys use FRAX as the stablecoin and our protocol buys Kp3r tokens to fractionally back FRAX? Additionally, we can use Keep3r to automate all the Frax AMOs which would be super synergetic. FRAX will give Kp3r all the benefits of having made a native stablecoin by essentially sucking up Kp3r tokens as collateral itself so the positive effects of using FRAX are enjoyed by kp3r token holders as if they created their own stablecoin but they also enjoy FRAX’s deep liquidity in Curve, 100m+ TVL on Uniswap etc.

Essentially, instead of creating a new stablecoin that has to overcome the hurdles of stablecoin liquidity/utility itself, why not use FRAX which has a close integration and friendship with the entire yearn ecosystem?

FRAX is currently 84% backed and can go up or down based on the market’s pricing of the FRAX stablecoin. Additionally, we have algorithmic market operation (AMOs) strategies which are essentially like yearn strategies but automated stability mechanisms to keep the FRAX peg tight. For example, we have an AMO that mints new FRAX and uses idle USDC collateral to add liquidity into our Curve pool. It then takes the FRAX3CRV LP tokens and deposits them into yearn’s vault to earn yield for the protocol while keeping the peg tight. You can read more about it here: Curve - Frax ¤ Finance

These AMOs would be ideal for automating using Kp3r rather than relying on the FRAX core team to continually poke them. You can think of AMOs as a protocol operated vault strategy but optimizing for stability/peg rather than yield.

FRAX has over $30m TVL as protocol controlled value in yearn’s crvFRAX vault. We also have over $20m TVL in the yUSDC vault. We’re also one of yearn’s original affiliate partners. In short, we love yearn and Andre’s ecosystem of protocols and have high synergy between everything.

What do you guys think? :slight_smile:


Lack of liquidity is bit of a stretch :slight_smile:

It’s not clear to me how KP3R stays relevant in the system with the proposed mechanism. If you enforce people to use STABLE and STABLE only as the collateral then the only reason to buy KP3R is use it for bonds. This fully removes part of the feed back loop where “Job Creators” buy KP3R.

I’d really like to see modeling or data to back this proposal. Mint/burn just doesn’t look like it makes the cut.

1 Like

I agree. The incentives on KP3R could be improved. I don’t see how adding another token helps that.

Here’s some ideas from problems that I’ve seen (I recently bonded 50 KP3R and wrote code to perform jobs just to find that the system is basically not feasible). The biggest problem (for k33pers) is that frontrunning is rampant, and drives most profits to zero or negative. This needs to be solved or the system falls apart. Somehow the system needs to allow k33pers to work together in order to become profitable again.

  1. In order to prevent frontrunning, the system should determine, for a per-job adjustable block span, which k33per has dibs. For this number of blocks, lets say 5, this chosen k33per is meant to perform the job. All other k33pers trying to do the work() in this span will fail. This prevents frontrunning.
    a. The keeper’s odds of being ‘chosen’ should be proportionate to the amount of bonded k3pr that the keeper has bonded divided by the total amount of bonded keeper. This incentives all k3per to be bonded.
    b. If the chosen keeper fails to perform the work() within 5 blocks, or whatever the setting per job is, then any keeper can now perform the job. If any other keeper performs the job, the chosen keeper should suffer some penalty on their bonded keeper, taking some of it. Keepers should always be ready to do jobs if they have bonded keeper. This taken penalty k3pr could be burned, introducing a deflationary mechanism, and pushing up the k3pr price over time.
    c. Investors can look at keeper’s performance, and invest their k3pr in them, bonding their k3pr to the most performant k3prs. This increases keepers odds of being chosen as the next keeper, since they now have more bonded (delegated) k3pr. A mechanism could be introduced that allows investors who do not run keepers, but invest in profitable keepers, to share in the profits according to their invested amount.

  2. The interface to jobs is not standard. Keepers want a standard interface to know when to perform work. It should be as simple as calling getCost(), getRevenue(), if profitable, check if they are chosen to do work()>, do the work().

  3. Non-yearn affiliated projects don’t want to buy k3pr to fund their jobs. They want to fund their jobs in their native token. Allow them to fund the jobs in their native token. Swap the native token to k3pr over time to pay the keepers. Swapping anything to k3pr increases the k3pr price. You want the projects to have as little friction as possible if you want the ecosystem to grow. Don’t introduce ANOTHER token like STABLE that other projects don’t care about.



hey @NUTELLA , actually we are working on this stuff, you might want to see the Keep3r V2 proposal

This proposal is just regarding tokenomics, we are discussing internally with Klim and we will provide more data regarding how this could impact the system and its benefits. So for now this proposal is halted until further data is provided.

Regarding @samkazemian post, sure its something to consider but implications are worse compared to what @milkyklim posted afterwards (from our POV), while we are not biased for any particular outcome in this proposal; we agree with Klim that there needs to be more data provided to build a good case for a change in the tokenomics (implementing a stablecoin just for the sake of having tighter liquidity is not enough).

1 Like

we are also discussing this in the k33per yearn discord channel, please check it out.