Validator Spending Reduction - 3 Onchain Options

[WillRuddick]

Feeling your pain. All our development and operations will suffer greatly in Kenya.

Cosmo-Local Network on Celo

[celogovernance]

Thank you @kamikazechaser and @yomfana for the correction with sources.

We need to correct our earlier explanation of the voting mechanics. The actual governance rules, as cited from the protocol code:

• Threshold: 80% for security changes (governanceConstitution.js L44)
• Formula: Approval = (yes / yes+no) > constitutionalThreshold
• Abstain: Counts toward quorum only, not toward approval percentage

(Proposals.sol L215)

Apologies for the confusion our incorrect explanation caused.

[Njambi]

I want to speak from lived experience, with humility and care for Celo and everyone here.

For Grassroots Economics, validators aren’t an abstract cost line. They’re critical infrastructure that real people depend on daily. Our communities, our field teams, Sarafu.Network — and even partners like Pretium — do not rely on Forno because, for our needs, it’s not production-grade: it can be slow, rate-limited, and unreliable under real-world load. Our validator-run RPC is what keeps users connected when conditions are hardest.

So when I hear “we could remove 100% of validators and nothing breaks,” I have to say: that may be true for some apps and some environments. It is not true on the ground, where people are already operating with fragile connectivity and thin margins of trust.

Ending validator rewards — or effectively eliminating validators — would directly reduce uptime, weaken support, and risk breaking trust with communities who can’t afford disruptions. These aren’t traders and dashboards. These are cooperatives, savings groups, and mutual-aid networks.

And there’s something deeper: validators represent a commitment. People who secured the network, showed up in governance, found bugs, and reinvested back into Celo long before it was easy or popular.

I’m not against efficiency. I’m for honesty. If we’re going to make cuts, let’s first agree on the facts, the real dependencies, and the real budget—then choose a path that doesn’t sacrifice the very communities Celo exists to serve.

[AlexSedra2]

I appreciate the level of engagement in this discussion, but some of the objections—particularly around the economic impact on validators—are missing a more fundamental point.

If a validator operation only works as long as rewards remain at current levels, then the issue is not the proposed reduction; it is the underlying business model. A model that depends indefinitely on emissions or grants is, by definition, neither scalable nor durable. Extending those rewards does not solve the problem—it merely delays confronting it.

Arguments framed around “keeping the lights on” implicitly assume that validator rewards are an entitlement rather than a transitional mechanism. They are not infinite, and treating them as such creates long-term fragility for the network. At some point, sustainability has to be decoupled from protocol subsidies.

I understand the decentralization concerns and the historical commitments that were made. However, ecosystems that survive are the ones willing to reassess those commitments when conditions change. Celo is at that inflection point. Pivots are uncomfortable, but refusing to adapt is worse.

There is also an uncomfortable reality that cannot be ignored: outside of Minipay, on-chain usage is thin. If Minipay were to leave tomorrow—launch its own L2 or migrate elsewhere—the network’s fate would not hinge on whether validator rewards are 0 or 100. The core issue would remain the same.

Protecting the status quo may feel safe, but it does not address the structural risks the network is facing. Survival requires prioritizing long-term viability over short-term protection of existing incentives.

[Njambi]

I appreciate the thoughtfulness of this comment, and I agree with one core premise: long-term sustainability cannot depend indefinitely on emissions or subsidies. That’s true for validators, and it should be true for every part of the ecosystem.

Where I think we diverge is in what problem we are actually solving right now.

For Grassroots Economics and similar operators, validator rewards were never treated as an entitlement. They were part of a transition bargain: maintaining decentralized, production-grade infrastructure while Celo evolved toward an L2 and, eventually, decentralized sequencing. That transition is not complete. Removing rewards before alternative revenue paths or sequencing models exist doesn’t “force sustainability” — it breaks real services mid-flight.

More importantly, this discussion is happening in isolation.

Today, Celo is spending ~$16k per day across programs like CICLOPs and others — largely under NDAs, with limited public accountability. If the concern is truly about structural fragility, ROI, and long-term viability, then validator rewards are not the primary risk surface. They are one of the most transparent and measurable expenditures we have.

Cutting validators while leaving opaque, centrally administered spending untouched sends a dangerous signal: that sustainability means reducing decentralized infrastructure, while centralized discretionary programs remain unquestioned.

Finally, I agree that usage concentration (e.g. MiniPay) is a real risk. But that is precisely why independent infrastructure, diverse operators, and resilient RPC providers matter. If MiniPay ever leaves, Celo’s survival will depend on whether it still has builders, operators, and communities who can stand on their own — not whether it optimized emissions fastest.

