Context
Currently, governance voting on Massa uses MASOG tokens, automatically assigned to the staking address based on the number of rolls held. This system creates a major security concern: to vote, stakers must use the private key of their staking address within a web environment (browser, wallet, etc.), increasing the risk of hacking or malicious smart contract interactions.
Proposal
I suggest implementing a vote power delegation mechanism in the MASOG smart contract.
Each staking address should be able to designate one unique delegate address authorized to vote on its behalf.
This delegate will be granted the full voting power associated with the MASOG held by the staking address.
If the delegate key is compromised or lost, the staker should be able to update the delegate address at any time, without losing their voting rights.
Benefits
Enhanced security: the node’s private key never leaves the server, reducing exposure to threats.
Flexibility: stakers can easily recover from compromise by changing the delegation.
Simplicity: limiting to one delegate per staker simplifies the governance model.
Implementation
This requires an update of the MASOG smart contract, adding a delegation logic without making MASOG tokens transferable. The goal is to enable indirect voting via a secure and controlled mechanism.
This is a very good suggestion. I have mentioned similar suggestions before. Why do you make such a suggestion? The security you mentioned is indeed a very important aspect. I want to say that on the other hand, if $MAS holders do not stake nodes, they cannot own MASSAOG, which means they have no voting rights. A careful analysis will reveal that this is a fallacy or an endless loop, a very serious problem. Specifically: To stake nodes, you need to run a server, which is difficult for ordinary users, and even for some technicians, it is not a simple matter, because at least you need to have your own VPS, which usually requires extra money to purchase and maintain. And it is precisely these users who are the larger target group of MASSA, the real blockchain users, rather than some minority pledgers. Furthermore, if ordinary users do not have voting rights, then they may not be more willing to use MASSA Chain.
Vote Power Delegation for MASOG is a feasible technical solution verified by other Web3 projects, but it is not a perfect technical solution. The core is that large holders or pledgers also have an equal share of voting rights, while small users have only a small number of voting rights.
This actually restricts decentralization and further weakens the enthusiasm of small users to vote, that is, voting becomes a direct decision made by large pledgers in fact.
Thank you very much for your response — it’s thoughtful and raises important concerns about the current governance model.
You’ve highlighted two key issues:
The lack of accessibility to governance for non-staking users.
The centralization of voting power among large stakers.
I completely agree with your analysis. Today, only node operators can earn MASOG and thus vote, which significantly limits inclusiveness. And even with delegation, voting power remains proportional to rolls, creating potential imbalances in governance.
That said, I believe your response is expanding the discussion beyond the core purpose of this proposal, which is more focused and specific.
The current proposal aims to solve a critical operational security issue: stakers are forced to expose their node’s private key in order to vote. This is a serious risk. Delegation offers a concrete and immediate technical solution to secure voting, without altering the power distribution model.
For now, this thread focuses on a security enhancement for current stakers, which is a foundational step we can take right away.
In case you don’t want to use the web interface, you can make calls from massa-client through your node.
func “vote”:
proposal_id - u64
value - i32
To simplify this, I suggest there will not be any problems for devs to add a new command to massa-client, so validators will not need to import their validator secret key to any of the web wallets to vote.
That’s a very good idea, thanks for suggesting it!
Adding a voting command to massa-client would be a simpler and faster solution to implement compared to smart contract-based delegation. It would already help reduce the risks of using a web wallet by allowing voting in a more secure environment.
I’d also suggest adding the ability to create proposals directly from the CLI — that way, the entire governance flow could be handled from massa-client.
That said, one question comes to mind: could this add too much weight to massa-client in the long run if we keep stacking governance features into it? Maybe at some point, a separate tool like massa-governance-cli could be considered if the governance layer keeps growing.
I agree this can help user experience and security when voting many times. The downside is the following: it gets simpler and safer to buy voting power delegations from others, which is not a good thing in general.
Therefore I would recommend to include safety mechanisms like the following (but I’m not sure this is enough):
one address can receive one voting delegation maximum (or a max MASOG supply % like 1% in total),
restrict delegate addresses’ vote timing so that they vote up to a day or 2 before the deadline, to give time to addresses who delegated to see the vote and revoke the delegation before the deadline in case the delegate address has been hacked or voted differently than expected.