A Proposal for SKALE Network's On-Chain Governance System

General
1

A Proposal for SKALE Network’s On-Chain Governance System

As the SKALE Network continues to grow, it is important to establish a transparent and decentralized governance system that allows token holders to have a say in the network’s technical development and future direction.

There were two key driving factors behind the strategy of this voting structure:

1 - A focus on simplicity with the goal of remaining flexible. The most prominent feedback received was to keep it as simple as possible at the start while leaving room for growth and greater specification as the network naturally evolves

2 - The second piece of key feedback received was to NOT reinvent the wheel. We selected a setup that is proven to work and modeled it to fit the specifics of the SKALE Network. DAOs and governance will continue to be innovated on and the flexible structure of this proposal will enable the network to adopt and change over time to embrace more beneficial techniques.

The following proposal outlines a voting system for the SKALE Network through on-chain governance, with an initial focus on adjusting economic parameters of the network.

Scope

The initial scope for SKL on-chain voting will be focused solely on technical components that impact economic parameters of the SKALE network. Examples include but are not limited to:

  • SKALE Chain Pricing
  • Network Inflation
  • Slashing Conditions & Penalties
  • Minimum Stake Requirement
  • Staking periods and Variable Returns for Variable Periods
  • Validator Incentivization

The primary goal is to get an on-chain voting system up and running while simplifying execution and minimizing risk and complexity.

Voting at this stage will NOT encompass the off-chain items listed below, but can be expanded in the future to cover a greater scope.

Voting will NOT have any direct control over governance of any one chain in the SKALE ecosystem. They will be independently governed based on their own DAO processes and rules.

While this voting structure focuses solely on technical governance of the network as it relates to economic factors it does not stop others from creating separate voting structures, DAOs, and pools of tokens that can be created to facilitate different voting and community goals.

Separate community DAOs can be created with their own voting structures that would govern non-technical project decisions including but not limited to:

  • Grants
  • Marketing decisions
  • Business development
  • Branding
  • Roadmap
  • Administration of individual SKALE Chains - ie Calypso/Europa

The voting structure listed below is a proposal based on aggregated feedback from validator operators, developers, core developers, open source contributors, delegators, community members, and other constituents. In order to ratify the voting structure, the first vote will be held to approve the voting mechanics and approval process. If the minimum thresholds are not met with a passing vote, then a new structure will be proposed and voted on.

