Earlier this month we closed the soundness gap in our confidential transfers: the no-inflation guarantee now rests on a hash-based STARK, so a quantum computer cannot forge a balance proof and mint coins. That post ended with one honest admission. The soundness was proven, but the amount-hiding was only evidenced.
This post is about closing that last gap, carefully, and the on-chain record of doing it.
The distinction that matters
A confidential payment has to hide the amount and also guarantee that no value is created. Those are two separate properties, and we hold ourselves to being precise about the status of each.
Our live construction is built on Winterfell, an audited STARK library. A STARK proves a statement without a trusted setup and with only a hash assumption, which is exactly what gives us post-quantum soundness. But Winterfell is not natively zero-knowledge. A STARK proof, left to itself, opens a handful of points on the polynomials that encode the computation, and from enough of those points an observer can interpolate and recover the witness, which here is the amount.
We made the amounts hidden anyway, by a masking layer: we run the proof over a longer trace, leave the trailing rows unconstrained, and fill them with cryptographic randomness, so the opened points never pin down the real values. We measured this. A held-out distinguisher trying to read the amount from the proof bytes sits at chance, the information-theoretic leakage bound comes out near zero, and two proofs of the same payment differ. That is strong evidence. It is not a proof. The hiding rested on our own masking argument rather than on a property of the proving system.
For a layer that protects value, evidenced is not the same as proven, and we said so plainly at the time. This is the successor.
A proving system that hides by construction
The fix is to use a proving system whose zero-knowledge is part of the system, not bolted on. We reimplemented the three confidential circuits (the note opening, the public-value opening for the plaintext ramps, and the two-input two-output transfer) on Plonky3, using its hiding polynomial commitment scheme. That scheme salts the Merkle leaves, adds random codewords, and randomizes the FRI batching, so the proof reveals nothing about the witness as a property of the construction. The amount-hiding stops being our argument and becomes the proving system's guarantee.
The Rescue Prime hash inside the circuit was reproduced over the new stack and cross-checked, byte for byte, against the hash the live chain already uses, so the note commitments are identical and the two systems interoperate. A note is a note across both.
Two facts made this practical to put in consensus. First, the verifier compiles to the same no_std WebAssembly target as the runtime, so it runs inside the state-transition function that every validator already executes. There is no new trusted node component and no host function. Second, the size cost is small: adding the verifier grew the compressed runtime by about fifty-eight kilobytes, under nine percent. The old worry that a STARK verifier is too heavy to carry in a runtime did not survive contact with the measurement.
Shipped the way value-bearing crypto should be shipped
We did not flip this on in one step.
It went live first as an isolated pool with no plaintext exit. Notes could be seeded and moved note to note, but nothing could be shielded in from a plaintext balance or unshielded out to one. No real value could enter or leave, so even a defect in a brand new verifier could not move funds. That let us exercise the verifier in real consensus with zero value at risk. A tampered proof was rejected in the block that included it without disturbing finality, which is the in-consensus evidence that a malformed proof cannot halt the chain, and a valid proof was accepted.
Only then, and only after an independent review, did we promote it to a value-bearing path by adding the plaintext on and off ramps. Those ramps use the same model as our live ramps: a shield burns a signature-authorized plaintext output and mints a note proven to open to exactly its value; an unshield spends a note proven to open to a revealed value, bound to its destination so a relayer cannot redirect it in transit, and mints a plaintext output, with a conservation counter that fails closed so nothing can ever release more than was shielded in.
Because the verifier lives in the runtime rather than in a node binary, both the deployment and its rollback are ordinary runtime upgrades. There was no validator software to roll out, and the rollback path is a single pinned upgrade away. That is a materially safer posture than a change that touches node software, and it is a direct payoff of keeping verification in the runtime.
The on-chain record
A full round-trip of real value through the new path is finalized on chain. Every step below is a finalized transaction you can open in the explorer.
- Shield real value into the new pool. The pool conservation counter went from zero to the shielded
amount. Block 1241409, extrinsic
0xf054bdbf...a096595a. - Attempt an unshield whose proof was re-pointed to a different address. Rejected, because the proof
is bound to its destination. Block 1241412,
extrinsic
0xbfc421fa...290845df. - Unshield to the rightful destination. Accepted, the note spent, the conservation counter back to
zero. Block 1241417, extrinsic
0xcd637ce9...4226c21c.
Finality held at a gap of two to three blocks across the upgrade and across the tests. The full record, including the runtime upgrades and the block hashes, is in the paper appendix linked from our research page.
How to use it
The proven-hiding path is wired into both the command line tool and the wallet. In the wallet, the private panel now has a proof system toggle. Leave it on the existing setting for the established path, or switch it to the new one to shield and unshield through the proving system whose hiding is a guarantee rather than an argument. Proofs are generated in your browser, so your amounts and blinding factors never leave your device. From the command line, the same flow is two commands.
Both paths are live. Real value still flows through the prior construction, whose soundness is proven and audited and whose hiding is strongly evidenced. The new path runs alongside it with the hiding now proven, deployed after an independent review and confined first to a pool where a defect could not have cost anyone a coin.
What is still open, stated plainly
A complete, written-out formal zero-knowledge proof of the exact masking construction on the prior path remains the principal open problem, and we are inviting peer review on it. The new path is the answer to that problem in the sense that it makes hiding a property of the proving system, but we do not overstate it: we claim that the proven-hiding path is now live and value-bearing, that it was reviewed before deployment, and that the evidence above is on chain and checkable. That is the bar we hold, and we would rather meet it than exceed our claims.