The Zero-Knowledge Proof You Are Imagining Is Probably Not the One We Ship

What the phrase makes people picture

Say "zero-knowledge proof" to a compliance team and they picture one thing: prove the customer is over eighteen without revealing their date of birth.

That is a predicate proof. It is the example every article uses, it is genuinely valuable, and it is a specific and demanding construction.

It is not what most systems shipping "zero-knowledge" credentials today actually do.

The two different things sharing the name

A zero-knowledge proof of knowledge, which is what a BBS+ presentation carries. The holder proves they possess a credential validly signed by the issuer, and reveals only the fields they choose. The hidden fields stay hidden, and the verifier learns nothing about them beyond the fact that a legitimate issuer signed the whole set.

A predicate proof, which computes over a hidden value. Not "here is my birth date" and not "here is a signed credential with a birth date I am withholding", but "the birth date inside this credential, which you will never see, satisfies the condition over-eighteen".

The first hides fields. The second computes on them. The second is harder, and it is what people mean when they say zero-knowledge.

What Solidus ships, exactly

Shipped: the zero-knowledge proof of knowledge embedded in a BBS+ presentation. You can hold a credential with ten fields, reveal two, and a verifier can confirm the issuer signed all ten without learning the other eight.

Not shipped: the general-purpose predicate circuits our own protocol whitepaper describes. Age-range, location-range and similar predicates would need separate zk-SNARK constructions, and no code implements those. The whitepaper describes them; the repository does not contain them.

So if your requirement is "prove over-eighteen without the birth date ever existing in the proof", we do not have it. If your requirement is "share two attributes from a credential and prove the rest were signed by the same issuer without disclosing them", we do.

Why the distinction is commercial rather than academic

Because they answer different regulatory questions.

Field hiding minimises what a verifier receives, which is a data-minimisation argument and a strong one. Predicate proofs minimise what a verifier could receive even in principle, which is a stronger argument and a smaller product surface.

A buyer whose compliance officer has been told they will never handle a date of birth again is expecting the second and will be sold the first by most vendors in this space, including us if we are careless. That is why this page exists.

The honest reason to care about the narrower one anyway

Selective disclosure with unlinkability is not a consolation prize. Revealing two fields instead of ten reduces breach exposure, reduces retention obligations, and reduces what a verifier can correlate across presentations.

All three of those are true at once and any of them alone would mislead.

What to ask any vendor claiming zero-knowledge

"Does your proof hide fields, or compute over them?" The answer separates the two constructions and most marketing pages will not have made the distinction.

"Which specific predicates do you support, and where is the circuit?" A predicate proof is a concrete artefact. If a vendor cannot name the predicates, they are describing field hiding.

"Has the cryptography been audited, and by whom?" For us the answer is no and nobody, with an audit targeted and contingent on funding.

Where this leaves a decision

If predicate proofs are your requirement, we are not the vendor and neither are most of the people advertising zero-knowledge credentials.

The audit status of this implementation

The unlinkability implementation described here is unaudited.