The Problem With Identity Today

Every time you prove who you are on the internet, you leak more than you need to. Want to prove you're over 18? You hand over your ID — which also reveals your full name, address, and exact birthdate. Want to prove you hold a certain credential? You expose the issuing institution, the issuance date, and often your wallet address. Want to verify you're a real person, not a bot? You solve a CAPTCHA served by Google, which logs your IP, your device fingerprint, and the time you accessed the page.

This isn't a bug in any specific product. It's the architecture. Traditional identity systems were never designed to prove attributes without revealing identities. You prove who you are by showing the whole document. Privacy is an afterthought, bolted on with consent checkboxes and privacy policies that nobody reads.

Two technologies have independently emerged to fix this at the protocol level: Zero-Knowledge Proofs (ZKPs) and Handshake (HNS). Most people in Web3 know one or the other. Very few have seen what happens when you combine both — and that combination is the privacy identity stack Web3 has been building toward without realizing it.

Part 1: What Zero-Knowledge Proofs Actually Do

A Zero-Knowledge Proof is a cryptographic method that lets one party (the prover) convince another party (the verifier) that a statement is true — without revealing why it's true or any information beyond the truth of the statement itself.

The classic non-technical example: imagine you want to prove to someone that you know the password to a locked room, without actually saying the password. A ZK system lets you walk through the door in front of them, proving you know it — without the password ever changing hands.

In practical cryptography, this translates to statements like:

  • "I am over 18" — without revealing my birthdate or name
  • "I hold a valid driver's license issued in Turkey" — without revealing the license number
  • "My wallet balance exceeds 1,000 USDC" — without revealing my wallet address or exact balance
  • "I have passed KYC with an approved provider" — without revealing which provider or when

The verifier learns exactly one bit of information: the statement is true. Nothing else leaks.

The Two Main ZK Systems You'll Encounter

zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge): compact, fast to verify, widely used in production systems like Zcash, Groth16 circuits, and many ZK-Rollups. The tradeoff: they require a trusted setup ceremony, which introduces a theoretical weakness if the ceremony is compromised.

zk-STARKs (Zero-Knowledge Scalable Transparent Arguments of Knowledge): no trusted setup required, and transparent — anyone can verify the proof generation process. Larger proof sizes than SNARKs, but considered more future-proof and quantum-resistant. Used by StarkWare and increasingly in privacy-critical infrastructure.

For identity applications, both are relevant. What matters for our purposes is the shared property: you can prove a fact without revealing the underlying data.

Part 2: Why Handshake Is the Right Identity Root

ZK Proofs solve the proof problem: how to verify an attribute without leaking data. But they don't solve the identity root problem: who issues the credential in the first place, and can that issuer be trusted to remain neutral and censorship-resistant?

Consider the standard Web2 approach to digital credentials. A government, bank, or tech company issues you an identity document. The credential lives in their database. If they revoke it, it's gone. If they're pressured by another government to suspend your access, it's suspended. If the company shuts down, your credential becomes worthless. The issuer is always a central point of failure — and a central point of control.

This is exactly the problem Handshake was built to solve, not for identity specifically, but for DNS — and it turns out DNS and identity have the same architecture problem.

How HNS Creates a Censorship-Resistant Identity Root

When you win a TLD auction on Handshake, you receive cryptographic ownership of that namespace — recorded on a proof-of-work blockchain that no single entity controls. Nobody can revoke your TLD through a policy decision. Nobody can seize it through a court order served on a registrar, because there is no registrar. The only way to alter HNS name records is to control a majority of the network's mining hashrate — the same bar that makes Bitcoin transactions irreversible in practice.

This means a Handshake TLD can serve as a sovereign identity root: a namespace where credentials are issued, recorded, and verified without any central party having the ability to revoke or censor them.

Under your TLD, you control:

  • What credentials are issued (the schema)
  • Who can issue them (subdomain delegation)
  • What cryptographic keys are associated with each identity (TLSA records, DNSSEC)
  • The rules for revocation — which can be made transparent and immutable on-chain

