stCELO launch on Friday - feedback on our plan for validator election

Dear Celo community,

cLabs plans to launch stCELO, a Celo native liquid staking derivative, on Friday this week! Specifically, we will launch the protocol and have planned integrations (WebApp, DEX, Lending, etc.) for the weeks afterwards. This protocol will allow anyone to stake their $CELO (earning rewards and supporting the network) and at the same time to use that capital across ecosystem DApps. To earn staking rewards for the users of stCELO, the protocol must vote for validator groups with all the $CELO it has locked. In its current implementation, it is only possible to vote for a maximum of 10 validator groups at any given time. In this post, we share how we plan to cast the votes for validator groups and solicit feedback from the community on our approach.

Specifically, we guide our approach by the following principles:

  1. Efficiency: For holders of stCELO: We want to vote for validators in a way to maximize the return. For the community / cLabs: We want to ship fast and iterate towards better (and more complex) solutions later on.
  2. Neutrality: We want to cast votes in a comprehensible way, based on objective measures which are important for the protocol stCELO to work, or for the Celo ecosystem to function. Besides these core caveats, we aim to stay neutral in the selection of individual validator groups.
  3. Credibility: Our approach should be verifiable by anyone based on on-chain data.

Based on these principles, we have come up with the following rules to select the validator groups we vote for with stCELO:

A) We create a shortlist of eligible validator groups
i) We start with all validator groups of Celo which have at least one validator elected [we need active validators to receive rewards]
ii) Of those, we select all which have an uptime score of >98% [we need high uptime to receive maximum rewards]
iii) Of those, we select the lower two tertiles of validator groups regarding number of votes received (specifically this means excluding validator groups with over 3,750,000 votes) [we aim to support the decentralization of Celo]
iv) Of those, we select all which have had zero slashing incidents in the past [slashing incidents decrease rewards]
v) Of those, we select all which have >2,000,000 votes as open capacity [we can only vote for 8 validators and want to ensure a minimum of 16M votes that we can cast]
This results in the list shared below.

B) We randomly select a subset of the shortlist
i) We commit to a blocknumber (and share the hash prior to its mining) and use the randomness contract to generate a seed with that block as input for a random selection algorithm
ii) We use this script to select 8 validator groups randomly from the shortlist and then vote for those: GitHub - m-chrzan/validator-selector. We do select less than the maximum number of 10, such that we have two free slots available under normal conditions and retain some flexibility around changing votes.

We hope our approach is understandable and we are looking very much forward to your feedback and to releasing the protocol to all of you for usage!

Matt for the stCELO team

PS: Happy to chat with everyone on how we can help here or on Discord matt#9000
PPS: the github repo of the protocol GitHub - celo-org/staked-celo

Appendix A: Shortlist

Addresses of validator groups part of the shortlist, selected as described above:
0x0f66619058BB9675f3d394FCc2cE236a29901571
0x15Ed3f6b79F5Fb9Ef1D99D37314Dd626b3005F0b
0x2AF540161Cbeb58FdC99b159c76E390598860510
0x2c2B0f71d59B546B2CAfd222696589c13C3c325C
0x34649AdA2cB44D851a2103Feaa8922DedDABfc1c
0x3D451dd723797b3DE938C5B22412032B6452591A
0x3DcF2ED8dC84a63FfD2bfDc3CDb2fA0B1aeAfE5c
0x5402172E972b31Fc9F0383F53f45823Ab5037379
0x602B65795BCc64b2fb329AC004236E194f077158
0x614B7654ba0cC6000ABe526779911b70C1F7125A
0x69cd274C6AcBc08F664eD7B2D54aaB6615BC1d70
0x70FC0b021dFdBb9A106D1Ed8F35f59D3f23eCb7B
0x71dcC67baEECd9308e341359f70B782D9C3565b8
0x81AE1C73A326325216E25ff1af9EA3871195036E
0x81cef0668e15639D0b101bdc3067699309D73BED
0x82f8Bcf96f24BA60Ef041D192c7CE04C907E2fb8
0x8493BD3De67AC341D4cC11531f96a1A2cdBf29aD
0x8580dB53C3ebC56230662B771ceF2707E92Ef83A
0x89d5bd54C43dDd10905A030DE6Ff02EbB6c51654
0x95aE59515915D6c493a846aE022F93726652b50A
0xAcdf897493A6000dbe256791E8A2beCbb405FD4F
0xB33e9e01E561a1Da60f7Cb42508500e571afb6Eb
0xb35Be22BccB0dB9dC62967dcF15fEB97C20f854e
0xc24baeac0Fd189637112B7e33d22FfF2730aF993
0xc64DF5Be250264bf2888591D87cdeB13BFADC501
0xC7d5409fEe80B3Ac37Dbc111664dC511a5982469
0xc8A81D473992c7c6D3F469A8263F24914625709d
0xd25c6a9FEf4744E8d4F90Bf6bdFAF7686909d799
0xD72Ed2e3db984bAC3bB351FE652200dE527eFfcf
0xE075ba4b1dCAF75513118d7aA08A057c658842c9
0xE141831c2c1198d79B9Ff61cD97C3bAca7F071E0

8 Likes

