Prove the role.
Hide the organization.
A reference-grade zero-knowledge proof of vLEI role-membership: a holder proves control of a GLEIF-rooted organizational role credential without revealing the entity, the LEI, or the role-holder — with a per-verifier scoped nullifier, so two verifiers can't correlate the same holder. Reference implementation on self-minted test-ecosystem credentials — not adopted, endorsed, or used by GLEIF.
The honest boundaries, before anything else.
Every limit of this construction, stated up front. If a property isn't listed as real below, we don't claim it.
What it proves — and what it withholds.
The vLEI is GLEIF's verifiable-credential system for organizational identity: a chain from GLEIF's root of trust down to a named person holding a named role at a named legal entity. Presenting one normally reveals all of that. Here, the holder proves "I hold a role credential that chains to the pinned GLEIF root of trust" in zero knowledge — the verifier learns the fact and a role tier, and nothing else. The vLEI/KERI ecosystem has no zero-knowledge story anywhere; this is a novel reference implementation.
Hidden
The legal entity, the LEI, the role-holder's identifier, and the credential's identifier (SAID) never leave the holder. The verifier sees a membership proof against a published root — not which member.
Proven
That an attesting aggregator verified, at admission time, that the holder's role credential chains to the pinned GLEIF root of trust — KEL replay, delegation, and ACDC issuance/revocation, all checked in the clear before admission. Optionally, that the role meets a requested tier (e.g. an Official Organizational Role).
Scoped
Each presentation carries a nullifier derived for that verifier alone: unlinkable across verifiers, rate-limitable within one. A byte-identical replay of a captured transcript is rejected.
How it actually works
01Admission: verify in the clear, once+
An attesting aggregator runs the full vLEI chain verification in the clear — KEL replay, delegation, ACDC issuance and revocation status against the pinned GLEIF root of trust. Only a credential that passes is admitted: its blinded leaf, bound to an aggregator-attested role tier, is folded into a membership accumulator whose root the aggregator publishes.
02Presentation: prove membership, reveal nothing+
At presentation time the holder proves, in a Groth16/BN254 zero-knowledge proof, membership of a leaf under the published root — plus a role-tier predicate if the verifier requests one — without revealing which leaf. The proof also binds a nullifier derived from the holder's secret and the verifier's scope, so the same holder shows different, uncorrelatable nullifiers at different verifiers.
03Verification: fail-closed, typed rejects+
The verifier pins the trusted root and verifying key, checks the proven predicate matches the one it requested, guards against replay, and only then runs the pairing check. A foreign root, a tampered nullifier, a tier escalation, a predicate mismatch, or a replayed transcript each produce a typed rejection — you can watch all of them happen in the demo below.
04The trust model, stated plainly+
The SNARK does not re-verify KERI/ACDC; it proves accumulator membership under a root the aggregator publishes and is trusted to maintain honestly and rotate on revocation. The Groth16 setup uses a fixed published seed, so soundness is demonstration-grade: anyone who reruns the seeded setup can forge proofs under this verifying key. That is why this page calls itself a reference construction.
Watch it accept — and watch it refuse.
This runs the real thing on this server: the demo mints two role holders (one Official Organizational Role, one Engagement Context Role), admits them through the real admission protocol into a throwaway accumulator, then presents real Groth16 proofs — one honest accept, then a series of adversarial attempts that must each be rejected for the stated reason. The first run proves everything from scratch and can take a minute or two; the verdict is cached after that.
Calls GET /vlei/zk/demo on this
server — real proofs, no mock path.
Per-tier member counts are published on purpose: a tier-gated proof is only as anonymous as the number of members in that tier — in this two-holder demo, a tier-2 proof identifies its holder. A deployment needs a large membership set for the proof to hide within.
The exact honest claim this proof makes (verbatim from the server)
The claim, in full.
Claim K5-1 — verbatim from the claims ledger
A reference-grade zero-knowledge proof of vLEI role-membership: a holder proves control of a GLEIF-rooted organizational role credential without revealing the entity, LEI, or role-holder, with a per-verifier scoped nullifier (unlinkable across verifiers, rate-limitable within one). It is classical Groth16/BN254 — NOT post-quantum, uses a single-party trusted setup (demonstration-grade soundness, not a multi-party ceremony), and runs on self-minted credentials in the GLEIF test ecosystem. The vLEI/KERI ecosystem has no zero-knowledge story anywhere; this is a novel reference implementation — NOT adopted, endorsed, integrated, or used by GLEIF.