Proof,
Not Exposure.

An institution needs to know whether someone qualifies for a service.

That sounds straightforward. Yet answering a narrow question can involve collecting a much broader set of information: an identity document, an exact date of birth, an address, or supporting records that reveal more than the decision requires.

The institution needs an answer. The person is asked to surrender a document.

DNA Protocol is building an alternative around a different principle: verify the required claim without unnecessarily disclosing the information behind it.

Our digital identity and zkPrivacy infrastructure connect credentials, scoped requests, cryptographic proofs and inspectable evidence. The current public workflow demonstrates this using sample credentials, real proof computation and optional XRPL Testnet anchoring. It is a working evaluation environment, not a claim of production identity verification. Explore the connected workflow.

1. The institutional problem

Consider an institution-operated portal offering a programme restricted to adults.

For the age-eligibility step, the question is simple:

Does this participant meet the minimum age requirement?

If the portal requests a complete identity document to answer that question, it may also receive a photograph, document number and other details unrelated to the age decision.

Those additional fields create additional responsibilities. Someone must decide who can access them, how long to retain them and how to handle their eventual deletion. If several services repeat the same process, the participant's information becomes distributed across more systems.

The problem is not that institutions should stop checking eligibility. It is that checking eligibility and collecting complete identity records are not always the same requirement.

This distinction is reflected in the W3C's verifiable-credentials guidance, which discusses data minimisation and the use of claims that reveal only what a verifier needs. W3C privacy considerations.

DNA Protocol's approach asks institutions to separate three questions:

• What fact must be established?
• Whose assertion of that fact will the institution accept?
• What evidence is necessary to support the decision?

Answering those questions precisely creates the foundation for a more privacy-conscious verification process.

2. Two complementary layers

Digital identity and zkPrivacy address different parts of that process.

The identity layer establishes the credential relationship: an issuer makes a claim, a holder possesses the relevant credential material, and a verifier decides whether to accept it.

The privacy layer changes how a supported claim can be demonstrated. Rather than disclosing the underlying value, the holder supplies a cryptographic proof that the required condition is satisfied.

For example, a proof can establish that a supported age threshold is met without revealing the exact birth date. This is a recognised application of zero-knowledge proofs in credential systems. W3C zero-knowledge proofs.

Neither layer replaces the other.

A credential without an appropriate disclosure mechanism can reveal too much. A mathematically valid proof without a trustworthy source can establish a relationship involving information that was never properly verified.

Identity supplies the basis for trust. Zero-knowledge proofs limit what must be disclosed when exercising that trust.

3. One connected workflow

DNA Protocol brings these responsibilities into a connected journey.

Establish the credential

The process begins with an issuer.

In a real institutional deployment, the issuer would need an appropriate process for establishing the underlying information. The receiving institution would decide whether that issuer is acceptable for its particular purpose.

DNA's current evaluation uses a demonstration authority and test eligibility records. A signed registry snapshot and a holder commitment provide technical elements of the credential relationship, while the issuer's real-world authority remains a separate trust decision. Credential issuance.

That separation matters. Cryptography can help establish that information corresponds to an accepted registry and key. It does not independently establish that an organisation collected accurate information or was entitled to issue the claim.

Hold the credential

Vault provides the holder-facing part of the journey.

The holder works with a test credential and the private values needed to generate a proof. These private inputs are not included in the resulting proof package.

This changes the interaction from uploading a complete record to responding to a defined verification request. The current Vault is an evaluation interface, not a production document-storage or credential-recovery service. Credential holding and sharing.

Sandbox provides a separate environment for exploring the identity workflow and understanding the roles before following the connected journey.

Define the request

An institution should not request an undefined confirmation that someone is “verified.”

It should specify the requirement relevant to the decision.

zkBridge coordinates this request, including a challenge and a validity window. The holder can review the requested policy and audience before completing the proof flow.

Here, “bridge” refers to coordination between participants in the verification process, not the movement of tokens between blockchains. The purpose is to connect a particular request with the holder's response. Scoped requests.

For our illustrative programme, the request concerns adult eligibility. Other enrolment requirements remain separate.

Generate and verify

The holder's browser generates a Groth16 proof using the supported private inputs.

In the public age-policy evaluation, the proof excludes the holder secret and exact sample birth date. The verifier receives the proof and public inputs needed to check the statement against the sample registry, policy and one-use challenge.

zkProof performs the application-side verification. The public workflow includes eligible, underage and expired sample cases so that the evaluation is not limited to a successful outcome. Connected proof evaluation.

The institutional significance is straightforward: the receiving service can evaluate a supported condition without receiving the private values used to prove it.

Inspect the evidence

A useful verification process must also explain its result.

