Slurp #2 Draft | Community council elections for Epoch 1

SLURPs
1

Abstract

SLURP #1 establishes the process to formally propose and ratify changes to the protocol. It establishes a council, which role will be to vote on SLURPS. Amongst this council are two “community seats”. SLURP #1 specifies who these two community council members will be for the first Epoch.

This SLURP #2 proposes to submit these two community council seats to a community vote.

Rationale

As describes in SLURP #1 itself, “The community proposes SLURPs and votes for community Council seats”. Submitting the first Epoch to this rule would bring consistency to the protocol.

Having the community seats picked by the core contributors could be seen as a conflict of interests as the incentives of both parties are not always necessarily aligned. Having the first Epoch set up this way could weaken the protocol’s reputation and integrity.

Allowing the representatives for the community to be elected by the community itself would give more legitimacy to the protocol, and since the proposals are to be proposed by the community, having someone they elected as a council member will make the ideations and discussions more fluid and constructive.

Specification

Vote (for the SLURP)

  • Quorum: >= 50%
  • Pass: > 50%

Should the vote pass and be considered Approved, it will modify SLURP-1 and nullify the pre-selected Community Council seats, but will not impact Node Operator Council seats. Should the vote fail this SLURP will be considered Rejected, and SLURP-1 in its entirety as written will be considered Approved. Should the vote fail to meet quorum, it will be considered as Rejected.

Excluded Addresses

Chainlink Labs

  • 0xdedA4c43136D4f40F75073B0d815c648330fD072

Node Operators

  • 0x6879826450e576B401c4dDeff2B7755B1e85d97c
  • 0x20C0B7b370c97ed139aeA464205c05fCeAF4ac68
  • 0x26119F458dD1E8780554e3e517557b9d290Fb4dD
  • 0x479F6833BC5456b00276473DB1bD3Ee93ff8E3e2
  • 0xF2aD781cFf42E1f506b78553DA89090C65b1A847
  • 0xc316276f87019e5adbc3185A03e23ABF948A732D
  • 0xfAE26207ab74ee528214ee92f94427f8Cdbb6A32
  • 0x4dc81f63CB356c1420D4620414f366794072A3a8
  • 0xa0181758B14EfB2DAdfec66d58251Ae631e2B942
  • 0xcef3Da64348483c65dEC9CB1f59DdF46B0149755
  • 0xE2b7cBA5E48445f9bD17193A29D7fDEb4Effb078
  • 0x06c28eEd84E9114502d545fC5316F24DAa385c75
  • 0x6eF38c3d1D85B710A9e160aD41B912Cb8CAc2589
  • 0x3F44C324BD76E031171d6f2B87c4FeF00D4294C2
  • 0xd79576F14B711406a4D4489584121629329dFa2C

Candidate Eligibility

Following conclusion of voting on this SLURP, there will be a period of one week during which candidates will be able to put their name up for election. Node operators and Chainlink Labs employees are not allowed to run. You cannot put someone else’s name up to run for the election, only yours. Nominate yourself by posting a brief bio to be considered by voters in the Elections category of talk.stake.link.

Voters (for the Community Seats Election)

Only SDL/stSDL/SDL in LP position not belonging to a node wallet or Chainlink Labs are allowed to vote

Election

After a one week nomination and discussion period on talk.stake.link, the candidates will be put up for a vote using weighted voting based on simple SDL/stSDL/SDL in LP position holdings for the voters designated above via Snapshot. The two candidates with the most votes will be elected for the first Epoch.

Copyright

Copyright and related rights waived via CC0.

4 Likes
2

Thanks for putting this together @mashed_mole. Will propose if that this doesn’t pass, then this part:

Only SDL/stSDL/SDL in LP position not belonging to a node wallet or Chainlink Labs are allowed to vote.

Should be its own proposal re community seats.

2 Likes
3

How would we guarantee the experience/track-record of the first chosen community seats in this model? I know that we have a number of popular individuals in the Chainlink Community, but being popular would not always mean they are the best fit for bootstrapping the protocol. In my opinion having a few select individuals with proven track records in contributing to such governance models and/or bootstrapping DAO’s would be more desirable for the first epoch.

2 Likes
4

Thanks for the thought, time, and effort that went into proposing this @mashed_mole. I have a couple suggested modifications and additions to the Specifications section (and the inclusion of a Copyright section), included in the following text. Additionally, I’d ask that your doc be formatted into markdown format in the same way SLURPs 1&2 are. Check out hack.md for a nice markdown editor.

Specifications