This isn’t about protecting the status quo.
It’s about not mistaking cost-cutting for strategy, and not dismantling the backbone of the ecosystem before the alternative systems are actually in place.

I fully support a holistic spending and impact audit across all Celo programs — validators included. Let’s turn the lights on everywhere before deciding which rooms to close.

[davidcasey]

As director of Funding the Commons and a Celo Scout, I’ve spent some time studying how public goods funding mechanisms succeed and fail across dozens of ecosystems, and years on the ground with founders operating at and beyond the edges of the financial system. I don’t believe any of the three options truly serve the Celo ecosystem’s highest good, and I want to explain why from a PGF perspective.

This doesn’t appear to be cost reduction. It appears to be reallocation from transparent to opaque.

Will Ruddick and David Dao have made this point clearly: the CELO being “saved” doesn’t disappear. To my understanding, it redirects flows to programs like CCF (which faces serious community concerns about accountability) and programs like CICLOPS - currently spending approximately $3M per six months under NDA, without public accounting of recipients or outcomes.

If we genuinely want to cut costs, the proper order would be to do a full audit before cutting. Then cut where the lowest ROI actually is. From my perspective, this would be efficient public goods funding administration. What we’re doing here instead is eliminating the one spending category that’s fully transparent, permissionless, and community-verified.

Validators are decentralized community investment, not “spending”.

Validator rewards aren’t payroll. They’re a mechanism that lets the community express preferences through staking. They’re how Celo maintains infrastructure at the edges - in Kenya, Nigeria, etc - where Forno isn’t a real answer.

Celo was built for real-world use. As the first Celo Scout, and later as director of Funding the Commons, I’ve been working with UNDP, UNICEF, and builders from East Africa to LatAm to Southeast Asia. If the network doesn’t function at the edges - resilient, decentralized, locally maintained - then who cares if it works in San Francisco? I have Visa and Stripe and Venmo and ACH and SWIFT, and a stable fiat currency regime. The people Celo aims to serve often don’t.

Grassroots Economics and other validators reinvest rewards into liquidity pools that drive actual on-the-ground transactions. That’s not an expense - that’s ROI.

The validator community doesn’t just run nodes - they show up to governance calls, file bug reports, build tooling, and create the coordination layer that makes Celo governable. That’s not overhead. That’s the difference between a living ecosystem and a corporate service.

The sequencing is backwards.

PGF Mechanism design: don’t tear down the old system before you’ve built and validated the new one. ie where is the decentralized sequencer? The transparent allocation mechanism? The public dashboard showing CCF outcomes? The audits of spending across the system?

We’re cutting the one funding mechanism that is working in a transparent, permissionless, community-governed way - one that creates operational resilience for the network itself - and replacing it with something that hasn’t yet been proven out.

What I’d support:

1. Transparency first: Publish full CCF/CICLOPS spending before any reallocation.

2. Audit before cuts: Let the community see actual ROI across all spending categories, then decide where to reduce.

3. Honor the L2 commitment: Validators were told they’d transition to decentralized sequencer roles. Keep them whole until that’s live and proven.

4. Rule-based adjustments: If we need flexibility, implement @Dee’s circuit-breaker proposal - price-band triggers with automatic reinstatement rules.

I don’t depend on Celo validator fees. But I’ve seen what the validator community produces, and I’ve seen what opaque grant programs produce. In my experience, transparent mechanisms consistently outperform opaque ones.

David Casey CEO @ Funding the Commons, Celo Scout

[alex_Verda]

@Dee

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.

I like the idea of a dynamic reward mechanism that variably scales, tied to value-added services. Could you provide more specifics on what you had in mind?

[alex_Verda]

@Dee

User activity → protocol revenues → everything else gets easier to handle.

True. I’m working on an FX Perp DEX on Celo, currently in Beta (beta.perpex.ai or beta.updown.xyz), which I hope will bring additional onchain users/volume to Celo. Feedback welcome (TG: @AlexLWitt).

[alex_Verda]

@yomfana

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.

I’m not very technical, so sorry for the ignorance, but I don’t understand why we need 100 different RPCs from 100 different validators? It seems like a handful of solid RPC choices should be sufficient? Can we not use alchemy.com, tenderly.co, etc. RPC endpoints?

[alex_Verda]

@Thylacine

Is the idea seriously to just keep resubmitting the highest Yes one until it passes quorum?

My understanding is that there needs to be >80% approval: yes/(yes+no), so it’s not a matter of just resubmitting. There needs to be a significant majority support.

