Tokenized Governance?

B.Protocol went live almost 6 months ago, and currently has over 300 users and TVL of over $100m. The control over the protocol was handed to users from day 1, with a 6 months timelock in order to give time for the community to be established. This timelock ends on April 26th.

During this 6 month period, users accumulated non-transferable voting rights (score), and we made it clear the score is not a token.
It was always our intention to have non tokenized governance, based on the actual usage of the platform.

However, it is not our decision to make.

Handing over 100% of the genesis voting power to the users excludes the team from the ability to vote. Over the recent month a discussion has been carried out on B.Protocol’s Discord server, and it became apparent that some community members might prefer having a tokenized governance (post the April 26th Genesis vote).

Given the Genesis vote is only a few weeks away, we believe that now is the time for the community to reach a decision about it.
We welcome community members to convey their opinions in this thread, and in parallel an off-chain Snapshot vote (according to user Score) will be used to weigh the community wishes.

About the vote

How to vote

EDIT: @dr.sushi formalized the question and setup a proposal for the community to vote on.
Maker users can vote here.
Compound users can vote here.

In the voting page, you can vote by:

  1. Connect your MetaMask with the same account you use for B.Protocol (where your mScore/cScore is kept).
  2. Choose your vote (Yes/No).
  3. Sign the vote on MetaMask - the signature is free and has no fees or gas costs!

The vote will start at April 8th, 3 AM UTC, and will last for 1 week

What is the meaning of the vote outcome?

As we described in an earlier post, towards the genesis vote, off-chain votes will be used to signal the community opinion. However there is no way to guarantee that the on-chain vote will reflect it.
Nevertheless, it will lay the ground for further and more detailed discussion on the governance structure post the Genesis vote.


Can anyone post a proposal to vote?


currently yes. if there will be too much spam, the community will have to decide on filtering mechanisms (e.g, minimum score for the user who make the proposal).

feel free to raise proposals at (maker) and (compound), and the community still never voted, it would make sense to make the voting period at least 1 week.
if you have any technical questions, feel free to also ask in our discord.

Can we make a proposal to not only tokenized the score as the governance token but also do an airdrop to reward the early supporters of B protocol and other defi platforms like maker, comp, aave, uni and sushi, etc, in order to do a marketing and get more new users?

Technically everything is possible.
I think for good order the community should first decide on the basic question, e.g., tokenized vs non-tokenized governance.

If you believe the answer should be affected by whether or not there should be an airdrop, then maybe it should be part of the question. But on the face of it, it sounds like something that should be discussed only after the basic question was resolved.

1 Like

I think governance should be tokenized and fungible, or else the incentives of the governors may fall out of wack. DxDao had this problem where tons of people accumulated their non-fungible, non-tokenized voting rights, but didn’t participate at all. And they had a separate economic token entirely. Afaik, they’ve been making moves to consolidate the two into one. So tokenized governance allows the market to more effeciently allocate voting power. It’s an age-old truth and it applies here: people vote with their wallets. The best manifestation of this yet is tokenized governance tokens - the real beauty being that the vote doesn’t just go towards affecting outcomes that help your bottom line, but that those successful outcomes give the vote itself value to help your bottom line.

Handing over 100% of the genesis voting power to the users excludes the team from the ability to vote.

Personally, I’d prefer that the founding team keep or be gifted some small amount of genesis voting power (and thus tokens). They have a lot at stake here, obviously, but more importantly we have a lot at stake in them. I’d welcome anything that incentivizes their continued involvement in this project.


Please no. That doesn’t often seem to work. And it gives whales an opening to buy huge amounts of voting power from dumpers. The marketing is great, but I think there are other ways to get those users interested.

1 Like

I welcome tokenized governance because I believe it attracts many DeFiers who get used to it.

By the way, airdrop could be a short-term marketing. But it’s too early. If B. protocol’s profitability is not known and is not sure, many people will dump immediately after the airdrop.


I think tokenization would help to bring more attention to b.protocol. I believe it will also bring value to the current Score holders as it will provide options to earn fees and interest on the governance token while still benefiting from Jar distributions. Score holders would also have the option to borrow against the token.

