DEV Community: Solidus Network

BBS+ for the compliance officer

Solidus Network — Sun, 28 Jun 2026 20:56:03 +0000

The compliance officer's question on BBS+ selective disclosure: does this satisfy our regulatory data minimization requirements better than our current policy-and-process approach?

The short answer: yes, with concrete consequences.

GDPR Article 5(1)(c) requires data to be "adequate, relevant and limited to what is necessary." Most enterprises satisfy this via policy: documented purposes, access controls, retention schedules, audit logs. The policy approach is auditable but inherently leaky — humans make policy mistakes, audits catch some, the regulator catches the rest.

BBS+ selective disclosure satisfies Article 5(1)(c) at the cryptographic layer. The user's wallet generates a proof that contains only the claims the relying party requested; nothing else is transmitted. There is no policy mistake to make; the cryptography enforces minimization.

For the compliance officer, three operational changes follow.

Change 1: Audit defensibility. When the regulator asks "how do you ensure data minimization on credential presentations," the answer becomes architectural rather than procedural. The auditor can verify the cryptographic constraint; no further investigation is needed.

Change 2: Breach impact reduction. When an enterprise system is compromised and credentials are exposed, only the previously-disclosed claims are at risk — not the underlying credential data. The "we lost 10M records of full PII" event becomes "we lost 10M tokens that prove the user is over 18, signed by an issuer key." Materially different consequences.

Change 3: Cross-border data flow simplification. The Schrems II problem for EU-US data flows is partly about the volume of personal data crossing the border. With selective disclosure, the EU user's actual identity data never crosses; only the proof. Many compliance teams that have wrestled with Schrems II find the cryptographic minimization is the cleanest answer.

The procurement-side question: which credential format gives us BBS+ today? Solidus ships it. Multiple other SDKs ship it. Don't accept a vendor proposal that promises BBS+ "in the roadmap" — the audit defensibility comes from production-deployed cryptography, not future promises.

For specific use cases — high-volume KYC, GDPR-sensitive cross-border flows, regulated transaction-tier verifications — BBS+ is the right primitive. For lighter use cases, SD-JWT VC (claim-level disclosure without predicate proofs) is often sufficient and easier to deploy. The compliance officer should know the difference and ask vendors which they ship.

The migration economics: deploying BBS+ into an existing OID4VP verifier stack typically takes 1-2 engineering sprints. The compliance benefit is immediate; the regulatory defensibility upgrade is significant.

solidus.network

The chain shouldn't store your data: anchoring proofs, not data

Solidus Network — Thu, 25 Jun 2026 22:56:38 +0000

In 2015, Tim Berners-Lee — the inventor of the World Wide Web — was asked about blockchain-based identity and gave a direct answer:

The chain is too slow. The chain is too expensive. The chain is too public.

He was right.

A decade later, the identity-on-blockchain conversation has matured. Most credible identity projects no longer propose storing personal data on chain. The cryptography has gotten more refined; the architectural discipline has improved; the lessons of "let's just put everything on chain" have been absorbed.

But the architecture that emerged is not uniformly applied. There are still identity systems out there with too much information on-chain — credential subjects, attribute values, even biometric hashes that practically enable correlation. Each of these is a legacy of the early "store everything on chain" era that the field has been slowly leaving behind.

Solidus's architecture, by contrast, anchors proofs, not data. Here is what that means in practice, and how we reconcile with the Berners-Lee critique.

What goes on chain

Three things, and only three things:

Issuer public keys — the cryptographic identities of organizations that can issue credentials. A bank, a government, a KYC vendor. These keys are public by design. Without them, the credentials they issue cannot be verified.

Revocation references — pointers (typically status list URLs or revocation tree roots) that let a relying party check whether a previously issued credential has been revoked. The references are non-identifying; they do not reveal who holds the credential, only that the revocation state has changed.

DID Document roots — the cryptographic commitments to the DID Document of each did:solidus identifier. The DID Document itself contains keys and service endpoints; it does not contain personal data.

