Range Proof

A range proof lets a verifier confirm that a committed but hidden value falls inside an allowed interval — typically 0 ≤ v < 2^n — without learning the value. They are the load-bearing primitive in confidential transaction systems, where amounts are encrypted but the network still has to guarantee nobody created value out of nothing.

Why it matters

In a transparent ledger, conservation of value is trivial to check: sum the inputs, sum the outputs, compare. When amounts are hidden behind commitments, that arithmetic still works homomorphically, but one thing is no longer visible — whether an output encodes a negative amount. A negative output would let a transaction balance while secretly minting supply.

The range proof is what closes that hole. Remove it, weaken it, or skip verifying it, and confidential issuance becomes unbounded.

Where it goes wrong

Range proof verification is computationally expensive, which creates pressure to optimise — batching, precomputation, and caching verification results. Each optimisation is a place where the proof can stop being checked while the code still reports success.

The September 2026 Liquid Network incident is the canonical example: a cache-key collision in Elements' range proof verification meant an invalid proof could hit a cache entry populated by a valid one, skipping verification entirely and allowing roughly 3,998 unbacked L-BTC to be created.

In audit scope

Treat any caching, batching or short-circuit layer in front of range proof verification as part of the verifier itself. The question is not "is the proof verified?" but "is there any input for which the verification result is returned without the proof being evaluated?"