Vote

  • Quorum: >= 50%
  • Pass: > 50%

Should the vote pass and be considered Approved, it will modify SLURP-1 and nullify the pre-selected Community Council seats, but will not impact Node Operator Council seats. Should the vote fail this SLURP will be considered Rejected, and SLURP-1 in its entirety as written will be considered Approved. Should the vote fail to meet quorum, it will be considered as Rejected.

Candidate Eligibility

Following conclusion of voting on this SLURP, there will be a period of one week during which candidates will be able to put their name up for election. Node operators and Chainlink Labs employees are not allowed to run. You cannot put someone else’s name up to run for the election, only yours. Nominate yourself by posting a brief bio to be considered by voters in the Elections category of talk.stake.link.

Election

After a one week nomination and discussion period on talk.stake.link, the candidates will be put up for a vote using weighted voting based on simple SDL/stSDL/SDL in LP position holdings via Snapshot. The two candidates with the most votes will be elected for the first Epoch.

Special Note

This SLURP is functionally an anti-pattern/out-of-band amendment to SLURP-1. In the future, while council-style governance is active, all future SLURPs must be proposed to and voted upon by the council.

Copyright

Copyright and related rights waived via CC0.

### Specifications

#### Vote

* Quorum: >= 50%
* Pass: > 50%

Should the vote pass and be considered `Approved`, it will modify SLURP-1 and nullify the pre-selected Community Council seats, but will not impact Node Operator Council seats. Should the vote fail this SLURP will be considered `Rejected`, and SLURP-1 in its entirety as written will be considered `Approved`. Should the vote fail to meet quorum, it will be considered as `Rejected`. 

#### Candidate Eligibility

Following conclusion of voting on this SLURP, there will be a period of one week during which candidates will be able to put their name up for election. Node operators and Chainlink Labs employees are not allowed to run. You cannot put someone else’s name up to run for the election, only yours. Nominate yourself by posting a brief bio to be considered by voters in the `Elections` category of talk.stake.link.

#### Election

After a one week nomination and discussion period on talk.stake.link, the candidates will be put up for a vote using [weighted voting](https://docs.snapshot.org/proposals/voting-types#what-is-a-voting-system) based on simple SDL/stSDL/SDL in LP position holdings via Snapshot. The two candidates with the most votes will be elected for the first Epoch.

#### Special Note

This SLURP is functionally an anti-pattern/out-of-band amendment to SLURP-1. In the future, while council-style governance is active, all future SLURPs must be proposed to and voted upon by the council. 

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).
1 Like
5

That is a fair concern. There will be an election period during which candidates can promote themselves. This entails putting their background forward. So voters will have the info and will be able to make an informed decision. Then it comes down to crypto incentives, community voters are incentivised to protect the value of their token, so they are supposed to make a decision consistent with this.

6

Thank you Eric. I will check with the community and get back to you on the suggested additions. Ok, sure re format.

1 Like
7

Thank you Jonny, yes agreed. But even if this passes might need to somehow specify somewhere that this will be the voters allowed to vote on all subsequent epochs.

1 Like
8

Voting is now live for SLURP-2!

9

I am in favour of this proposal as it would be good to learn more about the proposed candidates and also to see if there is a more suitable candidate(s) in the community.

I also note that this proposal is unlikely to reach the quorum of 6.8m SDL as in SLURP #0 and #1, the vast majority (134m of the 136m) of the SDL used in voting belonged to the LinkPool and node operator wallets. This left just 2m SDL of voting coming from the community.

10

Hi there @EqS thanks for sharing your thoughts! Currently, the community has 15.26 million SDL, so the minimum 50% quorum should be somewhere around 7.63 million SDL instead of 6.8 million SDL. That means that the quorum is already lower than it should be. However I can see a scenario where the quorum for purely community-related votes is lowered down in the future if participation is not consistent enough :+1:

I’m not sure how it will look like yet but I’m looking forward to explore it and have conversations about this together with y’all.

11

Can we talk a minute about Jimmy RUssle? Why does this person deserve a community seat when he is that out of touch with the community?

He even lies to mods in main chat by saying the screenshots are photoshopped. How can you believe he is the right choice for the community seat?

jimmy 1
jimmy 11079×1793 374 KB

jimmy 2
jimmy 21071×1655 341 KB

jimmy 3
jimmy 3719×1280 124 KB

12

Hi @sdfa, please remember to stop copy-pasting the exact same post in several threads or there will be a ban. You can see my response to this question in the other thread. Thanks again for sharing your concern though.