First step towards Decentralized Governance

Massa Improvement Proposals Tools
1

Introduction:

This proposal by Massa Foundation introduces a possible first version of decentralized governance on Massa, with the aim to allow more collective participation in decisions impacting the Massa ecosystem.

We suggest tackling two easier topics first: blockchain parameter updates, and ecosystem grants. The described governance system would allow the community to quickly setup a vote on matters such as the one discussed here regarding block reward, and to be more active in shaping the future of the Massa ecosystem through the Grant Program.

More complex topics would follow later, after testing this first version for some time. These could include arbitrary changes to the core codebase and algorithms, arbitrary changes to the ledger, direct funding of community initiatives with no Foundation contracts, etc.

We welcome feedback on the following, while on our side we study its legal implications in detail. The main new concept is a soulbound governance token used to vote, and then there are specific details around proposals and votes, and a smart contract with a Deweb frontend.

Scope:

  • Parameter update proposal: Change a set of blockchain parameters, listed in the code here:

    • Examples: ROLL_PRICE, BLOCK_REWARD, LEDGER_COST_PER_BYTE, THREAD_COUNT, T0, MAX_OPERATIONS_PER_BLOCK, ROLL_COUNT_TO_SLASH_ON_DENUNCIATION
    • If the proposal passes, Massa Labs (or any tech team) can publish a new version of the node with the parameter update, together with the update procedure/timeline.

  • Grant application: Give a grant or bounty to a project for the Massa Ecosystem

    • Example: Team A wants to build a Full On-Chain Coffee Machine. They apply for a grant of 100k MAS in total, with two milestones of 50k MAS: smart contract + DeWeb frontend deployed, and 1 million coffees made.
    • Example: Team B has built a Full On-Chain App with 1,000 active wallets so far, they apply for a bounty.
    • If the proposal has good support from the community (based on votes), the Massa Foundation will do basic sanity checks (KYC of the team, check relevance of amount based on previous grants and current budget), and if all is fine sign a grant contract with the team.

Massa Governance token:

  • We create a new MAssa SOulbound Governance token, called MASOG token.
  • MASOG is earned by stakers at each cycle based on their number of rolls and with a bonus for the duration of their staking. The exact formula we propose is the following:
    • Let’s define the function nbRolls(address, cycle) giving the number of rolls of the given address at the given cycle.
    • Let’s define the function avgRolls(address, cycle)=average(nbRolls(address, c) for c in [cycle-1000: cycle-1])
    • Then we design the function mintMASOG(address, cycle) giving the number of MASOG tokens minted to the given address at the given cycle as mintMASOG(address, cycle) =
      • 0 if nbRolls(address, cycle) < avgRolls(address, cycle)
      • avgRolls(address, cycle) * (1+min(oginess(address, cycle)/15000, 2))/1289 otherwise
    • Where the oginess function is oginess(address, cycle)=max n / #(mintMASOG(address, i)>0 for i in [cycle-n:cycle-1]) > n-10
      (intuitively, from how many cycles have I been staking well, missing at most 10 cycles)

Procedure/Lifecycle of a parameter update proposal:

  • The candidate creates a forum post on https://forum.massa.community/ in a “parameter update proposal” category, detailing the proposal and reasoning/background (following a template)
  • The candidate connects to governance.massa, submits the proposal:
    • Link to the forum post
    • Exact parameter changes (set of parameter names + new values), example: {ROLL_PRICE: Amount = Amount::const_init(80, 0), T0: MassaTime = MassaTime::from_millis(15000)}
    • To prevent spam, the submission costs 1,000 MAS which are burnt on the smart contract. Submitters must hold a minimum of 1,000 MASOG.
  • The governance contract triggers a 3-weeks discussion period, which can happen on any place but preferentially on the forum post. This Discussion status is shown on the governance.massa frontend.
  • Using the autonomous smart contract feature, the governance contract triggers a voting period of 1 week. During this period, any MASOG holder can vote YES/NO/BLANK on governance.massa. A (TEXT) reason can be provided optionally. If at least 50% of the MASOG supply has voted YES, then the proposal has passed.
  • The governance.massa frontend shows the result of the vote.
  • Several proposals can be processed in parallel, they are all tracked on governance.massa.

Procedure/Lifecycle of a Grant application: similar to the previous one, except:

  • The candidate creates a forum post on https://forum.massa.community/ in a “grant application” category
  • The candidate connects to governance.massa, submits the application:
    • Link to the forum post
    • Summary of the application
    • Entity and Massa address which would receive the grant
    • Expected grant amount (MAS)
    • To prevent spam, the submission costs 1,000 MAS which are burnt on the smart contract.
  • The governance contract triggers a 1-week discussion period
  • Using the autonomous smart contract feature, the governance contract triggers a voting period of 1 week. During this period, any MASOG holder can vote SUPPORT/NOSUPPORT/BLANK on governance.massa, except the applicant itself who cannot vote for its own application. A (TEXT) reason can be provided optionally.
  • If there are many applications, maybe we should batch their timing so that voters can connect once per month and vote on all at the same moment.

