SNIP 33 - proposal for Starknet decentralized validation

đź“ś Development Proposals SNIPs
1

snip: 33 (temporary number)
title: Starknet decentralized validation
description: Discuss a concrete proposal for Starknet decentralized validation milestone
author: Ohad Barta (@ob1337)
status: Draft
type: Standard
category: Core

Simple Summary

Starknet v0.14 symbolizes the first stepping stone towards complete decentralization, with several sequencers StarkWare operates internally that already agree on Starknet blocks via the Tendermint algorithm. This SNIP describes a suggested implementation for the next Starknet decentralization phase: decentralized validation.
Decentralizing the network is complicated and will be done over time. This SNIP justifies the milestone selected, briefly details which challenges this milestone will tackle and which are saved for later, and then moves to describe the milestone itself.
Lastly, this SNIP is an unpolished draft for initial community feedback. Feel free to make suggestions to modify anything - and your feedback will be used to alter, or even completely pivot, this thinking direction for Starknet v0.15.

Motivation

Motivation for decentralization

Decentralization is a core value of Starknet, both ideologically and pragmatically. From the ideology perspective, Starknet aims to bring it to the masses: a place that has great UX and stores unlimited possibilities without settling on security or reverting de facto to a centralized or small set of players that control the ecosystem. Decentralization is a cornerstone for achieving this vision—allowing anyone to participate in the network and decide how its state would roll.
Pragmatically, decentralization can be a key differentiator of SN compared to many other chains. SN aims to be the execution layer of Bitcoin, with many BTCFi projects and opportunities spawned within the last several months. We cannot expect this brand to hold with a centralized environment or vision.

Motivation for having a decentralized validation as a milestone

Decentralization of a living network is all but trivial. We aim to do so through a series of incremental upgrades, each including a higher level of control on Starknet given to STRK stakers, and each introduces new edge cases and things that could go wrong - allowing the protocol evolution to tackle them separately. Thus, to justify decentralized validation as a milestone, we need to explain why:
It is a significant technical step forward compared to 0.14
There is a significant step to be done from this step to a decentralized block proposing.

Why is decentralized validation a significant step forward compared to 0.14?

ATM, StarkWare runs all the sequencers that validate the next SN block. The sequencers are executed in close geographical proximity, and are very few in number (between three and five). Several assumptions around the privacy of the p2p security network allow for simpler implementation for the 0.14-version of decentralization. All of these assumptions will probably not hold when any staker can take part in the protocol, even if its just validating - hence complicating the protocol substantially.
In addition, decentralized validation will correlate for the first time the decentralized protocol of SN with its staking protocol - a significant change to the staking protocol and its reward mechanisms, as well as the expectations from different staking parties - which should be carefully tested.

Why the gap between decentralized validation and complete decentralization is still far and wide?

With complete decentralization, SW is no longer the only block proposer. Therefore, several system elements must be redesigned.
Take fees, for example - currently, all fees go to the current block producer. However, if a transaction has 100 L2->L1 messages - this is a significant cost that will be paid to the sequencer, while the Prover (short-term SW and long-term potentially someone else in the protocol) will have to pay. A second area to look on is the feeder gateway that currently fetches all the network data through a centralized database. When SW offers all the blocks this is fine, but synchronizing against the latest chain tip would need to be revisited when anyone may propose the next block and SW sequencer doesn’t have a special role or permission. In particular, this will force a public mempool p2p (for decentralized validation only, it suffices to make only the p2p the sequencers use public)

Specification

Here are the decentralized validation requirements that will dictate the exact implementation.

Starknet performance

Decentralized validation is a setback for a well-performing system, as it’s clear that decentralizing a system comes with latency and additional costs. Thus, we will require the following:

Throughput

Despite the need to finalize each block only after a consensus is reached, SN throughput should not change by more than 5% compared to its 0.14 performance. This intuitive requirement, which can also be parsed as “performance should stay the same,” might require additional protocol features, or define restrictions on who can be valdiator, for example - requiring all validators to set up their machines within a given geographical cluster.

Cost

Setting up a validator node will not cost more than $1000/month. This cost range is in line with costs in other decentralized systems such as Solana and Cosmos, and what ensures that the aggregated network cost will stay in a reasonable range even with dozens of validators. Also, this implies that base fees will not change with this version, keeping Starknet scaled.

