Range proofs in 80 lines: Pedersen commitments and a tiny Bulletproof

How a Bulletproof actually compresses a range proof to logarithmic size. Derive the inner-product argument from scratch, run a toy prover/verifier in the browser, and pick the right range-proof primitive for 2026.

A confidential transaction has to prove one annoying little thing: that the hidden amount is non-negative and bounded. Without that, an attacker can mint coins out of thin air by committing to a “negative balance” that wraps around the field. The cryptographic primitive that does the proving is the range proof, and the question of which range proof to ship in 2026 is — surprisingly — still live.

This post does three things:

Derives the inner-product argument that makes Bulletproofs short.
Walks an 80-line, runnable toy Bulletproof prover/verifier in the browser.
Maps the trade-offs between Bulletproofs, classical range proofs, and SNARK-based range proofs onto the deployment surface I keep hitting in zera-sdk.

It’s a sibling piece to Pedersen commitments, in production. Read that one first if “Pedersen” still feels like a textbook word to you. This one assumes you know what C = a·G + b·H is and want to know what to do with it.

What a range proof has to do

The setup. A prover holds a value $v$ and a blinding factor $\gamma$ , and publishes a Pedersen commitment

V = v \cdot G + \gamma \cdot H

with $G, H$ independent generators of an elliptic-curve group of prime order $q$ . The hiding property of $V$ comes from $\gamma$ being uniformly random; the binding property comes from $G$ and $H$ being independent (no known $\beta$ with $H = \beta G$ ).

The prover then wants to convince a verifier that $v$ lies in some range, typically $[0, 2^n)$ for $n = 32$ or $n = 64$ . Crucially, $v$ stays hidden. The verifier learns only the fact that the committed value is in range.

The naive proof of " $v \in [0, 2^n)$ " is to commit bit-by-bit: write $v = \sum_{i=0}^{n-1} a_i \cdot 2^i$ with $a_i \in \{0,1\}$ , commit to each $a_i$ , and prove each $a_i (a_i - 1) = 0$ . That works. It takes $O(n)$ commitments and $O(n)$ proof size, which is what Confidential Transactions in Bitcoin shipped in 2015 and which is roughly 2.5 KB per transaction at $n = 64$ .

Bünz, Bootle, Boneh, Poelstra, Wuille, and Maxwell (2018) — the Bulletproofs paper — got that down to about 672 bytes, with no trusted setup, by replacing the linear blob with a logarithmic-size inner-product argument. The compression ratio is roughly 4× over the naive bit-commitment scheme, and it gets better as the range grows.

The inner-product argument, derived

The whole game in Bulletproofs is the inner-product argument (IPA). Forget range proofs for a paragraph. The IPA proves the following:

Statement. Given commitments $P \in \mathbb{G}$ and $\mathbf{G}, \mathbf{H} \in \mathbb{G}^n$ , plus a scalar $c \in \mathbb{F}_q$ , the prover knows vectors $\mathbf{a}, \mathbf{b} \in \mathbb{F}_q^n$ such that

P = \langle \mathbf{a}, \mathbf{G} \rangle + \langle \mathbf{b}, \mathbf{H} \rangle \quad \text{and} \quad \langle \mathbf{a}, \mathbf{b} \rangle = c.

The naive proof is to send $\mathbf{a}$ and $\mathbf{b}$ — that’s $2n$ scalars. The IPA gets it to $2 \log_2 n$ group elements plus two scalars.

The trick is recursion. Split each vector in half: $\mathbf{a} = (\mathbf{a}_L \,|\, \mathbf{a}_R)$ , same for $\mathbf{b}, \mathbf{G}, \mathbf{H}$ . The prover sends two cross-terms:

L = \langle \mathbf{a}_L, \mathbf{G}_R \rangle + \langle \mathbf{b}_R, \mathbf{H}_L \rangle, \quad R = \langle \mathbf{a}_R, \mathbf{G}_L \rangle + \langle \mathbf{b}_L, \mathbf{H}_R \rangle.

The verifier responds with a random challenge $x \in \mathbb{F}_q^*$ . Both parties then compute folded vectors of half the length:

\mathbf{a}' = x \cdot \mathbf{a}_L + x^{-1} \cdot \mathbf{a}_R, \quad \mathbf{b}' = x^{-1} \cdot \mathbf{b}_L + x \cdot \mathbf{b}_R,

and the verifier folds the generators in the dual direction:

\mathbf{G}' = x^{-1} \cdot \mathbf{G}_L + x \cdot \mathbf{G}_R, \quad \mathbf{H}' = x \cdot \mathbf{H}_L + x^{-1} \cdot \mathbf{H}_R.

