How Zyphe Implements DIDs for Compliant Web3 Identity

Key highlights

• Blockchain identity verification became a regulator-blessed primitive in 2025 once W3C ratified the Verifiable Credentials Data Model 2.0 and the EU's eIDAS 2 wallet rollout cemented decentralised identifiers as production infrastructure.
• Zyphe supports five production DID methods: did:web for institutional issuers, did:ion for minimal trust assumptions, did:ebsi for EU integration, did:key for ephemeral cases, and the Zyphe-native did:zyphe for KYC Passport reuse.
• A Zyphe verifiable credential carries selective disclosure via ZKP-derived proofs, revocation through BitstringStatusList, and cryptographic proof integrity bound to the issuer's signing key.
• With eIDAS 2, the customer's wallet returns a Verifiable Presentation exposing only requested predicates, and Zyphe sits as a complementary issuer or verifier rather than competing with the wallet.
• DID-based KYC produces signed, cryptographically-verifiable counterparty data that flows into FATF Recommendation 16 Travel Rule networks without the receiving VASP contacting the issuer.
• The honest limits in 2026: resolver infrastructure dependencies, uneven VC 2.0 adoption, status-list privacy still being researched, and consumer wallet UX that is still maturing.

A decentralised identifier (DID) is a globally unique identifier created and controlled by the subject without reliance on a central registry, resolving to a DID Document of public keys and metadata. For KYC, the DID binds a verified identity attestation to a wallet address: the verification produces a verifiable credential issued to the customer's DID, which operators verify against the issuer's signature without contacting the issuer directly. A centralised vendor cannot revoke it, lose it in a breach, or sell it.

Hero / opening

Blockchain identity verification stopped being a buzzword in 2025 when W3C ratified the Verifiable Credentials Data Model 2.0 and the EU's eIDAS 2 wallet rollout cemented decentralised identifiers (DIDs) as a regulator-blessed primitive. Most KYC vendor blogs describe DIDs at the FATF and W3C framework level. This piece is the technical spec: which DID methods Zyphe uses, how the verifiable credentials are issued and revoked, how the architecture compares to centralised identity schemas, and what the eIDAS 2 wallet integration actually looks like in production.

What is a decentralised identifier, and why does it matter for compliance?

A decentralised identifier (DID) is a globally unique identifier created and controlled by the subject without reliance on a central registry. The DID resolves to a DID Document containing public keys, service endpoints, and other metadata the verifier needs to authenticate the subject's claims.

The compliance-relevant property: the subject controls the identifier. A centralised vendor cannot revoke it, lose it in a breach, or sell it. The verifier resolves the DID through a verifiable mechanism (a blockchain, a DNS-based registry, a peer-to-peer network) and validates credentials issued against it.

For KYC specifically, DIDs become the binding between a verified identity attestation and a wallet address. The customer's KYC verification produces a verifiable credential issued to their DID; that credential is presented to operators who verify the issuer's signature without contacting the issuer directly.

The reusable side of this binding is what we call the KYC Passport.

For the broader Web3 architecture context, see Decentralized KYC and Decentralized PII Storage.

Which DID methods does Zyphe support in production?

DID methods are the technical mechanisms by which a DID resolves to its DID Document. The W3C registry includes over 100 methods; only a subset are production-ready for compliance use.

The methods Zyphe supports as of April 2026 (bracketed for confirmation against current engineering-team specs):

1. [did:web] for institutional issuers. The DID resolves via HTTPS to a well-known endpoint on the issuer's domain. Best for regulated CASPs that want their issuer identity tied to their corporate domain.
2. [did:ion] Microsoft-pioneered, Bitcoin-anchored DID method with strong decentralisation properties. Used where the operator wants minimal trust assumptions on issuer-side infrastructure.
3. [did:ebsi] for EU institutional integration. The European Blockchain Services Infrastructure (EBSI) operates a permissioned ledger for cross-border government services, including identity. eIDAS 2 wallet integration flows through EBSI for many EU member-state implementations.
4. [did:key] for ephemeral and lightweight cases. The DID is the public key itself; no resolution infrastructure required. Used in selective-disclosure flows where the credential lifetime is short.
5. [did:zyphe] Zyphe-native method for the network's internal DID registry, optimised for KYC Passport reuse across operators.

This is the same primitive behind our DeFi KYC architecture.

The architectural choice that matters for the operator: which method does the verifying party need to resolve? A DeFi protocol on Ethereum will likely verify did:ion or did:zyphe via the protocol's native verifier contract. A regulated EU CASP will likely accept eIDAS 2 wallet credentials anchored to did:ebsi.

For the regulatory context, see our eIDAS 2 EU Digital Identity Wallet KYC compliance guide.

What does a Zyphe verifiable credential look like in practice?

A verifiable credential under the W3C VC Data Model 2.0 is a structured object containing claims about the subject (the customer), an issuer (Zyphe), a proof signature, and metadata.

A simplified example of a Zyphe-issued KYC credential:

Three operationally important properties:

• Selective disclosure. The operator typically doesn't need the entire credential. ZKP-derived proofs (see our ZKP in production KYC breakdown) let the operator verify specific predicates ("kycLevel >= 3", "jurisdiction == GB") without seeing the underlying credential.
• Status checking via BitstringStatusList. Revocation is checked against a status list rather than a per-credential database lookup, preserving privacy while enabling near-real-time revocation.
• Cryptographic proof integrity. The proof is cryptographically bound to the issuer's signing key. A revoked or expired credential fails verification deterministically.

For the architectural detail, see Decentralized KYC and the KYC Passport.

How does Zyphe's DID architecture compare to centralised identity schemas?

The contrast that defines the procurement decision in 2026.