Voting Process and Rules

  • All proposals will be hosted on the SKALE Forum to collect feedback from the community (https://forum.skale.network)

  • Token holders can propose or vote on proposals through their wallets using the approved voting tool, Snapshot.

  • The voting will take place on the Ethereum Mainnet.

  • As a measure to protect against attacks and for incentive alignment, only staked tokens are qualified to vote.

  • Proposals will be open for voting for a period of 14 days.

  • In order for a vote to be qualified it must meet a minimum threshold of voting power within the network. The quorum requirements will be set at 33.334% of staked tokens in the network.

  • Proposals will be approved if they receive greater than 50% of YES votes tokens.

  • These mechanics can be changed via future voting proposals.

  • At the time of this writing based on total supply and staked metrics 939,187,538.8 votes are required for a quorum and 469,593,769.4 would be required to approve a vote

  • Validators will be enabled to vote on behalf of delegates who do not utilize their votes.

  • The weight of a vote will be proportional to the amount of SKL tokens staked.

  • Voting rules and mechanics can be modified through governance proposals.

  • Voters can vote YES, NO, ABSTAIN

Summarize Goals:

  • Empower the SKALE community to have a say in the network’s economic parameters and their impact on the network’s security, resilience, and user experience.
  • Encourage token holders to participate in the governance process.
  • Foster a decentralized and transparent decision-making process.
  • Ensure that the network’s economic parameters align with the interests of its stakeholders.

Conclusion:

The proposed voting system for the SKALE Network’s on-chain governance is designed to ensure that all key stakeholders in the SKALE community have a voice in the network’s economic parameters and their impact on the network’s stability, security, and user experience. By staking their SKL tokens, token holders can cast their votes and play a role in shaping the network’s future. We believe this will help to ensure that the SKALE Network remains aligned with the interests of its stakeholders and continues to meet the needs of its users

About me and my process:

Most of you in the community know me as the Lead Community Developer for the Calypso NFT Hub. I also spend a considerable amount of time helping projects in the SKALE ecosystem, building open source tools for the ecosystem, speaking about SKALE at events, and holding developer workshops as an independent SKALE developer. In addition, I consult and work with a number of entities in the SKALEverse on a contract basis including some key projects within SKALE and the core team. I was asked by a number of stakeholders within the SKALE ecosystem to take the lead on creating a proposal for on-chain voting. I started by researching governance mechanisms for many Proof-of-Stake networks. I collated the best practices as well as the common mistakes and errors. I also looked at non-proof of stake network governance protocols in DeFi and L2 products. I then spoke with many different constituents within the SKALE community including validators, delegators, builders, core team members, dApp devs, and community members. The process has taken many turns with the vast amount of feedback and learnings. In the end, the proposal reflects what most have considered a “great starting point” for governance because it focuses on simplicity, flexibility, and growth of governance. It doesn’t pigeon hole the project in any way and allows for proper and urgently needed governance to come into fruition. I hope to see this proposal move to a vote in the very near future. Please leave your feedback in the comments and thank you for your support.

– TheGreatAxios

6 Likes
2

This is a great first step into governance. I like how it provides a safe way to start providing community governance, and a path to grow. Well done!

2 Likes
3

This is cool, and as @tobowers mentioned this a great first step. Great work and looking forward to seeing this grow.

3 Likes
4

Nice work, Axios!!

In general, I am very much in favor of getting started as soon as possible and in the most simple and flexible way possible. I think this plan is a great first step for voting. I also like that you got input and contribution from many different people and stakeholders.

I have a few pieces of feedback:

1 - * Proposals will be open for voting for a period of 14 days. – I think we should consider moving this down to 7 days. Many newer voting protocols have 7 rather than 14 days. This would give us more agility while still having enough time to get votes. Do others agree with me?

2 - In order for a vote to be qualified it must meet a minimum threshold of voting power within the network. The quorum requirements will be set at 33.334% of staked tokens in the network. – I think this is a good starting point, but I think it should move up over time to make successful votes require a greater overall percentage of staked tokens in order to be approved. Or a vote would require 2/3 rather than 50% majority to be approved. The danger in the short-term of having the number too high is that turnout is traditionally low for onchain voting. We don’t want a vote system that can’t approve anything. Obviously, in the long term if it is too low there is danger for votes to be approved that don’t reflect enough of the majority. In general, I’m personally good with this number now, but in the long run think we should look at it and use onchain voting to adjust the thresholds as we learn as a community.

In summary, I think this is great. I’d love to see 14 turn to 7, but other than that I’m personally good to go. We need to get voting going ASAP!!! Let’s do this!!!

2 Likes
5

Great proposal @TheGreatAxios!

SKALE Network’s On-Chain Governance System holds tremendous potential for empowering the community and ensuring decentralized decision-making.

Looking forward to seeing how this proposal evolves and contributes to the growth and resilience of the network. Kudos for fostering transparency and inclusivity!

1 Like
6

Yep, great start and thanks for all the work you’ve put into this.
I agree with @jackoholleran’s two points about vote duration and threshold. 7 days is probably enough to start with. The “start small and iterate” approach should mean there’s flexibility to change things as required. One of the first votes could be to raise the % threshold if all goes well.

7
1 Like
8

It’s great to finally see a first step in SKALE Governance, nice job @TheGreatAxios

One question I have is on

  • Validators will be enabled to vote on behalf of delegates who do not utilize their votes.

Does this mean validators would each default to their own vote, and if delegators to a validator abstain from voting, then their votes will default to the validator? I think it’s an important point to clarify the mechanics here.

If not, validators could potentially change their voting preference once it is realized they have more voting power to wield.

1 Like
9

Chadwick - I agree that more detail needs to be added here. Let’s ping Axios and have him push more details into the proposal on the process and defense mechanisms against malicious attack vectors for unused votes.

1 Like
10

I really like that only staked token vote, and that if delegators do not vote, validators vote for them.

I think starting fast and simple makes sense, and initially it is easier to do it on mainnet because tokens are staked there, but once we start voting we need to move to a SKALE chain asap.

With SKALE Connect released in 2.1.1 and already available on SKALE mainnet it is easy to implement without having to move tokens.

1 Like
11

First off, props, props, props- to all the time and effort that went into this proposal! Very excited to see governance going live on SKALE.

After reading through the proposal several times, these points were the few things that came to mind as points to mention:

  1. A short “Defined terms and definitions”, as a section or in-line embedded, would be a nice to have for clarity or accessibility

  2. Would like to clarify the use of “vote” in bullet point (BP) 6, as ‘vote’ is also used for token holders at BP-2, and I believe BP-6 is referencing the quorum for a Proposal’s voting outcome.

    • Perhaps with either ‘proposal vote’ or ‘Vote’?

  3. I second Chadwick’s post about clarity around Validator voting inheritance. My first thought for un-utilized voting power on behalf of a delegators was to figure out either A or B or C:

A. Is it summed to the Validators staked total increasing their vote’s weight?
B. Is it a proxy vote cast on behalf of the delegator, equal to the weight of the aforementioned delegator’s stake?
C. Other not considered by me atm?

  1. I think clarification of initialization/termination of a voting period window so it’s clearly defined for voters

Just want to re-iterate, overall solid proposal. Looking forward to voting soon :slight_smile:

12

Should the community allow dapps on SKALE to vote with their tokens too?

if there is a dapp on SKALE, they could vote with their TVL?

13

Thank you!

#1 - I agree that that should be sufficient at the start. Would love to see others jump in and yay/nay as well just to get a better idea, but I think the agility as you say would be well worth it to make it easier for all parties involved on a vote to stay more engaged

#2 - I agree, down the road as the collective network becomes more comfortable with the process then this can be amended with a vote.

Thanks for your support!

14

Thanks for your feedback here. After further review and discussion with various parties, I apologize for the lack of clarity here. I’ll be providing a more detailed writeup of how this could work and follow up with you and others who share this feedback to work towards a group decision that stays in line with the simplicity of this initial proposal.

15

Hey Stan!

Thank you for your great feedback.
I am in the process of diving deeper into how we can enable the validator voting in a secure manner with the planned tools while still making sure that it does not cause unbalanced voting or negate access to voting for delegators.

I will provide more detail back here in the forum for everyone once additional exploration on this topic is complete.

As for on-chain SKALE Chain voting, I think that is something that as a collective can be explored and planned out.

Thanks for the feedback!

16

Replied here as well: Discord

On this I don’t feel at this time it is something that fits the ethos of this particular proposal. That is something that could make sense at governance on the individual chain level in the near future for a chain/protocol such as the Europa Hub.

17

Thanks for your detailed feedback!

#1 - Agreed
#2 - Good catch here, the first point is used correctly. The second is being used a touch incorrectly and should be a proposal only
#3 - Those are all good points and I will work through them fully before getting back to everyone here in the forum. At this time, I believe I am leaning more toward Option B, however I want to make sure more information is provided for this particular topic related to what can actually be done and what the process would look like for a solution along these lines.

Thanks for your support!

18

So we probably should think about the source code for this and how the community should run it.

19

I am hearing a proposal for source code will be published soon. @axios and dev community will be posting. Let’s get that going and get governance off the ground!!!

20

Hey gang. Haven’t had a lot of time to go through the governance proposal, but on my first read I have a question — does it make sense to have a dual-share voting structure here? That way Skale owners are also incentivized (and stakers would be MORE incentivized).

This would resemble A and B share structures in normal corporations and would reward ALL participants in the Skale ownership community, and would further reward those choosing to stake. It would also allow token holders to “defend” against decisions made by stakers and overall add to the democratization of Skale (one token gives you a voice and vote in our community).

I’m happy to come back with a more detailed vision for how we could incorporate this into the model if anyone would care to include this idea. Ultimately I think it’s unfair to deny everyone a right to a seat at the table if you own a token. Just my two cents. Thanks.