That is the entire on-chain footprint per user-identity event. No name. No date of birth. No address. No biometric. No document number. No image. No private key. Just the cryptographic anchors that the rest of the system needs to verify against.

Where the personal data lives

In a personal data pod that the user controls.

The pod concept comes from Berners-Lee's Solid project at MIT, started in 2015. The idea is that every person has a "pod" — a personal data store, possibly self-hosted or possibly hosted by a chosen provider — that contains their personal data. Applications request access to specific data; the user grants or denies on a per-attribute basis. The data never centralizes.

Solidus is Solid-compatible, in the sense that our wallet can read and write to Solid pods, our credential format is interoperable with Solid resource shapes, and our access control respects Solid permissions. We are honest about the current state: full Solid Protocol conformance is on the roadmap; "Solid-compatible, migration-ready" is the accurate description today.

For users who do not want to run their own pod, we provide a hosted pod option as a convenience. The hosted option is end-to-end encrypted; we cannot read the contents. The threat model is that we (the hosting party) could subpoenaed for the encrypted blobs but not for the plaintext, which is materially different from the centralized "we hold everything, including the keys" model.

For users who do want to run their own pod — self-hosted, or chosen-provider-hosted — the wallet handles the data lifecycle the same way. The chain does not care where the pod is.

How verification works when data is off-chain

This is the part that worries people who are new to decentralized identity. If the credential lives in a pod, and only proofs go on chain, how can a relying party verify anything?

The answer is in the standards. A Verifiable Credential is a JSON-LD document signed by the issuer's private key. Anyone with the issuer's public key (which is on chain) can verify the signature. The credential itself does not need to be on chain; only the public key of the entity that signed it needs to be reachable.

When a user presents a credential to a relying party, the wallet provides the credential plus a presentation proof. The relying party fetches the issuer's public key from the chain, verifies the credential signature, verifies the presentation proof, and checks the revocation status against the on-chain revocation reference. The relying party never sees the personal data unless the user chose to disclose it.

For selective disclosure — where the user shares only "over 18" but not the actual birthdate — BBS+ signatures provide a derived proof that the credential satisfies the predicate, without revealing the underlying value. The chain stores the issuer's public key; the proof is computed in the wallet; the relying party verifies the proof. The birthdate never leaves the user's pod.

This is a clean separation of concerns. Personal data lives where the user controls it. Cryptographic anchors live where they can be verified. The chain provides the trust root; the wallet provides the privacy.

Why this matters

It matters because the alternative — storing personal data on chain in any form — does not survive contact with regulation, with breach disclosure, with right-to-be-forgotten requests, or with the basic principle that the user should be able to leave a system without their data being held hostage.

It also matters because Tim Berners-Lee was right.

The chain is too slow for personal data — a single credential might be 5 kilobytes; multiplying that by millions of users is unworkable. The chain is too expensive for personal data — anchoring 5 KB costs orders of magnitude more than anchoring a 32-byte hash. The chain is too public for personal data — even encrypted, the metadata leaks.

By anchoring proofs and not data, we sidestep all three problems. The chain stays lean, anchoring the trust roots that the rest of the system needs. The data stays personal, controlled by the user, in a pod they own.

This is the architecture Berners-Lee was pointing toward, in his 2015 critique. It just took the rest of the field a decade to catch up.

solidus.network

did:solidus and the lineage of identity standards

Solidus Network — Thu, 25 Jun 2026 10:55:58 +0000

A DID method is a small specification document, technically. But the act of submitting a DID method to the W3C registry, of having it reviewed by the community of identity standards practitioners, of having it accepted into the public list — this is more than a technical act. It is a form of community-anchored consecration.

The lineage matters. The x.500 directory standards of the 1980s established that identity could be represented as structured data with a registry. The LDAP refinements of the 1990s made the architecture deployable at internet scale. OAuth and OpenID Connect in the 2000s established federation as the dominant pattern for cross-platform authentication. The W3C DID Core specification of the 2020s represents the next step: a registry of methods rather than a registry of identifiers, allowing the architecture to support many different anchoring strategies.

