Wrapping STARKs to SNARKs: When Proof Compression Actually Pays Off

Short summary (for listings): Wrapping STARK proofs into tiny, EVM‑friendly SNARKs can slash L1 gas and latency—if your pipeline and risk profile fit. This post gives concrete thresholds, emerging practices, and real‑world stacks (RISC Zero, SP1, Boojum) so you can decide when compression is worth it.

Why this matters now

If you’re settling to Ethereum mainnet, verifying a raw STARK on-chain is still prohibitively expensive in both calldata and execution gas. The economic reality on Ethereum since EIP‑1108 (pairing precompile discounts) and EIP‑4844 (cheap blob DA, unchanged calldata pricing) strongly favors posting small pairing‑based proofs. That’s why modern STARK stacks increasingly end in a Groth16/Plonk verifier on BN254, even when they use STARKs internally for proving speed, transparency, and post‑quantum properties. (eips.ethereum.org)

What “STARK → SNARK wrapping” actually is

At a high level, the pipeline has three layers:

Prove the computation with a STARK (fast prover; large proof).
Recursively compress/aggregate those STARKs with a STARK recursion circuit (keeps everything “transparent” so far).
Verify that recursive STARK inside a succinct SNARK (usually Groth16 on BN254) and post only the tiny SNARK on-chain.

Two concrete implementations:

RISC Zero zkVM
- RISC‑V execution → STARK “segment receipts” → STARK recursion into one “succinct receipt” (~200 kB) → STARK‑to‑SNARK circuit emits a Groth16 “receipt” that the on‑chain verifier checks. (dev.risczero.com)
Succinct’s SP1 zkVM
- Prover splits into shards → recursively compresses with STARKs → wraps as Groth16 (~260 bytes) or Plonk (~868 bytes) for EVM verification (~270–300k gas typical). (docs.succinct.xyz)

Bigger picture: zkSync’s Boojum also moved proving to STARKs for throughput, but explicitly plans a final pairing‑based wrapper so Ethereum verifies a succinct proof via BN254 precompiles. (zksync.mirror.xyz)

On-chain economics in 2025: why the wrap is cheap and the raw STARK is not

Pairing precompiles (EIP‑1108)
- Ethereum’s bn128/alt_bn254 precompiles make ECADD/ECMUL/pairing checks relatively cheap: pairing gas ≈ 45,000 + 34,000·k for k pairings. Groth16 verifiers typically perform a small constant number of pairings. (eips.ethereum.org)
Typical Groth16 verifier gas
- Empirical measurements put a Groth16 verify around ~200–300k gas, with a simple model ≈ 207,700 + 7,160 × l where l is the number of public signals (ex‑calldata). Real-world stacks and aggregators cite ~250–300k gas for on‑chain verification. (hackmd.io)
Calldata still bites
- EIP‑4844 created cheap blob DA for rollups, not cheaper calldata; proof bytes submitted to a verifier still pay 4/16 gas per byte (and EIP‑7623 proposes raising calldata price for data‑heavy txs). A ~260‑byte Groth16 is negligible; a ~200kB STARK is not. (blocknative.com)
Raw STARK verification gas and size
- STARK verification involves many Merkle openings and FRI queries; on Ethereum that means millions of gas plus very large calldata. Community measurements and notes place single STARK verification on the order of ~2.5–5.0M gas, and proof sizes in the ~100–200kB range. (community.starknet.io)

Net result: in today’s fee model, posting a Groth16/Plonk that attests to a STARK is orders of magnitude cheaper than posting/validating the raw STARK on L1.

The break-even: when does wrapping actually pay?

Think of the on‑chain cost per settlement as:

Raw STARK: Gas ≈ G_stark_verify + calldata_gas(proof_stark_bytes).
Wrapped: Gas ≈ G_snark_verify + calldata_gas(proof_snark_bytes).

Using conservative 2025‑era figures:

G_snark_verify ≈ 230k–300k; proof_snark_bytes ≈ 260–900 bytes (Groth16 vs Plonk) → calldata ≈ 4k–15k gas. Total ≈ 235k–315k gas. (hackmd.io)
G_stark_verify ≈ 2.5–5.0M; proof_stark_bytes ≈ 100–200kB → calldata ≈ 0.4–3.2M gas (depending on byte distribution). Total ≈ 2.9–8.2M gas. (community.starknet.io)

Even if your STARK verifier is unusually optimized, you need to be 10×–30× better than the common baselines to rival a Groth16 wrapped proof on Ethereum. Unless you’re verifying off‑chain (see “Verification layers” below) or on a chain with a native FRI/hash precompile, wrapping is the economic default for Ethereum L1.

A subtlety: EIP‑4844 reduces DA costs for rollups but does nothing for the cost of proof bytes passed to a verifier contract (they are calldata, not blobs). That tilt further favors SNARK‑wrapped proofs on L1. If EIP‑7623 (increase calldata price) lands, the gap widens. (blocknative.com)

Practical stacks that already do this (and what to copy)