Combined with ZK Proofs, this becomes something genuinely new: an identity system where credentials are issued from a censorship-resistant root, and proofs derived from those credentials reveal nothing except the minimum required to satisfy a query.

Part 3: How the Stack Works Together

Let's walk through a concrete example. Imagine a user wants to access a DeFi protocol that requires proof of KYC without exposing their wallet address or personal data to the protocol itself.

Step 1: Identity Issuance (HNS Layer)

A KYC provider — a licensed identity verification service — operates under a Handshake TLD. Call it identity.verifier/. When a user completes KYC, the provider issues a Verifiable Credential anchored to that TLD's DNSSEC chain. The credential is tied to the user's cryptographic key — not their name or wallet address — and is stored in the user's own wallet or identity manager.

The trust chain looks like this:

HNS Blockchain (Proof of Work)
    ↓
Urkel Tree Root (TLD record)
    ↓
DNSSEC Chain → identity.verifier/ trust anchor
    ↓
Verifiable Credential signed by verifier's key
    ↓
User's cryptographic key (wallet or DID)

No central database. No revocable entry in a company's server. The credential is cryptographically tied to a root that lives on an uncensorable blockchain.

Step 2: Proof Generation (ZK Layer)

When the user wants to access the DeFi protocol, they don't submit the credential. They generate a ZK Proof that proves:

  • "I hold a valid credential from identity.verifier/"
  • "That credential satisfies the KYC requirement of this protocol"
  • "The credential has not been revoked"

The proof reveals none of the following: the user's name, their wallet address, the exact credential content, when KYC was performed, or which specific identity was verified. It's a single bit: valid.

Step 3: Verification (On-Chain)

The smart contract or verifier checks the ZK Proof against the trust anchor published in the HNS TLD's DNSSEC chain. Because the trust anchor is on-chain and publicly verifiable, the verifier can check it without trusting the user, the issuer, or any third party. The verification is fully self-contained.

User → ZK Proof → Smart Contract
               ↓
       Checks against HNS trust anchor
               ↓
       ✅ Valid KYC — access granted
       (Zero personal data leaked)

Part 4: Why This Combination Is Uniquely Powerful

ZK Proofs alone don't solve the trust root problem. You can have a perfect privacy-preserving proof, but if the credential it's derived from was issued by a company that can be pressured, hacked, or shut down, the privacy guarantee is hollow. The issuer is still a single point of failure.

Handshake alone doesn't solve the privacy problem. You can have a perfectly censorship-resistant namespace, but if credentials issued under it reveal your wallet address, your identity, or your transaction history when presented to a verifier, the decentralization doesn't help your privacy.

Together, they close both gaps:

  • HNS provides a trust root that can't be seized, revoked, or manipulated by any central authority.
  • ZK Proofs ensure that credentials derived from that root prove only what needs to be proven, leaking nothing else.

The result is identity infrastructure that is simultaneously verifiable, private, and censorship-resistant — three properties that have never co-existed in a single identity stack before at the protocol level.

Part 5: Real Applications Right Now

1. Compliant DeFi Without KYC Databases

A DeFi protocol can require KYC compliance — satisfying regulators — without building or storing a KYC database. Users prove compliance via ZK + HNS-anchored credentials. The protocol never sees personal data. Regulators can audit the issuer (the KYC provider), not the protocol.

2. Age Verification Without ID Scanning

A platform requiring age verification can accept a ZK proof that a user holds a valid age credential from an HNS-anchored issuer. The platform learns "over 18" and nothing else. The user's real age, name, and government ID never touch the platform's servers.

3. Proof of Humanity for AI Agent Networks

As AI agents proliferate — a trend dominating Web3 discussion in 2026 — distinguishing human users from bots becomes critical. A ZK proof tied to an HNS-issued humanity credential lets a user prove "I am a verified human" across any protocol, without creating a centralized registry of humans that can be hacked or censored.

4. Cross-Protocol Reputation Without Doxxing

