Public-interest protocol initiative Seeking €65,000 grant funding Planned with Fraunhofer TRAIN collaboration

The zero-knowledge trust network for humans, agents and devices.

Trust, anchored below today’s identity stack.

.zkdid™ proposes a decentralised, zero-knowledge DNS trust anchor for people, agents and devices, designed to prove uniqueness and continuity without exposing raw biometrics, surrendering sovereignty, or depending on closed registry power.

Explore the architecture Watch private proof flow
Grant ask

Seeking €65,000 for a 12-month research and architecture phase.

The proposed phase is structured around Fraunhofer TRAIN research delivery, open publication, standards-aware design, and reusable public artefacts.

Research-first scope Voluntary project leadership Open outputs intended Chain-agnostic design
Zero-knowledge privacy Open-source intent Standards-aware design Proof-of-personhood Human-rights orientation
Trust paradox

The structural problem .zkdid™ is designed to address.

€65k

Architecture-first budget directed to research delivery.

Fraunhofer

A credible institutional pathway for implementation and standards work.

Architecture-first, standards-aware delivery
Open source under Apache 2.0 intent
Public-good, token-free governance direction
Designed for institutional scrutiny, not hype cycles
The problem

The identity industry still depends on trust anchors that can be captured.

Decentralised identifiers promise sovereignty, but in practice most systems still rest on registries, issuers, resolvers, or naming layers that users do not control. That leaves a structural weakness at the root of identity itself.

Registries become chokepoints

Most identity systems still depend on someone else’s registry, resolver, or approval logic. That makes the trust anchor easy to centralise, capture, or quietly reshape.

Privacy is often conditional

Biometrics and personhood checks are commonly handled through systems that can accumulate raw data, create tracking surfaces, or force users into opaque trust relationships.

Sovereignty stops at the wrong layer

Wallets and credentials may look decentralised on the surface, yet the foundation beneath them can still be governed by gatekeepers with the power to revoke, deny, or surveil.

The ecosystem keeps rebuilding the same root

Projects repeatedly reinvent naming, uniqueness, and Sybil resistance instead of sharing a neutral trust substrate that can serve many DID methods and applications.

Why existing systems still fail

Many projects improve a layer. Few fix the root.

  • New DID method: solves identifier format, but not the neutrality of the underlying trust anchor.
  • Credential wallet: improves user experience, yet often depends on external registries and issuer power.
  • Biometric personhood scheme: may prove uniqueness, but can introduce tracking, centralisation, or long-lived identifiers.
  • Naming service: may resolve names, but is rarely designed from the start for privacy-preserving personhood and standards alignment.
The trust paradox

Users are told they are sovereign, but must still trust the infrastructure that defines them.

This is the paradox at the centre of proof-of-personhood and digital identity. The systems that claim to protect autonomy often require users to rely on exactly the registries, operators, or trust frameworks that could later reshape, surveil, or constrain that autonomy.

To be recognised, a person must enter someone’s system.
That system can define what counts as valid identity.
The same actor can often observe, revoke, or throttle access.
So the promise of sovereignty is weakened at the foundation itself.
Conventional identity claim

“This is John Smith, verified by XYZ.”

This model centres the authority making the claim. It can create dependency on issuers, reusable identity assertions, and more visibility than many people should have to accept.

  • Identity is bound to who verified you
  • Verification can reveal too much, too often
  • A central party stays structurally important
The .zkdid™ distinction

“This is the same unique human you interacted with before.”

That is a fundamentally different promise. It focuses on continuity, uniqueness, and anti-impersonation without needing to reveal the person behind the interaction or expose raw biometric data.

  • Not a duplicate or synthetic actor
  • Not an impersonator wearing someone else’s credentials
  • Not a demand to disclose a person’s full identity to every service
The proposed solution

.zkdid™ proposes a decentralised DNS trust anchor enhanced with zero-knowledge proofs.

Instead of pushing all trust into wallets, issuers, or app-layer logic, .zkdid™ aims to create a more neutral identity root: open, standards-aware infrastructure designed to verify personhood and integrity without turning privacy into a trade-off.

Identity-first decentralised DNS

Aims to turn naming infrastructure into a privacy-preserving trust anchor for people , agents and devices, rather than treating identity as an afterthought above the stack.

Zero-knowledge and trustless by design

