Two privacy coins and a dozen Ethereum rollups are betting on completely different math to prove things without revealing them. Monero has leaned on Bulletproofs since 2018. StarkNet, Immutable’s zkEVM, and Polygon Miden have built their scaling stacks on zk-STARKs. Both promise the same headline feature, a way to prove a statement is true without showing the underlying data, but the engineering trade-offs between them are large enough to decide which chains survive a quantum computer and which ones stay cheap to run on Ethereum today.
This comparison pulls proof-size and benchmark data from three independent academic studies, current adoption numbers from StarkNet and Immutable, and the gas-cost math that Ethereum rollups actually pay to post STARK proofs on-chain. Neither system needs a trusted setup, which already rules out the classic “SNARK versus everything else” framing. What separates Bulletproofs from zk-STARKs is proof size, verification speed, and whether the underlying math survives Shor’s algorithm.
Both systems fall under the broader umbrella of zero-knowledge proofs, cryptographic constructions that let one party convince another that a statement is true without revealing why. What makes Bulletproofs and zk-STARKs worth comparing directly, instead of lumping them in with zk-SNARKs, is that they occupy opposite corners of the design space: one optimizes hard for compactness on a single, narrow statement (a value sits in a range), the other optimizes for handling any computation at all, at the cost of a much bigger proof. Neither is a drop-in replacement for the other, and picking wrong shows up later as either bloated transactions or unaffordable gas bills.
How Bulletproofs Work
Bulletproofs, introduced by Bünz, Bootle, Boneh, Poelstra, Sasson, and Maxwell in the 2017 paper published on the IACR eprint archive, are built around an inner-product argument over elliptic curve groups. The core trick is a range proof: proving a committed value falls between 0 and 2^n without revealing the value itself. The original paper shows the proof for an n-bit range needs only 2·log2(n) + 9 group and field elements, so proof size grows logarithmically with the bit length of the range, not linearly. That is the entire pitch: small proofs, no setup ceremony, straightforward math.
Under the hood, a value is first hidden inside a Pedersen commitment, a homomorphic commitment scheme that lets the prover add and manipulate committed values without ever opening them. The range proof then reduces to showing that a polynomial built from the bits of the committed value satisfies specific algebraic constraints, and the inner-product argument compresses what would otherwise be a linear-size proof down to a logarithmic one by recursively folding the vectors in half at each round. Aggregation is where Bulletproofs get genuinely clever: proving that eight separate outputs are all in range costs barely more than proving one, because the aggregated proof shares most of its structure across all eight statements, which is exactly why Monero batches range proofs across a transaction’s outputs instead of sending one per output.
Monero adopted Bulletproofs for RingCT range proofs in 2018 and moved to the improved Bulletproofs+ construction in late 2020. On Monero’s Ed25519 curve, a single original Bulletproofs proof for one output runs about 676 bytes. Bulletproofs+ trims that by roughly 96 bytes per proof, landing at 576 bytes. A newer variant, Bulletproofs++, compresses a 64-bit range proof down to 416 bytes, a reduction Blockstream Research describes as making range proofs nearly 40% smaller than the original design. Range proofs alone still account for 29% to 42% of a typical Monero transaction’s size, so every byte saved here matters at the protocol level.
The catch is the underlying assumption. Bulletproofs rely on the hardness of the discrete logarithm problem over an elliptic curve, the same category of math that Shor’s algorithm breaks on a sufficiently large quantum computer. That makes Bulletproofs fast, compact, and setup-free today, but not a long-term bet against quantum adversaries.
How zk-STARKs Work
zk-STARKs, developed by Eli Ben-Sasson and the team that later founded StarkWare, take a different path entirely. Instead of elliptic curve commitments, STARKs encode a computation as an algebraic execution trace, then use the FRI (Fast Reed-Solomon Interactive Oracle Proof of Proximity) protocol and Merkle trees, built purely from hash functions, to prove the trace is consistent. StarkWare’s own 2018 paper on the construction is framed around the words “scalable, transparent, and post-quantum secure,” and that title is the whole sales pitch: no trusted setup, and security that rests on hash collision resistance rather than number-theoretic assumptions.
The workflow starts by running the program and recording every register and memory state at every step, the execution trace. That trace gets interpolated into a low-degree polynomial, and FRI proves that the polynomial really is low-degree without a verifier ever seeing the whole thing, by repeatedly folding it and spot-checking random points. Every value that goes into the proof is hashed into a Merkle tree, so verifying the proof means checking a handful of Merkle paths and a few polynomial evaluations rather than re-running the entire computation. StarkWare’s own interactive walkthrough, STARK 101, breaks this arithmetization-to-proof pipeline down for engineers who want to see the actual field arithmetic instead of just the marketing summary.
Proof size for STARKs grows polylogarithmically with the size of the computation being proven, technically worse asymptotics than Bulletproofs’ pure logarithmic growth, but in practice STARK proofs handle arbitrary computation, not just range proofs, which is why they underpin general-purpose zkVMs like Cairo (StarkNet), Polygon Miden, and RiscZero. The trade-off shows up immediately in raw proof size: where a Bulletproofs range proof fits in a few hundred bytes, a STARK proof for a realistic circuit lands in the tens of kilobytes, and can exceed 500 KB for heavier computations.
Because STARKs don’t depend on elliptic curve discrete logs, they are considered post-quantum secure. Grover’s algorithm gives quantum computers a quadratic speedup against hash-based schemes, which is why STARK security parameters are set high enough that a 128-bit classical security level still leaves roughly 64-bit security against a quantum adversary, a comfortable margin for now.
Bulletproofs vs zk-STARKs: Full Specs Comparison
The table below lines up the two systems across the properties that actually decide which one a protocol team picks.
| Property | Bulletproofs / Bulletproofs+ | zk-STARKs |
|---|---|---|
| Introduced | 2017 (Bünz, Bootle, Boneh et al.) | 2018 (Ben-Sasson et al., StarkWare) |
| Core primitive | Inner-product argument, elliptic curve commitments | FRI protocol, Merkle trees, hash functions |
| Trusted setup | None (transparent) | None (transparent) |
| Security assumption | Discrete logarithm problem | Collision-resistant hash functions |
| Quantum resistance | No, vulnerable to Shor’s algorithm | Yes, hash-based security |
| Proof size (64-bit range) | 416-676 bytes depending on variant | Not applicable (general computation, not a single range) |
| Proof size (general circuit) | Grows with number of constraints, kilobytes for complex statements | Roughly 45 KB to 200+ KB for realistic circuits |
| Size scaling | Logarithmic in bit length and output count | Polylogarithmic in computation size |
| Typical verification time | Under 1 ms to a few ms per range proof | 10 ms to 20 ms per proof |
| Typical proving time | 4 ms to 73 ms for range proofs, seconds for large aggregates | Roughly 1.6 seconds for mid-size circuits |
| Primary production use | Confidential transactions (Monero, Grin, Liquid) | ZK-rollups and zkVMs (StarkNet, Immutable, Miden) |
| General-purpose computation | Limited, optimized for range proofs | Yes, arbitrary programs via zkVMs |
| On-chain verification cost (Ethereum L1) | Not designed for EVM gas model | 2.5M to 6M+ gas per proof, depending on aggregation |
Two rows carry most of the decision weight for teams building today: quantum resistance and general-purpose computation. Bulletproofs win on raw compactness for a narrow job (range proofs). STARKs win when the statement being proven is an arbitrary program and the system needs to still be secure in 15 years.
Benchmark Data From Three Independent Studies
Vendor claims about proof systems are common. Independent benchmarks are rarer, and three recent ones give a consistent picture even though they test different circuits and hardware.
A 2024 study published in the journal Information, “Evaluating the Efficiency of zk-SNARK, zk-STARK, and Bulletproof in Real-World Scenarios,” ran a MiMC hash circuit through all three systems. For a small instance, Bulletproofs produced a 737-byte proof in 6.756 ms of proving time, verified in 0.899 ms. On a larger, more realistic circuit, the same Bulletproofs implementation produced a 1,300-byte proof but took 30 seconds to prove and 1.1 seconds to verify. The STARK implementation in the same study produced a 45,000-byte (45 KB) proof, but proving finished in 1.6 seconds and verification in just 16 milliseconds.
A related benchmarking thesis from the University of Twente, testing the same three protocol families in an equivalent practical application, reached a similar conclusion from a different angle: STARK proofs were the largest by far, but STARK proving and verification were the fastest on average across the tested workloads, while Bulletproofs were the slowest in both proving and verification time once circuits grew past simple range proofs.
A third paper, a 2025 comparative evaluation presented at SCITEPress, focused specifically on 64-bit range-proof configurations rather than general circuits, the use case Bulletproofs was actually designed for. There, Bulletproofs looked far better: proof generation in 55 ms to 73 ms depending on hardware, verification in 4.7 ms to 8.6 ms, and a proof size holding steady at 672 bytes. That result matters because it shows Bulletproofs’ reputation for being “slow” only holds once you push it outside its home turf of range proofs into general-purpose circuit territory.
| Study | Workload | Bulletproofs result | zk-STARK result |
|---|---|---|---|
| Information (2024), small instance | MiMC hash circuit | 737 bytes, 6.8 ms prove, 0.9 ms verify | Not tested at this scale in the cited table |
| Information (2024), large instance | MiMC hash circuit | 1,300 bytes, 30 s prove, 1.1 s verify | 45 KB, 1.6 s prove, 16 ms verify |
| University of Twente thesis (2024) | Equivalent practical application | Slowest proving and verification of the three protocols tested | Fastest proving and verification on average |
| SCITEPress (2025) | 64-bit range proof | 672 bytes, 55-73 ms prove, 4.7-8.6 ms verify | Not the focus circuit of this study |
The pattern across all three: Bulletproofs stay small and fast when the job is a narrow range proof. Once the statement becomes a general computation, Bulletproofs’ proving time balloons while STARK verification stays fast and predictable despite the much larger proof.
Quantum Resistance: The Assumption Gap
This is the single biggest architectural difference between the two systems, and it doesn’t show up in a benchmark table. Bulletproofs derive their security from the discrete logarithm problem on an elliptic curve, the same family of hard problems behind RSA and ECDSA that Shor’s algorithm can solve in polynomial time on a large enough quantum computer. No known variant of Bulletproofs changes this. The entire inner-product argument is built on curve arithmetic.
zk-STARKs avoid that dependency by construction. Every commitment in a STARK proof is a hash, and every check reduces to hash collision resistance and low-degree testing over a finite field. Grover’s algorithm still applies to hash-based schemes, but it only offers a quadratic speedup rather than the exponential break Shor’s algorithm gives against discrete log and factoring problems. StarkWare’s original paper leans on this directly, framing “post-quantum secure” as a first-class design goal rather than an afterthought.
For a privacy coin like Monero, this is a known, accepted trade-off. The project has been open that Bulletproofs are not quantum-safe and treats it as a future migration problem rather than an immediate one. For an Ethereum L2 expecting to secure billions of dollars in value for a decade or more, the calculus is different, which is a large part of why StarkNet, Immutable’s zkEVM, and Polygon Miden all built on STARK-based proving from day one instead of retrofitting it later.
There’s also a “harvest now, decrypt later” angle specific to privacy systems that doesn’t apply the same way to a rollup’s validity proofs. A validity proof only needs to be sound at the moment it’s verified, once a STARK or Bulletproofs proof is checked and a block finalizes, there’s nothing left to retroactively break. Confidential transaction amounts are different: if an adversary records encrypted or range-proofed transaction data today and a cryptographically relevant quantum computer arrives in a decade, discrete-log-based privacy guarantees on that historical data could be unwound after the fact. That asymmetry is a big part of why the post-quantum conversation around Bulletproofs is framed as a privacy problem first and a scaling problem second.
Trusted Setup and Transparency, Explained
Both systems are correctly described as transparent, meaning neither requires a trusted setup ceremony where participants generate a structured reference string that must be destroyed afterward. This puts both Bulletproofs and zk-STARKs in the same camp as Halo 2 and against SNARK constructions like Groth16 that need a per-circuit ceremony. Ethereum.org’s own documentation on ZK-rollups flags trusted setup risk as one of the main reasons some rollup teams gravitate toward transparent systems in the first place, since a compromised or poorly run ceremony can undermine the entire proof system’s soundness.
But “no trusted setup” doesn’t mean “no assumptions.” Bulletproofs’ transparency comes at the cost of relying on a classical hardness assumption that quantum computing eventually breaks. STARKs get transparency and post-quantum security simultaneously, which is precisely why survey papers like the TU Munich zero-knowledge proofs overview list both as “trusted setup: no” in the same table, while separating them sharply on the security-assumption axis. The practical result: if a protocol’s only requirement is avoiding a ceremony, either system qualifies. If the requirement is avoiding a ceremony and surviving a future quantum adversary, only STARKs clear both bars.
On-Chain Verification Costs and Pricing
Verification cost is where the two systems diverge in a way that has nothing to do with cryptography and everything to do with where they’re deployed. Bulletproofs are verified as CPU operations inside a blockchain’s consensus code, Monero, Grin, and Liquid all check proofs this way, so cost is measured in milliseconds of compute, not gas. STARKs, by contrast, are frequently verified on Ethereum L1 itself, where every operation costs gas, and that cost is well documented because StarkNet publishes it.
| Proof system / configuration | Verification cost | Context |
|---|---|---|
| Bulletproofs+ (64-bit range, per proof) | ~0.9 ms CPU time | No gas model, verified in-consensus (Monero, Liquid) |
| Original Bulletproofs (64-bit range, per proof) | 4.7-8.6 ms CPU time | SCITEPress 2025 benchmark, varies by hardware |
| Raw STARK verification, single proof | ~2.5M-5M gas | Direct on-chain verifier, before calldata costs |
| STARK calldata (100-200 KB proof) | ~0.4M-3.2M gas | Cost scales with EIP-7623 calldata pricing |
| SHARP aggregated proof (“train”) | ~6M gas per train | StarkNet batches many L2 blocks into one L1 verification |
| Per L2 block inside a SHARP train | ~215K gas | Fixed cost once amortized across a batch |
| Optimized partial-aggregation batch | ~200K-500K gas | Lower-bound configurations cited in rollup cost comparisons |
The takeaway isn’t that STARKs are expensive and Bulletproofs are cheap in some universal sense. It’s that Bulletproofs were never designed to be posted to an EVM chain and priced in gas, while STARKs were designed exactly for that job, and StarkNet’s entire economic model is built around amortizing that 6M-gas SHARP cost across as many L2 blocks as possible to push the per-user fee down. A protocol that needs cheap on-chain verification on Ethereum has to think in aggregation strategy, not raw proof size, when working with STARKs. That framing also explains why side-by-side dollar comparisons of the two systems are misleading on their own, Bulletproofs’ cost lives entirely in CPU cycles a node operator already pays for, while a STARK proof’s cost is a line item paid directly in ETH gas, denominated by whatever the network’s base fee happens to be at the moment the proof lands on-chain.
Real-World Deployments in 2025 and 2026
Monero remains the highest-profile Bulletproofs deployment. Every confidential transaction on the network uses Bulletproofs+ range proofs, and the project’s own documentation notes range proofs still make up 29% to 42% of total transaction size even after the 2020 upgrade from the original Bulletproofs construction.
Grin and the Mimblewimble protocol built their confidential transaction model around Bulletproofs-style range proofs from the start, using them to hide transaction amounts while keeping the ledger auditable for sum-based verification, the core trick that makes Mimblewimble blocks so much smaller than typical UTXO chains.
Blockstream’s Liquid Network uses the newer Bulletproofs++ construction for confidential assets, taking advantage of the 416-byte proof size, the smallest of any variant discussed here, to keep confidential asset transfers compact on a federated sidechain.
StarkNet, StarkWare’s Ethereum L2, is the flagship zk-STARK deployment. Reporting from May 2025 put StarkNet’s total value locked at roughly $629 million according to L2Beat’s rollup tracking, and StarkNet was recognized as the first ZK-rollup to reach Stage 1 decentralization, a milestone tracking how much control has moved from the StarkWare team to the protocol itself. StarkNet’s own technical documentation lays out how the Cairo VM compiles programs down to the execution trace that eventually becomes a STARK proof.
Immutable’s zkEVM, built on STARK-based proving through StarkEx and zkEVM infrastructure, processed an average of roughly 498,000 daily transactions in Q1 2025, up 5.7% quarter over quarter from about 469,000, with cumulative transaction count passing 150 million and total contracts deployed reaching 1.9 million.
Polygon Miden, a STARK-based, EVM-compatible rollup originally announced on Polygon’s engineering blog, spun out of Polygon as an independent entity on April 29, 2025, raising a $25 million seed round. Miden’s public testnet has been running since November 2023, and by early 2026 the project had signed a memorandum of understanding with Korea Digital Asset (KODA), signaling continued institutional interest in STARK-based infrastructure outside the US and Europe.
RiscZero takes the zkVM idea furthest by proving execution of arbitrary RISC-V programs through a STARK-based proving system, letting developers write proofs in Rust rather than a domain-specific circuit language. It is the clearest example of how STARKs’ polylogarithmic scaling and general-purpose arithmetization pay off: the same proving stack that verifies a Cairo program on StarkNet can, in principle, verify any compiled RISC-V binary, a flexibility Bulletproofs’ range-proof-specific design was never meant to offer.
Developer Tooling and Ecosystem Maturity
Proof size and gas cost are only half the decision. The other half is whether a team can actually ship with the tooling that exists today. Bulletproofs has the advantage of age here: the reference Rust implementation in the dalek-cryptography ecosystem has been battle-tested inside Monero and Grin for years, and range-proof libraries built on it are stable enough that most integration work is plumbing, not cryptography. Blockstream’s libsecp256k1-zkp library extends that further with production Bulletproofs++ support for Liquid’s confidential assets.
The STARK tooling landscape looks different: younger, more fragmented, but moving fast because so much venture and foundation money has gone into it. StarkWare’s Cairo language and Stone prover are the most production-hardened path, backed by StarkNet’s live mainnet and years of SHARP aggregation in production. Polygon Miden ships its own Miden VM and assembly language, optimized for client-side proving rather than only server-side rollup batching. Winterfell, the Rust STARK-proving library originally built by Facebook’s Novi team and now maintained by the broader community, gives developers a lower-level toolkit for building custom AIR circuits without adopting a full VM. RiscZero goes the opposite direction, letting developers write ordinary Rust and compile it to RISC-V rather than learning a new circuit language at all. None of these are drop-in interchangeable, and a team picking a STARK stack in 2026 is choosing a multi-year tooling commitment, not just a cryptographic primitive.
For teams evaluating both, the practical signal is this: if the requirement fits inside “prove this value is in a range” and a mature library already exists for the target language, Bulletproofs integration is typically weeks of work. If the requirement is “prove this arbitrary program executed correctly,” that work was never available in Bulletproofs to begin with, and the real comparison is between STARK toolchains, not between STARKs and Bulletproofs.
Choosing Between Bulletproofs and zk-STARKs: 7 Use Cases
- Confidential transaction privacy coins. If the entire job is hiding transaction amounts in a range proof, Bulletproofs+ or Bulletproofs++ deliver smaller proofs with less proving overhead than any STARK setup would for the same narrow task.
- Mobile and light-client wallets. A 416-byte to 676-byte proof downloads and verifies almost instantly on constrained hardware, where a 45 KB-plus STARK proof adds real bandwidth and storage cost per transaction.
- Ethereum L2 rollups posting proofs to L1. STARKs are the established choice here (StarkNet, and STARK-based zkEVMs), because the gas-cost math and aggregation tooling around SHARP already exist and are actively optimized.
- General-purpose verifiable computation (zkVMs). Arbitrary program execution, not just range proofs, is what STARK-based systems like Cairo, Miden VM, and RiscZero are built for. Bulletproofs were never designed for this.
- Systems with a 10-year-plus security horizon. Anything that needs to still be trustworthy after large-scale quantum computers exist should default to STARKs’ hash-based assumptions over Bulletproofs’ discrete-log dependency.
- Federated or non-EVM sidechains with tight bandwidth budgets. Liquid’s choice of Bulletproofs++ for confidential assets shows the pattern: no gas model to optimize against, just raw proof size and verification speed.
- New chains without an existing STARK toolchain. Building a STARK prover and AIR-based circuit from scratch is a bigger lift than implementing a Bulletproofs range proof, so teams on a tight timeline building a narrow privacy feature often start with Bulletproofs and revisit later.
Migration Guide: Moving From One Proof System to the Other
Teams outgrowing Bulletproofs usually hit the wall described in the benchmark section: proving time exploding once the circuit stops being a simple range proof. Moving to zk-STARKs is not a drop-in swap, it changes how the underlying program has to be written. It also changes the team’s skill requirements, since designing an AIR circuit is a different discipline than writing an arithmetic circuit for a discrete-log-based system, and most teams underestimate how much of the original Bulletproofs integration work has to be redone rather than reused. Here’s the realistic path.
- Audit what’s actually being proven. If it’s still just range proofs on committed values, migrating to STARKs likely isn’t worth the proof-size cost. The problem may be implementation efficiency, not the proof system.
- Re-express the computation as an execution trace. STARK systems need the statement written as an Algebraic Intermediate Representation (AIR), a fundamentally different model than the arithmetic circuits Bulletproofs implementations typically use.
- Pick a STARK framework. Options in production today include StarkWare’s Cairo/Stone prover stack, Polygon Miden VM, and RiscZero’s zkVM, each with different tooling maturity and language support.
- Budget for larger proving hardware. STARK proving is more memory-intensive than Bulletproofs range proofs. Provers benefit from parallelization but need more RAM and compute per proof.
- Plan the on-chain verifier and gas budget separately. If proofs post to Ethereum L1, design for aggregation from day one. A single unaggregated STARK proof at 2.5M-5M gas plus calldata is not economically viable at retail transaction volume.
- Decide on a data availability strategy. The 100-200 KB calldata per STARK proof is a real, recurring cost. Teams need to decide between posting full calldata, using a DA layer, or validity-proof-only designs.
- Run a dual-verification period. Keep the Bulletproofs path live and cross-check outputs against the new STARK path before fully cutting over, the same pattern StarkNet and other rollups used during their own decentralization milestones.
The reverse migration, STARK to Bulletproofs, is rarer in practice because it usually means giving up general-purpose computation for a narrower, faster range-proof-only system, a trade most rollups aren’t willing to make once they’ve built an entire zkVM around STARK proving.
Pros and Cons
Bulletproofs
- Pro: proof sizes as small as 416 bytes for a 64-bit range proof (Bulletproofs++)
- Pro: sub-millisecond to low-single-digit-millisecond verification for range proofs
- Pro: no trusted setup, mature production track record since 2018 (Monero)
- Pro: minimal bandwidth footprint, ideal for light clients and mobile wallets
- Con: not quantum-resistant, relies on discrete logarithm hardness
- Con: proving time balloons on general-purpose circuits (30 seconds in one benchmark)
- Con: not built for arbitrary computation, mainly optimized for range proofs
zk-STARKs
- Pro: post-quantum secure, hash-based assumptions only
- Pro: fast, predictable verification (10-20 ms) regardless of proof size
- Pro: handles arbitrary computation through zkVMs (Cairo, Miden, RiscZero)
- Pro: transparent, no trusted setup ceremony required
- Con: proof sizes 45 KB to 200+ KB, two to three orders of magnitude larger than Bulletproofs
- Con: raw on-chain verification can cost 2.5M-6M+ gas before aggregation
- Con: heavier prover hardware and memory requirements
Known Weaknesses and Open Criticisms
Neither system is free of trade-offs its own community openly discusses. For Bulletproofs, the University of Twente benchmark found it the slowest of the SNARK/STARK/Bulletproofs trio in both proving and verification once circuits move past simple range proofs, and the discrete-log dependency is a known, accepted long-term liability rather than a surprise. Encryptorium’s post-quantum risk research groups Bulletproofs with Halo 2 as “discrete-log transparent systems,” noting they avoid trusted setup ceremonies but still share the classical curve dependency that undermines their quantum story.
For zk-STARKs, the criticism concentrates on size and cost. Proofs running 45 KB to 500 KB are genuinely large compared to a 288-byte SNARK or a 672-byte Bulletproofs range proof, and that size translates directly into calldata costs on Ethereum, which is why StarkNet’s entire cost model depends on the SHARP aggregation trick rather than posting individual proofs. Implementation complexity is also real: building and maintaining a STARK prover, an AIR circuit compiler, and a recursive aggregation layer is a significantly bigger engineering lift than integrating a Bulletproofs range-proof library.
Memory pressure during proving is a second, less publicized STARK criticism. Because the prover has to materialize an entire execution trace and interpolate it into polynomials before FRI folding even starts, proving large programs can require gigabytes of RAM, a real constraint for teams trying to run provers on commodity cloud instances instead of specialized hardware. Bulletproofs provers, by contrast, scale with the number of range constraints rather than an entire program trace, which keeps memory demands far more predictable even when proving time is slow.
The Verdict: What the Data Actually Shows
There’s no universal winner here, and the data doesn’t support pretending otherwise. For narrow range proofs on committed values, the job Bulletproofs was built for, it wins decisively: 416 to 676 bytes per proof, sub-millisecond to single-digit-millisecond verification, and a five-year production track record inside Monero. That’s why Grin and Blockstream’s Liquid made the same choice.
For general-purpose verifiable computation with a long security horizon, the picture flips just as decisively toward zk-STARKs. A 45 KB proof is a real cost, but StarkNet’s $629 million TVL and Immutable’s 150 million cumulative transactions show the ecosystem has already priced that cost in and built aggregation tooling around it. The post-quantum security margin, combined with fast, size-independent verification around 10-20 ms, is the deciding factor for any system expected to still matter in 2036.
The short version: choose Bulletproofs when the statement is a range proof and bandwidth is the binding constraint. Choose zk-STARKs when the statement is an arbitrary program, the system needs to survive future quantum attacks, or it’s already living on an Ethereum L2 where the aggregation economics have been solved by someone else.
What the benchmark data adds that marketing pages leave out is how sharply the trade-off flips depending on workload. Push Bulletproofs past a simple range proof and proving time jumps from single-digit milliseconds to 30 seconds in the Information 2024 study, a thousand-fold slowdown that never shows up if a team only tests the happy path. Push STARKs down to a trivially small statement and the 45 KB-plus proof overhead stops making sense next to a 672-byte Bulletproofs alternative. Neither system is broken. Both are simply specialized, and the benchmark numbers in this comparison exist to stop teams from discovering that specialization the hard way, in production, after the architecture is already locked in.
Frequently Asked Questions
Do Bulletproofs and zk-STARKs both avoid a trusted setup?
Yes. Both are transparent proof systems and neither requires a structured reference string ceremony. That puts them in a different category from SNARK constructions like Groth16, which need a per-circuit trusted setup.
Which one is quantum-resistant?
zk-STARKs are considered post-quantum secure because they rely on hash collision resistance rather than discrete logarithm hardness. Bulletproofs depend on elliptic curve discrete logs, which Shor’s algorithm can break on a sufficiently powerful quantum computer.
Why are STARK proofs so much bigger than Bulletproofs?
STARKs encode an entire computation trace and prove it using hash-based Merkle commitments and the FRI protocol, which produces proofs in the tens to hundreds of kilobytes. Bulletproofs are optimized specifically for range proofs, a much narrower statement, which is why they can stay under 700 bytes.
Does Monero plan to move away from Bulletproofs?
Monero currently uses Bulletproofs+ for all confidential transactions and has been open that the scheme is not quantum-safe, treating it as a longer-term research question rather than an immediate migration. No production cutover to a STARK-based or other post-quantum range-proof scheme has shipped on mainnet as of this writing.
How much does it cost to verify a STARK proof on Ethereum?
A raw, unaggregated STARK proof can cost roughly 2.5 million to 5 million gas to verify on L1, plus calldata costs for the 100 KB to 200 KB proof itself. StarkNet reduces this dramatically by aggregating many L2 blocks into a single SHARP proof costing around 6 million gas per batch, amortized across all included blocks.
Can zk-STARKs be used for confidential transactions like Bulletproofs?
Technically yes, since STARKs can prove arbitrary computations including range constraints, but the proof size overhead makes them impractical for the narrow job of hiding a transaction amount compared to a purpose-built range-proof scheme like Bulletproofs+.
Which chains use zk-STARKs in production today?
StarkNet is the largest, with roughly $629 million in total value locked as of May 2025. Immutable’s zkEVM and Polygon Miden, which spun out from Polygon in April 2025 with a $25 million seed round, are also built on STARK-based proving.
Is one system simply “better” than the other?
No, and the benchmark data backs that up. Bulletproofs wins decisively on proof size and speed for narrow range proofs, while zk-STARKs wins on post-quantum security and general-purpose computation. Independent studies like the University of Twente thesis found Bulletproofs slowest overall on general circuits and STARKs fastest, but that ranking flips once the workload is restricted to the range proofs Bulletproofs was actually designed for.