Each step in this lineage required two things. A technical innovation that addressed a previously-unsolved problem. And community acceptance through the standards bodies — the rounds of review, the implementation experience, the working group consensus that a contribution belongs in the lineage.

The W3C DID Method Registry process embodies the second of these. It is not a fast process. It is not a marketing event. A method is submitted, reviewed by working group members and the broader community, revised based on feedback, and eventually accepted (or not) based on whether the contribution meets the criteria the working group has developed.

The criteria are substantive: does the method comply with DID Core, does the security analysis hold up, does the privacy analysis hold up, does the conformance documentation match what implementations actually do. The working group's review is rigorous because the registry's value depends on the rigor; a registry full of poorly-reviewed methods would be useless.

When a method is accepted, what's been accepted is not just technical conformance. The community of standards practitioners has implicitly agreed that the method belongs in the lineage. The acceptance carries weight because the practitioners are reputable, the process is transparent, and the criteria are public.

The civilizational meaning of this kind of consecration. Across history, secular societies have developed institutions for accrediting work that meets community standards. Academic peer review, professional licensing, building code compliance, certificate authority audits. Each of these is a process for the community to say "this work meets our shared standards; we accept it."

The W3C DID Method Registry serves a similar function for identity infrastructure. It is the community's mechanism for accrediting which methods belong in the shared standards lineage. The acceptance is not a one-time event; it carries with it ongoing accountability to the community's standards.

For Solidus, the submission of did:solidus to the W3C DID Method Registry is participation in this process. We are not asking for marketing approval; we are asking for technical and community review. The first round of review produced feedback; we revised; subsequent rounds have continued the process. Whether and when the method is accepted depends on the working group's assessment of whether the contribution meets the standards.

The deeper meaning of "registered" — when it eventually happens for did:solidus or any peer method — is the community's acknowledgment that the method belongs in the lineage. The acknowledgment matters more than the technical badge; the badge is a side-effect of the deeper acknowledgment.

This is one of the durable values of standards bodies. The W3C, the DIF, the IETF, the ISO. Each represents a community-anchored accreditation function that has been developed over decades. The work the standards bodies do is patient, technical, often invisible to the broader public. The civilizational value is real.

The reader who comes to this article asking "why does the W3C registry matter" gets the answer: because the registry is the community's mechanism for accrediting which methods belong in the standards lineage, and the lineage is the foundation of credible identity infrastructure at internet scale.

For the broader civic conversation about identity infrastructure, support for the standards bodies is the durable contribution. Not advocacy for any specific vendor; not advocacy for any specific method. Advocacy for the institutions that accredit the work and maintain the lineage. Solidus is one of many contributors to those institutions. The institutions matter more than any individual contributor.

The next century of digital coordination will rely on identity infrastructure that traces back to the standards work being done in this decade. The W3C DID Method Registry, the DIF working groups, the IETF protocol drafts — these are the durable lineage. The methods that survive will be the methods that earned community acceptance through these institutions.

solidus.network

Agent identity in 2026: a CTO's integration calendar

Solidus Network — Wed, 24 Jun 2026 13:27:44 +0000

Agent identity is a 2027 budget event for any business whose customers will use agents.

The technical timeline is clear: ERC-8004 (agent identity registry) is stabilizing through 2026; x402 (credential-aware payment header) is shipping integrations through 2026; major agent infrastructure (the LLM-native agent platforms, the wallet-integrated agent services) is integrating credential acceptance through 2026-2027. By Q3 2027, your customers' agents will start presenting credentials at your platform.

The CTO question for 2026: have you specified the credential-acceptance path for agent traffic at your platform?

If not, you're in the situation businesses found themselves in for mobile in 2009 — the user behavior changed; the platforms that scrambled were the ones that didn't anticipate. The agent-traffic version of this is the same shape: traffic patterns change, credential expectations change, payment-attribution requirements change. The platforms that build the acceptance path early are the ones whose customer experience holds up.

