TL;DR: In the coming weeks, we’ll be exploring Snapshot for governance in Smooth to vote on penalizing withdrawal addresses linked to validators not using MEV, with voting based on a weighted whitelist tied to rewards contributed to the pool.
Overview
As we work to ensure the Smooth ecosystem remains healthy and fair, one challenge we face is how to address validator misbehavior, particularly from those not utilizing MEV. While we’re developing a more comprehensive governance framework through Smooth DAO (learn more about the DAO proposal here), we need a simple, effective solution to tackle this issue as soon as possible.
We’re proposing to use Snapshot, a decentralized voting platform as a temporary governance tool that will allow the community to weigh in on penalties for misbehaving validators.
How Snapshot Voting Works
Snapshot is widely used in many DAOs, and we think it could be an effective governance tool for Smooth as well. You can read more about it here.
We’ll create a new space called “Smooth”, where (for now) only Dappnode can create proposals. These proposals will specifically address whether to penalize withdrawal addresses tied to validators that are not using MEV.
Key Points:
-
Voting Eligibility: Participation will be restricted to a weighted whitelist of withdrawal addresses registered in Smooth.
-
Weighted Voting: Voting power is determined by the total accumulated rewards of the validators linked to each address. This approach ensures that long-term Smooth participants have greater influence over the governance process.
On-Chain Results
The voting outcomes will be recorded on-chain using Snapshot’s “osnap” module. This enables Smooth’s Oracle to act on these results and penalize the validators accordingly.
Next Steps
There are still several details to figure out. For example:
- Voting periods: How long should each voting period (proposal) last?
- Minimum quorum: Should there be a minimum number of votes required for a proposal to pass?
- Penalties: What should the penalties look like? Would it be better to start by warning users, perhaps by issuing “yellow/red cards” to all their validators?
To refine these aspects, we plan to run test proposals on the Holesky testnet before deploying the system on mainnet.
We need Your Feedback
What do you think of this approach? Are there elements we should reconsider or improve? Your input will help shape how we move forward with governance in Smooth.