How Zyphe Implements DIDs for Compliant Web3 Identity

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.

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.

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.

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

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.

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.

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

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:

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.

The bottom line

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