FIP: Opportunity For Another Consensus

[CassOnMars]

Problem

A sufficiently decentralized protocol needs members of a consensus set that is sufficiently decentralized. Proof of Authority does not achieve this, especially with five consensus set members owned by one company (or a second company with strong financial ties to the first).

High Level Solution

There are two paths, one simpler, one more complicated, both mutually pursuable for the greater good.

1. Add an open call for full validators to enlist non-affiliated members of the validator set.
2. Switch from PoA consensus to either a non-PoA model (There are now PoW algorithms that do not impart extreme costs to run), or create a PoS-based validator set for open participation.

Notes

This is an incomplete draft proposal, a full LOE will be added soon.

[vrypan]

On 1)

The protocol generated ~$1.5m (please someone share the exact number) of revenue from Pro subscriptions. This amount can be used to fund validator operations. (We need a cost estimate by Merkle and Neynar who are already doing it).

Additionally, Pro subscribers can point to the validators that they want to fund: The UI will show a list of validators and the user can pick the addresses where they want their Pro subscription to be distributed.

[ThatAlexPalmer]

pro subscribers can point to the validators they want to fund

Yeah, strongly support this idea.

[wenakita]

PoA, PoW, Po… doesn’t matter. If rewards are PoS, so is decentralization

[androidsixteen]

I'm supportive of this FIP directionally -- one of the main concerns I had about migrating from Hubs to Snapchain was the "masternode" approach adopted as a result. Initially it made sense to gate the number of write nodes while stability and perf were uncertain, but sufficient time has elapsed to begin hardening this a bit more

That said, I think migrating to PoS would be a mistake -- it adds a lot of complexity on top of the obvious questions around what the staking asset would be. A better solution IMO would be PoA with a larger validator set + more governance (ie. https://x.com/sunnya97/status/1673686815155396608)

This offers a middle ground with more capture resistance than the current system, while also avoiding opening the can of worms that comes with PoS

[derekbrown]

Considering that USDC is available on all of the major chains and doesn't carry a ton of chain-bias with it, I suspect that would be the most logical staking asset. Agreed with your comments, though.

I personally think that PoA is fine ("sufficiently decentralized") with a larger validator set.

[androidsixteen]

I personally think that PoA is fine ("sufficiently decentralized") with a larger validator set.

🤝

Considering that USDC is available on all of the major chains and doesn't carry a ton of chain-bias with it, I suspect that would be the most logical staking asset. Agreed with your comments, though.

Two issues with this imo:

1. You get counterparty risk with the asset issuer if it's a fiat collateralized stable -- ie. Circle can influence and outright break conensus
2. Exogenous assets (ie. bridged assets) have oracle risk. With USDC, this resolves to counterparty risk with CCIP, since they are the sole oracle, but the best staking asset is probably gonna be one natively issued on Snapchain -- which opens the can of worms around adding opcodes / more compute primitives as well as issuing a canonical native asset

[CassOnMars]

This is why I suggested a simpler first pass of expanding the validator set. Simple, compatible, hardens consensus to not effectively be one entity.

[androidsixteen]

Didn't realize they were sequential, thought it was option a vs option b

If so, I'm for step 1, but against step 2 (or option b, whatever)

[vrypan]

Expanding the validator set can be a huge step forward. And using PRO subscription funds to fund them adds a light governance layer.

For me, expanding the validator set is not only about censorship resistance, but also expanding the entities that have a saying on how Snapchain evolves.

[jobiteth]

A Concrete and Pragmatic Idea: The Hybrid "Protocol Treasury + Cost-Cover" Model

This would be the most robust and least risky alternative, combining the best of several proposals:

Base Treasury Fund: A fixed percentage (e.g., 30%) of all "Pro" subscriptions is automatically allocated to a common fund (Treasury) for validators.

Distribution Based on Demonstrated Activity: The Treasury is distributed monthly among all active validators in proportion to:

The read/write traffic they served (an objective metric of useful work).

A cryptographic verification that they store all the data (simplified Proof of Useful Storage).

Optional Cost-Cover Fee: Validators can additionally set a minimal technical fee (micro-payment) for processing complex or high-volume write operations. This would primarily be paid by commercial applications or bots, not regular human users.

Advantages of this hybrid model:

Sustainable: Recurring revenue from the treasury + variable revenue from service.

Fair: Validators are rewarded for the actual work they do.

Open: Anyone can become a validator. If they serve useful data to the network, they receive funds.

No friction for the common user: Normal actions (writing casts, reading) have no cost.

Anti-capture: It is difficult for a single entity to control many validators, as each one's performance is measured individually.

[jqmwa]

52% of US has a 6th grade literacy level, and this is a steep learning curve, I postulate toning down the technical insider jargon subliminal and making it easier to comprehend to become more equitable for non-intellectuals as well as pseudo-intellectuals.

[vrypan]

I agree. What's your preferred consensus mechanism in this case? Snapchain uses Tendermint/Malachite, do you have any suggestions on how to achieve stronger decentralization? Cassie proposed two options, but if you have a better suggestion, it would be great to share it here!

[jqmwa]

I don’t have a strong preference between specifics yet — my main concern is who can realistically participate, not just which algorithm is used.

Tendermint-style PoS can work if validator entry is genuinely open and not economically or socially gated. Cassie’s ideas around open validator calls and reducing affiliation concentration seem like good first steps.

From my perspective, focusing on low barriers to entry, transparent selection, and gradual decentralization over time may matter more than picking the “perfect” consensus model upfront.

[CassOnMars]

It's unclear to me which things are unnecessary "technical jargon", this is a discussion about a consensus algorithm. In addition, a cursory evaluation of reading level analysis on the proposal firmly places the reading level at 10th-12th grade comprehensibility. Just as the average citizen does not care about the doping levels of silicon, so too will they not about a choice of consensus algorithm.

[jqmwa]

That’s fair, just suggesting discussions benefit from being open, even if most people ignore them.

i think i got triggered from seeing sufficiently decentralized so i may have been excessive detailing it

We have a similar issue here where our board has 20 members, and only 2 are fully integrated in the system.

users would call it sufficient, but sufficient for a social graph like farcaster likely needs less bias and more chaotic randomness (like G-d)

i propose an optional plain-language framing alongside the technical discussion, to possibly help attract contributors who don't know they care yet.

it's less about lowering rigor, and more about widening the funnel for future decentralization

[CassOnMars]

I used the term "sufficiently decentralized" specifically because this is the term that the team in control of the project repo and the primary client app developer uses. The intention is that presently, the current implementation does not satisfy any reasonable definition of the term – no matter what bending of terminology would be employed to suggest otherwise.

That said, an associated PR with further details has now been created: farcasterxyz/snapchain#730