We are building tools to explore how a person can prove a specific claim without sharing every underlying detail. Our current reference workflow brings test credentials, zero-knowledge proofs and XRPL receipts into one connected experience.
Cryptographic proofs can check bounded claims. Ledger records can provide public evidence. Neither replaces a trustworthy issuer or establishes a person’s real-world identity on its own.
🧬 Digital Credentials
Explore test issuance, holder commitments and signed registry snapshots in a controlled evaluation workspace.
🧬 Scoped Proof Requests
Bind a request to an audience, challenge and validity window. Check the claim without including its private witness in the proof.
🧬 Hands-On Evaluation
Follow the issuer, holder and verifier roles with test samples. Inspect rejection cases as carefully as successful results.
🧬 Evidence Inspection
Read proof results, registry references, current status and optional XRPL evidence as distinct checks.
The connected evaluation moves between Vault, zkBridge, zkProof and zkTransparency, with an explicit XRPL anchoring step. The separate Identity Sandbox explains the roles and checks through a guided lab.
Biological identity remains a research direction. Today’s tools do not process real DNA, validate clinical results or prove genomic ownership. Production adoption requires independent review and a clearly defined operator and trust model.
- Test credentials and holder commitments
- Audience-bound presentation requests
- Browser-generated proofs for a defined policy
- Signed registries and explicit verification results
- Optional registry evidence on XRPL
- Validated transaction receipts, not just hashes
- Current status alongside historical evidence
- Clear boundaries between evaluation and production
A verifier should request a specific claim, not an entire identity file. Data minimisation begins with the question.
A proof is meaningful only in relation to its circuit, public inputs and acceptance policy. State those boundaries clearly.
A ledger receipt, issuer signature and zero-knowledge proof answer different questions. Inspect each on its own terms.
The holder secret stays in the original browser tab. Do not put real identity documents or genomic data into the evaluation tools.
A valid signature identifies a signing key. Whether that issuer is trusted is a separate decision for the verifier.
Use an audience, challenge and expiry to define the intended presentation. Request freshness is part of verification.
Historical success does not mean a credential is still active. Revocation and expiry need a current check.
Check the network, validated status and transaction result. A returned transaction hash alone is not confirmation.
An expired request or rejected proof is a meaningful result. A useful evaluation makes failure understandable.
Some continuation and receipt links carry access capabilities. Share them only with the intended participant.
Accounts and submitted ledger metadata are public. Encryption does not hide the existence of a transaction.
Genomics is a future application area, not a capability established by a test age-eligibility demonstration.
Independent review, recovery, issuer governance and privacy assessment matter more than a polished demonstration.