DID Washing

The tech industry has perfected the art of borrowed credibility.

Put "W3C Compliant" on your product, and developers relax. Flash "ISO Certified" on your homepage, and procurement departments check a box. These signals work because standards represent collective verification—hundreds of engineers debating, testing, and agreeing that something works as claimed.

But here's the problem: the signals are easy to fake.

In January 2026, a press release appeared across major crypto publications. A Web3 project—which we'll call [REDACTED]—claimed to offer "an encrypted DID (Decentralized Identifier) system" providing "unconditional basic income" to users worldwide. The language was perfect. The terminology was current. The implications were extraordinary.

If true, [REDACTED] had solved two of the hardest problems in digital identity: self-sovereign verification and sustainable wealth distribution.

If false, they'd simply dressed a centralized KYC system in W3C vocabulary and called it innovation.

This case study applies Entity Veracity principles to find out which.

The DID Binary Test

Before we examine the claims, we need to establish a fundamental principle:

You're either doing DID or you're not.

A W3C Decentralized Identifier has a specific syntax: did:method:method-specific-identifier

Either your system produces identifiers in this format that resolve to DID Documents via a documented method specification—or it doesn't. There's no "kind of DID" or "DID-like" or "our version of DID."

The one-question filter: Can the platform revoke your identifier?

• If yes → It's not a DID. It's a credential they issued.
• If no → It might be a DID. Check the method specification.

DIDs are self-sovereign by definition. Either the user controls the keys and hosts/anchors the DID Document, or it's not a DID. There is no middle ground.

This binary test will govern our entire analysis.

The Claim

[REDACTED] makes three core assertions in their public communications:

Claim 1: DID Implementation

"[REDACTED] has developed an encrypted DID (Decentralized Identifier) system that ensures user privacy while enabling seamless interaction within the ecosystem."

Claim 2: Self-Sovereign Identity

"Users maintain control over their digital identities through the [REDACTED] Protocol."

Claim 3: Unconditional Basic Income

"Through its UBI mechanism, [REDACTED] distributes value to all verified users, creating a sustainable economic model."

Let's apply the Pure Claim test from Chapter 4. Can these assertions be expressed as verifiable Triples?

Marketing Language	Attempted Triple	Verifiable?
"encrypted DID system"	[REDACTED] — [implements] — [W3C DID Core 1.0]	?
"user control"	[User] — [controls] — [Private Key]	?
"UBI mechanism"	[System] — [distributes] — [Convertible Value]	?

The question marks are the investigation.

The Verification

Test 1: Does a DID Method Exist?

The W3C DID specification requires every compliant implementation to publish a DID Method Specification—a document defining how identifiers are created, resolved, updated, and deactivated. As of July 2022, when DID Core 1.0 became a W3C Recommendation, over 180 methods had registered in the W3C DID Spec Registries.

Search conducted:

• W3C DID Method Registry (w3c.github.io/did-spec-registries/)
• Academic databases for method specification
• GitHub repositories for DID implementation code
• Project whitepaper and technical documentation

Result: No registration found for any DID method associated with this project. No DID method specification document exists. The GitHub repository contains basic smart contracts for staking and tokens, and zero DID implementation code.

Test 2: Who Controls the Keys?

True self-sovereign identity, as defined by the W3C DID specification, means "individuals and organizations can generate their own identifiers using systems they trust." The user creates the cryptographic key pair. The user hosts or anchors the DID Document. No permission is required.

[REDACTED]'s actual process:

1. User downloads the project's app
2. User submits government identification for KYC verification
3. The platform verifies identity and issues a credential
4. User receives access controlled by the platform's systems

This is traditional Know Your Customer compliance—the same process your bank uses. The user doesn't generate keys. The user doesn't host a DID Document. The user receives a credential from a centralized authority.

Apply the Binary Test: Can the platform revoke the user's identifier? Yes—if the platform decides the user violated terms of service, the credential disappears. Therefore, by definition, this is not a DID.

Test 3: Is the UBI Convertible Value?

The Basic Income Earth Network (BIEN) defines Universal Basic Income as "a periodic cash payment unconditionally delivered to all on an individual basis, without means-test or work requirement." The key word is cash—value that can purchase goods and services.

[REDACTED]'s mechanism:

• Verified users receive tokens permanently staked at high APY
• Additional earnings through daily check-ins
• The token is not listed on any major cryptocurrency exchange
• "Cashouts" occur only through peer-to-peer marketplace within the ecosystem

Critical finding: The token has no established market value. It cannot be converted to food, housing, or any basic need. Legitimate UBI programs like GiveDirectly's Kenya experiment distribute real currency. [REDACTED] distributes database entries with speculative future value.

The Corporate Reality

Before declaring this a scam, we must acknowledge what is verifiable:

Legitimate Corporate Registrations:

• Registered entities exist in crypto-friendly jurisdictions (Switzerland, Singapore)
• Corporate filings are publicly accessible

Verifiable Founder Background:

• Named executives have documented careers in financial services
• Professional history appears in multiple databases

Real Community Activity:

• Major conference sponsorships (independently verified)
• Mobile app with significant download numbers and user reviews

Something is being built. The question is whether what's being built matches what's being claimed.

The Red Flags

Shadow Leadership:
Official corporate registries list board members who appear in zero public communications. Different individuals handle all marketing. Why are the registered leaders invisible in a "transparency-focused" identity project?

