Identity, without
unnecessary exposure.

Digital services often collect an entire document to answer a much smaller question. Is this credential current? Was it issued by an accepted authority? Does its holder meet an eligibility rule? DNA Protocol explores how to answer bounded questions with less disclosure, while keeping the evidence inspectable.

The design separates three things that should not be confused: an issuer makes a claim, a cryptographic proof checks a defined relation, and a ledger records public evidence. None is a substitute for the others. A correctly verified proof can still rely on an untrustworthy issuer; a confirmed transaction can still contain a false claim.

The current reference implementation is a synthetic digital-identity evaluation on XRPL Testnet. It connects credential holding, presentation requests, eligibility proofs and optional ledger receipts. It is not a national identity service, a genomic identity system or a production-ready personal document store.

The connected journey begins in Vault, where a holder creates a synthetic credential and retains the secret needed to prove possession. zkBridge creates a scoped presentation request. The original Vault browser generates a proof, and the connected zkProof verifier evaluates it. An explicit ledger action can then publish registry evidence, which zkTransparency exposes alongside the scoped receipt.

These are complementary interfaces, not separate blockchains. zkBridge coordinates a presentation handoff; it does not bridge tokens or prove another chain’s consensus. The Sandbox is an evaluation environment for the same class of identity workflow, not an additional trust authority.

This architecture describes the connected /pipeline/ routes. Some tools also expose standalone demonstrations with different checks. Their results must be read according to the mode actually used.

In the lab, the holder generates a random secret. A Poseidon commitment to that secret is combined with synthetic birth and expiry dates and a credential serial to form a registry leaf. A depth-8 Merkle tree commits to the active registry. A membership path lets the holder prove inclusion without presenting the entire registry as the private witness.

The demo authority signs a registry envelope with Ed25519. The envelope binds the registry root, version, workspace and verification-key digest. This signature is checked by the application outside the Groth16 circuit. The system should therefore be described as a proof against an authenticated registry, not as an issuer-signature proof inside the circuit.

An issuer signature identifies a signing key. It does not establish that the issuer is a government or that its underlying facts are true. In this evaluation, the authority is trusted only within the lab and the attributes come from fixed synthetic fixtures.

Real deployment would require issuer governance: enrolment rules, key custody and rotation, revocation authority, audit trails and a way for verifiers to decide which issuers to accept. The demo backend performs both issuer and verifier roles; it does not demonstrate institutional independence.

The eligibility circuit uses Groth16 on BN254. It checks that the prover knows a secret opening the holder commitment in a registry leaf; that this leaf belongs to the public root; and that its synthetic birth and expiry dates satisfy the requested policy. The current relation requires birthDay ≤ cutoffDay and asOfDay ≤ expiresDay.

The circuit produces a nullifier derived from the holder secret, nonce and audience. This binds the proof output to a particular presentation context. The verifier must still enforce its request lifetime, compare the expected public signals and consume the request once. A cryptographically valid proof can be rejected because its context is stale or already used.

This does not prove a real person’s age, uniqueness, nationality, consent or genomic characteristics. It proves the specified relation over the lab’s committed synthetic data. Sound cryptography cannot make an unverified input fact true.

In the connected evaluation, anchoring is an optional, explicit action. The service submits registry evidence to XRPL Testnet and records the transaction reference. An inspector should check the validated ledger result and the actual submitted fields. A returned hash alone is not sufficient evidence of a successful transaction.

The ledger makes submitted account and transaction metadata public. It does not conceal a memo, evaluate this Groth16 circuit or decide whether an issuer is trustworthy. The connected application performs proof verification off-ledger. A registry anchor must not be presented as XRPL validators independently verifying the holder’s eligibility proof.

Vault also has a separate native-credentials demonstration using CredentialCreate, CredentialAccept and CredentialDelete. Its backend signs for the demo issuer and holder using Testnet accounts. That is not a user-wallet consent flow, and a native credential object is not a zero-knowledge proof. Read the XRPL Credentials model ↗.

The legacy zkProof transaction lookup inspects ledger and packet evidence. The connected /pipeline/ verifier is the mode that checks a Groth16 eligibility proof. These results answer different questions and should remain separately labelled.

Zero knowledge limits what the proof reveals about its private witness. It does not automatically hide account activity, timing, public signals, service logs or the fact that a presentation occurred. Repeated identifiers, roots and transaction metadata can create correlation opportunities. Privacy analysis must cover the whole workflow, not only the circuit.

Continuation and receipt links contain scoped bearer capabilities. Whoever obtains a valid link may gain its associated access. They are not public marketing URLs. The holder secret stays in the original browser memory in the current workflow; refreshing that tab can make a credential unusable. This is not a durable recovery design.

The service uses encrypted state storage, but the backend can read the state it processes. At-rest encryption is not end-to-end encryption against the operator. A real document vault would additionally need a defined encryption and key-recovery model, retention policy, access controls and recipient-sharing rules.

Revocation and expiry affect current validity. They do not remove a previously published ledger record or undo knowledge already disclosed to a recipient. Likewise, an earlier accepted proof is a historical result, not a perpetual eligibility certificate. The verifier must check the current registry and request context.

