SHARP Operator Guide

The SHARed Prover (SHARP) is Starknet's shared infrastructure for generating and settling validity proofs on Ethereum L1. Instead of each application submitting its own proof, multiple Cairo programs—from Starknet OS blocks to standalone application logic—are batched into a single aggregated proof. This design amortizes the L1 verification gas cost across many jobs, making on-chain verification economically viable for a wide range of workloads. A SHARP operator runs the pipeline that collects proof jobs, generates a composite proof using Starknet's proving software (Stone or Stwo), and submits the final proof to the GpsStatementVerifier contract on Ethereum.

The operational lifecycle of a SHARP job begins when a user or sequencer submits a Cairo program execution trace. The SHARP operator aggregates these jobs, manages the proof generation queue, and decides when to trigger the proving process based on economic thresholds and time constraints. Once a proof is generated, the operator submits an L1 transaction to verify it, paying the gas cost upfront. The system then reconciles costs by attributing a pro-rata share of the L1 verification fee to each job included in the batch. Operators must continuously monitor the proving pipeline for stalls, L1 gas price volatility, and verification transaction failures that can delay finality for all dependent systems.

For teams running a SHARP instance, operational resilience depends on robust job scheduling, L1 gas management, and failure recovery procedures. A delayed or failed proof submission does not just affect a single application; it blocks the L1 state update for every job in that batch, impacting bridges, L2-to-L1 messaging, and any protocol relying on verified Starknet state. Chainscore can review SHARP deployments for cost efficiency, pipeline health monitoring, and disaster recovery readiness, ensuring that prover operators maintain reliable verification throughput under varying network conditions.

The SHARP (SHARed Prover) pipeline is the operational backbone that converts Cairo program execution traces into verified STARK proofs and settles them on Ethereum L1. For an operator, the pipeline is not a single software component but a sequenced workflow: a Cairo program and its inputs are submitted as a job, the Stone (or next-generation Stwo) prover generates a STARK proof, multiple proofs are aggregated into a single recursive proof, and a final Solidity verifier contract on L1 checks the proof and updates the state root in the fact registry. Understanding this architecture is essential for managing throughput, latency, and cost.

Operationally, the most critical decision point is the aggregation strategy. SHARP aggregates proofs from disparate applications into a single L1 verification transaction, amortizing gas costs across all participants. An operator must monitor the proof aggregation queue, configure job scheduling policies to balance latency against cost efficiency, and manage the L1 verification transaction submission—including gas price estimation and nonce management—to prevent stalled proofs. The pipeline's health is defined by the time from job submission to L1 fact registration, with key failure modes including prover crashes, insufficient L1 gas funding, and data availability mismatches between the generated proof and the on-chain state.

For teams running SHARP instances, the operational surface includes the prover's Cairo layout compatibility, the fact registry contract's state on L1, and the economic parameters of proof submission. A misconfigured prover can generate proofs that the L1 verifier rejects. A poorly timed L1 transaction can incur excessive costs or delay finality for dependent L2-to-L1 messages. Chainscore can review a SHARP deployment's end-to-end architecture, validate job scheduling and aggregation logic, and stress-test the pipeline against L1 gas volatility to ensure reliable and cost-optimized verification throughput.