Validator Spending Reduction - 3 Onchain Options

Following this most recent governance call on 12/18/2025 and based on suggestions raised both during the call and in recent forum discussions, we would like incorporate broader community input.

We plan to run a set of onchain transactions to better understand community sentiment across three suggested options. For those who want to see historical context and the origin of these 3 options, see the post here.

Approvers will then only approve the one with more yes votes.

Options under consideration:

1. Reduce the set by half

2. Reduce rewards by half

3. Keep the current set, with rewards reduced to zero. Note, this wouldn’t require a huge heads up time for cLabs like reducing the validator set to 0 would (see here for details).

Each option will be presented as a separate onchain transaction so community members can evaluate them independently. Approvers will then only approve the one with the most yes votes.

2 Likes

Whats the purpose for reducing rewards to zero?

Do the validators play any role as rpc providers?

I updated the proposal above to clarify. Basically, several community members suggested reducing the validator count to 0 for additional cost savings, but that would have meant a lot of cLabs and audit work (see Marek’s post here for details), so option 3 is meant to be economically equivalent to going to 0 without the engineering/audit work.

from what I understand validators are the rpc nodes so what does it mean if the validator set is going to be halved? what if all validators are removed? Would this require running nodes for the rpc?

@swiftstaking thoughts?

Validators are RPC providers, BUT it’s a service that is NOT being used. There are multiple RPC providers. Forno, provided by cLabs, is already freely available and covers RPC needs.

Before and after L2, most developers, etc. still just using Forno. Before L2, no one had any problem with just using Forno, so I don’t think validators are providing a critical service.

In other words, we could get rid of 100% of validators and Forno would still be working well covering RPC needs.

Worth noting, with just 1 or 2 validators, staked CELO, voting rewards, Celo token time locks, etc. would work normally.

PS: Very open to being corrected, maybe I’m missing something you’re seeing?

Alex, thanks for staying the extra time on the last governance call and not rushing this. It didn’t feel like you were trying to ā€œwinā€, it felt like you were trying to understand. I genuinely appreciate that.

I didn’t agree with the early framing or some of the initial numbers but I do recognize the net-positive outcome: this debate has forced the community to confront the real questions: tokenomics, value accrual and CCF accountability. This is where the real leverage is. Those are healthy conversations for Celo.

Regarding the three current onchain options, I’m going to vote NO on all. Cutting RPC-provider spend is not a substitute for a value-accrual model, this is ā€œcost cuttingā€ in isolation while the real driver remains unresolved. If we grow real revenues, this whole conversation becomes easier. Why buy and hold CELO? And how do we grow durable revenue streams?
User activity → protocol revenues → everything else gets easier to handle.

I’m looking forward to the tokenomics discussions. Personally, I’d love to see ā€œETH validation on Celoā€ style initiatives that increase TVL, generate real fees and create yield narratives people can believe in.

If the community truly wants a spending reduction lever, I’d rather do it rule-based and future-proof, not via governance whiplash. A dynamic reward mechanism tied to transparent price thresholds (with clear reinstatement rules) is cleaner than debating ā€œlow hanging fruitā€ every time price moves. Implement it as a governance-approved rule, then execute it operationally. There may even be a path to implement this quickly via score/reward parameters without touching staking yield mechanics via the Score Management Committee.

Would you be open to a 4th proposal along those lines (price-band circuit breakers)? If yes, I’m happy to help draft the thresholds based on runway and CELO-per-epoch assumptions.

5 Likes

The claim that validator-run RPCs are ā€œnot being usedā€ is bold and demonstrably false. RPC usage data is not broadly public, and the one dataset that is public already contradicts this narrative and shows meaningful real-world usage.

The idea that Forno is some kind of developer-grade silver bullet is equally detached from reality. Forno is explicitly not designed for serious developer workloads. It is rate-limited, websocket connections are intentionally unstable by design, many methods are unavailable, and the SLA makes this clear in black and white. It exists primarily for end-user interaction. Anyone who has actually benchmarked community RPCs against Forno knows they are orders of magnitude better.

The assertion that ā€œwe could get rid of 100% of validators and Forno would still workā€ is frankly reckless. Yes, technically, you could run a blockchain with one or two validators and still have staking, voting, and timelocks function. And by that same logic, you could also light the entire decentralization model on fire. Centralization is not a clever optimization; it is a systemic failure mode.