The new commitment is

P' = x^2 \cdot L + P + x^{-2} \cdot R,

and you can check by direct expansion that $P' = \langle \mathbf{a}', \mathbf{G}' \rangle + \langle \mathbf{b}', \mathbf{H}' \rangle$ exactly when the original $P$ relation held. Recurse on $(\mathbf{a}', \mathbf{b}', \mathbf{G}', \mathbf{H}', P')$ . After $\log_2 n$ rounds, the vectors are length 1 and the prover just sends the two remaining scalars.

That’s the entire IPA in seven lines of math. Total proof size: $2 \log_2 n$ group elements (the $L_i$ and $R_i$ from each round) + 2 final scalars. At $n = 64$ , that’s 12 group elements + 2 scalars ≈ 416 bytes.

flowchart LR
A[a, b length n] --> S1[split into halves]
S1 --> X1[prover sends L_1, R_1]
X1 --> C1[verifier sends challenge x_1]
C1 --> F1[fold to length n/2]
F1 --> R{length 1?}
R -->|no| S1
R -->|yes| F[send final a, b]
F --> V[verifier checks single point]

From IPA to range proof in two reductions

The range proof reduces to the IPA in two steps.

Step 1: bit decomposition as a vector identity. Write $v = \langle \mathbf{a}_L, 2^{\mathbf{n}} \rangle$ where $\mathbf{a}_L \in \{0,1\}^n$ is the bit decomposition and $2^{\mathbf{n}} = (1, 2, 4, \dots, 2^{n-1})$ . Define $\mathbf{a}_R = \mathbf{a}_L - \mathbf{1}^n$ (so each $a_{R,i} \in \{0, -1\}$ ). The conjunction " $v \in [0, 2^n)$ " becomes the vector identities

\mathbf{a}_L \circ \mathbf{a}_R = \mathbf{0}^n, \quad \mathbf{a}_L - \mathbf{a}_R = \mathbf{1}^n, \quad \langle \mathbf{a}_L, 2^{\mathbf{n}} \rangle = v.

The first identity (Hadamard product is zero) is exactly the bit constraint $a_i (a_i - 1) = 0$ rewritten.

Step 2: collapse three vector identities to one inner product. The verifier samples challenges $y, z$ . The prover constructs polynomials

\mathbf{l}(X) = (\mathbf{a}_L - z \cdot \mathbf{1}^n) + \mathbf{s}_L \cdot X,

\mathbf{r}(X) = \mathbf{y}^n \circ (\mathbf{a}_R + z \cdot \mathbf{1}^n + \mathbf{s}_R \cdot X) + z^2 \cdot 2^{\mathbf{n}},

with $\mathbf{s}_L, \mathbf{s}_R$ random blinding vectors. The inner product $t(X) = \langle \mathbf{l}(X), \mathbf{r}(X) \rangle$ is a quadratic in $X$ , and the constant term $t_0$ collapses to

t_0 = z^2 \cdot v + \delta(y, z), \quad \delta(y, z) = (z - z^2) \langle \mathbf{1}^n, \mathbf{y}^n \rangle - z^3 \langle \mathbf{1}^n, 2^{\mathbf{n}} \rangle.

The verifier knows $\delta(y, z)$ (it’s all public scalars) and knows $V$ (the commitment to $v$ ), so it can check the $t_0$ equation against $V$ . The prover then runs the IPA on $\mathbf{l}(x)$ and $\mathbf{r}(x)$ for a fresh challenge $x$ , and that is what gets compressed to $\log_2 n$ .

The whole construction is one Pedersen commitment, two challenges, two polynomial-coefficient commitments, and an IPA. It fits in a paragraph and runs in a browser.

The 80-line toy

This is a runnable Bulletproof-style range proof for $n = 4$ (so $v \in [0, 16)$ ). It is intentionally small. It uses scalar arithmetic in a tiny prime field instead of an elliptic-curve group, which means it demonstrates the protocol shape but provides zero cryptographic security. Read it for the algebra, not the hardness.

sandbox [ vanilla-ts ]

run

Runnable playground (requires JavaScript)

/index.ts

// Toy Bulletproof-shaped range proof for v in [0, 16).
// Uses a tiny prime field (q=2^61-1) to make the algebra readable.
// NOT a cryptosystem. NOT constant-time. Read it for the SHAPE.
//
// Reference: Bunz, Bootle, Boneh, Poelstra, Wuille, Maxwell (2018)
// https://eprint.iacr.org/2017/1066