Finality

Moving to a decentralized validation phase should have no effect on the preconfirmation time from the SW sequencer, which should stay in the subsecond area. We are inspecting ways to reduce block times further - efforts that are decoupled from this feature.

Staking protocol and reward distribution

This feature is the first time the SN roadmap meets the SN staking protocol, giving real responsibility to stakers to attest blocks.

Who can attest blocks?

The current suggestion is to have a committee of Stakers, consisting of the top-100 largest stakers, weighted according to their amount of stake (such that it sums up to 100%). The set of stakers and their respective weight will be decided at the beginning of every epoch, according to the weight they had at the start of the previous epochs. Therefore, a staker not in the top-100 will not get rewards during the epoch. A staker in the committee will be expected to sign on blocks through the p2p network.

What is the attestation needed for a block to be confirmed? And how are rewards distributed?

More than two-thirds of this epoch’s committee should sign on the block (weighted by staking amount) for the block to be accepted into the consensus. In addition, for each block during the epoch, a “rewarded proposer” of the block that will be treated as a “must signer” (meaning that even if two-thirds of the stake signed but this rewarded proposer didn’t, the block will be thrown) is defined. This rewarded proposer will then get the block reward, which will be constant per block.
At this stage, the exact mechanism for deciding ahead of time who the rewarded proposer is is still TBD, but the requirement is that the rewarded proposer of each block be known at least 5 minutes in advance.

Centralization-lever

As described above, this feature introduces a threat to SN liveness, as a bug within this feature might cause SN to freeze until the bug is resolved and validators upgrade to the newest software stack. To mitigate this scenario and prevent significant network downtime, this suggestion also includes an additional and optional “plugin” - a mechanism to nullify signature validation, as explained above, reverting Starknet to a centralized state.
Automatically detect freeze - If an epoch included less than â…” of the blocks an epoch should have (assuming max configured block time), Starknet would automatically move to a centralized state, and SW would continue to produce new blocks without waiting for validation for some time of up to X hours (Think on X as a significant time that allows proper investigation but still relatively short. Probably between 12 hours and 3 days). In this period, validators will not be required to participate in the protocol, and staking rewards will not be distributed.
Revert to decentralized flavor—when X hours eclipses, Starknet would have to return to a decentralized flavor unless the Security Council approved prolonging the centralized period because the correction and upgrade processes require more time. Furthermore, the Security Council needs to explicitly allow SW to use the lever again in the future, preventing SW from continuously moving to a centralized state without real justification.

No breaking changes

This feature will entail no breaking changes to SN, meaning that all transactions valid with V0.14 will stay valid after this feature, and that there would be no RPC change. Shall a conclusion be made that breaking changes are necessary to secure one of the above requirements - this SNIP will be altered to present the tradeoffs and decide together on a path forward.

Implementation

Once we agree on the specifications, this section will contain the concrete design and suggestions for SN OS behavior.

Security Considerations

To never actually use the optional lever detailed above, this feature will require thorough testing of its code and the resiliency of the validators participating in the protocol. The following testing mechanisms are suggested, and more checks and validation ideas are welcome:

  • Have a dedicated testing network for test the reliability of stakers for a few weeks, before moving even to the testnet phase
  • This period will also include at least one stress test to ensure costs and throughput are up to expectation and that many transactions don’t cause the network to slow down

History

Copyright

Copyright and related rights waived via MIT.

2

I currently run a SN phase 2 validator out of my home residence along with an ETH validator. Decentralization indeed requires major tradeoffs and its good to discuss them openly and early. My main concern is in the concept of rewarding the top 100 stakers by only allowing them to propose blocks. We currently have over 100 stakers and by locking rewards to only the most entrenched it hurts decentralization as it consolidates new entrants that would otherwise be nodes themselves.

Also, I would highly dissuade the argument that the validators should be set up within a geographical cluster. If that is a necessary requirement for performance it would be better to stay centralized until the network improvements can be made. I do not find decentralizing across 100 AWS accounts running on us-east-1 to be compelling.