A user can prove "I have a credit score above X on Protocol A" to Protocol B, without revealing their identity, wallet address, or any specific transaction history. Reputation becomes portable and private — a property the current internet makes nearly impossible.

The Missing Primitive — And Why HNS Gets There First

The current Web3 identity landscape has fragments of this stack but not the whole thing. ENS provides human-readable names but relies on Ethereum's governance and doesn't offer censorship-resistant root ownership in the same structural sense. W3C DIDs (Decentralized Identifiers) provide a credential standard but don't specify a trust root — they defer to whichever blockchain or registry the implementer chooses. Most ZK identity projects (Polygon ID, zk.me, Worldcoin) build their own trust roots — often a company or a DAO — rather than anchoring to an uncensorable naming layer.

Handshake is the missing piece: an uncensorable, proof-of-work-secured naming layer that can serve as the trust root for credentials that ZK Proofs can then make privacy-preserving. Nobody has fully assembled this stack yet. That's both a gap and an opportunity.

What This Means for Builders

If you're building identity infrastructure on Web3, the ZK + HNS stack gives you properties no other combination offers today:

  • Your credential issuing root can't be taken down by any government or company
  • Your users' privacy is protected at the cryptographic level, not the policy level
  • Your verifiers can check credentials without trusting you as the operator
  • Your system works even if your company ceases to exist — the trust root is on-chain

The tooling is maturing rapidly. ZK proof libraries (circom, Halo2, SP1) are production-ready. HNS node software (hsd) and resolvers are stable. Verifiable Credential standards (W3C VC Data Model) are widely adopted. The assembly work — connecting these pieces into a coherent identity stack — is the frontier.

FAQ

Do ZK Proofs require a blockchain to work?

No — ZK Proofs are a cryptographic primitive that can operate off-chain. However, for decentralized identity applications, anchoring the trust root and revocation status on-chain (via HNS or another blockchain) is what makes the system trustless. Without an on-chain anchor, you still depend on a central server to confirm the credential is valid.

Can a Handshake TLD be used as a W3C DID Method?

Yes. W3C DID Methods define how a DID Document is created, resolved, and updated on a specific system. A Handshake TLD can serve as the basis for a DID Method where the DID Document is resolved via the HNS blockchain, using the Urkel Tree proof structure for trustless, offline verification. This would give HNS-based DIDs the strongest censorship-resistance of any DID Method currently in use.

What happens if the ZK proof system has a bug?

ZK proof systems can have implementation bugs — this is one of the reasons audits of ZK circuits are critical and why proven systems like Groth16 and PLONK are preferred over custom implementations for production identity. A bug in the proof system would be separate from the HNS trust root — the TLD ownership and DNSSEC chain would remain valid. The security of the stack is modular: a flaw in the ZK layer doesn't compromise the HNS layer, and vice versa.

Is this quantum-safe?

Partially. Handshake uses Blake2b + SHA3 for its proof-of-work, which is considered quantum-resistant. However, the ECDSA keys commonly used for credential signing are not quantum-safe. A fully quantum-resistant implementation would pair HNS with post-quantum signature schemes (like CRYSTALS-Dilithium or SPHINCS+) for the credential layer. zk-STARKs, unlike zk-SNARKs, are also considered quantum-resistant. A complete post-quantum ZK + HNS stack is technically feasible today with existing primitives.

How does this differ from Worldcoin or Polygon ID?

Worldcoin (World ID) uses biometric scanning (iris scans) to establish proof of humanity, with trust rooted in a company-controlled system. Polygon ID uses ZK proofs for credential privacy but roots trust in Polygon's blockchain and its governance. Both are ZK-based but neither uses an uncensorable, proof-of-work-secured naming layer as the trust root. HNS provides a trust root that doesn't depend on any company's continued existence or any DAO's governance decisions.

Architecture and original research by NIHON — Handshake Infrastructure & Web3 Identity, June 2026. To resolve Handshake domains natively, download the SkyInclude Browser. For more on building with HNS, explore LearnHNS.