Starknet's validity proofs are generated by two primary prover implementations: Stone, the production prover currently securing the network, and Stwo, a next-generation prover under active development. Prover software releases dictate the performance, cost, and compatibility of proof generation for all entities submitting proofs to the L1 verifier. This page tracks versioned releases for both provers, providing SHARP operators, rollup teams using Starknet's proving stack, and application-specific provers with the information needed to maintain a reliable proving pipeline.
Protocols
Starknet Prover (Stone and Stwo) Release Notes
Chronological index of versioned releases for Starknet's core proving software (Stone and Stwo). Covers API changes for proof generation, new Cairo layout support, performance benchmarks, and breaking changes affecting SHARP operators and application provers.
introduction
PROVER SOFTWARE RELEASES
Introduction
Versioned releases of Starknet's core proving software, Stone and Stwo, detailing API changes, performance benchmarks, and breaking changes for SHARP operators and application provers.
Each release may introduce new Cairo layout support, alter proof generation APIs, or change the computational cost profile of proving operations. Breaking changes can require operators to update job submission logic, re-optimize Cairo program inputs, or adjust L1 verification cost models. Performance improvements, such as faster recursive proof composition or reduced memory footprints, directly affect proving latency and operational expenses for high-throughput environments.
Teams operating SHARP instances or integrating Starknet's proving system into their own rollup architectures should treat prover upgrades as critical infrastructure changes. A release that deprecates a layout or modifies the starkware_proof API can break automated proving pipelines without corresponding protocol-level changes. Chainscore can review prover integration upgrades, assess performance regressions against production workloads, and validate that proving pipelines remain compatible with the latest Stone and Stwo releases.
STARKNET PROVER RELEASE IMPACT
Release Snapshot
Operational impact assessment for teams integrating Stone or Stwo prover releases into their proving pipeline.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Cairo Layout Support | New layout types may be added or deprecated, altering proof generation requirements for specific application classes. | Application provers, SHARP operators, rollup teams | Verify layout compatibility against the release notes and test proof generation with target Cairo programs. |
Proof Generation API | API method signatures, request parameters, or response schemas may change, breaking existing integration code. | Prover operators, integration engineers | Review API diff in release notes and update integration code. Run integration tests against testnet before production deployment. |
Performance Benchmarks | Proving time, memory usage, or CPU requirements may shift, affecting operational cost and latency. | SHARP operators, rollup teams, infrastructure planners | Re-benchmark proving workloads with the new release. Resize instances if performance characteristics have changed. |
Breaking Changes | Removal of deprecated endpoints, changes in default behavior, or new mandatory parameters. | All prover operators | Audit release changelog for breaking changes. Schedule a maintenance window for migration and regression testing. |
L1 Verification Cost | Changes to proof structure or aggregation logic can alter the gas cost of L1 verification transactions. | SHARP operators, rollup teams managing L1 settlement | Simulate verification transactions on a testnet fork to estimate new L1 costs. Update cost models and alerting thresholds. |
Proving Pipeline Compatibility | A new prover version may require updated input generation, job scheduling, or output handling logic. | Teams running custom proving pipelines | Test the full pipeline end-to-end with the new prover binary. Validate job submission, proof retrieval, and error handling. |
Security and Bug Fixes | Releases may patch vulnerabilities or correctness bugs that affect proof validity. | All prover operators | Prioritize upgrades that include security fixes. Review advisory for exploitation risk and apply mitigations if immediate upgrade is not possible. |
technical-context
STONE AND STWO PROVING BACKENDS
Prover Architecture and Release Impact
Understanding the operational and integration impact of Starknet's prover release cycle, from the current Stone prover to the next-generation Stwo prover.
Starknet's validity proofs are generated by two distinct prover backends: the production Stone prover and the next-generation Stwo prover. Stone is the current, battle-tested STARK prover written in C++ and optimized for the existing Cairo VM. Stwo is a new prover, written in Rust, designed to be significantly faster and to support the next-generation Cairo VM. Release notes for these provers document breaking API changes, new Cairo layout support, performance benchmarks, and modifications to the proof generation pipeline that directly affect SHARP operators and application provers.
Operationally, a new Stone release may introduce a breaking change to the proof input format or deprecate a Cairo layout, requiring SHARP operators and rollup teams to update their job submission logic and re-validate their proving pipelines. A Stwo release marks progress toward its production readiness, with each version adding support for new Cairo features or improving proof generation speed. Teams running their own prover instances must track these releases to avoid submitting proofs that the L1 GpsStatementVerifier contract can no longer validate, which would cause a liveness failure for their L2-to-L1 messaging or state settlement.
Integration risk is concentrated in the interface between the prover and the SHARP job scheduler. A change in the prover's API, the expected binary format of a compiled Cairo program, or the dynamic layout selection logic can silently break a proof generation pipeline if the operator's client is not updated in lockstep. Chainscore can review prover integration upgrades, assess performance regressions against historical benchmarks, and validate that a team's updated proving pipeline correctly interacts with the target L1 verifier contracts before a release is deployed to production.
PROVER RELEASE IMPACT
Affected Systems and Actors
SHARP and Application Provers
Prover operators running SHARP instances or application-specific proving pipelines are directly affected by Stone and Stwo releases. Each version may introduce new Cairo layouts, modify proof generation APIs, or change job scheduling parameters.
Key actions:
- Review release notes for breaking API changes to proof submission endpoints.
- Test new prover versions in a staging environment before production cutover.
- Monitor proof generation benchmarks to detect performance regressions.
- Update job scheduling logic if proof aggregation parameters change.
- Verify L1 verification costs remain within acceptable bounds after upgrading.
Chainscore can review prover upgrade integration, assess performance regressions, and validate proving pipeline compatibility before production deployment.
implementation-impact
PROVER SOFTWARE RELEASES
Operational Impact Areas
Versioned releases of Stone and Stwo introduce API changes, new Cairo layouts, and performance characteristics that directly affect SHARP operators, application provers, and rollup teams relying on Starknet's proof system.
01
Proving Pipeline Compatibility
Each prover release may alter the proof generation API, modify supported Cairo layouts, or change input format requirements. SHARP operators and application provers must validate that their job submission pipelines are compatible with the new version before upgrading. Breaking changes in the prover interface can stall proof generation and delay L1 settlement. Chainscore can review prover integration upgrades and assess compatibility risks before production deployment.
02
Performance Regression Testing
New prover releases may introduce performance regressions that increase proof generation latency or computational cost. Teams operating SHARP instances or generating application proofs should benchmark new versions against their historical workloads before rolling out to production. Metrics to monitor include wall-clock proof time, memory consumption, and cost per proof. Chainscore can design and execute performance regression test suites for prover upgrades.
03
Cairo Layout Support Changes
Prover releases may add, deprecate, or modify support for specific Cairo layouts. Applications using custom or less common layouts must verify continued support before upgrading their proving infrastructure. A dropped layout can break proof generation for dependent applications and require migration to a supported layout. Chainscore can audit application proving pipelines for layout compatibility across prover versions.
04
L1 Verification Contract Compatibility
Proof outputs from new prover versions must remain verifiable by the deployed L1 verification contracts. SHARP operators should confirm that updated proof formats are accepted by the GpsStatementVerifier and fact registry before submitting proofs on mainnet. A mismatch can result in rejected verification transactions and wasted gas costs. Chainscore can validate end-to-end proof settlement across prover and verifier versions.
05
Multi-Prover Transition Planning
As Starknet transitions from Stone to Stwo, teams may need to operate both provers in parallel during a migration window. This requires dual pipeline maintenance, comparative benchmarking, and gradual cutover planning. Operators should define clear success criteria and rollback procedures before beginning the transition. Chainscore can provide migration architecture reviews and cutover validation for multi-prover deployments.
06
Cost Model Recalibration
Prover performance improvements or regressions directly affect the cost of proof generation and L1 verification. Teams should recalibrate their cost models with each release to ensure accurate pricing for users and sustainable economics for prover operations. Changes in proof aggregation efficiency can shift the break-even point for batch sizes. Chainscore can review prover cost models and recommend optimization strategies based on release benchmarks.
PROVER SOFTWARE UPGRADE IMPACT
Compatibility and Risk Matrix
Assess the operational and integration impact of new Stone and Stwo prover releases on proving pipelines, verification contracts, and dependent systems.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Cairo Layout Support | New or deprecated Cairo builtin layouts may be introduced, altering proof generation requirements. | Application provers, SHARP operators, rollup teams | Verify that your program's compiled layout is still supported and benchmark proof generation costs. |
Proof Generation API | API method signatures, input structures, or error codes for proof generation may change. | SHARP operators, automated proving pipelines | Review API diffs in release notes and update integration code before deploying to production. |
Verification Key Updates | New prover versions may require updated on-chain verification keys or contract logic. | L1 verification operators, bridge security teams | Confirm that the deployed GpsStatementVerifier contract is compatible with proofs from the new version. |
Performance Benchmarks | Proving time, memory usage, or CPU requirements may shift significantly between versions. | Infrastructure teams, cost-optimization engineers | Run benchmarks against your specific workload; do not rely solely on published general benchmarks. |
Proof Aggregation Logic | Changes to how SHARP aggregates multiple proofs can affect submission cost and latency. | SHARP operators, rollup teams using shared proving | Monitor L1 verification gas costs after upgrade and adjust job scheduling parameters. |
Breaking Changes | Deprecated features, removed CLI flags, or changed configuration formats. | All prover operators | Test upgrades in a staging environment against your full proving pipeline before mainnet rollout. |
Stwo Integration Milestones | New Stwo components may be introduced as experimental or alongside existing Stone binaries. | Early adopters, teams planning Stwo migration | Evaluate feature completeness against your proving requirements; do not assume production readiness. |
STONE TO STWO MIGRATION READINESS
Prover Upgrade Operator Checklist
A practical checklist for SHARP operators and application provers preparing for a Stone to Stwo prover upgrade. Each item identifies a critical verification step, explains its operational significance, and specifies the signal that confirms readiness before upgrading a production proving pipeline.
What to check: Compare the new prover's API specification for job submission, status polling, and result retrieval against the current Stone prover API your system integrates with. Focus on changes to required parameters, authentication methods, response schemas, and error codes.
Why it matters: A breaking API change in the proof generation request format will cause job submission failures, stalling your proving pipeline and potentially delaying L1 settlement if you are a SHARP operator.
Readiness signal: Your integration tests pass against a Stwo testnet endpoint using the same job submission client code that runs in production, with all response objects parsed without errors.
resource-links
STARKNET PROVER RELEASE REFERENCES
Canonical Resources
Use these primary resources to verify Stone and Stwo release status, compatibility notes, Cairo dependencies, and operational impact before changing a proving pipeline.
Chains We Build On
Looking to build on a specific blockchain?
We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.
EVM ecosystems
- Ethereum
- Arbitrum
- Optimism
- Polygon
- Avalanche
- Cronos
Non-EVM ecosystems
- Solana
- Sui
- Aptos
- Hedera
- Stellar
- NEAR
Additional ecosystems
- Polkadot
- Cosmos
- TON
- Cardano
- Algorand
- Tempo
Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.
PROVER RELEASE FAQ
Frequently Asked Questions
Common questions from SHARP operators, application provers, and rollup teams evaluating Stone and Stwo releases for proving pipeline compatibility, performance, and migration planning.
Stone is the current production prover, written in C++, and is the only prover capable of generating proofs that are verifiable by the L1 GpsStatementVerifier contract today. It supports all active Cairo layouts and is the required prover for SHARP operators submitting proofs to Ethereum mainnet.
Stwo is the next-generation prover, written in Rust, designed for significantly faster proof generation and a more modular architecture. It is currently in active development and not yet integrated into the mainnet SHARP pipeline.
Guidance:
- SHARP operators and mainnet provers must continue running Stone. Verify your Stone version against the canonical release tags.
- Application provers and rollup teams evaluating future performance should begin testing Stwo in isolated environments to understand the API changes and benchmark potential latency improvements.
- Do not attempt to submit Stwo-generated proofs to L1 until the fact registry and verifier contracts are upgraded to accept them.
Trusted by Industry Leaders
Delivering blockchain solutions for 5+ years.
We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.
Selected Partners & Clients
“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”
L
Lee Erswell
CEO, Telos Foundation
how to get started
How to get started?
If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
Explore More Solutions
Discover our
blockchain development services.
We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.
Book a Call
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.