Staking Design Discussion

Staking BPRO

There has been a lot of conversation lately revolving around staking on the discord and telegram. Yaron shared a few important things to consider around timing and how v2 would come into the picture with fees hopefully. For the reasons he mentions I do believe it to be early, but not so early we can’t discuss what system we should implement to help retain participants in the the governing of the protocol be it staking or something new and different.

This isn’t the first time that staking BPRO has been discussed but the community has yet to come up with a design that could be implemented. Perhaps our ever expanding partner project list will lead to a solution, but I have yet to come up with one personally. We should use this thread to brainstorm and as soon as there is a concrete proposal that the community supports I will put it up for a vote.


At the current time there is sort of a conundrum with the goal being to reward hodling long term, but the incentive periods themselves are now short term, e.g. 3 months and the protocol young.

Also, moving along from the previous thread Rewarding BPRO holders it seems that it is hard to come up with a model that gains acceptance, and has some utility beyond just pushing out BPRO.

Just browsing I seem to see:

  • The “buy and burn” seemed to be on the negative side in the previous discussion.
  • There was also the suggestion for veBPRO, which had some for, some against.

Have other models been considered? How can they relate and have a utility function for B.Protocol?


What is the point of staking? Understandably, it is not in anyone’s interest to have dead capital in the wallet, but will it have a positive impact on protocol?
Since the BPRO token is not currently associated with the value generated by the protocol, pure staking would only result in an accumulation of the governance token and sell-off again remains the only option.
Maybe staking would make sense if the BPRO distribution was not only capital weighted but also partly social weighted? By social activity I mean time-lock staking + governance participation i.e.
If BPRO farming(distribution) is currently the only incentive mechanism then at least we can use it to increase the activity of the DAO community/holders?


I think that staking BPRO and getting rewarded in a stable (possibly LUSD?) is a more likely situation in the long term for this and other reasons. The percentage of dividend you get could also be weighted by attendance in governance votes.

When I think of BPRO staking and v2 I picture the DAO holding a floating basket of staked BPRO the DAO can use for the v3 pool, ETH, and stables. If liquidity is being provided by the DAO it should be time-locked BPRO with fees going to BPRO holders, not from reservoir IMO. A large percentage of the ETH and stables should be farmed. The basket could also enjoy the benefits that the B.AMM provides when it comes to creating a higher leverage position that it farms. It would act as a rebalancing reward pool that adjusts dividend payouts depending on incoming revenue.

Another thought I had was using the same type of idea as UMA KPI options for vesting tokens where you can withdraw some reduced percentage of your original BPRO staked if you want to withdraw early but if you wait until maturation you get your entire deposit back. This would add a lot of complexity though compared to a simple time-lock and generally I find the less complexity the better.

All of this is much easier said than done of course (and rather vague at this point), but I think having some sort of starting vision is important.


As a newcomer to bprotocol, my uneducated perspective was that Bpro would be utilized as part of the liquidation backstop. In some sort of dao Staking Reserve? Locked such as VeCrv in a liquidity contract to be used in such liquidations. Stakers would spilt liquidation revenue over a scheduled period of time to build reserves and dao liquidity.

1 Like

I think this should happen as well eventually. The design of such an implementation is not trivial though considering the incredibly unstable nature of the token. Figuring out how to use it as a backstop in a safe way is important.

We are trying to determine the best way to accomplish something like this currently. What do you think of my post’s approach? Any changes or details you think are important to mention? We have brought up veCRV as a design base before but there are a ton of differences between the two projects goals. Rolling the best of what they have into B.Protocol is definitely on my mind though.

Either way glad to have you around :slight_smile:

1 Like

Hello! After reviewing previous discussions, I agree with this solution.

Assigning a bscore to token holders has many advantages:

  • As mentioned, the architecture for revenue sharing is already in place. It would be relatively easy to implement this compared to other solutions. The most difficult aspect would be getting the ratio right - i.e. balancing the incentivization of token holders vs. protocol users. We don’t want to deincentivize utilization.

  • This mechanism is simple to conceptualize and explain to newcomers, and indeed would be somewhat novel in the defi space.

  • A potential locking/vesting period could be implemented to further incentivize holding - i.e. your bscore accrual rate increases with longer vesting

  • Governance participation could be incentivized by an added accrual rate for active participation. Even without this, the success of the protocol leads to the success of holders by virtue of higher rewards from your bscore, so governance partipation will increase.

Again, this mechanism is already in place. It needs only to be transferred to holders. This to me seems the obvious way forward. I look forward to further discussion!



So you see bScore as a universal score that receives payouts, replacing mScore and cScore?

Agree if we eliminate separate scoring systems for each protocol and roll them into bScore, otherwise I think it could become slightly cumbersome to explain. Not sure how hard it would be to have an overarching score either, considering the rewarding system for each integration will be unique to that projects design.

I like score boosting through staking as a novel approach a lot and you are right that the distribution system is already in place.

