Two of the most-used privacy coins on the market solve the same problem, hiding transaction amounts and identities, with completely different math. Monero uses Bulletproofs. Zcash uses zk-SNARKs. Both are zero-knowledge proof systems, but the trade-offs between them (proof size, setup requirements, verification speed) shaped two of crypto’s longest-running privacy architectures in opposite directions. This comparison breaks down what each system actually costs in bytes, milliseconds, and trust assumptions, using only figures published in the original research papers and each project’s own technical documentation.
Bulletproofs, introduced in a 2018 paper by Benedikt Bünz and coauthors at Stanford’s Applied Crypto Group, are short, non-interactive zero-knowledge proofs designed specifically to prove that a hidden number falls within a range, without a trusted setup. zk-SNARKs, the broader family that includes Zcash’s Groth16-based shielded transactions, can prove arbitrary computation, not just range membership, but do so through pairing-based elliptic curve math that traditionally requires a one-time trusted setup ceremony. Both systems are actively used in production cryptocurrencies today, and both have been upgraded multiple times since their original release, Bulletproofs through the Bulletproofs+ and Bulletproofs++ generations, and Groth16 through Zcash’s Sapling and Orchard network upgrades. Neither project has switched to the other’s approach, which is itself a useful signal: after years of production experience, both teams still consider their original design the right fit for what they’re trying to hide.
What Bulletproofs and zk-SNARKs Actually Prove
Bulletproofs were purpose-built to solve a narrower problem than general zk-SNARKs: proving that a committed value lies within a specific numeric range without revealing the value itself. That’s exactly what a confidential transaction needs, proof that an output amount is between 0 and some maximum (so nobody can create money out of thin air by using a negative number), without showing what that amount actually is. Stanford’s own project page describes Bulletproofs plainly as “short non-interactive zero-knowledge proofs that require no trusted setup,” a description that captures both what they do and their headline advantage, as published on Stanford’s Applied Crypto Group Bulletproofs page.
zk-SNARKs solve a more general problem. A SNARK can prove that an arbitrary program executed correctly, range checks included, but also far more complex statements, such as proving a shielded transaction spends a valid, previously unspent note and that the sender knows the corresponding spending key, all without revealing any of it. Zcash uses this generality to prove entire transaction validity in zero-knowledge, not just that an amount sits in a range. That extra power comes from encoding computation into pairing-friendly elliptic curve operations, which is also the source of the SNARK’s smaller, constant-size proofs and its dependency on a trusted setup. Readers wanting the deeper mechanics of how pairing-based SNARKs stack up against a transparent alternative can see our separate comparison of zk-SNARKs against zk-STARKs, which covers the setup-versus-transparency trade-off from the rollup side of the industry rather than the privacy-coin side covered here.
How Bulletproofs Work: The Inner-Product Argument
A Bulletproof starts with a Pedersen commitment, a cryptographic value that hides a number while still letting math be performed on it. To prove that the hidden number falls within a range like 0 to 2^64 minus 1, the prover expresses the range check as a set of linear and inner-product relationships over bit representations of the number, then compresses those relationships using a technique called an inner-product argument. That compression step is what keeps the proof small: instead of sending one piece of data per bit of the range (which would scale linearly), the inner-product argument folds the proof down so it scales with the logarithm of the bit-length instead.
The entire construction avoids pairings and avoids any parameter that has to be kept secret and later destroyed. Every value used, the elliptic curve generators, the commitment bases, is public and can be independently regenerated by anyone verifying the proof, which is exactly what having no trusted setup means in practice, the same public-parameter philosophy behind commitment structures like the Merkle and Verkle trees used elsewhere in blockchain proof systems. This is also why aggregation works so cleanly: multiple range proofs can share the same inner-product argument structure and get batched together into one proof that’s only slightly larger than a single proof would be, which is the mechanism behind the 121 KB to roughly 1 KB improvement for 32 aggregated range proofs.
How Groth16 zk-SNARKs Work: Pairings and the Structured Reference String
Groth16 takes a different path. A program gets compiled into an arithmetic circuit, then into a Quadratic Arithmetic Program, a polynomial representation of the circuit’s constraints. The prover uses a structured reference string, generated once during the trusted setup, to encode a proof that the polynomial relationships hold, using elliptic curve pairings to let the verifier check the proof without seeing the underlying witness data. Because pairings let the verifier confirm a relationship between encrypted values without decrypting them, the proof collapses to just a few curve points, typically three, regardless of how large or complex the original circuit was.
That constant-size property is Groth16’s core strength and the reason Zcash could build an entire shielded transaction, hiding sender, receiver, and amount together, into a single sub-300-byte proof. The trade-off is that the structured reference string has to come from somewhere, and if the “toxic waste” randomness used to generate it isn’t properly destroyed, the security guarantee breaks. Zcash’s original Sprout ceremony and later Sapling ceremony were both run as multi-party computations specifically to distribute that risk across independent participants who would each need to collude for the ceremony to be compromised.
A rough skeleton of what a Bulletproofs range proof workflow looks like using the Dalek library shows how little setup is involved compared to a SNARK circuit:
// 1. Generate public parameters (no secrets, no ceremony)
let pc_gens = PedersenGens::default();
let bp_gens = BulletproofGens::new(64, 1);
// 2. Commit to a secret value and build the range proof
let secret_value = 4294967295u64;
let blinding = Scalar::random(&mut rng);
let (proof, committed_value) = RangeProof::prove_single(
&bp_gens, &pc_gens, &mut transcript,
secret_value, &blinding, 64,
)?;
// 3. Verify (fast, and can be batched with other proofs)
proof.verify_single(&bp_gens, &pc_gens, &mut transcript, &committed_value, 64)?;
Every parameter in that flow is public and deterministic. There’s no equivalent of a setup ceremony step to run before the first proof can be generated, which is the practical, code-level version of the no-trusted-setup property discussed throughout this comparison.
Common Mistakes Teams Make Choosing Between Them
The most frequent mistake is treating Bulletproofs as a drop-in replacement for zk-SNARKs generally, rather than specifically for range proofs. A team that needs to hide an entire transaction’s spend logic, not just an amount, will find that Bulletproofs alone can’t express that statement efficiently, since they weren’t designed as a general-purpose circuit system. Bolting range-proof-only cryptography onto a problem that needs full transaction privacy usually means the team ends up needing a SNARK or STARK anyway, on top of whatever Bulletproofs work they already built.
A second common mistake is underestimating how much the choice of proof system locks in future upgrade paths. Because Bulletproofs, Bulletproofs+, and Bulletproofs++ all use incompatible proof formats at the byte level, a network that adopts one version needs a coordinated upgrade, often a hard fork, to move to the next. Teams that don’t plan for this kind of format churn from the start can find themselves maintaining verification code for multiple proof format versions simultaneously, which adds real complexity to wallet and node software long after the original cryptography decision was made.
A third mistake is assuming that having no trusted setup automatically means a system is more secure in every dimension. Bulletproofs remove ceremony risk, but that’s a different property from being immune to implementation bugs, side-channel attacks, or the underlying discrete-log assumption eventually weakening. Both Bulletproofs and Groth16 SNARKs have been through public audits precisely because removing one category of risk doesn’t remove all of them, and treating a no-setup design as inherently safer than a well-audited setup-based one skips over the actual engineering work involved in securing either system.
Bulletproofs vs zk-SNARKs Specs Table
The table below lines up both systems on the properties that matter most for engineers choosing between them.
| Property | Bulletproofs / Bulletproofs+ | zk-SNARK (Groth16) |
|---|---|---|
| 64-bit range proof size (original) | ~672-688 bytes | Not applicable (SNARKs prove general circuits) |
| 64-bit range proof size (Bulletproofs+) | 576 bytes | N/A |
| Full shielded transaction proof size | N/A (range proofs only) | 192-296 bytes (Zcash Sapling/Orchard) |
| Cryptographic base | Elliptic-curve discrete log, inner-product arguments | Pairing-friendly elliptic curves |
| Trusted setup | Not required | Required (per-circuit ceremony for Groth16) |
| Quantum resistance | No, discrete-log based | No, pairing-based |
| Proof size scaling | Logarithmic with range bit-length and aggregation | Constant, independent of computation size |
| Verification time (single proof) | ~0.9 ms (Bulletproofs+, 64-bit range) | Under 1 ms (Groth16) |
| Proving time | ~4 ms (Bulletproofs+, 64-bit range) | ~50-150 ms depending on hardware and circuit |
| Batch verification | Yes, strong support for verifying many proofs together | Supported but less central to the design |
| General-purpose computation | No, range proofs only | Yes, arbitrary circuits |
| Best-known adopters | Monero (RingCT), Grin/Mimblewimble | Zcash (Sapling, Orchard shielded pools) |
Proof Size: A Narrower Gap Than SNARKs vs STARKs
The original 2018 Bulletproofs paper reports a 64-bit range proof at roughly 688 bytes, and implementations like the Dalek cryptography library put the same proof at approximately 672 bytes. That’s already in a similar order of magnitude to a Groth16 SNARK proof, unlike the two-to-three-orders-of-magnitude gap seen between SNARKs and STARKs. The proof size formula behind Bulletproofs is 2 times the base-2 logarithm of the range’s bit-length, plus 9 group and field elements, each roughly 32 bytes on a 256-bit curve. That logarithmic scaling is the entire point of the design: a single 64-bit range proof and an aggregated proof covering 32 outputs both stay compact, growing only slightly in size even as the number of ranges being proven increases sharply.
That aggregation property produced one of the more dramatic before-and-after numbers in the space: the Bulletproofs paper reports that aggregating 32 range proofs together comes out to roughly 1 KB total, compared to about 121 KB using the range-proof schemes that predated Bulletproofs. That’s the number that made Bulletproofs an easy adoption decision for Monero, which had been paying a steep per-transaction size cost under its earlier range-proof approach.
The Bulletproofs family kept shrinking after the original 2018 release. Bulletproofs+, described in a 2020 paper, cuts a 64-bit range proof to 576 bytes, saving 96 bytes per proof compared to the original Bulletproofs construction, a reduction to about 85.7% of the prior size, according to the Bulletproofs+ paper on the Cryptology ePrint Archive. A further iteration, Bulletproofs++, pushes a 64-bit range proof down to 416 bytes, which is 28% smaller than Bulletproofs+ and 39% smaller than the original Bulletproofs construction. For a two-output aggregated proof on a Monero-style 256-bit curve, Bulletproofs++ reports a combined proof size of around 640 bytes.
Trusted Setup: The Feature Both Systems Get Compared On
This is the property that shows up in nearly every write-up comparing the two systems, and for good reason. Bulletproofs need no structured reference string and no ceremony of any kind. The math relies entirely on standard discrete-log assumptions over elliptic curve groups and inner-product arguments, parameters anyone can generate independently and verify are honestly constructed. Stanford’s project documentation makes this contrast explicit, noting that “compared to SNARKs, Bulletproofs require no trusted setup,” a distinction that has shaped how privacy coin communities evaluate new cryptography, per the same Bulletproofs project page.
Zcash’s Groth16-based shielded pools, by contrast, needed a multi-party trusted setup ceremony to generate the structured reference string their proofs depend on. If every participant in that ceremony had colluded and kept a copy of the secret randomness used, they could have forged proofs that appeared valid without being backed by real value, effectively counterfeiting shielded coins undetectably. Zcash ran its original ceremony with multiple independent participants specifically to make that collusion scenario implausible, and documented the resulting parameters in its own protocol specification, available at Zcash’s published protocol specification. The ceremony risk is a one-time cost rather than an ongoing one, but it’s a cost Bulletproofs never had to pay in the first place.
Quantum Resistance: Neither System Is Ready
It’s worth being direct about a point that sometimes gets glossed over in privacy coin marketing: neither Bulletproofs nor Groth16-based zk-SNARKs are quantum-resistant. Bulletproofs rely on the hardness of the discrete logarithm problem over elliptic curves, the same category of assumption that a sufficiently powerful quantum computer running Shor’s algorithm would break. Groth16 zk-SNARKs rely on pairing-based elliptic curve assumptions, which fall to the same style of quantum attack. Both fall into the same not-post-quantum category as other elliptic-curve-based schemes like Curve25519 and secp256k1.
This matters more for long-lived privacy claims than for most other cryptographic use cases. A transaction hidden today with either Bulletproofs or a Groth16 SNARK could, in theory, have its privacy retroactively broken once large-scale quantum computers exist and historical blockchain data is still public. Neither Monero’s nor Zcash’s current production systems have swapped in post-quantum range proofs or post-quantum SNARK constructions, and our broader look at where post-quantum cryptography adoption actually stands in 2026 shows this gap isn’t unique to privacy coins, most of the internet’s cryptographic infrastructure is in the same boat.
Scaling Impact: What Smaller Proofs Mean at the Block Level
Proof size differences that look small per-transaction compound quickly once they’re multiplied across every block a network ever produces. The headline number from the original Bulletproofs paper, roughly 121 KB shrinking to about 1 KB for 32 aggregated range proofs, translates directly into smaller blocks, faster initial blockchain sync for new nodes, and lower storage requirements for anyone running a full node over the network’s entire history. That’s not a one-time saving either: every block mined after the upgrade carries the smaller proof format, so the effect accumulates for as long as the network keeps running.
The same compounding logic applies to the smaller jumps between Bulletproofs generations. A 96-byte saving per range proof looks minor in isolation, but multiplied across every transaction output on a network the size of Monero’s, sustained over years of blocks, it adds up to a meaningful reduction in the blockchain’s total on-disk footprint. This is part of why Monero’s core developers treated the Bulletproofs+ upgrade as worth the coordination cost of a network-wide fork rather than leaving the older, larger proof format in place: the savings are permanent and network-wide, not a one-off convenience for the transactions made right after the upgrade.
Real-World Benchmarks From Multiple Sources
Pulling together the numbers from the original research papers and each project’s technical documentation gives a clear picture of how proof size evolved across three generations of range-proof design, compared against the SNARK baseline.
| Source / scheme | 64-bit range proof size | Verification time | Proving time | Trusted setup |
|---|---|---|---|---|
| Original Bulletproofs (2018 paper) | ~672-688 bytes | Not separately benchmarked in original paper | Not separately benchmarked in original paper | No |
| Bulletproofs+ (2020 paper) | 576 bytes | ~0.9 ms | ~4 ms | No |
| Bulletproofs++ (later paper) | 416 bytes | Not directly compared in same units | Not directly compared in same units | No |
| Groth16 zk-SNARK (Zcash Sapling/Orchard) | N/A (192-296 byte full proof, not range-specific) | Under 1 ms | ~50-150 ms depending on hardware | Yes |
The comparison isn’t perfectly apples-to-apples, Bulletproofs numbers describe a range proof, while Groth16 numbers describe a full shielded transaction proof, but the pattern that emerges is still useful: Bulletproofs verification speed at 0.9 milliseconds is in the same rough neighborhood as Groth16’s sub-millisecond verification, while Bulletproofs proving time of about 4 milliseconds for a single range proof is dramatically faster than Groth16’s 50 to 150 milliseconds for a full circuit, which isn’t surprising given how much more computation a general-purpose SNARK circuit represents compared to a single range check.
Batch Verification: Where Bulletproofs Pull Ahead
One place Bulletproofs have a structural advantage is batch verification. Because Bulletproofs are built from inner-product arguments over shared elliptic curve groups, many proofs can be verified together using shared random challenges, cutting the average per-proof verification cost substantially compared to verifying each proof independently. That matters directly for block validation on a network like Monero, where a single block might contain dozens of transactions, each with its own range proof, and a full node needs to validate all of them as fast as possible to keep sync times reasonable.
Groth16-based SNARKs support batch verification too, but it isn’t as central to the scheme’s design story the way it is for Bulletproofs, where the original paper treats batching as one of the headline efficiency features rather than an optional add-on. For networks processing high transaction volumes with range-proof-heavy privacy features, that batching advantage compounds directly into lower node operating costs and faster initial blockchain sync for new participants.
Developer Tooling: Rust Crates vs Circuit Compilers
The developer experience for the two systems looks almost nothing alike. Building with Bulletproofs generally means pulling in a library like Dalek’s bulletproofs crate in Rust, defining what value needs a range proof, and calling a prove function, there’s no separate circuit-design phase because the statement being proven (this value is in this range) is fixed and well understood. Building with zk-SNARKs means designing an arithmetic circuit first, in a language like Circom or a framework like arkworks or bellman, compiling that circuit, running a setup phase to generate proving and verification keys, and only then generating proofs against that specific circuit.
That difference in workflow reflects the difference in what each system is built to do. A Bulletproofs implementation is closer to calling a well-defined cryptographic primitive, similar to calling a hash function, while a SNARK implementation is closer to writing a small program in a constrained, circuit-friendly language and then compiling it into a proving system. Neither is inherently harder to use correctly, but they demand different skill sets: Bulletproofs work requires understanding elliptic curve group operations and commitment schemes, while SNARK circuit design requires understanding how to express program logic as polynomial constraints, a skill that has its own learning curve independent of the underlying cryptography.
Auditing and Security Track Record
Both proof systems have been through years of public scrutiny in production settings, which matters more for privacy-critical cryptography than benchmark numbers alone. Monero’s Bulletproofs implementation went through independent audits before mainnet deployment in 2018, and the Bulletproofs+ upgrade in 2022 followed the same pattern of public review before the network-wide switch. Grin’s Mimblewimble implementation of Bulletproofs range proofs has likewise been reviewed as part of the protocol’s broader security audits, given how central range proofs are to preventing inflation bugs in a confidential-transaction system.
Zcash’s Groth16 circuits went through a formal, multi-party ceremony process precisely because a single point of failure in the trusted setup would undermine the entire shielded pool’s integrity, and the project has published detailed documentation of how each ceremony was run, including participant counts and the steps taken to ensure toxic waste was destroyed. Both projects treat their zero-knowledge cryptography as consensus-critical infrastructure, and neither has shipped a major proof-system upgrade without a public audit trail, a bar that any team evaluating either system for a new project should hold itself to as well.
Real-World Examples: Who’s Using What
Both systems have years of production use behind them, in networks with very different privacy architectures.
- Monero adopted Bulletproofs in 2018 to replace an older, far larger range-proof system, and upgraded again to Bulletproofs+ in 2022, with Monero’s official announcement confirming every range proof in a transaction became 96 bytes smaller after the switch, per Monero’s official Bulletproofs+ announcement.
- Grin, built on the Mimblewimble protocol, uses Bulletproof range proofs that historically accounted for a large share of total transaction size, with a Grin community proposal documenting plans to migrate to Bulletproofs+ for the same 96-byte-per-proof savings seen on Monero, discussed on the Grin community forum.
- Zcash’s Sapling and Orchard shielded pools use Groth16-based zk-SNARKs to prove full shielded transaction validity, not just range membership, giving Zcash a fundamentally different privacy model built around proving an entire spend is valid in zero-knowledge.
- Monero’s FCMP++ roadmap, part of ongoing research into the network’s next major privacy upgrade, is built around what’s described as generalized Bulletproofs with logarithmic proof size, extending the same Bulletproofs lineage rather than switching to a SNARK-based approach.
- Confidential transaction research more broadly traces back to a proposal from Blockstream years before Bulletproofs existed, and Bulletproofs were explicitly designed to make that same confidential-transaction concept practical at blockchain scale by cutting proof sizes down from the impractical figures the earlier scheme required.
Pricing and Tooling Costs
Like most zero-knowledge cryptography, neither Bulletproofs nor Groth16-based zk-SNARKs are sold as commercial products with a price tag. Both are implemented in open-source libraries, so the real cost comparison is engineering time, ceremony coordination, and the computational cost of proving and verifying at scale.
| Cost category | Bulletproofs / Bulletproofs+ | zk-SNARK (Groth16) |
|---|---|---|
| Core libraries | Free and open source (Dalek Bulletproofs, Monero’s implementation) | Free and open source (bellman, libsnark, snarkjs) |
| Trusted setup ceremony cost | None required | One-time multi-party ceremony coordination effort |
| Per-proof bandwidth cost | Low, hundreds of bytes per range proof | Low, hundreds of bytes per full transaction proof |
| Verification compute cost | Low, sub-millisecond with batching | Low, sub-millisecond per proof |
| Proving compute cost | Low for range proofs specifically | Higher for full-circuit proving, though improving with GPU acceleration |
For a network that only needs to prove amounts are non-negative and within range, Bulletproofs deliver that guarantee with less proving overhead than standing up a full SNARK circuit would require. For a network that needs to hide entire transaction logic, not just amounts, a SNARK’s general-purpose circuit model is doing meaningfully more work, and its cost profile reflects that.
What Industry Sources Say
Benedikt Bünz, one of the original authors of the Bulletproofs paper at Stanford’s Applied Crypto Group, describes the protocol directly: “Bulletproofs are short non-interactive zero-knowledge proofs that require no trusted setup,” according to Stanford’s Bulletproofs project page. In the same documentation, Bünz draws the comparison to SNARKs explicitly, noting that “compared to SNARKs, Bulletproofs require no trusted setup,” the single most-cited trade-off between the two systems across the cryptography research community.
That framing lines up with how Monero’s own documentation describes the Bulletproofs+ upgrade, and how Zcash’s protocol specification describes the ceremony requirements behind its Groth16 circuits. Neither project disputes the basic trade-off: Bulletproofs trade some proof size and generality for removing ceremony risk, while Groth16 SNARKs trade ceremony risk for smaller, general-purpose proofs capable of hiding an entire transaction’s logic rather than just a numeric range.
Use-Case Recommendations
Neither system is a universal answer. The right choice depends on what’s actually being hidden and how much computation needs to happen inside the proof.
- Building a confidential-transaction feature that only needs to hide amounts: Bulletproofs or Bulletproofs+, since range proofs are exactly the problem they’re optimized for, with no ceremony to coordinate.
- Building a shielded transaction system that needs to hide sender, receiver, and transaction logic together: zk-SNARKs, since only a general-purpose circuit can express that combined statement in one proof.
- Launching a new privacy coin or Mimblewimble-style protocol from scratch: Bulletproofs+, given the proven adoption path through Monero and Grin and the absence of ceremony coordination overhead at launch.
- Building a system where blocks contain dozens of range proofs that all need fast validation: Bulletproofs, for the batch verification advantage baked into the scheme’s design.
- Prototyping a zero-knowledge feature quickly without recruiting ceremony participants: Bulletproofs, for the same reason STARKs get chosen over SNARKs in setup-averse projects, transparency simplifies the launch checklist.
- Migrating an aging range-proof implementation for bandwidth savings: Bulletproofs++ over the original Bulletproofs, given the documented 39% size reduction for 64-bit range proofs.
Migration Guide: Upgrading Between Bulletproof Generations or to SNARKs
Projects already running an older range-proof scheme, or an early Bulletproofs implementation, generally follow a similar sequence when upgrading.
- Confirm the exact proof size savings for your transaction shape. Bulletproofs+ saves a documented 96 bytes per range proof regardless of input count, while Bulletproofs++ saves more but has seen less production battle-testing than Bulletproofs+.
- Plan for a hard fork or soft fork depending on your consensus rules. Monero’s move to Bulletproofs and later Bulletproofs+ both required network-wide upgrades, since old and new proof formats aren’t interchangeable at the validation layer.
- Re-benchmark proving and verification time on your actual transaction volume. Published benchmarks (0.9 ms verification, 4 ms proving for Bulletproofs+) come from controlled test conditions and should be validated against your own hardware and batch sizes before committing.
- Decide whether you need general-purpose computation or just range proofs. If your privacy model has grown beyond hiding amounts into needing to hide transaction logic entirely, moving toward a zk-SNARK architecture (accepting the trusted setup trade-off) may be necessary rather than optimizing further within the Bulletproofs family.
- If moving toward SNARKs, plan the trusted setup ceremony early. Ceremony coordination, recruiting independent participants, verifying contributions, and publishing the process transparently, takes significant lead time and should not be treated as a late-stage detail.
- Update wallet software and light client verification logic. Both range-proof format changes and a move to SNARK-based proofs require updating every piece of software that verifies transactions, not just the consensus-critical validation code.
- Audit the new proof system independently before mainnet deployment. Every major Bulletproofs and Groth16 upgrade referenced in this comparison went through public review and audit before being adopted in production, and skipping that step on a privacy-critical cryptographic change is a security risk regardless of which proof system is chosen.
Pros and Cons
Bulletproofs advantages: no trusted setup required, strong batch verification support, logarithmic proof size scaling with aggregation, and a clear upgrade path through Bulletproofs+ and Bulletproofs++ that keeps shrinking proof sizes. Bulletproofs drawbacks: limited to range proofs and similar statements rather than arbitrary computation, not quantum-resistant, and proving time that, while fast for range checks, doesn’t generalize to complex transaction logic the way a SNARK circuit does.
zk-SNARK advantages: can prove arbitrary computation in a single proof, small constant-size proofs regardless of circuit complexity, and a mature ecosystem built around Zcash’s years of production shielded-pool operation. zk-SNARK drawbacks: requires a trusted setup ceremony that introduces a one-time collusion risk, higher proving time for complex circuits, and, like Bulletproofs, no resistance to a future large-scale quantum computer.
The Verdict: Which One Should You Actually Use
Based on the data gathered here, the choice comes down to what’s actually being proven, not which system is objectively better. If the goal is hiding transaction amounts specifically, and nothing more complex than a range check, Bulletproofs and its successors are the more efficient, lower-risk choice: 576-byte range proofs with Bulletproofs+ and 416-byte proofs with Bulletproofs++, no ceremony, and strong batch verification, which is exactly why Monero and Grin built their entire confidential-transaction models around this family.
If the goal is hiding an entire transaction’s logic, not just an amount, including sender, receiver, and spend validity all in one proof, zk-SNARKs remain the more capable tool, which is why Zcash never migrated its shielded pools to a Bulletproofs-only design despite the ceremony trade-off. The two systems aren’t really competing for the same job. Bulletproofs won the range-proof efficiency race outright, and SNARKs still own the general-purpose zero-knowledge computation category that Bulletproofs were never built to compete in.
Frequently Asked Questions
Do Bulletproofs need a trusted setup?
No. Bulletproofs are built entirely from standard elliptic-curve discrete-log assumptions and inner-product arguments, so there’s no structured reference string or ceremony required, unlike Groth16-based zk-SNARKs.
Which cryptocurrencies use Bulletproofs?
Monero adopted Bulletproofs in 2018 and upgraded to Bulletproofs+ in 2022. Grin, built on the Mimblewimble protocol, also uses Bulletproof range proofs and has discussed migrating to Bulletproofs+ for further size savings.
Are Bulletproofs smaller than zk-SNARK proofs?
Not necessarily. A Bulletproofs+ range proof is 576 bytes, while a Groth16 zk-SNARK proof used in Zcash’s shielded pools runs 192-296 bytes for a full transaction proof. The comparison isn’t perfectly equivalent since SNARKs prove more than just a range, but SNARK proofs are generally smaller per-proof.
Can Bulletproofs prove things other than a numeric range?
Bulletproofs can be extended to prove some other statements expressible as arithmetic circuits, but they’re primarily used and optimized for range proofs in production systems. They aren’t a general-purpose replacement for zk-SNARKs.
Are Bulletproofs or zk-SNARKs quantum-resistant?
Neither is. Bulletproofs rely on elliptic-curve discrete-log hardness, and Groth16 zk-SNARKs rely on pairing-based elliptic-curve assumptions. Both would be broken by a sufficiently powerful quantum computer running Shor’s algorithm.
Why did Monero switch to Bulletproofs?
Monero’s prior range-proof scheme produced proofs that scaled poorly with the number of outputs. Bulletproofs’ logarithmic scaling cut aggregated proof sizes from roughly 121 KB down to about 1 KB for 32 range proofs, a dramatic bandwidth savings that made the switch an easy call.
What’s the difference between Bulletproofs, Bulletproofs+, and Bulletproofs++?
Each generation shrinks the 64-bit range proof size further: roughly 672-688 bytes for the original Bulletproofs, 576 bytes for Bulletproofs+, and 416 bytes for Bulletproofs++, while keeping the same no-trusted-setup property throughout.
Is Monero more private than Zcash because it doesn’t need a trusted setup?
Not necessarily. The two networks make different privacy trade-offs rather than one being strictly more private. Monero’s Bulletproofs-based RingCT hides amounts and mixes transactions with decoys by default for every user, while Zcash’s Groth16-based shielded pools can hide sender, receiver, and amount together, but shielded transactions have historically been optional rather than mandatory for every Zcash transaction. Trusted setup risk and default privacy strength are separate questions.
Should a new privacy-focused project pick Bulletproofs or zk-SNARKs?
Start by asking what needs to be hidden. If it’s just transaction amounts, Bulletproofs or Bulletproofs+ get the job done without a ceremony. If the design needs to hide the entire transaction’s validity logic in a single proof, a zk-SNARK architecture is the more capable choice despite the setup cost. For background on the broader zero-knowledge proof landscape these systems sit within, see our comparison of zk-SNARKs against zk-STARKs and our overview of cryptography fundamentals.
