Protocol: StakedCelo (stCELO)
Status: DRAFT — for community discussion
Author(s): Mc01 / pahor167
Type: Multisig owner rotation (operational governance)
Multisig: 0x78DaA21FcE4D30E74fF745Da3204764a0ad40179 (3-of-6)
Hello stCELO users,
Summary
We propose replacing the six current signers of the StakedCelo owner multisig with the six members of the cLabs Security Council. The signing rule (3 of 6) and the on-chain waiting period stay the same.
The reason is practical. StakedCelo stakes CELO across a set of validator groups, and that set needs regular upkeep. When a group shuts down or stops being eligible — a “dead” group — the CELO staked to it gets stuck, and the bot can no longer move it to healthy groups. Only the multisig can fix this, by removing dead groups and adding good ones. Today that takes weeks, mostly because collecting signatures from the current signers is slow. Putting the multisig in the hands of a small, always-available, security-focused team lets us spot a problem, decide, and act the same day. It does not weaken any security setting of the multisig.
Motivation
The set of validator groups changes over time. Groups shut down, lose eligibility, or go “dead.” When that happens, the CELO that StakedCelo staked to them stops earning rewards, and the bot cannot move it on its own. The only way to fix the set — add healthy groups, remove dead ones — is through the StakedCelo multisig.
That path is slow today. Collecting signatures from the current signers, then waiting out the on-chain delay, means one change can take weeks from start to finish. Most of that time is spent just getting the signers to sign, not the on-chain delay itself. We have already seen this go wrong: by the time a replacement group was added, that group had itself gone dead, so the change did not help and the funds stayed stuck. The multisig needs to be run by a team that can notice a problem, decide, and act without a multi-week wait.
Background: how StakedCelo curates default groups
The DefaultStrategy contract holds the set of default validator groups. Only the multisig can add or remove a group (through calls like deactivateGroup and addActivatableGroup). The bot — rebalance, revoke, activate — can only work with the groups already in the set; it cannot add or remove any.
Recent bot improvements help: dead groups are now drained and skipped during rebalancing, so a dead group already in the set does less harm. But the bot still cannot change which groups are in the set. That decision belongs to the multisig, so every group change waits on the multisig.
The problem, quantified (current mainnet state)
StakedCelo currently votes for 36 validator groups. 24 are healthy and 12 are not. Those 12 unhealthy groups hold about 5.43M CELO of stuck stake.
| Category | Groups | Stake |
|---|---|---|
| Healthy | 24 | — |
| Unhealthy (total) | 12 | ~5.43M CELO |
| — of which dead (shut down for good) | 6 | ~2.73M CELO |
| — of which failing (not usable right now) | 6 | ~2.70M CELO |
| Largest single dead group | 1 | ~2.25M CELO |
| Largest single failing group | 1 | ~2.40M CELO |
The bot cannot move this stake right now. The healthy groups it would move it to have no room to take on more votes, and the dead groups fail the check outright. The only way to free it is to remove the dead groups and add groups with room — and only the multisig can do that.
Before and after — the mission in one view:
| Today | After cleanup | |
|---|---|---|
| Groups the stake sits in | 24 healthy + 12 unhealthy | all healthy |
| CELO stuck in unhealthy groups | ~5.43M | ~0 |
| — of that, in dead groups | ~2.73M | ~0 |
| Stuck CELO earning rewards | no | yes |
The mission is to move from the left column to the right, and keep it there. A faster-moving signer team is what makes this ongoing cleanup possible.
Proposed change
We propose swapping the six current signers of the StakedCelo multisig for the six cLabs Security Council members. The 3-of-6 signing rule does not change.
| Current signer (replaced) | New signer |
|---|---|
0x256F4B1F578Cd7bEaA440429caFb5AD21aBf6fd3 |
Marek 0x0Bd06B2b192BD9eC316f2880A0c296D9Bc3225e0 |
0x91f2437f5C8e7A3879e14a75a7C5b4CccC76023a |
Piers 0x21e595451bDD69a85cf946f37f5A6A356C3F875D |
0x3784a50f16af1C135b741914449BEa4AfdB0c5c4 |
Karl 0x812f7C111476D45998e6D0C615B41c180C362263 |
0x1f5979355411dF24c5Ce21Df5bD9f2fff418c194 |
Pavel 0x74bc9E59B52117Ccf5Ee457cFb0CBE83b339A065 |
0x4d82BfC8823a4F3AF82B0AdE52ff3e2d74A04757 |
Javi 0x4D89adf3a4a71b25FB1a6D702Cf059CF5BebD02d |
0x01AAe13F65fB90B490E6614adE0bffFA57AC5bbc |
Paul 0x8b4b85f78F799F8364198FFEd2266d3cb3EA0daE |
On-chain action (specification + verification)
The change runs on the multisig itself. It is a single submitProposal(address[],uint256[],bytes[]) call (selector 0x52745014) that bundles six replaceOwner(address,address) calls (selector 0xe20056e6). Each replaceOwner swaps one old signer for one new one, so the number of signers stays 6 and the threshold stays 3.
Process:
- A current signer submits the proposal. This counts as the first confirmation (1 of 3).
- Two more current signers confirm it.
- On the third confirmation, the 7-day waiting period starts.
- After 7 days, any signer can execute it.
How to check it: before execution, getOwners() returns the six current signers; after execution, it returns the six new signers listed above. required() returns 3 both before and after.
submitProposal calldata — send to 0x78DaA21FcE4D30E74fF745Da3204764a0ad40179
0x52745014000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000001400000000000000000000000000000000000000000000000000000000000000220000000000000000000000000000000000000000000000000000000000000000600000000000000000000000078daa21fce4d30e74ff745da3204764a0ad4017900000000000000000000000078daa21fce4d30e74ff745da3204764a0ad4017900000000000000000000000078daa21fce4d30e74ff745da3204764a0ad4017900000000000000000000000078daa21fce4d30e74ff745da3204764a0ad4017900000000000000000000000078daa21fce4d30e74ff745da3204764a0ad4017900000000000000000000000078daa21fce4d30e74ff745da3204764a0ad401790000000000000000000000000000000000000000000000000000000000000006000000000000000000000000000000000000000000000000000000000000000c0000000000000000000000000000000000000000000000000000000000000014000000000000000000000000000000000000000000000000000000000000001c0000000000000000000000000000000000000000000000000000000000000024000000000000000000000000000000000000000000000000000000000000002c000000000000000000000000000000000000000000000000000000000000003400000000000000000000000000000000000000000000000000000000000000044e20056e6000000000000000000000000256f4b1f578cd7beaa440429cafb5ad21abf6fd30000000000000000000000000bd06b2b192bd9ec316f2880a0c296d9bc3225e0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000044e20056e600000000000000000000000091f2437f5c8e7a3879e14a75a7c5b4cccc76023a00000000000000000000000021e595451bdd69a85cf946f37f5a6a356c3f875d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000044e20056e60000000000000000000000003784a50f16af1c135b741914449bea4afdb0c5c4000000000000000000000000812f7c111476d45998e6d0c615b41c180c362263000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000044e20056e60000000000000000000000001f5979355411df24c5ce21df5bd9f2fff418c19400000000000000000000000074bc9e59b52117ccf5ee457cfb0cbe83b339a065000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000044e20056e60000000000000000000000004d82bfc8823a4f3af82b0ade52ff3e2d74a047570000000000000000000000004d89adf3a4a71b25fb1a6d702cf059cf5bebd02d000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000044e20056e600000000000000000000000001aae13f65fb90b490e6614ade0bfffa57ac5bbc0000000000000000000000008b4b85f78f799f8364198ffed2266d3cb3ea0dae00000000000000000000000000000000000000000000000000000000
Velocity: what actually improves
The biggest delay today is simply getting the current signers to sign, which can take weeks. With an always-available council in charge, that drops to the same day: spot the problem, decide, submit.
To be clear, the 7-day on-chain waiting period still applies to every multisig action, and this change does not touch it.
Risks
Medium. The 3-of-6 rule and the 7-day wait both stay the same, so the multisig’s security settings do not change. The trade-off is that control moves to one group — the cLabs Security Council, a known, security-focused team. We are trading some decentralization for faster response on an operational multisig.
Next steps
Please share feedback in this thread. After that, the current signers submit the change on-chain. We will post a follow-up reply with the submission transaction, the date the 7-day wait ends, and the execution transaction — the same way past StakedCelo actions have been reported.