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

General
21

Hey @its_witjak

Thank you for your feedback. I would recommend going through the proposal first!.

Also, while all suggestions are welcome and will be entertained (as this is a community wide decision), I would like to point out a couple of things:

The proposal states that voting power should only come from staked tokens. This is important for two reasons.

  1. Those who stake are co-owners of the SKALE Network and are helping to secure and support it in it’s growth.

  2. Being able to vote without staking opens up the door for attacks through mechanisms like flash-loans which can negatively impact the network as a whole.

Additionally, this is a common setup for many of the successful governance models within the space. As noted within the proposal, much research was put in to understand and learn from both failure and success to help make the initial governance setup for the SKALE Network be implemented successfully and able to benefit the network as a whole.

Opportunities for voting as you are suggesting could be something done at the chain level within a specific DAO if the community of such a chain wanted to implement it, however, for this initial proposal I will continue to advocate for voting power to come from staked tokens only.

Thanks again for your feedback and I look forward to your continued involvement!

22

I like @its_witjak’s idea. I see the value in getting more involvement, engagement, and co-ownership amongst all tokens holders while maximizing democratization. The more the broader token holding owners can play a role, the stronger the co-ownership of the network becomes and ultimate the stronger the community becomes.

I think Axios is also right that preventing the attack vector of a bad actor buying tokens with the goal of making an aggressive play against the network is a higher order need in the first launch of token voting. Other proof of stake networks have taken the same route as Axios’ proposal and that is because POS networks are built on the fundamental principle that staked tokens are the primary vehicle to ensure security of the core blockchain. dApps and DeFi projects that do not run base level consensus and foundational security have far less voting security exposure than a POS network. Voting is a connected element to blockchain security and so requiring tokens to be staked for voting, protects the core security as there is a committed alignment between stakers and security. In the case of SKALE the alignment is very strong as the staking period is two months and this guarantees that only truly committed actors get to vote. Purchase and vote attacks combined with shorting activities are a real threat when you open up onchain voting.

I personally would like to see a secondary voting policy that enables all holders to vote. However, I think it would be important to limit the negative impact a bad actor could have while maximizing the impact committed and positive/value add community members could have. This is the challenge. If someone comes up with a good idea or has a good proxy of how other POS networks manage this, please share it. I will also be doing research.

All of that said, I would love to see the voting model mobilized as soon as possible and done in a manner that can change and modify to pull in new ideas such as a A/B model that captures community involvement while mitigating risk from bad actors. I propose to push forward with the current model now (unless we see something actionable very soon). I also hope that more SKL owners start staking and commit their tokens to the security of the network as we kick this off. We also need to see the code from SnapShot and have it reviewed by the community before the voting ratification happens.

23

Hey everyone!

Following up here, here is the specification for how the delegated voting will work:

Background

The following information pertains to Proposal for SKALE Network’s On-Chain Governance System which can be found posted here and specifically how the actual votes would count and be weighted.

In the initial proposal, the following was flagged for further discussion:

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

The specification and examples below aim to help the community understand what delegated voting is.

Token Delegation States

Proposed - Delegator has proposed token delegation to a validator. Tokens are not considered staked until accepted by a validator and the next epoch begins.

Accepted - Validator has accepted a proposed delegation. The tokens are not considered staked until the next epoch.

Rejected - Delegator has delegated tokens to a validator and the validator has rejected the delegation. These tokens are not considered staked or delegated and must be delegated to a different validator.

Staked - Tokens are considered staked once a validator accepts the token delegation and the acceptance occurs before the next epoch.

Completed - Delegator has requested to undelegate their tokens to the current validator. At the end of the current epoch, the undelegation will complete and the tokens are no longer considered staked. Tokens can be redelegated at this point, but will not be considered staked until they are accepted and the next epoch occurs

Examples

  • Tokens delegated on May 30th and accepted on May 31st will be considered staked on June 1st
  • Tokens delegated on June 2nd and accepted any time during June will not be considered staked until July 1st