Verification is intended to rely on cryptographic proof and verifiable state rather than asking a central operator to decide who is real, while avoiding exposure of raw biometrics, passport scans, or unnecessary personal data.

Bolt-on trust layer

Designed as a reusable identity-risk layer: analogous in purpose to Web2 anti-abuse tools such as reCAPTCHA, but built for privacy-preserving DID, proof, resolver, and device infrastructure rather than opaque scoring.

Human-rights-oriented architecture

Identity existence is treated as infrastructure. Access decisions can sit higher up, but the core anchor is intended to remain resolvable and resistant to arbitrary global disablement.

Public-good governance direction

The governance model is intended to avoid token-weighted capture, rent extraction, and venture-style incentives that can distort core identity infrastructure.

Institution-ready standards path

The work is framed to map against recognised identity, credential, trust-anchor, and privacy frameworks so CTO, CISO, policy, and audit audiences can evaluate fit quickly.

Standards and trust-framework fit

Designed to map against the frameworks serious reviewers already care about.

.zkdid™ is not presented as a replacement for the existing identity ecosystem. It is intended as a privacy-preserving trust-anchor layer that can be evaluated against recognised DID, credential, regulatory, and resolver-based trust frameworks.

W3C DID CoreIdentifier, document, method, and resolution alignment intent.
Verifiable CredentialsCredential and proof workflows remain compatible with issuer/verifier ecosystems.
DIF ecosystemDesigned for DID method, resolver, wallet, and trust-layer interoperability discussions.
Fraunhofer TRAINTrust-anchor integration blueprint for DNS-style and registry-aware verification flows.
eIDAS / EUDI directionArchitecture can be assessed against European digital identity and trust-service expectations.
GDPR-aware designData minimisation, privacy by design, and scoped disclosure are architectural requirements.
Storyboard proof flow

A private proof journey, shown as a device-native flow.

The storyboard turns the architecture into a human-readable journey: keys stay hardware-bound, credentials remain local, the registry receives commitments rather than identity data, and verifiers receive fresh scoped proofs.

Local firstKeys and raw credentials remain on the device.
Proof basedCommitments and nullifiers reduce duplicate or synthetic actors.
Resolver awarePublic verification material is exposed without raw identity.
Lifecycle safeRecovery and credential updates preserve continuity without exposing the person.
Step 01 / 10

Private onboarding on a sovereign phone root.

The user begins locally. Keys stay device-bound, and no raw biometrics or personal documents leave the phone.

Swipe or tap the phone to move through the steps.

Discuss the flow
How it works

A high-level architecture for trust without exposure.

This phase is architecture-first. The immediate goal is to formalise the trust model, privacy boundary, standards alignment, and integration logic required for later implementation.

  • A decentralised DNS-style root zone for people, agents and devices
  • Zero-knowledge proofs linked to domains rather than raw personal data
  • Compatibility mapping for W3C DID, VC, DIF, TRAIN, eIDAS-facing, and GDPR-aware trust frameworks
  • Separation of identity existence from service-level authorisation
01

A unique domain anchor is established

A .zkdid™ identity domain is designed to act as a neutral naming and discovery anchor for a person or device, independent from any single wallet, vendor, or platform.

02

Proofs are generated off-chain

Zero-knowledge circuits are intended to let a person prove relevant facts such as uniqueness, continuity, or an attribute threshold without disclosing raw source material.

03

Only what must be anchored is anchored

The registry model is designed around commitments, references, and verification logic rather than publishing revealing biometric or personal data to the network.

04

Applications resolve trust, not exposure

Wallets, DID methods, governance systems, services, and IoT devices can query the trust anchor to verify integrity while preserving the privacy boundary.

05

Policy remains above the root layer

The architecture deliberately separates identity existence from service-level authorisation, reducing the risk that one central actor can erase a person from digital participation.

Why this matters in practice

Designed for edge and device adoption, not just another app.

.zkdid™ is intended to serve as a shared trust substrate for ecosystems that need personhood, continuity, naming, and integrity without defaulting to centralised databases or rent-seeking control points. The longer-term direction is edge-native and device-aware: designed to sit as close as possible to the operating system, resolver, and hardware trust boundary rather than being reduced to just another application layer product.