What this argument really reveals is a willingness to trade long-term network integrity for short-term budget convenience, while pretending that redundancy, independence, and decentralization are optional luxuries. They aren’t. If the conclusion of your reasoning is ā€œwe don’t need validators because one provider works for now,ā€ then you’re not missing something; you’re actively arguing for the weakest possible version of the network.

Well I’m hopeful that at least Ethereum is headed in the right direction. I hope Celo can borrow a leaf.

10 Likes

I’m not sure what’s going on with these three governance proposals.

Is the idea seriously to just keep resubmitting the highest Yes one until it passes quorum? If we fail to even meet quorum on one of these ideas, that’s feedback that there is no clear consensus (although one could argue that because there’s no multi-option polling in current governance that quorum could be aggregated among all three).

But under the current rules, we should not give a special dispensation to any of these proposals to just immediately resubmit, for the very reason that the entire discussion itself is so controversial.

I do understand the urgency of ā€œplug the leaksā€ mindset, but so much has happened on the side in the last couple of months: ā€œbusā€, tokenomics working group, S2 abstract etc, aren’t we doing ourselves a disservice by not condensing everything together?

Anyway, we’ll see what comes out of it soon I guess. One thing is for sure, governance participation and interest has seen a huge increase in quality and volume of responses, which I love.

4 Likes

Shouldn’t the transaction description in https://mondo.celo.org/governance/271 say ā€œReduce rewards to zeroā€ instead of ā€œReduce rewards by halfā€?

1 Like

Celo’s moat is not Forno, not a parameter tweak or optimisation. It’s the human layer: a diverse and mission-aligned community that actually shows up. That community is being treated like a disposable cost line under the banner of ā€œsavings.ā€ Once you burn that coordination layer, it is not sure if it will ever come back at all. The fallback is bitter and hard to rebuild.

I’ve been in this industry for almost a decade to watch ecosystems die in slow motion. It usually isn’t one technical failure, it’s governance legitimacy collapsing while people tell themselves ā€œwe can fix it laterā€. You can’t rebuild long-lived operators set and trust on demand.

Celo’s ambition was the first billion users. That only works if CELO becomes more valuable through durable demand and revenue engines not austerity theatre. You can always get professional services with Alchemy and Quicknode but they won’t be participating in governance calls, proposals discussions, emergencies and tooling.

The asset you’re cutting is the one you can’t replace. There are very few places where a community member would organise a 2 hours call on the 5ft and 6 days later, you get over 40 participants from around the world for it. It’s truly sad that this is taken for granted and completely gets ignored in these discussions. A 2-hour call with 40+ participants on short notice is not ā€œnormalā€ in crypto. That’s the asset you don’t get to burn and then pretend you can reconstitute later.

This process is trial-and-error governance, not a defensible decision path. Across four threads, the rationale has shifted repeatedly from ā€œselling pressureā€ to ā€œvalue rankingā€ to ā€œno one uses RPCsā€ etc. Governance legitimacy matters. Celo foundation and large holders have shaped validator elections. Watching major voting weight swing late in a way that eliminated many small operators creates further uncertainties. If Celo wants to be credible, it should not rush structural decommissioning on changing narratives. Currently out of 218 voters, there are 3 addresses that represent 93% of the yes votes (3.244m/3.478m) to set the rewards at 0 and thus eliminate the set.

If I’m wrong and this is ā€œjust opsā€, the upside is you save some money and maybe reduce a bit of noise.
If I’m right, and I’ve already watched this pattern play out, then you’re not trimming fat, you’re amputating core stakeholders. You burn the coordination layer and governance legitimacy at the same time and then everyone tells themselves ā€œwe can fix it laterā€. But you can’t. This results in slow-motion ecosystem death: fewer long-lived operators, less trust, less participation in emergencies/tooling, more bitterness and a community that stops showing up.

That’s the tragedy path: Celo joins all the dead ecosystem that exists in this industry not because of technical failure but because the social layer collapses under contested premises and rushed structural decommissioning.

If you want a responsible path: pause. Let’s do tokenomics work and then come back with a single defensible proposal. And if you really want to push this through, then I’ve already offered to help create a bridge proposal that’s rule-based, provides a better balance between runway and ecosystem preservation, and prevents amputation of core stakeholders on highly controversial claims.