RISC Zero (zkVM as an L1 coprocessor)
- Architecture explicitly includes a “STARK‑to‑SNARK” R1CS circuit that consumes the recursive STARK and outputs a Groth16 “receipt” verifiable in a canonical Solidity contract. On‑chain verification is milliseconds‑fast and small enough to be integrated into typical application flows. (dev.risczero.com)
- Security model separates the transparent STARK (post‑quantum assumptions) from the BN254 Groth16 translator (trusted setup; quantum‑vulnerable). Versioning uses a “control root” over allowed recursion programs to avoid new ceremonies on updates. (dev.risczero.com)
SP1 (Succinct)
- Offers three proof types: compressed (STARK only), Groth16 (~260 bytes, ~270k gas), and Plonk (~868 bytes, ~300k gas), with off‑chain/no_std and Wasm verification options and a ready‑to‑use EVM verifier template. Suitable when you want a fixed gas footprint and tiny calldata on any EVM chain. (docs.succinct.xyz)
zkSync Boojum
- Moved proving to a STARK‑centric library (Goldilocks field; GPU‑friendly), with an explicit final step to wrap in a pairing‑based SNARK for Ethereum verification—precisely to leverage EVM precompiles. (docs.zksync.io)

Security and governance trade‑offs you must accept (or mitigate)

Trusted setup vs transparency
- Groth16 needs a structured reference string. Many teams reuse Aztec’s “Ignition” ceremony; SP1 notes it seeds Groth16 keys from Ignition plus extra entropy. If you prefer no trusted setup, pick Plonk (universal/updatable SRS) at the cost of somewhat larger proofs (~868 bytes) and similar gas. (docs.succinct.xyz)
Quantum considerations
- Your inner STARK remains hash‑based and post‑quantum; the final Groth16 translator relies on BN254 pairings and would be vulnerable to a large quantum adversary. Most teams accept the risk window (quantum not imminent, upgradability possible). RISC Zero documents this split explicitly. (dev.risczero.com)
Upgradability hygiene
- Treat your on‑chain verifier address and verifying key hash as critical configuration. Copy RISC Zero’s pattern of versioned “control roots” for recursion programs or match SP1’s pinned VK bytes to make upgrades deliberate and auditable. (dev.risczero.com)

Cost modeling you can take to a budgeting meeting

