Who can operate a prover on Starknet — individuals, validators, or only specialized firms? Are independent actors currently running their own provers now ?
This fact-check may be outdated. Consider refreshing it to get the most current information.
Executive summary
Starknet’s prover — the software that generates cryptographic proofs for blocks — is now open-source (S-two/Stwo) and integrated into SHARP, enabling independent operators, validators, and even client devices to run proving workloads; StarkWare and Starknet documentation explicitly say the stack and S-two are open-source to allow anyone to run provers and contribute compute to the network [1] [2] [3]. Recent deployments of S-two on mainnet are described as allowing “independent operators to contribute computing resources,” and SHARP’s architecture lists the prover component as a discrete, replaceable element [4] [5]. Available sources do not mention a formal restriction that only specialized firms may operate provers.
1. Who can operate a prover? — Open-source by design, not permissioned
StarkWare and Starknet documentation state the prover (Stone and the next‑gen S-two/Stwo) is open-source and part of the SN Stack, which is intended to let “anyone” run the pieces that power Starknet — including provers — under permissive licenses such as Apache 2.0 [6] [7] [8]. The SHARP documentation explicitly lists the Prover as a component (either Stone or S-two) that generates STARK proofs for Cairo PIEs, signaling modularity and the technical possibility for diverse operators to run prover nodes [5]. Starknet blog posts and StarkWare announcements frame this openness as a decentralization step: open-sourcing the prover “will allow the community to maintain and develop the network independently” [7] [3].
2. Practical reality today — mainnet S-two rollout and independent operators
Multiple news reports covering the S-two rollout stress that the new prover “allows independent operators to contribute computing resources,” and that S-two has been deployed to prove every Starknet block on mainnet, replacing previous proving components [4] [2] [9]. StarkWare’s messaging emphasizes that S-two is fast enough to enable client‑side proving on phones and laptops, expanding the potential operator set beyond specialized datacenters [2] [1]. SHARP (the shared prover service) was designed to aggregate proving jobs and accept proofs from provers, reinforcing the model where different provers can submit proofs into a shared pipeline [5].
3. Validators vs. independent provers — overlapping roles but distinct responsibilities
Starknet’s decentralization roadmap explains that staking and validator responsibilities are being phased in across stages: staking stages aim to give validators increasing responsibility (attesting, validating, and eventually producing and proving blocks), while separately the prover ecosystem is being opened to the community [3] [10]. Roadmap language notes validators will assume full responsibility for maintaining and operating the network in later staking phases, and that at the same time the proving process is moving toward open-source S-two; however, one Starknet page also cautions “the proving process will remain centralized under StarkWare” in an earlier phase — indicating transitional complexity rather than a permanent single-operator model [10] [3].
4. Are independent actors already running provers? — evidence of early non‑StarkWare contributions
Reporting and community examples show independent proof submissions have occurred historically and that the SN Stack contains community-built provers and verifier components [11] [8]. Blockworks and Starknet materials point to third‑party implementations and experiments: Sandstorm was the first open-source STARK prover to submit an independent proof, and engineers have personally built provers and submitted proofs to Starknet verifiers as proof‑of‑concepts [12] [11]. News about S-two’s mainnet deployment emphasizes that independent operators can now contribute compute resources [4] [13].
5. Friction points and real-world limits — code availability ≠ instant mass participation
Open-sourcing the prover eliminates legal barriers, but operational and economic challenges remain. Starknet and third‑party reporting highlight that S-two is fast and lighter, enabling client devices, but running production-grade provers at scale still requires software integration (SHARP gateway, schedulers, validators) and potentially nontrivial ops work [5] [1]. The roadmap also implies staged decentralization: validators won’t immediately take over all duties — transition phases, staking coupling, and shared proving integration mean the ecosystem will decentralize over time rather than overnight [3] [10].
6. Competing narratives and the stakes — decentralization vs. operational stability
StarkWare frames open-sourcing S-two as both a performance and decentralization milestone; industry outlets echo that message and stress independent contribution improves censorship resistance [4] [2] [13]. At the same time, Starknet’s own roadmap candidly warns that proving remained centralized under StarkWare during earlier phases, and that decentralization is a multi‑stage effort tied to staking and protocol upgrades [10] [3]. That tension—between “open to anyone” and “practical centralization during phased rollout”—is explicit in the sources.
7. Bottom line for operators and observers
Technically and legally, individuals, validators, and firms can operate provers: the code and SN Stack are open-source, SHARP accepts proofs, and the S-two rollout is described as permitting independent operators to contribute compute [7] [5] [4]. Independent, non‑StarkWare proofs and experimental provers have already been submitted in the ecosystem [11] [12]. However, full, widespread decentralization is a staged roadmap item with operational and economic frictions that mean specialized firms will likely remain important actors during the transition [10] [3]. Available sources do not mention any rule that only specialized firms may run provers.