const Q = (1n << 61n) - 1n; // Mersenne prime, fits in BigInt comfortably.
const N = 4;                // bit-length of the range

const mod = (x: bigint) => ((x % Q) + Q) % Q;
const add = (a: bigint, b: bigint) => mod(a + b);
const sub = (a: bigint, b: bigint) => mod(a - b);
const mul = (a: bigint, b: bigint) => mod(a * b);
function inv(a: bigint): bigint {
// Fermat: a^(Q-2) mod Q
let r = 1n, base = mod(a), e = Q - 2n;
while (e > 0n) {
  if (e & 1n) r = mul(r, base);
  base = mul(base, base);
  e >>= 1n;
}
return r;
}
const dot = (a: bigint[], b: bigint[]) =>
a.reduce((s, ai, i) => add(s, mul(ai, b[i])), 0n);
const had = (a: bigint[], b: bigint[]) => a.map((ai, i) => mul(ai, b[i]));

// Fiat-Shamir: deterministic challenge from a transcript.
async function challenge(transcript: string): Promise<bigint> {
const buf = new TextEncoder().encode(transcript);
const h = await crypto.subtle.digest("SHA-256", buf);
let x = 0n;
for (const b of new Uint8Array(h)) x = (x << 8n) | BigInt(b);
return mod(x) || 1n; // never zero
}

// PROVER -----------------------------------------------------------
async function prove(v: bigint) {
if (v < 0n || v >= 1n << BigInt(N)) throw new Error("out of range");
// Bit decomposition.
const aL = Array.from({ length: N }, (_, i) => (v >> BigInt(i)) & 1n);
const aR = aL.map((b) => sub(b, 1n));
const ones = new Array(N).fill(1n);
const twos = Array.from({ length: N }, (_, i) => 1n << BigInt(i));

// Sanity: aL . 2^n == v, aL o aR == 0, aL - aR == 1
console.log("aL . 2^n =", dot(aL, twos), " (should be", v, ")");
console.log("aL o aR  =", had(aL, aR), " (should be all 0)");

// Verifier challenges (Fiat-Shamir over the public commitment v).
const y = await challenge(`y|${v}`);
const z = await challenge(`z|${v}|${y}`);

// y-vector
const yN = Array.from({ length: N }, (_, i) => {
  let r = 1n; for (let k = 0; k < i; k++) r = mul(r, y); return r;
});

// l(x), r(x) at x=1 (one round of IPA — toy)
const lVec = aL.map((a, i) => sub(a, z));
const rVec = had(yN, aR.map((a) => add(a, z)))
  .map((v, i) => add(v, mul(mul(z, z), twos[i])));

// Inner product t = <l, r>
const t = dot(lVec, rVec);

// delta(y,z) = (z - z^2) <1, y^n> - z^3 <1, 2^n>
const z2 = mul(z, z), z3 = mul(z2, z);
const sum1y = dot(ones, yN), sum1_2n = dot(ones, twos);
const delta = sub(mul(sub(z, z2), sum1y), mul(z3, sum1_2n));

// The relation: t == z^2 * v + delta(y,z)
const expected = add(mul(z2, v), delta);
return { t, expected, lVec, rVec, y, z };
}

// VERIFIER ---------------------------------------------------------
function verify(p: Awaited<ReturnType<typeof prove>>) {
const ok1 = p.t === p.expected;
const ok2 = dot(p.lVec, p.rVec) === p.t;
return { ok1, ok2, ok: ok1 && ok2 };
}

// IPA fold (one round, demonstrating the recursion pattern) -------
function ipaFoldOnce(a: bigint[], b: bigint[], x: bigint) {
const half = a.length / 2;
const xi = inv(x);
const aP = a.slice(0, half).map((v, i) => add(mul(x, v), mul(xi, a[half+i])));
const bP = b.slice(0, half).map((v, i) => add(mul(xi, v), mul(x, b[half+i])));
// The cross terms L, R have the same inner product as the original.
return { aP, bP };
}

// DEMO -------------------------------------------------------------
(async () => {
const out = document.getElementById("out")!;
const lines: string[] = [];

for (const v of [0n, 7n, 15n]) {
  const p = await prove(v);
  const r = verify(p);
  lines.push(`v=${v.toString().padStart(2)}  t=\${p.t.toString().slice(0,18)}...  ok=${r.ok}`);
}

// One-shot IPA fold to demonstrate the recursion shrinks the vectors.
const a = [3n, 5n, 7n, 11n], b = [2n, 4n, 6n, 8n];
const x = await challenge("ipa|demo");
const folded = ipaFoldOnce(a, b, x);
lines.push("");
lines.push(`ipa fold: a length ${a.length} -> ${folded.aP.length}`);
lines.push(`           b length ${b.length} -> ${folded.bP.length}`);

// Out-of-range case should fail (negative -> wraps if we let it).
try {
  await prove(-1n);
  lines.push("ERROR: prover accepted v=-1");
} catch (e) {
  lines.push(`prover rejected v=-1: ${(e as Error).message}`);
}

out.textContent = lines.join("\n");
})();