Proof-of-personhoodSupports one-real-human assertions without exposing source biometrics or documents.
Trusted continuityLets services know they are interacting with the same unique human again.
IoT registriesExtends trust and discovery to devices and connected infrastructure.
Sybil-resistant governanceSupports governance flows where uniqueness matters more than token balance.
Selective disclosureEnables minimum-necessary proof such as authorised entry or age threshold.
OS and resolver directionIntended to move closer to the operating system, resolver path, and device trust boundary over time.
Cross-ecosystem integrationChain-agnostic and designed to interoperate across ecosystems.
MVP focus

This phase is designed to leave the ecosystem with reusable architecture.

  • Complete ZK-DID architecture design
  • Early standards engagement and specification direction
  • Integration architecture across naming and trust flows
  • TRAIN trust-anchor blueprint and risk models
  • Open repositories, toolkit material, and publication outputs
Illustrative anchor example

A DID can point to an opaque .zkdid™ trust anchor without exposing a readable identity.

This is an illustrative mock-up, not a final specification. The point is to show how a DID document or related metadata could reference a non-human-readable .zkdid™ anchor while keeping service endpoints, proof material, and policy logic cleanly separated from raw personal identity.

Opaque rootThe anchor is intentionally non-human-readable and does not reveal a real-world identity.
Resolver awareApplications resolve verification material and service metadata rather than personal source data.
Policy above rootAuthorisation, permissions, and business rules can change without deleting the underlying identity anchor.
Illustrative JSON mock-up
{
  "id": "did:zkdid:9f3b2d7e4c1a8b6f",
  "alsoKnownAs": [
    "zkdid://4f7c.8a10.f13d.91be.7c42"
  ],
  "verificationMethod": [{
    "id": "#device-key-1",
    "type": "JsonWebKey2020",
    "controller": "did:zkdid:9f3b2d7e4c1a8b6f"
  }],
  "service": [{
    "id": "#resolver",
    "type": "ZkDidResolverEndpoint",
    "serviceEndpoint": "https://resolver.zkdid/query"
  }],
  "proofAnchor": {
    "ddns": "zkdid://4f7c.8a10.f13d.91be.7c42",
    "nullifierRoot": "0x8f2a…91c4",
    "stateCommitment": "0x71bd…e440"
  }
}

Mock-up only, shown to illustrate the relationship between a DID, resolver metadata, and an opaque .zkdid™ trust anchor.

Credibility and standards value

Structured for serious review, not hype cycles.

The case for .zkdid™ is not built on token speculation or marketing theatre. It is built on architecture, open publication, standards alignment, institutional collaboration, and the reuse value of shared public infrastructure.

Project leadership

Led as a public-interest initiative rather than a venture-backed product.

The project is being driven by the originator of .zkdid™ with strategic guidance contributed voluntarily, helping keep grant funding directed toward research delivery, architecture, publication, and open outputs.

Research delivery pathway

Fraunhofer TRAIN is the proposed execution partner for the funded phase.

The planned collaboration is framed around Fraunhofer Society’s TRAIN team, providing a serious pathway for trust-anchor research, integration architecture, and standards-aware technical output.

Ecosystem and standards context

DIF relevance matters because standards adoption matters.

.zkdid™ is being developed with awareness of the Decentralized Identity Foundation ecosystem under the Linux Foundation umbrella. That context is included to show standards relevance and interoperability intent, not to overstate formal DIF endorsement.

Fraunhofer collaboration pathway

Planned delivery is framed in collaboration with the Fraunhofer Society’s TRAIN team, building on existing DNS trust research and implementation capability.

Fraunhofer Society ↗Fraunhofer TRAIN ↗

Standards-aware interoperability

The architecture is intended to align with DID and credential standards, remain compatible with the wider identity landscape, and minimise unnecessary fragmentation across ecosystems.

DIF / Linux Foundation context ↗

Alpha proof-of-concept and early research work

The initiative already has an early public alpha proof-of-concept and supporting research material available, giving funders and collaborators a clearer view of the first practical research step rather than a finished product claim.

Alpha proof-of-concept on GitHub ↗

Comparative research base

The programme is supported by comparative analysis exploring public-good governance, personhood infrastructure, and the risks of capture in identity systems.

Comparative paper ↗
Why this is strategically different

Foundational infrastructure creates leverage far beyond a single application.