The integration target: OID4VP (the verifier-side protocol) supports both human-bound and agent-bound credentials. The credential format is the same Verifiable Credential Data Model 2.0. The verification logic is the same — only the credential schema differs (agent credentials include delegation scope, principal identifier, validity window).

The build-vs-buy decision is straightforward. Build path: integrate an SDK (Solidus or another) and add the agent-credential acceptance logic. ~2-3 engineering sprints. Buy path: wait for your incumbent identity vendor to add agent support. Cost-comparable on the long run; faster control on the build path; less optionality on the buy path.

Strategic considerations.

One: agent-aware merchants will be preferred routing partners for agent platforms. If your platform accepts agent credentials cleanly, agent platforms will route their high-value traffic to you preferentially.

Two: the compliance audit trail for agent transactions requires credential-attestation, not behavioral fingerprinting. The architecture wins out over the heuristic approach for regulated transactions.

Three: the cost economics of credential-aware agent verification are 10-100x lower than the bot-detection approaches that try to behaviorally identify agents.

Recommend CTOs of B2C platforms, fintechs, payment processors, and content platforms start the agent-identity integration in 2026. The CTOs who wait until Q4 2027 will be paying premium prices for emergency integration; the CTOs who plan in 2026 will have stable, low-cost agent-acceptance paths.

The Solidus SDK ships the agent-credential acceptance logic alongside the human-credential acceptance logic. One integration, both entity types. The economics scale.

solidus.network

"Another identity L1?" — answered with standards, not whitepaper

Solidus Network — Tue, 23 Jun 2026 11:52:19 +0000

The first question any informed observer asks Solidus is: another identity L1?

It is a fair question. There is a graveyard of self-sovereign identity projects from 2018-2022 — Sovrin, uPort, and others — that built credible architectures, attracted talented teams, and ran out of runway before adoption could fund operations. The skepticism toward yet another chain with the word "identity" in it is well-earned.

This is our answer.

We invent exactly one thing