7 Likes

:fire: NO on all :fire:
There is another way.

Thanks @Dee @Thylacine @yomfana for say what seems obvious out loud.
Thanks @kamikazechaser for your post here Delegate Thread: Grassroots Economics - #2 by kamikazechaser to explain a sane path forward and our views at Grassroots Economics and how much harm this will cause to Celo and people on the ground if ANY of these proposals pass.

some basic integrity questions:

  1. Who is vetting proposals before they are put up for vote?

  2. Can anyone explain what this means?

ā€œā€œNoā€ votes will not be counted for the purpose of picking a winning choice, therefore voters can explicitly abstain by voting ā€œnoā€ on all three options. ā€œNoā€ votes do not affect quorum.ā€

  1. Can anyone point me at some governance docs to explain how this is supposed to work? Is this somehow normal? How can ā€˜no’ votes mean nothing?

  2. Who holds the keys to the stCELO contract? (Or explain the reason to hide the names?)

  3. @alex_Verda Since you are the face of this proposal and after our last call vowed to research and make changes; 1. You were unaware of Celo CICLOPs spending. 2. You were unaware that the minted Celo based on this proposal will still be minted and available for use by CCF. 3. You were unaware of the usage of block rewards to cover dev costs and operations in field.

You were quite humble and I was really hopeful that I would see some result of your leanings research. What has caused you instead to simply push this proposal through?

  1. @ericnakagawa or anyone? Is there any upside for Celo to being a centralized corporate service? (No decentralization, not a blockchain in any way) Who does it benefit? Will this increase investment in Celo - are their investors interested in Celo as a corporate centralized service?

(This proposal being pushed so hard …. without any clear path forward - after the L2 transition .. .begs these questions … )

  1. What else needs to be asked and answered?

Let’s speak honestly and ask and answer hard questions in public so Celo gets stronger.

Season 2:

:oncoming_bus: Celo Bus Station :oncoming_bus:

-Will Ruddick

11 Likes

We voted no at all the 3 options.

The discussion around validator spending reduction is timely and important. As Celo evolves in its current architectural context, it is reasonable for the community to reassess validator economics, operational costs, and long-term sustainability. Cost efficiency, in itself, is not the issue at hand.

The challenge lies in how this discussion is being conducted and under what conditions proposals of this magnitude are being advanced.

First, there has not yet been a sufficiently mature community-wide discussion or visible consensus around the need, scope, or design of validator spending reductions. Changes that directly affect validator incentives, network participation, and security assumptions require deeper deliberation, clearer articulation of trade-offs, and broader alignment with validators, delegators, and ecosystem stakeholders before being formalized into on-chain options.

Second, timing matters. Advancing proposals that introduce structural and potentially coercive changes immediately ahead of a new Season creates uncertainty. Validators and ecosystem participants depend on predictable incentive frameworks for planning, infrastructure investment, and long-term participation. Sudden shifts at this stage risk undermining coordination rather than strengthening it.

Third, the proposals currently lack transparent foundations. Key elements remain unclear, including:

  • The economic models or assumptions informing the proposed reductions

  • The methodology used to calculate the cuts

  • The criteria for evaluating acceptable risk and security thresholds

  • The operational process for implementing these changes with validators

Without this level of clarity, it becomes difficult for the community to assess the long-term implications for decentralization, resilience, and validator diversity.

Finally, the overall approach appears misaligned with Celo’s governance culture, which has historically emphasized collaboration, collective alignment, and co-creation. Governance driven by compressed timelines or pressure-based decision-making risks eroding trust, particularly in a network that has consistently prioritized community-first coordination.

In summary, while revisiting validator costs may be a necessary step for Celo’s next phase, such changes should be grounded in transparent data, shared analysis, meaningful validator engagement, and a well-structured governance process. Reopening the discussion with these foundations in place would enable the community to co-design a solution that balances efficiency with long-term network health.

We encourage continued dialogue, improved transparency, and a collaborative path forward.

7 Likes

Any user can submit a proposal to the Governance smart contract along with a deposit of 10,000 CELO. There is no formal vetting committee, the forum discussion serves as informal vetting, and the Governance Guardians review proposals for format and completeness. The community discussion and governance calls are where substantive review happens.