Agree that this should align incentives nicely either way. All around I think it is good starting idea as well for a future reward system.

Welcome and glad you are interested in BProtocol :slight_smile:

Interesting, I suppose I’m thinking more a separate score that exists alongside those protocol-specific scores, with a percentage of rewards redirected from cScore/mScore/etc proportional to revenue generated by each. This seems comparitively much simpler than the complexity of an overarching score.

Now that I am thinking about it, it strikes me that this could create a positive feedback loop - users/lp’s would be incentivized to hold the token in order to receive the percentage of revenue that is ‘redirected’ from their c/mScore.


I agree that the architecture would be simpler and generally, simpler is better. I just wonder if it is over compartmentalizing the revenue streams that v1 and v2 could provide to users. IMO we should actually be allowing each to work together to create a compounding pool of value that rewards token holders and users. Maybe it can even act as a v2 liquidator if it gets big enough…

I wonder if staking BPRO could unlock the ability for the DAO to farm a portion of your cut of the Jars before the distribution (would require a redesign of the v1 system I’m pretty sure) and use that as well as the fees from your v2 positions to boost your bScore. If something like this is possible I would think separating everything up would be the wrong direction to go in the long term.

1 Like

This seems reasonable. If I’m understanding correctly, this could alternatively work by assigning a percentage of the jars to the DAO, which then takes the total pool and 1. farms that liquidity and/or 2. deposits that liquidity into v2 as a liquidator. In this case, this ‘pool’ in control of the DAO could then have its own bScore in aggregate, with its rewards distributed to stakers proportionally, eliminating the need for individual bScores. Individual mScores/cScores would function the same, with the only difference being the cut going to the DAO acct.

1 Like

Hello, I am bringing over this post from another user on the Discord, reproducing with some edits and my own thoughts. This is intended to be a starting point for community discussion, eventually leading to a formal proposal:

Implementation of Yield Boost mechanism for BPRO token

The goal of this proposal is to implement a staking/booster mechanism which will provide value accrual to the BPRO token.


This proposal aims to implement a staking/booster mechanism that will allow for real use case and demand for the BPRO token outside of governance. The mechanism will reward protocol users as well as holders/liquidity providers.

Something similar to this idea was originally developed and implemented successfully by another project (vault staking protocol similar to yearn) and the code is readily available and audited (Certik). The proof of concept is the same for this application of token value accrual.

I will list the relevant links/medium articles for that project at the end of this proposal.

The goal of this proposal is to introduce a “booster” mechanism to staking the BPRO token - namely, staking BPRO accelerates and amplifies the potential yield of the staker’s assets deposited in the protocol. Users who currently use Bprotocol will have the option to stake BPRO tokens, which will provide a weighted increase of the proportion of the ‘jar’ that these participants receive, up to a defined limit. This could function within the current score system by having a proportional increase in mScore, cScore, etc… based on the amount of BPRO staked. All proportional to the amount of assets deposited in the protocol.

In addition, LP providers from UNI/SUSHI BPRO pools will be able to stake their LP tokens in a vault which can also be boosted through staking.

By allowing for an increase in weighted stake in the pool this will incentivize all participants to stake their BPRO as it would be to their own benefit and can be seen as “increased leverage” to their yield with no risk and also to be on a “level playing field” with everyone else who does purchase it.

Providing the acceptance of the general outline of this idea, further details will be established on the use of boosters to ensure they are not misused and work as capitally efficient as possible.

For example:

A user has $10m worth of TVL from Maker that he has brought to Bprotocol. The user can now purchase a booster (by staking $500 worth (just example) of BPRO tokens) to get a 5% increase of his mScore. The extra rewards he gains far outweighs the cost of purchasing/staking so he would be inclined to do so.

An equivalent ‘staked BPRO’ could be issued as a stand-in for holders for governance purposes. This means you’ll be able to stake your BPRO tokens to earn rewards from the utilization of the protocol while also being able to vote on the governance proposals.

The details of the specific proportions/limits of rewards increase can be examined further by the team/community as the main focus of this proposal is to introduce a long term token value accrual mechanism to the BPRO token.

Here is a breakdown of the booster mechanism:

  • Each booster level amplifies your bScore by 5%
    -There is a limit of 5 (arbitrary number) booster levels but the cost (amt of BPRO required to stake) will scale to your total value deposited
    - Once BPRO is unstaked, the increase to your bScore from the booster is taken away, proportionally to the amount unstaked.

The original medium post where this idea originated:

GITHUB with open sourced code for booster mechanism:

What I have outlined here is not exactly the booster mechanism used originally, but the concept of using the token to ‘boost’ yields I think fits very well with the score mechanism B Protocol already has in place, so it may be a better fit. Not trivial to implement technically I am sure, as this isn’t a basic fork and would require some custom integration with the bScores, it’s more of a high-level concept similarity.

Hopefully this post can generate some good discussion and progression on how to move ahead with staking.


Bumping the staking discussion thread in the hopes of restarting more serious discussion around a concrete design the community supports.