Specification of Voting

  • Voting power is directly proportional to the amount of tokens staked on a 1:1 basis
  • Voting should be done as single choice meaning each delegator or validator can choose one option when voting from the available options
  • Most votes should adhere to the core options of: Yes, No, Abstain
  • Only staked tokens at the time of the voting period opening are eligible to vote and only until the voting period closes
  • Potential validator voting power is the number of SKL tokens delegated to a validator
  • If a validator votes, the entirety of their voting power will be used
  • Delegators can vote differently than the validator they are delegated to
  • Delegators who do not participate in voting, will have their voting power claimed by the validator if the validator they have delegated to votes

Examples

Below are a couple of examples that have the goal of illustrating this dynamic voting power.

Example

The following example showcases voting power that can change based on delegator and validator voting. Additionally, if delegators do not vote, the validator automatically assumes their voting power.

Delegator A delegates 5 M to Validator V.

Delegator B delegates 12 M to Validator V.

Delegator C delegates 3 M to Validator V.

Validator V has 20 M in SKL delegations.

Who Votes Delegator A Delegator B Delegator C Validator V Total Voting Power
A 5 0 0 0 5
B 0 12 0 0 12
C 0 0 3 0 3
V 0 0 0 20 20
A, V 5 0 0 15 20
B, V 0 12 0 8 20
C, V 0 0 3 17 20
A, B 5 12 0 0 17
B, C 0 12 3 0 15
A, B, C 5 12 3 0 20
A, B, V 5 12 0 3 20
A, C, V 5 0 3 12 20
B, C, V 0 12 3 5 20
A, B, C, V 5 12 3 0 20

Example

The following example showcases an example vote with voting power represented by delegators and validators. Voting is single choice and the following row represent various outcomes of these three (3) entities.

Delegator A = 12 M

Delegator B = 6 M

Validator V = 2 M

Y = Yes

N = No

A = Abstain

DNV = Did Not Vote

A B V Yes No Abstain Total Votes
Y Y Y 20 0 0 20
N N N 0 20 0 20
A A A 0 0 20 20
DNV DNV DNV 0 0 0 0
Y N A 12 6 2 20
Y N DNV 12 6 0 18
N N DNV 18 0 0 18
N Y DNV 6 12 0 18
DNV Y N 6 14 0 8
DNV DNV Y 20 0 0 20
DNV DNV N 0 20 0 20
DNV DNV A 0 0 20 20
DNV N Y 14 6 0 20
N Y Y 8 12 0 20
N N Y 2 18 0 20

Conclusion

Please reply to this if you have questions or other feedback. While things have been stagnant for a short period of time hashing out the best ways to implement this and working towards a solution, we can now continue to move forward as a community with the goal of having the first vote as soon as the code strategy is ready to be used.

Also a big thank you to all of the community members who helped shape this specification with your amazing contributions.

TheGreatAxios

2 Likes
24

Hey guys, I have been chatting with @TheGreatAxios just after he proposed an idea for Governance System. So due to some challenges to accumulate all the data together in existing Snapshot strategies, I have modified a skale-delegation-weighted Snapshot strategy to satisfy all requirements that has requested in accordance with the initial forum post.

Thanks @TheGreatAxios for detailed example in a post above which throw away all misunderstanding which I had initially.

So please review the PR in snapshot-strategies repo

2 Likes
25

This looks good to me. Also, I’ve talked to many of the token delegators over the last month. I’ve heard nothing but overwhelming support for getting started in this manner. Everyone has one or two ideas to improve it, but in general there is mass support to start simple, and get more complex over time.

I say let’s goooooo!!! Time to get onchain voting up and running. We can iterate and improve by voting in new mechanisms or edits to this structure.

1 Like
26

Hey SKALE Community!

On-chain governance for the SKALE Network is officially live on Snapshot. You can find the first proposal here: Snapshot

The first proposal to approve what has been discussed and agreed upon in this thread can be found here: Snapshot

The voting period will be open for seven (7) days. If you are actively delegating according to the information in this thread, you are eligible to vote on this proposal.

Thank you to all of the community members for your contributions, feedback, and most importantly your support in the push to make this a reality.

TheGreatAxios

27

Hey SKALE Community!

I am posting here to report that the the first vote was successfully passed by the community!

You can see the final results here: Snapshot

This means that topics that have been agreed upon by the community to be in scope are available for the SKALE Community to propose changes too.

Thank you to everyone who contributed to this first proposal and voted to help establish governance for the network.

TheGreatAxios