The implementation relies on the selected cryptographic primitives, correct circuit constraints, verifier code, randomness and key handling. Its Groth16 artifacts use a development trusted setup. They are not the output of a production-grade, independently reviewed ceremony. A web deployment does not change that assurance level.

The verifier authenticates registry evidence and binds it to the expected verification-key digest. It checks freshness before and after asynchronous proof verification so that a changing registry cannot silently turn an old result into current acceptance. Requests have a limited lifetime and one-time consumption rules. These controls are necessary around the proof, not optional polish.

Operationally, the connected service persists state and uses concurrency controls. For ledger actions, pending transaction information must survive uncertain responses so that the service can query an existing submission rather than blindly submit again. Dependency failure should produce an explicit unavailable or unresolved state, not a fabricated success.

Before use with real people, the system needs independent circuit and application review, production key management, abuse testing, incident handling and a privacy assessment. The synthetic lab does not establish regulatory compliance or national-scale readiness.

A useful evaluation should include both successful and rejected presentations. Start with a synthetic adult fixture, then test an underage or expired fixture. Confirm that the requested audience and policy match the public signals. Repeat a consumed request and check that it cannot be accepted again. Revoke a credential and distinguish the earlier receipt from its current status.

For an explicit Testnet anchor, retain the transaction reference and confirm validation, result and published fields. Do not infer live ledger success from an animation, a generated proof or a local test. This whitepaper runs no transactions; the linked tools are the place to perform the evaluation.

XRPL Testnet is a separate network for experimentation. Its assets have no Mainnet value, and a test environment is not a permanence or availability guarantee. XRPL parallel networks ↗.

The register below describes implementation scope, not an independent audit or a real-time service-health monitor. Availability, rate limits and access requirements remain those of each tool.

The XDNA utility thesis is an application-layer proposal. It is not a requirement imposed by XRPL, and holding XDNA does not currently grant the service entitlements described here. The running synthetic identity workflow should not be mistaken for deployed token billing, token-gated access or token-based governance.

Four potential roles organise the proposal: service credits for defined application usage; developer access to specified tooling or capacity; ecosystem participation under published programme rules; and governance over explicitly scoped application decisions. Each role needs a concrete implementation, terms, limits and a way to verify what a user receives.

An access mechanism must not compromise the privacy objective. Public token balances, payment accounts and presentation activity can become linkable. If token utility is implemented, that relationship needs a documented threat model and a deliberate separation between service accounting and private credential data.

A credible utility release starts with a useful service and measurable delivery. It should publish what is live, what costs XDNA, how failures and refunds are handled, and which functions remain available without it. There is no promise of returns, guaranteed access or future value in this proposal.

XRPL transaction costs are paid in XRP. XDNA does not replace that requirement and does not secure XRPL consensus. An application may sponsor a network transaction or charge for its own service, but those are application decisions layered above the ledger’s fee mechanism. XRPL transaction cost ↗.

In a future XDNA service-credit model, the application would need to specify the service unit, payment verification, account attribution and redemption rules. It would also need to explain who funds any XRP transaction cost. A token transfer alone is not evidence that a proof was verified or that a credential is trustworthy.

Testnet faucet funds are used for evaluation. They are not a model for sustainable commercial operation and must not be conflated with Mainnet balances or token-sale proceeds. Any future paid deployment would require its own operational and commercial decisions.

Supply, allocation and sale information remain in the separate Tokenomics document. This technical and utility rewrite does not revise those figures or introduce new economic rights. The proposal must be evaluated independently from any expectation about token price.

DNA Protocol’s origins are in biological identity and data sovereignty. The present identity lab is narrower: it evaluates synthetic eligibility claims. It does not ingest DNA sequences, authenticate biological samples or prove ownership of a genome. Extending the system into genomics would be a new, separately validated application, not a change of labels.

A future research workflow might allow an authorised laboratory to issue a bounded credential about a test or research eligibility. A holder could then prove a specific predicate without sharing the underlying report. That design would still depend on validated laboratory processes, trustworthy issuance, appropriate consent and a circuit that faithfully represents the intended claim.

A hash can help detect changes to particular bytes. It does not establish lawful ownership, consent, biological provenance or the accuracy of a clinical conclusion. Hashes of sensitive or guessable inputs can also introduce privacy risks. A commitment scheme and its disclosure model must be designed for the actual data, not assumed safe because the output looks random.

No genomic or clinical claim should inherit credibility from this synthetic demonstration. Real samples, personal documents and genetic data do not belong in the evaluation tools. Partnerships, approvals and validated capabilities should be described only when they exist and their scope can be evidenced.

The next stage is to strengthen the existing workflow before multiplying tools. The goal is one coherent pipeline with clear issuer trust, well-defined proof statements, reliable evidence and honest failure states. A product should move beyond synthetic evaluation only after its assurance requirements are met.

Interoperability is a design direction, not a current certification. The W3C Verifiable Credentials Data Model ↗ offers a reference for issuer, holder and verifier relationships. The current custom registry and presentation formats are not claimed to conform to that standard or to provide a complete wallet protocol.

Release decisions should be gated by independent review, a suitable trusted setup and key-management model, explicit issuer acceptance policies, recovery design, privacy assessment, and tested load and failure behaviour. Dates or additional subdomains are not substitutes for those outcomes.