As a token, it would offer investors cash distributions from the protocol today—something no other token is doing that is associated with a project of comparable TVL (to my knowledge). Many AAVE and COMP investors are anticipating distributions from their respective protocols down the line, but potential fee structures would have to be voted-in. B.protocol tokens could generate cash-flow from inception, offering a unique value proposition. This could create buzz and would be a good excuse to do podcasts, shows, etc.

If the community wants particular fundamental decisions to be made by only those who use the program, such decisions can be established and made unchangeable by future governance. For example, the distribution ratio could be set in stone, if deemed optimal in perpetuity before the tokens are minted. It will be important to carefully assess the latitude afforded to future token holders to prevent deleterious changes and stave off potential negative effects associated with wales and flash loans.

Mechanisms and incentives will be critical in the success of the tokenization process. Requiring token holders to stake their tokens and vest for a certain period in order to receive liquidation proceeds is one idea. Maybe distribute proceeds based on how long the tokens have been staked. This way, users have somewhere to stash their tokens for utility, which is deflationary to the liquid supply on chain, and would foster price appreciation over time. A long vesting period would strongly discourage holders from un-staking, seeing that they’d have to start the vesting process all over again. If only b.protocol tokens staked within the protocol can earn liquidation proceeds, the cash-flow-per-token would be higher for this utility (not all tokens would be staked; some would be in liquidity pools, wallets, etc.), increasing token value, at least from the perspective of many.


Tokenization is best for the community, but the token mechanisms/incentives will be critical to the long term success of b.protocol.


1 Like

Quick questions:
Can the tokenized Governance and the mscore/cscore be 2 different tokens?

I favour the concept of mscore/cscore as a " credit score " and then creating a new governance token.

This would allow to create products/services built on top of the “credit score” token and then having the Governance token to control and incentivizing the utility of the protocol.

Technically it can be possible.
It was also proposed in the past by a member of the community that the jar will be distributed by a non transferable score, while the governance will be according to a token.
These things are technically possible.


Separating the score and the Governance would prevent conflict of interests and price speculation while allowing true DAO control of the protocol.

A non transferable credit score token creates a new product that opens does for multiple DeFi services integration that might benefit from a “credit score” both internal or 3rd party.

The separation of the Governance and “score” adds more flexibility, value and utility to b.Protocol.

My 2 gwei… Hope it helps.

Lotta good points here! But on the topic of AAVE/COMP/YFI not distributing cashflow, I think it has more to do with reinvesting earnings back into development.

Agree that governance token should exist :]

Founding Team should receive governance tokens for sure. They cannot be excluded.

This protocol has a lot of potential, but needs more awareness and expansion. Some ideas for future consideration:

  • Include more Assets from MakerDAO to liquidate (right now it is only ETH)
  • Create an Common Pool for participants to take loans out: it would allow to avoid liquidation as it could be managed in a more dynamic automated way. This would be accomplished by creating a “Super Account” that manages Collateral Ratio more dynamically. Instead of users depositing into Maker, they would deposit into this account, which could be held close to the limit and therefore be more capital efficient
    Participation in it would require a fee. Why would you participate? you avoid liquidations and get more capital efficiency.

My concern with making the score indefinitely non transferable is wallet compromise. What if a score holder’s keys are made public and they wish to dispose of a wallet for privacy/security concerns? What if a seed phrase is compromised?

I like the idea of allocating tokens for past and future development.

Also, the score can be made transferrable while still separating it from a governance token.

1 Like

Yes, it would be a pity to exclude @yaron et. al. But first, is it certain they don’t already get some score as early users of the protocol? And if they do, can additional allocation create unhealthy distribution of voting power?

Once user funds are pooled together, it makes the safety of the funds depends on the strength of the backstop. This demonstrates nicely the need for a strong backstop, and that a strong backstop could give rise to many interesting applications.
I created a topic to discuss potential applications of DeFi backstop primitive, and i think it would be better to discuss it there.


Thanks, I wrote down my thoughts over there. It would be great to consider this in a roadmap, I think there is huge potential.