/index.html

<!DOCTYPE html>
<html>
<body>
  <pre id="out" style="font-family: 'Geist Mono', ui-monospace, monospace; padding: 1rem; background: #0a0a0a; color: #4ade80; line-height: 1.6;">running...</pre>
  <script type="module" src="/index.ts"></script>
</body>
</html>

Open the vanilla-ts template on codesandbox.io

The shape is the thing. A real Bulletproof replaces my BigInt scalars with elliptic-curve points (typically Ristretto or BN254 G1), runs the IPA recursively to length 1 instead of just one fold, and uses Fiat-Shamir over a transcript that includes every public group element. The protocol stays under 700 bytes for $n = 64$ , and the verifier cost stays at $O(n)$ multiplications (the prover dominates at $O(n \log n)$ ).

Choosing a range proof in 2026

The trade-off space has settled enough to write down honestly.

Option	Cost	Latency	Blast radius	Notes
Naive bit-commitment range proof	~2.5 KB at n=64	Prover ~100ms, verifier ~10ms	Low risk; well understood since 2015	Confidential Transactions shipped this. Big proofs, but trivial to audit.
Bulletproofs (Bunz et al. 2018)	~672 bytes at n=64; logarithmic in n	Prover ~500ms, verifier ~20ms (linear)	Battle-tested in Monero, dalek-cryptography	No trusted setup. Best choice when you have one or a few range checks per tx.
Bulletproofs+ (Chung-Han-Hwang-Kim-Lee 2020)	~576 bytes at n=64	Prover ~10% faster than BP; verifier ~25% faster	Less deployment than original BP	Drop-in if you control both ends. Worth it for a fresh deployment.
SNARK-embedded range proof (Groth16 / PLONK)	~200-300 bytes; constant	Verifier ~3-5ms (constant); prover dominates	Inherits the SNARK's trusted setup story	Right answer when you're already paying for a SNARK. zera-sdk does this.
STARK-embedded range proof	~50-200 KB; logarithmic	Prover slow, verifier fast	Post-quantum, transparent setup	Big proofs are the cost. Worth it for batched provers (rollups, not transfers).

The pattern: if you’re already running a SNARK for the privacy proof, embed the range check inside it and pay nothing extra. If you don’t have a SNARK and you want short proofs without a trusted setup, Bulletproofs are the right answer. The naive bit-commitment scheme is what you ship when you don’t trust the cryptanalysis of either and you’re willing to pay 2.5 KB per transaction. STARKs are aspirational for transfers and the right tool for rollups.

In zera-sdk, the range check on amount is a 64-bit decomposition inside the Groth16 transfer circuit. Cost: 64 R1CS constraints (one per bit), zero additional bytes on chain. The Bulletproof would have been 672 bytes per spend, which on Solana at 5,000 lamports per byte adds up faster than the constraint cost in the prover.

What I’d reach for, and when

The framing I keep coming back to: range proofs are a feature of a privacy system, not a product. The product is the privacy pool. The range proof exists because, without it, the pool is exploitable. Pick the one that disappears most quietly into the rest of your system.

For the unified shielded pool on Solana, the SNARK-embedded approach wins for compute units and bytes. For a chain that doesn’t already have a SNARK, Bulletproofs are the line where the cryptography costs roughly the same per-byte on chain as a multisig and you stop arguing about it. For anything post-quantum, STARKs are the only answer — the discrete-log assumption everything else here leans on collapses to a quantum adversary, and the bullet has to be biting.

Bulletproofs greatly improve on the linear (in the bitlength of the range) proof size of confidential transactions. They are also a drop-in replacement for the range proofs used in Monero and other confidential-transaction systems, requiring no trusted setup and relying only on the discrete-logarithm assumption.

Bunz, Bootle, Boneh, Poelstra, Wuille, Maxwell ↗ source

The 80-line toy at the top of this post is the entire algebraic core of that paper, with the elliptic curve removed. Once you see that the inner-product argument is just fold the vector in half, prove a smaller statement, the rest of the construction is bookkeeping.