Groth16 verify gas (rule of thumb)
- Base ≈ 207,700 gas + ~7,160 × (# public inputs), excluding calldata; add ~4–16 gas/byte for calldata. Many production verifiers sit near 230–300k gas. Keep public inputs tight by hashing bulky statements into one field element. (hackmd.io)
STARK‑to‑SNARK wrap overhead
- Proving time increases versus pure STARK (you run a SNARK prover after recursion). SP1 and RISC Zero provide dockerized provers; for typical zkVM traces, end‑to‑end wall clock commonly sits in tens of seconds to minutes on commodity cloud GPUs/CPUs. Use remote provers (Bonsai, SP1 prover network) to keep latency predictable. (dev.risczero.com)
Aggregation economics
- If you’re verifying many user proofs, on‑chain SNARK aggregation can drop marginal costs dramatically (e.g., ~380k fixed plus tiny per‑proof inclusion costs), but you must manage latency and liveness of the aggregator. (docs.electron.dev)

Emerging best practices we apply for clients

Start STARK, end SNARK on Ethereum
- For public mainnet verification, plan to wrap unless you’re delegating verification elsewhere (see “Verification layers”). The bn128 subsidy is too strong to ignore. (eips.ethereum.org)
Recursion before wrapping
- Always recursively compress STARK segments before the SNARK step; don’t SNARK‑wrap multiple large receipts independently. RISC Zero’s “lift → join → identity_p254 → compress” flow and SP1’s shard → compress → Groth16/Plonk are mature references to copy. (dev.risczero.com)
Keep public inputs minimal
- Gas for Groth16 grows with the number of public signals; hash or Merkle‑commit bulky inputs into one field element, and verify membership within the zkVM instead of exposing them to the verifier. (hackmd.io)
Choose your final SNARK by deployment target
- Ethereum L1/L2 EVMs: BN254 Groth16 is the sweet spot (smallest proof, lowest gas). If you won’t accept trusted setup assumptions, choose Plonk on BN254; expect ~10–30k more gas and ~3–4× larger proof than Groth16, still tiny compared to a STARK. (docs.succinct.xyz)
Separate “control” from “business” code
- Mirror RISC Zero’s control‑root approach so protocol upgrades don’t require a new ceremony or break old proofs; keep verifying key hashes and versioning clear and on‑chain. (dev.risczero.com)
Exploit EIP‑4844 for data, not proofs
- Post bulk witness/state data to blobs; keep the proof itself as a tiny calldata payload to your verifier. Don’t attempt to verify from blob data directly. Track EIP‑7623—if calldata price rises, the case for wrapping strengthens further. (blocknative.com)
Operationalize proving
- Use managed proving (e.g., Bonsai for RISC Zero; SP1 prover network) to bound latency and capex. Bake in retries and fallbacks; proofs fail for mundane reasons (OOM, timeouts). (dev.risczero.com)

Verification layers: an alternative to on‑chain pairings

A newer option is to send your heavy proof to an off‑chain verification layer (often restaked and decentralized), get a signed attestation, and verify that on Ethereum for a fraction of pairings gas. For example, Aligned Layer reports ~40k gas per proof to verify a signature over the verification result, while supporting proof systems (including RISC0/SP1) that would be too expensive to verify natively in the EVM. Trade‑offs: added trust in the operator set and EigenLayer security assumptions, plus extra latency/batching. This can be compelling for high‑frequency B2B attestations or cross‑chain proof markets. (blog.alignedlayer.com)

Concrete scenarios and our recommendations

L2 rollup or zk light client settling on Ethereum L1
- Wrap. Your settlement proof should be Groth16/Plonk on BN254. Keep public inputs tiny; push ancillary data to blobs. If you’re STARK‑native internally (Boojum, RISC0, SP1), keep that and only SNARK‑wrap the final recursive receipt. (zksync.mirror.xyz)
Application‑specific coprocessor (oracle verification, signature batching, AI inference attestation)
- Wrap, unless you’re posting to a verification layer. Gas predictability matters for UX; budget ~250–300k per verification and <1 kB calldata. (dev.risczero.com)
Cross‑chain deployments
- Prefer Groth16 on BN254 where the destination supports pairings (many EVM chains and even Solana via BN254 precompiles are viable targets; SP1 ships verifiers for both). (github.com)
Strict no‑trusted‑setup governance
- Use STARK internally, wrap with Plonk rather than Groth16. You’ll still be far cheaper than raw STARK verification on Ethereum while avoiding a per‑circuit ceremony. (docs.succinct.xyz)
Very high‑volume proof inclusion (thousands+ per day) with tight gas SLOs
- Consider an attested verification layer to reduce gas to tens of thousands per inclusion. Keep an on‑chain pairing verifier as fallback for resilience. (blog.alignedlayer.com)

Implementation blueprint (90‑day plan)

Weeks 1–2: Choose zkVM and wrap strategy
- Pick RISC Zero or SP1 based on language/runtime and your ecosystem targets. Decide Groth16 (lowest gas) vs Plonk (no per‑circuit ceremony). Stand up dockerized provers and template EVM verifiers from vendor repos. (dev.risczero.com)
Weeks 3–5: Model gas and calldata
- Prototype your public inputs to fit within ~4–8 field elements; hash everything else inside the guest. Benchmark verify gas with your actual public inputs; aim for 230–300k gas. (hackmd.io)
Weeks 6–8: Proving pipeline hardening
- Implement recursion joins (RISC0 lift/join/identity_p254) or SP1 shard compression. Add retries, telemetry, and artifact signing. Target end‑to‑end proof latency under 2–5 minutes on commodity cloud. (dev.risczero.com)
Weeks 9–10: Security review
- Audit guest code and verifier contract; lock verifying key hashes; implement allow‑listed control program IDs (RISC0) or pinned VK bytes (SP1). (dev.risczero.com)
Weeks 11–13: Mainnet dress rehearsal
- Simulate high‑watermark batches, blob DA for data, and on‑chain verifications at target gas prices. If needed, integrate a verification layer for hot‑path scaling while keeping direct pairing verification as a fail‑safe. (blocknative.com)

A worked micro‑example: zk light client checkpoint

Goal: post a periodic L1 checkpoint attesting to N L2 blocks.

Proving
- Use zkVM to verify the L2 consensus and state transition for those N blocks; produce a recursive STARK receipt.
- Wrap to Groth16. Expect proof ≈ 260 bytes; public inputs: {root, epoch, vkey hash, nonce} ≈ 4–6 elements. (docs.succinct.xyz)
On‑chain verification
- Gas ≈ 207,700 + 7,160 × 6 ≈ 250–260k; calldata ≈ 260 bytes → ~4k gas; total ~255k gas. Update a mapping by root/epoch. (hackmd.io)
Cost avoidance
- Without wrapping, a single STARK verify could be ~3–6M gas and ~100–200kB calldata (>1–3M gas more)—a non‑starter on busy days and fatal if calldata pricing increases. (community.starknet.io)

Key risks and how to mitigate

Ceremony risk (Groth16): reuse well‑audited ceremonies (Ignition), keep keys public, add multi‑party contributions, or pick Plonk. (docs.succinct.xyz)
Quantum risk: accept the near‑term window and plan a migration path (e.g., rotate to a post‑quantum final wrapper later). Track Ethereum precompile roadmap for alternative curves/commitments. (dev.risczero.com)
Vendor lock‑in: prefer open‑source zkVMs (RISC0, SP1), export proofs in standard formats, and keep verifier code minimal and audited. (dev.risczero.com)

Bottom line for decision‑makers

On Ethereum in 2025, wrapping STARKs to a pairing‑based SNARK is almost always the dominant strategy for on‑chain verification. You retain the proving speed, transparency, and scalability of STARKs while paying a few hundred thousand gas to verify a 260–900 byte proof—benefiting from bn128 precompiles and insulating yourself against calldata pricing headwinds. Unless you’re verifying off‑chain via a restaked verification layer or deploying to a chain with native STARK precompiles, plan to wrap. (eips.ethereum.org)