Rather than funding another standalone app, this work aims to produce reusable infrastructure: architecture, SDK direction, specifications, verifier logic, and integration patterns that other teams can adopt or extend. That makes the value cumulative across identity, governance, registries, and IoT.

  • Shared trust substrate for DID methods, wallets, and registries
  • Open-source artefacts designed for permanent ecosystem reuse
  • Alignment potential with standards bodies, researchers, and policy audiences
  • Designed to interoperate across ecosystems rather than depend on any single chain or vendor
Feasibility signals

Ambitious, but grounded in a phased and inspectable path.

Institutional capabilityFraunhofer brings implementation depth, research maturity, and an existing DNS trust framework context.
Open governance logicPublishing architecture and tooling openly makes the work easier to inspect, challenge, and continue.
Technical scope disciplineThis phase prioritises architecture, standards fit, and integration blueprints before broader roll-out claims.
External validationThe work has already attracted attention from serious technical and institutional participants.
Roadmap and funding rationale

A measured 12-month phase designed to leave usable public artefacts behind.

The budget is directed entirely to research and delivery work. The project lead’s role is voluntary, helping keep the funding concentrated on architecture, integration, publication, and ecosystem value rather than salary overhead.

Phase 01Architecture

Define DID method, privacy model, trust boundaries, and proof assumptions.

Phase 02Integration

Map resolver flows, trust-anchor integration, and standards touchpoints.

Phase 03Validation

Use simulation, review, and partner feedback to harden the architecture.

Phase 04Publication

Release the toolkit, manuscript, workshops, and reusable public artefacts.

Phase 01 · Work package 1

ZK-DID architecture design

Formalise the DID method structure, privacy model, lifecycle flows, trust boundaries, and cryptographic assumptions.

€22,500
Phase 02 · Work package 2

Standardisation and integration architecture

Draft specification direction, resolution models, uniqueness mapping, governance processes, and threat modelling.

€22,500
Phase 03 · Work package 3

TRAIN trust anchor integration architecture

Define how .zkdid™ can function within the TRAIN framework, including cross-registry resolution and validation flows.

€10,000
Phase 04 · Work package 4

Publication, outreach, and toolkit release

Publish the manuscript, workshop material, and open architectural toolkit for ecosystem reuse.

€10,000
Phase 05 · Closeout

Final consolidation and reporting

Consolidate outputs, close the phase transparently, and leave reusable artefacts behind.

€0
Total requested

€65,000

The budget is intentionally modest relative to the level of architectural, standards, and publication output expected from a leading research institution.

  • Funding directed to Fraunhofer for research execution
  • Project lead contributing strategic guidance voluntarily
  • Architecture-first scope reduces theatre and keeps expectations realistic
Success metrics

Success is measured by real use, reproducibility, and external validation.

Infrastructure usage.zkdid™ registrations, proof verification, reproducible deployment, and demonstration scenarios.
Cross-stack adoptionIntegrations with wallets, DID methods, naming services, and visible GitHub activity beyond the core team.
Strategic validationStandards engagement, technical publications, workshops, and documented external interest.
Governance and principles

Designed to remain open, inspectable, and difficult to capture.

.zkdid™ is framed as public infrastructure. The intended governance posture is not-for-profit, token-free at the protocol level, and structurally resistant to the kinds of incentives that so often distort identity systems once they become important.

Identity as infrastructureThe root should not be easy to switch off, de-person, or capture.
Protection by designPersonal data and biometrics should be protected architecturally, not merely promised in the interface.
Open-source permanenceCore outputs are intended to be released openly so future teams can continue the work.
Resistance to captureThe governance direction explicitly resists corporate gatekeeping and token-weighted domination.
Closing call to action

Support a €65,000 grant phase that leaves reusable public infrastructure behind.

.zkdid™ is designed to address a deeper structural problem than most identity products touch. If the internet is going to rely on personhood, trust, and device integrity at scale, the root itself must be open, privacy-preserving, standards-aware, and resistant to capture.

View alpha proof-of-concept See the case for public-good registries See the grant breakdown Contact / request info
For fundersSupport architecture that can outlast any single vendor or app.
For institutionsEngage with a standards-aware trust anchor designed for accountability.
For contributorsInspect the open work, challenge assumptions, and help harden the design.
For ecosystem partnersExplore integration into wallets, DID methods, registries, and devices.