3
  1. The mechanism for selecting the rewarded proposer is not described
    How is the rewarded proposer chosen? How will the validator know in advance that they are the proposer? And what happens if the proposer is offline?
  2. No information about slashing or penalties
    What happens if a validator consistently misses blocks or intentionally harms the network? There should be at least a mention of slashing plans or a statement that slashing is not currently planned.
  3. Lack of clear motivation for validators
    What exactly will a top-100 validator receive? How much is the approximate reward per block? What kind of income can validators expect? A sample calculation would be very helpful.
4

What does this mean “requiring all validators to set up their machines within a given geographical cluster” ?

Also when you say validator costs at no more than $1000 per month? What would possibly cost $1000 per month?

6

:white_check_mark: Feedback on SNIP‑33

First of all, thank you for preparing this structured and well‑thought‑out proposal. It’s clear the team is approaching decentralization responsibly, gradually, and with strong technical awareness. I fully support the goal of aligning validation with the staking protocol and appreciate the plan for extensive stress‑testing before full deployment.

Below are several concerns and suggestions that I believe could strengthen the SNIP:

  1. Top-100 Validators Only
    Limiting attesters to only the top‑100 stakers may risk centralizing power among whales and excluding smaller but highly committed participants. A more inclusive mechanism - such as weighted randomness, rotating committees, or stake-based tiers - could foster decentralization and improve community trust.
    For comparison, both Ethereum and Solana support significantly larger active validator sets. While I understand that Starknet currently has only 123 active validators, this number will likely grow. The protocol should be designed to scale accordingly, rather than hardcoding small fixed sets.
    Moreover, with block time reduced to 6 seconds in v0.14 and longer epochs, a small committee will repeatedly sign blocks, further amplifying centralization risks over time.

  2. Rewarded proposer as a “must signer”
    Making the rewarded proposer a hard dependency creates a single point of failure. Please consider adding automatic fallback logic: if the rewarded proposer is offline for k seconds, a pre‑designated standby proposer (selected via VRF) should step in, with slashing applied to the absent node instead of discarding the entire block. However, slashing should only apply when the failure is attributable to the validator itself. If the issue stems from a broader network or protocol problem, no penalty should be enforced. This fallback and penalty mechanism needs careful design to distinguish between individual faults and systemic outages.

  3. Fallback to centralized mode
    A safety switch is valuable, but its use must be tightly governed and transparent. My recommendation:

    • Limit each fallback episode to ≤ 72 h, with clear protocol-level enforcement.
    • Do not allow repeated fallback activations unless formally reviewed and justified.
    • Publish an on‑chain incident report (block number, reason, duration, fixes). Ideally, this report should also appear on a dedicated public portal similar to incident dashboards.

  4. Undetermined Proposer Selection Mechanism
    This mechanism is pivotal for both fairness and liveness. Please detail and open‑source the algorithm (e.g., CometBFT weighted‑VRF or Narwhal/Bullshark schedule) before the SNIP moves to “Accepted”.

  5. Server costs and profitability
    My current mainnet node runs on a €21/month server, and my testnet node runs on a €17/month server. These machines typically use only 2–4 % CPU while validating (node + attestation service), with the rest of their capacity remaining idle. With the current model, I’m profitable and satisfied with the APR offered by the staking protocol.

    After this proposed change, I understand that rewards will include both APR and a portion of transaction fees. However, public dashboards currently show that Starknet generates only around $200–350 in daily chain fees, which is relatively low. If this remains the case, and if validators are required to upgrade to higher-performance servers (potentially up to $1000/month), the economics may no longer be sustainable.

    Therefore, it’s important to clearly define the hardware requirements for the sequencer and attestation stack. If possible, I would appreciate if you could also share the specs of the current centralized sequencer setup - it would help the community better prepare.

    If hardware requirements are modest, rewards should continue covering basic infrastructure. Otherwise, a dedicated incentive program could help bootstrap decentralized validation.
    Additionally, you could consider launching a testnet incentive program similar to Solana’s Tour De Sol (TDS). That initiative provided clear milestones, leaderboard visibility, and rewards for active and high-performing validators - helping the ecosystem attract new participants, test infrastructure at scale, and build confidence before mainnet decentralization. A similar program on Starknet would significantly boost validator engagement and help identify potential operators early.

  6. Public Mempool and MEV Risks
    The move to a public p2p mempool is necessary for decentralization but also opens the door to MEV extraction. Could the team elaborate on how MEV risks will be mitigated (e.g., via encryption, ordering rules, or delay strategies)?In particular, will there be any policies or enforcement mechanisms in place to deter MEV behavior? For example, will validators who engage in toxic MEV be disqualified from receiving grants from StarkWare or Starknet Foundation?Moreover, in some networks, validators benefit significantly more from forming MEV pools with other validators than from honest participation, due to the volume of profits these strategies can yield. Will such behavior be monitored on Starknet? And if so, will there be any on-chain or off-chain penalties? It would be reassuring to know whether Starknet plans to implement mechanisms to discourage or punish coordinated MEV extraction that undermines network fairness.

  7. Fee Enforcement and Sequencer Accountability
    The current documentation states that sequencers are prohibited from overcharging fees beyond the user-specified max_fee, but they are not yet enforced to strictly follow Starknet’s official fee formula. While this is acceptable during early stages of decentralization, it leaves room for abuse: a sequencer running a custom node (especially once the code is open-sourced) could modify the internal logic and charge inflated fees, as long as they remain under the max_fee.

    I believe this deserves broader discussion.
    Will Starknet eventually enforce fee consistency through proofs or protocol rules? Will there be slashing or disqualification mechanisms for sequencers consistently charging excessive or arbitrary fees within allowed bounds? Clear guidelines, enforcement, and transparency will be essential to maintain user trust and prevent extractive behavior as sequencer participation grows.