zkTransparency provides an inspection layer for supported records, distinguishing ledger information, packet structure and supported proof checks. It makes the available evidence visible without treating every transaction or recognised data format as a successful privacy guarantee. Evidence inspection.

This is important for operational review. “A record exists” and “the required checks succeeded” are different conclusions.

4. XRPL's precise role

XRPL provides an optional evidence-anchoring layer in the current Testnet journey.

Proof verification happens in the application. A separate, explicit action can publish a commitment to XRPL Testnet, providing a ledger reference that can be compared with the associated evidence.

An anchor is not a replacement for the proof. It does not establish the truth of a real-world identity claim, and XRPL validators do not perform DNA's application-specific Groth16 verification. DNA's lookup separates supported proof verification, transaction validation and commitment comparisons. zkProof verification scope.

This distinction prevents an important mistake: interpreting “on-chain” as synonymous with “verified.”

Institutions need both a clear account of what was checked and an accurate description of what the ledger records. Where anchoring is used, the supporting evidence must also remain available for meaningful inspection.

5. What actually changes

Return to the institution's adult-only programme.

In a document-upload approach, the age check can result in the portal receiving a complete document.

In the proposed credential-based approach, an accepted issuer establishes the relevant information, the participant responds to a narrowly defined request, and the portal evaluates the supported proof.

The portal's age-checking function receives evidence for its decision rather than another copy of the underlying document.

This is an illustrative institutional application, not a claim that a named institution currently uses DNA Protocol.

Its value is nevertheless concrete.

Less unnecessary collection. A service designed to receive only the required proof and public verification data can avoid collecting unrelated document fields at that step.

More consistent checks. A defined policy gives the verification process an explicit target. Reviewers can distinguish the requirement being evaluated from broader questions about the applicant.

Clearer accountability. Issuers are responsible for the assertions they make. Verifiers choose which issuers and policies they accept. Holders respond to specific requests. Evidence supports review of the resulting process.

A measurable integration objective. An institutional pilot can measure document uploads avoided, completion times, rejection handling, support demand and the quality of retained evidence. Those measurements would establish operational value; they should not be replaced by unsupported savings estimates.

The aim is not to remove every identity check. It is to stop treating every eligibility check as a reason to collect an entire identity record.

6. Privacy requires precision

Zero-knowledge does not mean that no information is revealed.

The verifier learns the outcome of the supported claim. Public inputs and workflow metadata may also be visible. When ledger anchoring is used, published addresses, timestamps and commitments can introduce correlation risks.

DNA's transparency tooling explicitly separates observable evidence from claims it cannot establish, including anonymity, confidentiality and real-world identity. Transparency boundaries.

A responsible institutional design therefore considers the entire workflow: issuance, proof generation, request handling, logging, retention and publication.

The correct privacy question is not simply, “Does this system use a zero-knowledge proof?”

It is, “What can each participant learn, and is that information necessary for their role?”

7. From evaluation to deployment

The current public identity pipeline demonstrates real cryptographic computation with sample credentials. It uses a development trusted setup and is not independently audited. Its test issuer and verifier share a service rather than representing independent institutional trust relationships. Current evaluation boundaries.

Moving from this environment to institutional production requires more than changing a network label.

It requires an accepted issuer, a reliable identity-proofing process where needed, secure key custody, credential recovery and revocation procedures, integration controls and independent security assessment. Those are deployment requirements, not services automatically supplied by the demonstration. Issuer readiness requirements.

An institution must also determine which information its particular service genuinely needs. A narrow eligibility proof does not automatically replace broader identification or recordkeeping requirements.

8. Beyond one policy

Age eligibility is a useful starting point because the distinction between a private input and a required answer is easy to understand.

The same institutional question arises elsewhere:

• Does this person hold an accepted professional qualification?
• Is this organisation approved for a particular procurement process?
• Is this participant entitled to enter a restricted service?

These are potential applications, not claims that the current age circuit already supports them. Each requires suitable credentials, trusted issuers, supported proof statements and an operational integration.

What carries across is the design principle: request evidence for the decision, rather than collecting every detail behind it.

9. The institutional outcome

DNA Protocol connects digital identity and zkPrivacy because institutions need both a trustworthy basis for a claim and a controlled way to verify it.

Credentials establish the relationship between issuer and holder. Scoped requests define the question. Zero-knowledge proofs support limited disclosure. Verification evaluates the supported statement. Inspection tools explain the available evidence. Optional XRPL anchoring adds a separate public reference.

Together, these components demonstrate an alternative to document-first eligibility checking.

The problem we address is unnecessary exposure during verification. The outcome we are building towards is an institution that can make a justified decision while collecting less information to make it.

That is the utility: not privacy instead of verification, but privacy built into how verification works.