🧊 [RFC] Karma Governance Contribution Analytics to distribute governance voting power


Mahesh Murthy (Founder of Karma)
mZeroNine (mStable)


This RFC would like to gather feedback around utilizing the governance contribution analytics suite from Karma in order to distribute voting power in the mStable ecosystem away from inactive stakers, and empower active stakers as well as other ecosystem participants that positively contribute to sound governance.

It is intended to achieve this via Karma’s analytics suite which can help identify active contributors across various systems mStable utilizes for governance and use their NFT Badge Minting Service that can be unlocked and subsequently claimed or airdropped to relevant wallets after fulfilling a set of criteria that the mStableDAO can freely define.


Largely inspired by Vitalik’s blog post on coin voting, a fairer and better governance system is still something that eludes most DAOs in the Ethereum ecosystem. It is now suggested to more closely look at the work that Karma has been doing in this space and discuss a potential opportunity to utilize their analytics system in our own governance system to distribute the weight that each MTA token has in the ecosystem towards incentivizing actively participating members in mStable’s governance for both native MTA stakers, as well as users that do not hold a stake in MTA.

Karma tracks and analyzes governance contributions across various systems such as Snapshot, Forum and Discord. Activity from these sources can be weighted differently to fit individual needs to generate contribution scores for active contributors. Based on these scores, governance power can be assigned to contributors to participate in mStable’s governance.

Below are two example scenarios to help understand how this works:

Contributor A stats in the last 6 months

  1. Has voted on 90% of the snapshot proposals
  2. Has created 3 RFCs on the forum
  3. Has created 2 proposals that went to a snapshot vote
  4. Has discussed 10 proposals on the forum
  5. Has posted 200 messages in governance or other relevant channels in Discord

Contributor B stats in the last 6 months

  1. Has voted on 70% of the snapshot proposals
  2. Has created 1 RFCs on the forum
  3. Has discussed 5 proposals on the forum
  4. Has posted 100 messages in governance or other relevant channels in Discord

Weights for each metric:

Snapshot Vote pct: 3

RFC created on forum: 5

Proposals created on forum: 10

Proposals discussed on forum: 1

Messages on Discord: 0.01

Contributor A score = (90 x 3) + (3 x 5) + (2 x 10) + (10 x 1) + (200 x 0.01) = 317

Contributor B score = (70 x 3) + (1 x 5) + (0 x 10) + (5 x 1) + (100 x 0.01) = 221

To reiterate, the above are only examples and community can decide the definition of contributors and their activities.

Issue governance power NFTs to contributors

Based on these scores, contributors can be awarded different tiers of NFTs. Example: Any contributor with a score above 300 is issued an L1 NFT, 200 - 299 is issued L2 NFT and so on.

A new snapshot strategy can be implemented to give different governance voting power to L1, L2, L3 NFT holders.

Further down the line, and if proven to be successful, an integration of this system would also allow for further NFTs to be created and distributed in order to continuously expand and diversify governance rights away from inactive users, and give the power instead to wholesome participants without needlessly punishing passive hodlers of stkMTA.


Given that the Top 5 staking addresses in our governance hold over 50% of the voting power, yet only one of them actively participates in our proposals, it is clear that we require more active contribution in our system without needlessly diluting or punishing active stakers.

With this way of distributing additional governance power to both active stakers and active participants, it is believed to only marginally dilute inactive stakers in the system, which should be seen as a net positive for both participants, as well as mStable governance overall.


  • Take initiative and tackle the issue of coin voting first-hand
  • Distribute governance power to active participants, no matter if they stake MTA or not
  • Set a foundation for further distribution of power to beneficial ecosystem participants


  • Marginally dilute passive and inactive stakers of MTA


We request a grant amount of $10k for setup and development of this project. You can find the milestones and breakdown below.

Milestone 1: $3k - Work with community and core team to flesh out the requirements, implement all necessary features in smart contract, build snapshot strategy and make changes to our backend application.

Milestone 2: $7k - Successfully issue NFTs, assign governance power and see the voting with new governance power in action in Snapshot.

Next Steps

It is suggested that the community comment on this RFC in the coming days, and bearing no significant opposition or change in ideation, we would move ahead with this RFC in the coming weeks and create a formal draft proposal on Github to be used for review.