Unsustainable Yields:
Marketing materials claim yields exceeding 100% APY. No legitimate investment mechanism generates such returns without external revenue or continuous new participant capital.

Multi-Level Referral Structure:
Token bonuses for referrals, ambassador programs, community node rewards. The system incentivizes recruitment over genuine economic activity.

No External Funding Disclosed:
Industry databases note no venture capital or institutional backing. Yet major conference sponsorships require significant capital. Where does the funding come from?

The Verdict

This project occupies an ambiguous space between legitimate startup and sophisticated marketing operation.

What it is: A centralized KYC identity system distributing proprietary tokens with no established market value.

What it claims to be: A W3C-compliant DID implementation providing unconditional basic income.

The gap between these two descriptions is the definition of DID-washing.

The project uses technical vocabulary—"Decentralized Identifier," "self-sovereign," "UBI"—to associate with legitimate movements while delivering something fundamentally different. This isn't necessarily fraud. It may be aggressive marketing, technical misunderstanding, or aspirational roadmap presented as current reality.

But for Entity Veracity purposes, the claims fail verification:

Claim	Pure Claim Test	Result
W3C DID implementation	No registered method, no specification, no resolver	FAIL
Self-sovereign identity	Centralized KYC, platform-controlled credentials	FAIL
Unconditional Basic Income	Non-convertible tokens, closed ecosystem	FAIL

The Distinction That Matters

This case study illuminates a critical distinction for anyone building or evaluating identity systems:

What you CAN legitimately offer:

• Teaching clients to set up their own did:web
• Attesting to identity via your own verified authority
• Creating registries that link attestations to client DIDs
• Providing checksum verification for artifacts

What you CANNOT offer without violating the definition:

• "We'll give you a DID"
• "Our platform provides your decentralized identity"
• "Sign up and receive your DID"

The moment someone else controls the keys, it's not a DID—it's a credential they issued. You can attest to someone's identity. You cannot give them a decentralized identifier.

Attestation: "I verify that John Smith produced this document" → Your signature, your authority

DID: "I am John Smith" → John's keys, John's domain, John's control

[REDACTED] conflates these. They're doing attestation (KYC verification) and calling it DID (self-sovereign identity). The vocabulary is borrowed. The implementation is absent.

Lessons for Entity Veracity

This case study demonstrates several principles from the book:

1. The DID Binary Test

You're either doing DID or you're not. The test is simple: Can the platform revoke your identifier? If yes, it's not a DID. If you can't find a registered method specification that another organization could independently implement, the claim is unverifiable.

2. Terminology Is Not Implementation

Anyone can write "DID" in a press release. The verification question is: Does a DID method specification exist that another organization could independently implement?

The W3C DID Method Registry is the deed registry for identity protocols. If your method isn't registered—or at least documented to the specification's requirements—the claim is Semantic Fluff.

3. The Receipt vs. The Story

[REDACTED] tells an excellent story: democratized identity, passive income, Web3 innovation. But the receipts—the verifiable triples—tell a different story: centralized KYC, speculative tokens, multi-level recruitment.

Apply Chapter 4's distillation: strip the adjectives, remove the modal verbs, eliminate the fluff. What remains? "User submits government ID to company. Company issues credential. Company distributes tokens company created."

That's not self-sovereign identity. That's a platform account with extra steps.

4. Founder Machine IDs Are Necessary But Not Sufficient

Founders may have verifiable credentials in the Knowledge Graph. Professional history may appear in multiple databases. This gives them legitimate Entity Veracity for their career—but it doesn't validate their project's technical claims.

A legitimate founder can build something that doesn't match its marketing. Transitive Authority (Chapter 4) transfers trust from person to project only when the person's expertise matches the project's domain.

5. The Standards Hierarchy Matters

Level	Example	Survivability
W3C/ISO Standard	DID Core 1.0	Survives institutions
Consortium Protocol	Hyperledger Indy	Survives companies
Enterprise System	Microsoft Entra	Survives products
Startup Protocol	[REDACTED]	Dies with funding

When you build on W3C DID, you're filing a deed in a public registry that will exist whether any single company survives. When you build on a startup's proprietary system, you're renting a room in their building.

Users of [REDACTED] have no deed. They have a lease—and the landlord controls the terms.

How to Verify DID Claims

For readers evaluating any project claiming DID compliance:

Step 1: Apply the Binary Test
Can the platform revoke your identifier? If yes, stop here—it's not a DID regardless of what they call it.

Step 2: Check the W3C DID Method Registry
Go to w3c.github.io/did-spec-registries/. Search for the project's method name. If it's not there, that's a yellow flag (not fatal—new methods take time to register).

Step 3: Find the Method Specification
Every compliant DID method must publish a specification document defining CREATE, READ, UPDATE, and DEACTIVATE operations. If no specification exists, the claim is unverifiable.

Step 4: Test Resolution
Use the Universal Resolver (dev.uniresolver.io). Enter the claimed DID format. If it doesn't resolve, the infrastructure doesn't exist.

Step 5: Examine Key Control
Ask: Who generates the cryptographic keys? If the user generates keys locally and hosts/anchors their own DID Document, it's self-sovereign. If the platform generates credentials after KYC, it's centralized identity with decentralized vocabulary.

Step 6: Apply the Pure Claim Test
Express each claim as a Triple. Search for the receipt that proves it. If you can only find the story, not the receipt, the claim is Semantic Fluff.