I’m excited to see Starknet take this step toward decentralization. Happy to contribute, test, and support where I can.

7

Thanks for the proposal @Ohad-StarkWare Interesting times for Starknet ahead!

So far I have a couple of questions:

  1. What hardware the validators are expected to run? And what do you think the latency requirements would be? Are validators expected to be geographically proximate?

  2. Wouldn’t the top‑100 committee limitation incentivize entities who own lots of STRK to spread their ownings over multiple validators thus making a bunch of smaller players like ourselves essentially irrelevant?

  3. Are there going to be slashing, economic incentives for attestation reliability, or mechanisms to rotate out underperforming validators?

Anyway, happy to see decentralization efforts progressing fast!

8
  1. This means demanding from all validators to operate within one geographical region (us-east, etc.) - tradeoff between latency between validators and ease of setting up one
  2. This is merely an upper bound to get feedback we are in the right cost vicinity. Will give breakdown of hardware and network specs needed, costs, and why in a few weeks time.
9

Thanks on this well thought feedback!

  1. I agree that there is a delicate tradeoff in. In the short term, I don’t think we will have significantly more than 100 influencial stakers by EOY (right now, while we have more than 100 stakers, many of them staked amounts that are very small and aren’t justifying a robust infra for sequencing long term). In the longer term, if we approach the 100 serious validators mark , we will inspect ways for lifting this barrier

  2. Since each block will be 2 seconds, after 2 seconds of being offline the responsibility will anyway move to another validator. You are correct it makes sense to somehow limit the affect of an offline validator further, I’m open to concrete suggestions that are future-compatible (in the sense that we can leave them also while anyone can propuse a block)

  3. Yes, the current intention is that the switch will be timelimited, we will discuss with Starknet’s security council how its usage should be communicated (transperantly) for justifying the security council approval for using it again

  4. Great point, will do!

  5. We will provide hardware suggestions as requested. We are also well aware that validators should have enough STRK staked to justify the cost. The STarkware delegation programs and potentially other similar programs should help in this regard. Thanks for the reference for TDS, will take a look!

  6. In the current suggestion, the mempool will stay private (only the seuqencer p2p, where transactions appear after they have been sequenced, will be shared with the validators). This means MEV, at least when other seqencers are concerned, is no issue for 0.15. (MEV for 0.15 as a whole, not by sequencers, is something we think about, and something simlar to timeboost for Starknet have been proposed in another thread). Am I missing something in this analysis?

  7. Note that in this milestone StarkWare would generate all blocks and get all transaction fees (and will also be the sole producer of proofs, which is actually more expensive than sequencing costs). We think this is fine as staking rewards, especially considering delegation programs, are much more significant than fees paid - but happy to receive feedbacks on this