Solidus composes from roughly 44 open standards and protocols. Some of them are obvious — W3C DID Core, W3C Verifiable Credentials Data Model 2.0, BBS+ signatures, SD-JWT VC, OpenID for Verifiable Credential Issuance (OID4VCI), OpenID for Verifiable Presentations (OID4VP), DIDComm v2, eIDAS 2.0, ISO mDL (mobile driver's license), NIST SP 800-63 identity assurance levels.

Some are less obvious — DID URL syntax (W3C), Status List 2021 for revocation (W3C), Verifiable Credential API (W3C), DID Method Registry process (W3C), the ISO 18013-5 mobile credential standard, the OpenID Federation framework. We adopt the standards as-published. We do not invent parallel implementations.

What we invent is exactly one thing: the chain that anchors the issuer trust and the revocation events that the rest of the stack has to verify against.

The reason we invent that one thing is that the existing options — anchoring on Ethereum, Polygon, or any general-purpose L1 — give identity operations the wrong gas economics, the wrong throughput profile, and the wrong validator incentive model. Verifying a credential is a signature check plus a revocation lookup. It is not contract execution. The EVM cost model is wrong for it by roughly two orders of magnitude.

So we build a purpose-built chain, with HotStuff BFT consensus optimized for finality (not throughput-maximalism), and we pay for it with the network's own economics. Everything above the chain layer — the credential format, the verification API, the selective disclosure cryptography — is the standard, as-shipped, integrated honestly.

What this means for "another identity L1?"

It means we are not in the same category as the SSI projects that failed.

Those projects, including the ones we admire most, made one of two structural mistakes. Either they built proprietary credential formats that diverged from W3C ahead of W3C reaching consensus (and then had to migrate later, losing years), or they built on Ethereum and lost to the gas-economics problem before they ever got to product-market fit.

We waited. The W3C Recommendation status for DID Core arrived in 2022. The VC Data Model 2.0 followed. BBS+ shipped at multiple production implementations before we depended on it. We are not gambling on the standards stabilizing; we are building after they stabilized.

And we are not building on a chain that prices us out. The cost of a credential verification on Solidus is on the order of fractions of a cent. On Ethereum mainnet, it would be measured in dollars. Identity operations at internet scale require the dimensions of throughput and cost that a purpose-built chain provides.

What "standards-native" means in practice

It means our SDK uses W3C VC Data Model 2.0 as the on-the-wire format, not a proprietary variant. If you implement a Solidus verifier and later need to verify a credential issued by a different W3C-compliant issuer, the cryptographic verification path is the same.

It means our DID method, did:solidus, conforms to W3C DID Core. We have submitted it to the W3C DID Method Registry as PR #713. It is under review, not merged; the registry process takes months, and we describe the status honestly at every stage.

It means we ship BBS+ as the production selective disclosure scheme. We ship SD-JWT VC for environments that prefer JWS-based credentials. We do not ship a proprietary ZK scheme that no one can audit.

It means our chain client uses OpenID Federation patterns for verifier-issuer trust establishment, which is what the EU eIDAS 2.0 framework will require by late 2026.

The opposite of standards-native is NIH — Not Invented Here, building your own version of every standard component. NIH lets you ship faster in the short run. It also locks you into a single-vendor ecosystem where no third party can verify your credentials, no other issuer can interop with you, and no acquisition path other than full takeover exists.

We are not building for that exit. We are building for the layer position.

Why this matters to a skeptic

If you are evaluating Solidus from the perspective of "another identity L1, why should I care?", the answer is in two parts.

First, the question of whether identity converges on an open layer or fragments forever into proprietary silos is already decided. eIDAS 2.0 mandates the wallet architecture. The agent stack consolidates around credential-aware payments. The W3C standards reach Recommendation status. Some chain will anchor this. The question is which.

Second, the chain that anchors it has to be honest about what it invents and what it composes. A protocol that claims to invent twenty new things at the identity layer is either lying or doomed. We claim one invention: the chain. Everything else is the standard.

If that resonates, look at the SDK. If it does not, the answer is in the public W3C DID Method Registry: PR #713.

solidus.network

"Sign in with Google" as the surveillance default — and the alternative civics

Solidus Network — Mon, 22 Jun 2026 10:54:18 +0000

"Sign in with Google" has become so naturalized that questioning it feels paranoid. This is itself worth questioning. When a surveillance arrangement becomes the unquestioned default, the surveillance no longer requires justification; the alternative requires justification.

The civic dimension of the default matters. A democratic society depends on the existence of un-surveilled spaces — spaces where citizens can think, discuss, organize, dissent, change their minds, without the activity being logged for later use. The architecture of identity infrastructure determines what un-surveilled spaces are operationally possible. If every authentication is logged centrally, the un-surveilled space collapses.

The historical analogue. The transition from cash payments to card payments transferred a similar amount of activity into the centrally-logged category. The card networks did not advocate for this transfer on the basis of its civic implications; they advocated for it on the basis of convenience. The convenience was real; the civic loss was diffuse and slow to be recognized. Decades later, scholars and regulators are arguing about whether the loss can be reversed.

The same pattern is repeating with identity. The federated authentication default — Sign in with Google, with Apple, with Facebook — was adopted on the basis of convenience. The civic loss is diffuse: every authentication metadata becomes part of a near-complete profile of the citizen's activity. The scale of the surveillance is invisible per-transaction and overwhelming in aggregate.

The architecture of decentralized authentication offers an alternative civics. A credential held by the user, presented selectively, verified cryptographically — no third party in the loop, no log retained by any centralized provider. The same convenience for the user (one identity, many services) but without the surveillance trade-off.

The civic case for this is not merely about privacy as a personal right. It is about preserving the structural conditions under which democratic society operates. The argument requires the same kind of intentionality the historical defenders of voting privacy, mail privacy, and association privacy applied.

Three structural conditions worth preserving.

Condition 1: Unobserved deliberation. Citizens forming political opinions, evaluating candidates, considering controversial views need spaces where the consideration is not logged. The current authentication architecture undermines this because the platforms where deliberation happens authenticate users through the surveillance default.

Condition 2: Reversible association. Citizens joining or leaving associations (political parties, religious groups, advocacy organizations, support networks) need the joining and leaving to be reversible without permanent record. The current authentication architecture creates permanent records of every association joined.

Condition 3: Cross-platform pseudonymity. Citizens engaging in some activities under one persona and other activities under another persona — a long-standing pattern of healthy democratic engagement — need the personas to be cryptographically separable. The current authentication architecture (one Google account → many services) breaks the pseudonymity by default.

Each of these is preserved by the decentralized authentication architecture and broken by the federated default. The civic stakes are real.

The transition from the federated default to the decentralized alternative is not just a technical choice. It is a civic choice. The technologists building the alternative — Solidus and peers — are doing civic work even when the immediate framing is commercial. The buyers integrating the alternative are making civic decisions even when the immediate justification is procurement.

The 100-year frame. The architectural choices made in 2026-2030 about identity infrastructure will shape the structural conditions of democratic society for generations. The convenience trade-off that produced "Sign in with Google" was not, in retrospect, a fair trade. The opportunity to undo it without giving up convenience exists in this decade.

For the citizen, this article is not asking for personal action — most readers cannot meaningfully shape the architectural choices at the platform level. The asks are different: notice the default; support technologists building the alternative; favor platforms that integrate the alternative; advocate where appropriate for regulatory frameworks that mandate it.

The civic case for decentralized authentication is the case for preserving the structural conditions of democratic society. The technology exists. The standards exist. The implementations exist. The choice to deploy them broadly is collective.

solidus.network

The $50B authentication tax: who actually pays and how to leave

Solidus Network — Sun, 21 Jun 2026 09:15:16 +0000

The $50B figure for global identity verification spend deserves a buyer-side breakdown, because the number alone is unactionable.

Roughly half ($23-27B) is human KYC spend at fintechs, exchanges, banks, and regulated platforms. Of that, the largest fraction is duplicative re-verification — the same user, verified at multiple platforms, paying multiple per-verification fees. The unit economics: $5-50 per verification, depending on documents required and LoA target, multiplied across the user-platform matrix.

Another $10-12B is enterprise IAM (Auth0, Okta, Ping, Microsoft Entra, others). The recurring per-user subscription fees + the integration consulting + the breach-disclosure costs make this category one of the higher-margin enterprise software categories.

Another $5-7B is identity proofing for credit, healthcare, government services. These flows are typically vendor-integrated (Experian, LexisNexis, others) with per-pull fees.

The remaining $5-10B is the long tail: agent identity, machine identity, certificate authorities, identity-adjacent fraud prevention.

For a buyer at a fintech with 1M monthly active users, the rough breakdown of their slice of this $50B is: KYC re-verification at $0.50-2 per MAU per year ($600K-2.4M); CIAM at $0.30-1 per MAU per year ($360K-1.2M); fraud prevention at $0.40-1 per MAU per year. Annual: $1.5-5M depending on tier.

The architectural exit from this stack: portable Verifiable Credentials. The same KYC credential satisfies the bank, the exchange, the fintech, the payment platform. The same CIAM proof works across SaaS tools. The buyer pays once for issuance, accepts presentations against the issuer's anchored key.

The transition cost is real but bounded. Integration cost: ~$200-500K for a mid-size fintech (SDK integration + compliance review + change management). Operational cost during transition: ~6 months of running both stacks. Net 3-year ROI for the typical fintech: $3-8M in cost reduction.

Three triggers to make the decision now: the EU eIDAS 2.0 mandate forces verifier-side integration by Q4 2026 (you need the wallet acceptance path anyway); the agent-identity stack is consolidating around the same primitive (you'll need it for agent traffic in 2027); the regulatory compliance bar is rising (selective disclosure is GDPR-by-architecture, not GDPR-by-policy).

The buyer side has been slow to see this. The CFOs who run the analysis early will be the ones whose identity stack is one of the lowest in the industry by 2028.

solidus.network

The convergence problem: one credential primitive for humans, agents, and machines

Solidus Network — Sun, 21 Jun 2026 08:53:24 +0000

We mapped more than 500 identity companies.

The pattern across all of them is the same, and it is structural. Each one solves identity for exactly one entity type — your login, your KYC check, your wallet, your agent — inside a silo none of them can leave. Because the silo is the business model. Their revenue requires the credential to stay inside their walls. The moment it ports, the moat is gone.

So identity fragments three ways at once:

Humans get re-verified endlessly. The same passport, re-checked on every platform, stored in every database, exposed in every breach.

AI agents have no shared identity primitive at all. As agents begin to transact in 2026 — booking flights, renewing subscriptions, negotiating refunds, paying bills — there is no standard way to prove who issued an agent, what it is cleared to do, or which human (or organization) is on the other side of that delegation.

Machines face the same gap. Industrial machine-to-machine identity exists in isolated enterprise stacks; nothing portable, nothing standards-native.

This is one problem wearing three masks. And the fix is not a better silo. It is a shared primitive that any of the existing solutions can build on top of.

The convergence thesis

Identity, like networking and TLS before it, will converge on an open layer underneath the products. The question is who builds it.

A credible candidate has to do three things at once. It has to be one open credential primitive — a W3C DID plus a Verifiable Credential, with selective disclosure, signed by issuers a relying party can independently verify. It has to be issuable once and reusable everywhere, across humans and agents and machines, without re-verification per platform. And it has to be anchored in a layer that survives the failure of any single issuer or verifier.

That is the protocol-shaped problem. It is not solved by a SaaS company that owns the credential after issuing it.

Why this hasn't happened yet

Two reasons. First, the standards needed to make it real — W3C DIDs and Verifiable Credentials 2.0 — only reached Recommendation status in 2022. Until then, "open identity" meant "competing whitepapers." The bricks were not baked.

Second, the incentive layer was wrong. Self-sovereign identity projects in the 2018-2022 era (Sovrin, uPort, others) built credible architectures and ran out of runway. Identity protocols are platform-shaped: network effects take years; revenue is gated on adoption you cannot manufacture; smart teams quit before the curve bends.

What changes in 2026 is the convergence of three forces. eIDAS 2.0 mandates EU digital identity wallets for 450 million citizens by December. The agent transaction stack is consolidating around ERC-8004 (an agent identity registry) and x402 (credential-aware payment headers). The W3C standards floor is set.

These don't converge again. The window for the open layer to be built is now.

What Solidus is

We start with the wedge that pays: portable verification for humans, on a chain that anchors identity claims rather than financial transactions. We use the W3C standards as-shipped — did:solidus is a method submitted to the W3C DID Method Registry (under review, not merged, never "registered"). We use SD-JWT VC and BBS+ for selective disclosure, both production-ready, both shipped on our testnet.

The same primitive extends upward as the agent stack and the machine stack mature. We are not building a separate identity protocol for agents and another for machines. The same did:solidus method, the same VC format, the same selective disclosure path.

That is the convergence: one credential primitive, three entity types, every relying party.

What this is not

It is not a replacement for Auth0, Sumsub, Privy, or Skyfire — they each own a slice of the market, and our job is to be the layer underneath them, not the head-to-head competitor. We are betting the layer position is where the leverage is, the way TCP/IP was the leverage position underneath the SaaS stack of the 1990s.

It is not a token-launch event. There is no SLDS allocation before mainnet. The pitch is the protocol and the shipped components, not a speculation mechanism. If you are evaluating this for a token-rotation strategy, this is not that.

It is not a finished product. Eight of nineteen planned surfaces are live on testnet today. The other eleven wait on proof of the first eight, not on capital.

What you can check today

The SDK is on npm — @solidus-network/sdk covers DID method, VC format, BBS+ proofs, chain client, wallet interactions. The repo is open at github.com/solidusnetwork. The W3C DID Method Registry PR is #713. We are a DIF Associate Member, contributing to the Identifiers and BBS+ working groups.

If you build on identity, build on the standards underneath. If the standards underneath need a chain that anchors them honestly, that is the bet.

solidus.network