Constants:

Here is a list of constants of the smart contract which we can tweak now in this discussion:

  • DISCUSSION_PERIOD=21 (days)
  • DISCUSSION_PERIOD_GRANTS=7 (days)
  • VOTING_PERIOD=7 (days)
  • SUBMISSION_COST=1000 (MAS)
  • SUBMISSION_MASOG_MIN_HOLD=1000 (MASOG)
  • AVG_ROLLS_HISTORY=1000 (cycles)
  • OGINESS_MAX_POWER=2 (cycles)
  • OGINESS_MAX_TIME=15000 (cycles)
  • OGINESS_MAX_MISSES=10 (cycles)
  • MASOG_FACTOR=1289 (number of cycles per month, so that 1 roll gives approx 1 MASOG per month)

Note on quorums:

The two voting topics have different purposes and therefore different proposed voting mechanisms. For changing blockchain parameters, which can have a very big impact on all holders, this proposal requires a ratio of 50% of the MASOG supply voting YES, which also implies a 50% quorum. That means nothing will pass if we don’t have 50% of the MASOG supply voting and voting YES. We should study if this is not too hard. For instance, what happens if too many keys are lost ? The increasing supply of MASOG tokens should minimize this problem in the first years at least.

A possible improvement could be the following: not counting the MASOG supply which did not vote in the last 12 months in the 50% ratio denominator (many more sophisticated mechanisms can be imagined here with updating quorums but maybe we should keep this simple).

For grant support, no quorum is really required in the code as the result is not automatic, it is taken into account by the foundation for the grant decision, so the number of votes can also be taken into account at the same time, and we don’t expect as much participation as for blockchain parameter changes. For instance, a

  • 0.001% support may be discarded
  • 3% support / 0.5% nosupport is already a strong support signal
9 Likes
2

I like the proposal. Few clarifications:

  1. MASOG aren’t burnt when an holder vote. Meaning that voting power increase overtime. The 50% ratio of all MASOG is problematic.

Proposed change: Implementation of a cap (Max MASOG) and decay function that decrease MASOG over time for nodes that haven’t been actively voting over a period of time.

Rational: To prevent centralisation of voting power and promote new nodes to participate.

  1. Increase the Average Rolls History Period:

Current Setting: AVG_ROLLS_HISTORY = 1000 cycles (~0.77 months).

Proposed Change: Increase AVG_ROLLS_HISTORY to 6,000 cycles (~4.65 months).

Rationale: A longer averaging period makes it harder for new large stakeholders to quickly accumulate significant voting power. It emphasizes long-term commitment over sudden, substantial investments.

2 Likes
3

Good ideas and it’s a great step towards more decentralized governance. Some things that come to mind are:

  1. Are MASOG tokens transferable, and thus tradeable? It’s important to consider the implications in both cases

  2. Maybe the issuance of MASOG tokens per cycle/block should be increasing, so historically earned MASOG becomes less valuable over time. E.g. the importance of historical work (staking) is less important now than it was in the past. This will also help solving the ‘lost keys’ argument

  3. Perhaps MASOG tokens should be earnable, in small portions, in other ways besides only running nodes. For example as extra rewards to liquidity providers on Dusa or a future lending platform. These people also have skin in the game and should, perhaps, have a say about the future of the platform

Curious to hear your thoughts

1 Like
4

I’m not sure I understand the concern here. Voting units increase for everyone so relative voting power stays similar, and 50% or MASOG supply stays meaningful.

Do we want more to “promote new nodes to participate” or to make “it harder for new large stakeholders to quickly accumulate significant voting power” ?

5

In this proposal they are soulbound, so not transferable/tradeable, to avoid “flash loans” on votes by external whales basically.

That’s a great point, then at which speed would we do it ?

We’re giving Massa incentives (grants, bounties or airdrops) to these important projects/users, which can in turn be staked and yield MASOG tokens amoung other things, so I guess this goal is already achieved in another way ?
Also I don’t really like the idea of centrally controlling a voting tokens’ bag somewhere.

2 Likes
6

The second, make it harder for huge nodes to get most voting power.

7

Concerning the point #1, the intent is to encourage nodes that are participating in voting and diminished the voting power of those not participating over time. Perhaps your recommendation already covers that which in that case, all good.

8

Good point, maybe this would increase participation overall. And if we reduce the denominator by the same amount, it also solves the quorum/lost keys problem (50% of the MASOG supply able to vote instead of 50% of the MASOG supply).

9

How to get stakers data on-chain ?
Stakers data is not available on-chain yet. We have two alternatives:

  • Add an opcode to get the list of stakers/rolls of the current cycle.
  • Build an oracle to bring this data to a smart contract (with some history)

@damir how difficult is the first solution ? Otherwise we can do the second solution.

How to update MASOG supply ?
With an autonomous smart contract obviously! Getting the data from the opcode or the oracle.