Meta Governors are encouraged to provide as much feedback as possible until then, so we can create the best possible outcome for mStable and its users.

1 Like

Thanks @mmurthy and @mZeroNine for the work that’s been put into this. Definitely an interesting topic. However, I don’t know if I would be supportive of mStable putting this in place right now. I like the Karma reputation scores for uses such as evaluating potential candidates for signer elections, but am not yet sold on ‘issuing’ governance power in this way. A couple of questions/discussion points though:

  • How would this fit in with our current Quests system? This was mStable’s own effort to reward participation and redistribute governance power via analysis of various off-chain or on-chain metrics. I worry about the complexity of having multiple systems of this nature.

  • How susceptible is this type of solution to being gamed by bots, for example? Long term I think moving towards fully on-chain governance should be the goal and I am a little sceptical of introducing more off-chain and somewhat centralized methods of distributing voting power. Long term, I would be more supportive of a system that used a widely adopted proof-of-personhood protocol along with on-chain metrics to offer voting power in a more decentralized way.

  • Is there a mechanism to stop NFTs being sold, or to stop voting power being re-financialized through a system that could bribe NFT holders to vote a certain way, for example?

Thanks for the questions @cam, your concerns are valid. I will let @mZeroNine who is more familiar with Quests system answer the first question. Below are my thoughts on the other two.

To get around the bot issue, we will mandate that users connect their forum handle and discord to their wallet and make sure that they are active in one of those systems. When I say active, it doesn’t mean someone just posting random messages on forum or discord. They have to perform specific actions like create proposals on the forum, discuss. We can track such activities. Also, we can integrate with something like Gitcoin passport that is solving the sybil issue.

I fully agree the end goal is fully on-chain governance but I can’t imagine forum/discord like systems going away where lot of discussions happen. Do you feel there is no value in looking at someone’s activity in such places?

Could you elaborate on the on-chain metrics part? We already index on-chain activity but that is not sufficient I believe.

We will make the NFTs non transferable. Regarding bribing, can someone not do the same today? They simply have to see who owns a good chunk of tokens and bribe them right?

I want to reiterate, we will take baby steps in introducing this initiative, learn, iterate and then automate it. That means, we can manually audit the top contributors initially, only give small voting power to subset of contributors and try and iterate.

Thanks @mmurthy - I did talk briefly with this to @dimsome and this is indeed possible, but it was definitely going to utilize dev cycles for an actual integration, so we felt that a Snapshot strategy causes less overhead to the core team and can still highlight the use case and serve as a great way to test drive the pilot of this integration with minimal impact to the team.

I don’t have much to add to the above otherwise, as we already ideated on this together beforehand, and I feel you gave all the answers already in regards to Cam’s queries, so thanks a lot for this! :sunglasses:

I’m generally in favor of this, but I’m not sure how I will vote in the end until I see an actual fully fleshed out proposal that can be argued over.

I’m concerned over the lack of documentation available at the Karma site. I want to see contract code, and I want to see dev documentation.

I assume Karma is a business as well, so I want to see any fees and costs associated with using the contracts and/or APIs.

@dimsome if there is anything our team can help with (sending PRs) to integrate with your Quests system, we are happy to do it.

Here is the contract code, it’s fairly straightforward ERC721 GitHub - show-karma/smart-contracts: Smart Contracts. The scoring calculation is open source and can be seen here GitHub - show-karma/reputation-scores: Reputation score calculation logic used for various DAOs in Karma. We haven’t implemented the Snapshot strategy yet, we will share it as soon as we built that. We do have API here but there is no integration work involved for this project that utilizes our API. However, someone could pull raw data from API and validate everything for themselves. I am happy to provide any other information.

Sure. I just updated the proposal with cost breakdown.

Thanks, please let me know which parts are not clear and I will update the proposal or answer questions here.

1 Like

Excellent, thank you for providing the links to that stuff! I wish it were linked on the main Karma site.

When I was speaking about a fully-fleshed out proposal, I mean one where the tentative weights and contributing factors for the NFTs have been made, so that we can try to come to a consensus about them.

I’m sure at that time, the elephant in the room about the purpose of MTA as a governance token will come into sharp focus.

Since this discussion won’t reach that point because it takes place after this RFC, all I can say is that this is ‘interesting, but I need the specifics.’

1 Like