10
  1. We will come up with concrete hardware specs in a few weeks time
  2. Stakers will be rewarded based on their stake, unless we have exactly 100 stakers, splitting makes no sense. You are right in the analysis that splitting could serve very large entities in “kicking” small ones, but this attack is not trivial to do for stakers that have a lot of delegated STRKs (they can’t just ask everyone to switch delegation to the other staker overnight), and gives very little (kicking out the 100th player means your stake as propotion of what the top 100 have put is increased by at most 1%) and comes with great social drawback - which is why I think this attack is unlikely. Do you agree with this analysis?
  3. While there are no in-protocol mechanisms planned ATM, There are dashboards that show liveness, and StarkWare itself will remove delegations from any validator that is underperforming (less than 99% availability)
11

Thanks for the clarification. Just one note: the current StarkWare delegation (1M STRK) is quite modest.

At 10% commission, it brings in around 7,730 STRK/year, or $950/year (~$79/month) at current prices - which is relatively low. If future validator requirements push infrastructure costs toward $1,000/month, this level of delegation won’t be enough to sustain many operators.

There is an ongoing delegation process from the Starknet Foundation as well, but the final amount and distribution criteria are still unknown.

In addition to a mainnet server, good practice - and in some cases a requirement - is to maintain a backup server and a testnet server. Both must meet similar performance standards, which further increases monthly costs. In fact, having a functioning testnet node will be a requirement for delegation eligibility from both StarkWare and the Starknet Foundation starting with staking V3.

Regarding the validator set: I disagree slightly with the idea that we won’t have more than 100 meaningful validators soon. The protocol itself sets 20k STRK as the minimum stake to run a validator - so anyone above that threshold should be considered a serious participant. Hard-limiting the set risks undermining decentralization as the network grows.

12

We support the direction towards progressive decentralization and view aligning validation with staking as an important milestone in Starknet’s evolution.

At the same time, we share some of the community’s concerns: limiting validation to the top‑100 stakers could unintentionally concentrate power and discourage new participants. A more inclusive or rotating committee design might better support decentralization in the long term.

13

Currently I am running servers in multiple locations, and whichever server receives the block first is the server that submits the attestation transaction.

When we transition to 0.15 will this still be the case? Will it still operate the same without the risk of double signing?

Ironically my home servers submit the attestations over 95% of the time and the data center servers only very occasionally make the attest. Maybe it is due to location or I have better network/switch gear than the data center.

14

RE point 2: Yeah, while I agree that such strategy doesn’t make sense for let’s say Ready or Braavos who have thousands of delegators but what prevents Binance from splitting those 40 millies they have and setting up 4 validators. And I assume there are more investors who hold significant amounts of STRK being approached by institutional validators who could do the same. As per current thinking, the more validators you have in the set, the higher the chance to become the “rewarded proposer”.

This points also echoes @saniksin’s comments that the current delegation parameters are quite modest to ensure sustainable decentralization.

15

I agree that nothing prevents Binance from doing so. However, they also gain very little. If currently binance has X STRK staked then the amount they get is propotional to X/X.+ <all STRK staked by others in top 100>. If they perform this attack then this formula isn’t changing, except the number of “STRK staked by others in top 100” drops a tiny bit. So its not like they are doubling their reward

I agree that delegation parameters should be inspected in the context of infra cost and staking yields - both are currently unknown

16

This is a solid step toward Starknet’s long-term decentralization vision. I like the incremental approach — aligning validation with staking while keeping performance impact minimal makes sense. The top-100 staker committee idea is interesting, though I think we should also explore mechanisms to keep smaller stakers engaged so we don’t concentrate influence too much early on. Excited to see how this evolves for v0.15.

17

At Stakely, we agree with the SNIP-33 proposal and we believe it is an important step towards Starknet decentralization. We understand that, in this first stage, limiting the active set to 100 validators can make coordination easier and help keep high performance.

However, we think this number is small and, in the long term, it might not help decentralization, as it could concentrate stake in fewer participants. The current total number of active validators is around ~160, so reducing to 100 means the stake from those outside will move to the ones staying in the set.

Our proposal is to select the 100 active validators randomly weighted by stake, so that all ~160 have the chance to participate. As a variant, it could be explored that, inside this randomness, a bit more weight is given to those who showed better performance in previous rounds, so that good performance slightly increases the chance to be selected. This would keep the network at ~160 total validators, avoid a too large committee that could hurt performance, and help reduce stake concentration, adding only a small complexity to the selection mechanism.