This is a fair question, and I appreciate you raising it publicly. The honest answer is there is no existing documentation for this format because it hasn’t been done before.

The mechanics work like this: ā€œNOā€ votes don’t affect quorum, so quorum must be reached through ā€œYESā€ and ā€œAbstainā€ votes only. For a proposal to pass it needs to fulfill two conditions: reach quorum, and achieve a majority of ā€œYESā€ votes (at least 60% of total votes including YES + NO + Abstain). So NO votes absolutely matter for the threshold calculation, they just don’t help a proposal reach quorum.

The rationale for this format: we blocked the original single proposal because there was clearly not consensus in the forum discussion. We extended the governance call by 30 minutes to allow continued debate. This triple proposal allowed multiple variations to be considered, with a hidden fourth option if none of these meet quorum, no changes are made. Voting ā€œNOā€ on all three is effectively voting for status quo.

Your point about documentation is valid. Novel governance mechanisms should ideally be documented before use, not after. We should formalize multi-choice voting rules for future proposals.

2 Likes

I can answer this part. It is not that there is someone who holds the keys to the contract but rather that when anyone who holds stcelo tokens vote all those votes come from one address (the stcelo contract address) so that it’s in fact probably several people / groups.

The UI being this way was not done in order to hide anything but rather because showing like this took 5 seconds of creating a label vs probably a few days to implement a system of capturing the vote events from st celo contract, saving them to a new db table. merging them with the votes, being sure to remove the aggregate version to avoid double counting. etc.

In short it was a MVP decision. if we had taken zero action instead of label it would be displaying the contract address.

I believe Address: 0xDa30d1F9...2e0B9ab8e | CeloScan shows the vote events for each address.

4 Likes

(at least 60% of total votes including YES + NO + Abstain

The constitutional threshold for these specific votes are 80% (security changes). See L44 celo-monorepo/packages/protocol/governanceConstitution.js at master Ā· celo-org/celo-monorepo Ā· GitHub.

Also the abstain votes are not factored in to get the final approval percentage. It is simply as @yomfana states:

Or here on L215: celo-monorepo/packages/protocol/contracts/governance/Proposals.sol at master Ā· celo-org/celo-monorepo Ā· GitHub

I have to be honest: the decision to deprecate the ex-validator set feels like a profoundly short-sighted move for the Celo ecosystem. As I see this change being finalized today (Currently passing), my own confidence in the project’s direction has been severely shaken.

For me, and for many others I’ve spoken with, the decentralized network of validators was a core part of Celo’s value. It was what we believed in. So, when I see major stakeholders phasing them out, I’m left with serious questions about the long-term strategy. Are we centralizing control? If so, what is the plan to maintain the trust and resilience.

I also find the timing deeply concerning. The announcement of a tokenomics call by @rene_celo to discuss these matters, seemingly after the decision has already been made, makes me feel like our input is an afterthought.

3 Likes

according to what you say this is a failure.

(at least 60% of total votes including YES + NO + Abstain)

Please help me understand. :fire:

3 Likes

The biggest risk here is sequencing: we’re removing one of the few remaining aligned stakeholder incentives before any new value-accrual engine is shipped. You have ignored people who have bought Celo to validate and participate in decentralize sequencers.

People didn’t stick around Celo for ā€œFornoā€. They stayed because they believed in participating, building and operating the network. Cut rewards to 0 and you’re breaking one of the rare participation loop.

This feels like IMF-style austerity: cut the most visible line item fast, claim ā€œdisciplineā€ and hope confidence returns while the underlying growth problem remains unsolved.

Austerity without a growth engine is not sustainability, it’s a controlled demolition.

6 Likes

Not sure.. what is this?! I though no more validators income… is that not the case?
I was about to Sign Out from Replit, Grok, chatGPT, Gemini, and X Premium subscription :confused:

Please everyone read this message from @marek (this is why we agreed to the L2 transition - risking everything on this promise):

Validators as Community RPC Providers: Under the new L2 architecture, validators will transition to operating community RPC nodes. These nodes provide essential infrastructure, enabling reliable access to the blockchain and supporting smooth network operations. This role ensures validators remain engaged while the decentralized sequencer model is developed and implemented. Additionally, by keeping current staking rewards and the election protocol that elects these RPC providers, this will ensure that stakers remain engaged.