Who shares what. And why.
Follow one age check from a signed credential to a verified requirement.
Personal data stays in your wallet during the check.
Illustrative ZKP flow. Other devices show network context; they do not receive this exchange.
Look inside the exchange.
Inspect the credential, request, proof or verification checks. Selecting a tab pauses the animation.
VC: the issuer-backed credential
A verifiable credential (VC) records claims made by an issuer and protects them against tampering. The issuer sends it to the wallet. A later verifier can check the required claim without receiving every field.
Fictional example fields, not a signed credential or executable proof. This illustration does not send personal data.
{
"type": "VerifiableCredential",
"issuer": "Demo issuer",
"credentialSubject": {
"name": "Alex Example",
"birthDate": "2000-01-01"
},
"issuerSignature": "[illustrative; not a real signature]"
}The mathematics behind the check
Conceptual notation. A selected proof system must verify the issuer-backed credential, the age condition and the binding to this request. A valid proof alone does not establish whether the issuer’s original information was correct.
π = Prove(pk, private_witness, public_inputs)
Verify(vk, π, public_inputs) → true / false
birthDate ≤ 2008-09-14 ⇔ age ≥ 18 on 2026-09-14Private witness: credential attributes and signature, with any required holder secret.
Public inputs: age threshold, agreed reference date, request challenge and the issuer or verification-key reference required by the chosen protocol.
The proof format, circuit, holder binding and status handling depend on the selected implementation. This animation does not run a ZKP engine.
A pilot validates the chosen proof system, supported devices, issuer trust and credential status checks.