Can anyone run a prover on Starknet and what resources or costs are required
This fact-check may be outdated. Consider refreshing it to get the most current information.
Executive summary
Anyone can run a Starknet prover in principle: Starknet’s roadmap and docs state provers are permissionless and the SN Stack, SHARP and open-source prover code make running provers feasible for community operators [1] [2] [3]. In practice, until recent upgrades, most proofs were produced via the shared SHARP service to amortize costs; the S-two (Stwo) open‑source prover and SHARP integration are intended to lower proving time (from ~24 minutes to under 3 minutes for a 2B L2 gas block in S-two MVP tests) and reduce costs by at least half, enabling consumer‑grade hardware and client‑side proving over time [4] [5] [6].
1. Who can run a prover — the published rules
Starknet documentation and FAQs state that sequencers and provers are meant to be permissionless components of the network: “Anyone will be able to set up a prover and create proofs for the validity of new blocks” and the SN Stack is published so community teams can use the components that power Starknet [1] [2]. StarkWare also committed to open‑sourcing the prover under Apache 2.0 as part of the decentralization roadmap, which removes a legal barrier to running your own prover [3].
2. The practical path today — SHARP and shared proving
Starknet currently uses SHARP, a shared proving service that aggregates many Cairo program executions into a single STARK proof to amortize cost. That means most ecosystem participants rely on SHARP (or managed services like Atlantic) rather than running a bespoke prover to avoid high per‑proof overheads [4] [1]. Documentation notes SHARP “is used to reduce costs and improve efficiency within the network,” and the transition of SHARP to S-two is part of the plan to make proving more affordable [4].
3. Resources required — software, hardware and integrations
The software stack is public: SN Stack components (Papyrus, Cairo VM, provers, verifiers), example prover implementations (Stone, Stwo), and community tooling are published on GitHub and the Starknet docs — so the technical prerequisites are available [2] [7] [8]. Hardware needs vary: recursive STARKs and the SHARP model were explicitly introduced to allow smaller, more available compute instances instead of huge monolithic servers, and Starknet materials highlight that S-two was designed to enable consumer‑device proving (phones/laptops) over time [9] [10]. Exact CPU/RAM/IO targets are not specified in the provided sources; available sources do not mention a concrete minimum machine spec.
4. Costs — economic reality vs. marketing claims
Historically, proving was expensive enough that SHARP was necessary to amortize cost; Starknet’s documentation frames SHARP as the current cost‑reduction mechanism [4] [1]. Starknet’s S-two rollout claims large efficiency gains: the S-two MVP promises reducing proof time for a 2B L2 gas block from 24 minutes to under 3 minutes and “decrease proving costs by at least half,” and later material touts orders‑of‑magnitude throughput improvements and consumer‑grade proving [5] [6]. Those are vendor and protocol claims; third‑party reporting repeats them but does not publish independent benchmark cost tables in the provided set [10] [11]. Therefore, exact dollar costs per proof or per‑block on today’s mainnet are not present in current reporting — not found in current reporting.
5. Decentralization incentives and hidden agendas
StarkWare and the Starknet project have an explicit roadmap to decentralize sequencing and proving; open‑sourcing the prover and publishing the SN Stack advance that goal [3] [2]. But there is a practical transition period: a shared prover (SHARP) and managed services remain core to operations today to keep fees reasonable and latency low [4]. The incentives for StarkWare and collaborators to promote S-two and SHARP include reducing fees and unlocking new use cases (and business opportunities around managed proving services and tooling) — those incentives align with decentralization in public messaging but also preserve a phased migration pattern [2] [4].
6. What to do if you want to run one — an actionable roadmap
Start by cloning and testing the SN Stack and related GitHub projects (Papyrus, provers, Lambdaclass’s starknet_stack examples) to run a local chain and watcher‑prover; experiment with the Stone/Stwo codebases and follow SHARP integration docs [8] [7] [4]. Join the Starknet community channels and follow the decentralization roadmap and FAQ for validator/prover participation rules and staking requirements as the network moves to a multi‑sequencer/validator model [2] [1].
Limitations: sources here provide feature claims, roadmaps and developer guidance but do not publish a granular, independent cost schedule or minimum hardware spec — available sources do not mention those specifics [5] [4].