I put three proposals, because I was attempting to include the alternative suggestions that came up in previous discussions. I spent extra time to try to incorporate feedback, NOT trying to throw stuff against the wall and see what sticks.

I do understand the urgency of “plug the leaks” mindset, but so much has happened on the side in the last couple of months:

Honestly, at least for me, some of it comes down to recent token price, many of us are holding at a significant loss.

One thing is for sure, governance participation and interest has seen a huge increase in quality and volume of responses, which I love.

Seriously…. I really did not anticipate the amount of feedback I’d get after the initial post. I had to digital detox over the holidays a bit TBH.

[alex_Verda]

@WillRuddick

Validators as Community RPC Providers: Under the new L2 architecture, validators will transition to operating community RPC nodes

I’m a little out of my depth here and I don’t want to open up too many cans of warms at once… but what would you think about a separate income stream for high-quality RPC nodes?

We probably don’t need 100 RPCs (?), but maybe ex-validators can apply for an income stream based on RPC performance/responsiveness for ~20 RPC providers? A new proposal, for example, would quantify the performance thresholds for the RPC providers.

Brainstorming mode, so feel free to pick apart.

[Thylacine]

@alex_Verda It looks like this failed to execute after being passed successfully (unless Mondo is out of date). I was under the impression this was more than a temperature check and would be executed, since it had the payload. Could you please confirm for the community what’s happened?

[alex_Verda]

@Njambi

Celo is spending ~$16k per day across programs like CICLOPs and others — largely under NDAs, with limited public accountability. If the concern is truly about structural fragility, ROI, and long-term viability, then validator rewards are not the primary risk surface. They are one of the most transparent and measurable expenditures we have.

If you had to assemble a dream team of who can really assess these costs and has direct insights, who would it be?

I’m concerned with spending across these programs, as @WillRuddick has also brought to our attention. As was suggested in a previous discussion, I think we need 3-5 people group to review expenses and create additional proposals.

My intention with the original proposal was that validator cost reduction should be a start, get some momentum going, but not the end.

[alex_Verda]

@Thylacine

It looks like this failed to execute after being passed successfully (unless Mondo is out of date).

My understanding is we’re in an execution window (15 hours left), but I’ve pinged Martin Volpe to educate myself, I’ll follow-up once I confirm.

[Thylacine]

Oh strange, there must a localization issue on Mondo, for me (UTC+10) it’s already showing as execution window closed.

[alex_Verda]

Mondo time appears off for me too, but, regardless, it seems the proposal has been approved and executed now. Regarding my statement above, I did confirm with Martin that my understanding was correct, he responded to me 8 hours ago, just seeing/responding here now though.

[Thylacine]

I have raised Localization issue with governance timer duration · Issue #428 · celo-org/celo-mondo · GitHub about the localization timer problem.

[kamikazechaser]

@alex_Verda

based on RPC performance/responsiveness

All Celo Community RPC nodes were unlimited, dedicated, and geographically well distributed. The real loss was not compute capacity performance or quality, but the removal of deeply embedded technical support from people whose primary focus was Celo itself.

Grassroots Economics has directly contributed critical technical value to the Celo ecosystem. We implemented an essential feature on the legacy Celo Geth client (node), eth_getBlockReceipts, at a time when it was unsupported for months despite being one of the most important RPC methods for any high-performance indexer. We also identified and helped surface a critical sequencer issue that prevented smart contract deployments on Celo for nearly 17 hours. We also maintain independent node configurations as an alternative to the cLabs/Optimism stack, while continuously contributing fixes and optimizations back to the cLabs configs. Before Ethereum conformity, when no mature tooling existed, we built Python and Go libraries to support Celo. We also pushed external teams to properly support Celo-specific features, including EthInfinitism. We operate as a challenger on Celo and were prepared to participate in any future protocol improvements.

The point is: RPC providers deliver far more than compute power. When they are deeply invested in the chain, they provide technical feedback loops, early detection of failures, protocol hardening, and informed governance participation. By eliminating Community RPC nodes, we also eliminated these feedback loops, this institutional knowledge, and ongoing technical stewardship.

I do not believe the risks and downstream effects of removing Community RPC nodes were adequately discussed or understood by the community before the decision was made to remove them entirely.

[Njambi]

Thank you. Here, Technical, @kamikazechaser Dee, Marek Oversight, @ddd @MilaRioja William Ruddick, Taylor lahey

[WillRuddick]

Audit dream team:
Technical: @marek @Dee @kamikazechaser
Oversight: @ddd @coi @MilaRioja @davidcasey @taylorlahey