The architectural argument: the centralised schema was designed for a world where the vendor was the trust anchor. The DID-based architecture is designed for a world where the user is the credential holder and the verifier is independent.

The same shift is the core argument in our look at decentralised KYC and how it works.

For the breach context that drove the architectural shift, see is KYC safe in 2026? and the identity breach epidemic 2026 analysis.

We also examine the vendor exposure in why your KYC vendor is your biggest data breach risk.

How does eIDAS 2 wallet integration actually work?

The EU Digital Identity Regulation (eIDAS 2), in force since 2024 with national wallet rollouts running through 2026, mandates EU member states to issue digital identity wallets to citizens. The wallet stores verifiable credentials, manages DIDs, and provides selective-disclosure flows to relying parties.

We break down the wallet's wider impact in our eIDAS 2.0 KYC guide.

For a regulated EU CASP integrating with Zyphe and the eIDAS 2 wallet, the flow looks like this:

1. Customer initiates onboarding on the CASP's app or website.
2. CASP requests verifiable credentials from the customer's eIDAS 2 wallet. Specific predicates: identity attributes (name, DOB, jurisdiction), KYC level, sanctions clearance.
3. Customer's wallet returns a Verifiable Presentation containing the requested predicates. Selective disclosure ensures only the requested attributes are exposed; the underlying eID document is not.
4. CASP's backend verifies the presentation. The DID is resolved, the issuer signature is checked, the credential status is queried.
5. CASP records the audit trail for MiCA Article 70 compliance. The threshold-encrypted log captures the verification event without exposing the customer's underlying identity.

The Zyphe layer in this flow operates as either an issuer of complementary credentials (sanctions, PEP, adverse media) that the wallet doesn't natively carry, or as the verifier infrastructure for non-EU credential types. The architecture is composable with the wallet rather than competitive with it.

For the broader regulatory context, see our crypto KYC compliance breakdown and VASP KYC compliance: MiCA & FATF guide 2026.

How do DIDs and verifiable credentials integrate with FATF Recommendation 16?

FATF Recommendation 16 (revised June 2025) requires VASPs to share originator and beneficiary identifying information on cross-VASP transfers above the threshold. The Travel Rule data exchange is downstream of KYC; the data quality of the originator payload is only as good as the upstream identity verification.

For the legal-sector detail on AML obligations, see our AML transaction monitoring overview.

DID-based KYC produces structured, cryptographically-verifiable counterparty data that flows naturally into Travel Rule networks. Three operational consequences:

For the supervisory expectations behind this exchange, see our FATF Travel Rule compliance guide for VASPs.

1. The originator's identity attributes (name, jurisdiction, sanctions status) are signed by the issuer and verifiable by the receiving VASP without contacting the issuer.
2. Status updates (revocation, jurisdiction change) propagate via the credential status list rather than per-recipient notifications.
3. Audit logs at both ends are cryptographically linked, enabling regulator inspection without exposing underlying customer documents.

For VASP-specific integration, see VASP KYC compliance: MiCA & FATF guide 2026.

What are the practical limits of DID-based identity in 2026?

Four constraints worth flagging for an honest evaluation.

1. Resolver infrastructure dependencies. Different DID methods rely on different resolution mechanisms. did:web depends on the issuer's HTTPS infrastructure; did:ion depends on Bitcoin and IPFS; did:ebsi depends on EBSI's permissioned ledger. Each carries operational risk that the operator's compliance team should map.
2. W3C VC Data Model 2.0 adoption is uneven. Some implementations still use VC 1.1 syntax. Compatibility shims are often required for cross-vendor verification.
3. Status list privacy is a research-active area. BitstringStatusList provides better privacy than per-credential revocation databases but is not perfect. Specific implementations have known correlation properties that motivated researchers can exploit.
4. Wallet UX in 2026 is still evolving. Most consumer wallets handle the DID and credential management opaquely; sophisticated users notice the rough edges. UX maturity will close further over the next 12 to 24 months.

For the operator-side detail, see the challenges facing KYC in a Web3 world.

How should an operator evaluate a DID-based KYC vendor?

Six questions for procurement:

Pair this with our checklist on how to evaluate crypto compliance vendors.

1. Which DID methods do you support, and which are production-grade? Vendors who answer "did:web only" are running a marketing layer.
2. Is the verifiable credential schema W3C VC Data Model 2.0 compliant? Backwards compatibility with VC 1.1 is acceptable; non-compliance is a red flag.
3. What's the credential revocation mechanism, and what are its privacy properties? BitstringStatusList is current best practice.
4. What's your eIDAS 2 wallet integration status? Vendors who can't accept verifiable presentations from EU citizen wallets are missing the largest near-term integration opportunity.
5. Is the audit trail AMLA-defensible per case? Per-credential identifier, policy version, threshold-encrypted regulator access.
6. How does revocation propagate across the network? Sub-second status updates are feasible; vendors quoting hours-to-days for revocation propagation are running architecturally weaker implementations.

For the broader vendor-evaluation framework, see our top compliance tools evaluation guide.

What does blockchain identity verification mean for your procurement decision?

Blockchain identity verification with DIDs and verifiable credentials moved from research to production in 2025. The W3C VC Data Model 2.0 ratification and the eIDAS 2 wallet rollout established the regulator-blessed primitives. The procurement question is no longer whether DIDs are real; it's whether the vendor's architecture treats them as a marketing layer over centralised storage or as the structural primitive the architecture is built around.

If the technical conversation belongs in your roadmap, book a 30-minute walkthrough and we'll show the production DID resolver plus the verifiable credential schema your engineering team will read first.

Related resources

1. ZKP technical, How Zyphe uses zero-knowledge proofs in production KYC
2. eIDAS 2 context, EU Digital Identity Wallet KYC compliance guide
3. Architecture, Decentralized KYC