Validator selection process makes sense to me. I appreciate the focus on improving decentralization by staking with the smaller groups. Mobius is happy to support stCELO when it goes live :slight_smile:

4 Likes

Hi everyone, Martin from the cLabs engineering team here. Here is the promised commitment hash for the block number from which we will source randomness for the random validator group draw:

0e9f04cb6e1b2bc434bc4375e64a28b0a90627bb704e5bb688f7c6e84fa4435f

The preimage of this hash will be published some time after the referred to block is mined. The format of the preimage is

<block number>:<64 character hex string salt>

and it was hashed with sha256. Specifically, once it is published, you will be able to verify using

echo -n "<preimage>" | sha256sum

1 Like

Alright, the selected block number has been mined, here’s the preimage:

13816816:cbc5fe668f6a3dd888dbabb59590458793d1f5bb103c0b41fe13c4fb4eb62c09

Randomness at block 13816816 was

eeebfcc9bf72d7966eb5413ff5f83270e5dca2f67231f566c95fbccd7216ad38

which results with the following selection of validator groups:

0xc24baeac0Fd189637112B7e33d22FfF2730aF993
0xb35Be22BccB0dB9dC62967dcF15fEB97C20f854e
0x3D451dd723797b3DE938C5B22412032B6452591A
0x15Ed3f6b79F5Fb9Ef1D99D37314Dd626b3005F0b
0x34649AdA2cB44D851a2103Feaa8922DedDABfc1c
0xc8A81D473992c7c6D3F469A8263F24914625709d
0x81AE1C73A326325216E25ff1af9EA3871195036E
0xD72Ed2e3db984bAC3bB351FE652200dE527eFfcf
4 Likes

Thanks for the update! Would love to integrate stCelo at DappLooker and launch dashboards to track key metrics for performance and adoption

Looking forward to this launch!

In the future, to be able to vote for more than 8 validators, would it be possible to instead of staking in the main contract, derive the staking in N sub-contracts, each of the sub-contracts voting for 8 different validators? The implementation would be a bit more complex but we wouldn’t have a limit in how many validators to support.

Another thing that I’ve been thinking about is the possibility of bribing users to vote for your validator. Say validator X wants to get elected, or they are close to the threshold and want to make sure they don’t lose their spot. They could pay an extra bribe to stCELO holders to have their validator voted for with higher weight. Not sure about all the implications, but just throwing the idea out there.

1 Like

Hey @matt,

Is stCELO already released? If yes can you share its address.
Do you think it will be interesting to integrate with DappLooker Celo network tokens dashboard?

cc: @Kevin

1 Like

Yes the smart contracts have been deployed, we’re still working on the webapp and finishing up dex integration - should come soon and then we will announce a bit more broadly about the launch.

the SC can be found here to play around with:
Celo Mainnet

  • Account.sol: 0x4aAD04D41FD7fd495503731C5a2579e19054C432
  • Manager.sol: 0x0239b96D10a434a56CC9E09383077A0490cF9398
  • RebasedStakedCelo.sol: 0xDc5762753043327d74e0a538199c1488FC1F44cf
  • StakedCelo.sol: 0xC668583dcbDc9ae6FA3CE46462758188adfdfC24

Alfajores Testnet

  • Account.sol: 0xDc5762753043327d74e0a538199c1488FC1F44cf
  • Manager.sol: 0x3a41F481F53E9256BABda5168ce6fe531A32E4A8
  • RebasedStakedCelo.sol: 0xefDCa962589e3d92e3073E1Ee469ac8268D3531B
  • StakedCelo.sol: 0x389f72265C748dB1C9a7b8bFdCFA33Ef8607748D

yes we already have some ideas of how to technically implement voting for more validator groups. @m-chrzan is the head brain on this :brain: however, until substantial adoption of stCELO is achieved, we will prioritize other things to achieve the biggest impact for the Celo ecosystem.

Yes, very good point too - “bribing” as the term has emerged from the Curve ecosystem is a very logic next step as soon as stCELO volume becomes relevant for individual validator groups AND the voting mechanism is changed. We will consider this in the v2 and the change of the voting mechanism. Essentially, we want to enable the protocol OR individual stakers to harvest such rewards, AND as such to enable validator groups to leverage stCELO to grow

If you have more needs or ideas for a potential v2, please keep them coming! We keep a repository of all the items. Other points we have heard so fare are for example:

  • rotating through all eligible validators of the shortlist
  • enable large validator groups to use stakedCELO and uniquely vote for their own validator group with the stCELO they created (e.g., think of Deutsche Telekom and how they might use
  • automate the deprecation of groups that have been slashed
  • lots of other stuff…

Hi,

Is this deployed yet?

yes the smart contracts are live on mainnet (see comment above for the contract addresses). a webapp, dex and other integrations will be coming live soon

1 Like

Note: There has been a new deployment on Alfajores. The latest smart contract addresses can always be found on the documentation site: Deployed Contracts - StakedCelo

@matt where can I read about changes in latest smart contracts?

Accordingly DappLooker Staked Celo dashboard will need update.

core code hasn’t changed it’s just about redeploying with new multisig etc. - also nothing has changed on mainnet, so daplooker should be good I think?!

1 Like

Yes no changes needed. Sounds good :+1: