Start with Identity
Subscribe
Tools

Top 7 Open-Source Decentralized Identity and Verifiable Credential Tools

The best open-source decentralized identity tools in 2026, from Credo and ACA-Py to walt.id, Veramo, SpruceID, CREDEBL, and Sphereon, compared on credential formats, protocol support, and readiness for the EUDI Wallet stack.

By SWI Community TeamUpdated 2026-08-2914 min read
Key takeaways
  • The decentralized identity stack settled in 2025 and 2026 on OpenID4VCI and OpenID4VP for issuance and presentation, with SD-JWT and mdoc as the credential formats, which is what the EU Digital Identity Wallet standardized on.
  • The leading open-source options are Credo, ACA-Py, walt.id, Veramo, SpruceID, CREDEBL, and Sphereon.
  • Choose by protocol stack first: tools built around OpenID4VC and SD-JWT align with the EUDI Wallet and national schemes, while the older DIDComm and AnonCreds lineage remains strong where zero-knowledge predicate proofs matter.

Decentralized identity spent a decade as a promising set of drafts and became a delivery deadline. Regulation (EU) 2024/1183 requires every member state to make a wallet available by 24 December 2026, mobile driving licences are shipping under ISO/IEC 18013-5, and the protocol argument that consumed the field for years has largely settled: OpenID4VCI for issuance, OpenID4VP for presentation, SD-JWT and mdoc as the credential formats.

That settlement matters for tool selection more than any feature comparison. Tooling built around the OpenID4VC stack aligns with what national programmes are deploying; tooling from the older DIDComm and AnonCreds lineage remains excellent but serves a narrower and more privacy-maximalist set of use cases. This guide covers seven open-source projects and where each sits. For concepts see what is decentralized identity and the decentralized identity vendor category.

Evaluation Criteria

We assessed each tool against the following dimensions:

  • Protocol support, OpenID4VCI and OpenID4VP versus DIDComm
  • Credential formats, SD-JWT, mdoc, W3C VC Data Model, AnonCreds
  • Role coverage, issuer, holder or wallet, and verifier
  • DID method support, did:web, did:key, and ledger-anchored methods
  • Maturity, production deployments and maintenance activity
  • Governance, foundation-hosted versus single-vendor
  • Developer experience, SDK quality and documentation

The Top 7 Open-Source Decentralized Identity Tools

1. Credo

Best For: Building mobile wallets and agents in TypeScript.

Overview

Credo, formerly Aries Framework JavaScript and now under the Open Wallet Foundation, is the TypeScript framework most decentralized identity mobile work is built on. It supports both lineages: DIDComm and AnonCreds from its Aries heritage, and OpenID4VC with SD-JWT for the current stack. React Native support means one codebase can serve a mobile wallet, which is why SDKs such as the ADEYA mobile wallet build on it.

Key Features

  • OpenID4VCI and OpenID4VP alongside DIDComm
  • SD-JWT VC and AnonCreds credential formats
  • React Native support for mobile wallets
  • Modular architecture with pluggable DID methods and storage
  • Open Wallet Foundation governance

License Apache 2.0.

Pros

  • Covers both the current and legacy protocol stacks, which de-risks a long build
  • Best option for a mobile wallet in the JavaScript ecosystem
  • Neutral foundation governance

Cons

  • Broad scope means a large API surface to learn
  • Mobile builds carry the usual React Native native-module complexity
  • Documentation lags feature development in places

2. ACA-Py

Best For: Production issuer and verifier agents in Python, with a long operational track record.

Overview

ACA-Py (Aries Cloud Agent Python) is the most production-proven open-source agent in the ecosystem, maintained with substantial contribution from the Government of British Columbia, which runs it in live public services. It is a server-side agent for issuing and verifying credentials, with a mature admin API, and it has added OpenID4VC support alongside its DIDComm and AnonCreds foundations.

Key Features

  • Server-side issuer and verifier agent with admin REST API
  • AnonCreds with zero-knowledge predicate proofs
  • DIDComm messaging plus OpenID4VC support
  • Multi-tenancy for hosting many issuers on one deployment
  • Real government production deployments

License Apache 2.0, under LF Decentralized Trust.

Pros

  • The strongest production track record in the ecosystem
  • Multi-tenancy makes it practical for platform deployments
  • Excellent AnonCreds support where predicate proofs matter

Cons

  • Python agent architecture is heavier than a library
  • AnonCreds ecosystem is narrower than SD-JWT
  • Operating it well requires understanding agent and wallet concepts

3. walt.id

Best For: End-to-end issuer, wallet, and verifier tooling aligned with the European stack.

Overview

walt.id provides open-source infrastructure covering the full triangle: issuer APIs, a wallet, and verifier services, with an explicit focus on the EU stack including SD-JWT, mdoc, and the OpenID4VC protocols. For teams building against eIDAS 2 requirements it is one of the fastest paths from nothing to a working end-to-end flow.

Key Features

  • Issuer, wallet, and verifier components in one stack
  • SD-JWT VC and ISO mdoc credential formats
  • OpenID4VCI and OpenID4VP throughout
  • Kotlin and JVM based, with REST APIs for language independence
  • EUDI-oriented feature development

License Apache 2.0, with commercial offerings from walt.id.

Pros

  • Complete stack rather than one role, which shortens prototyping considerably
  • Explicit alignment with the European regulatory stack
  • Active development against a moving specification target

Cons

  • Single-vendor project rather than foundation-governed
  • JVM stack may not fit every environment
  • Feature split between open source and commercial offerings

4. Veramo

Best For: Flexible, modular credential handling in JavaScript and TypeScript applications.

Overview

Veramo is a modular framework for working with DIDs and verifiable credentials in JavaScript, designed as a set of composable plugins rather than an opinionated agent. Its strength is flexibility: you assemble exactly the DID methods, credential formats, and storage you need. That makes it a good fit for embedding credential capability into an existing application rather than deploying a standalone agent.

Key Features

  • Plugin architecture for DID methods, credential formats, and storage
  • W3C Verifiable Credentials Data Model support
  • Works in Node.js and browser contexts
  • Key management abstraction with multiple backends
  • Composable rather than prescriptive

License Apache 2.0.

Pros

  • Easiest way to add credential handling to an existing JavaScript application
  • Genuinely modular, so you carry only what you use
  • Good DID method coverage

Cons

  • Less complete OpenID4VC coverage than walt.id or Credo
  • Flexibility means more assembly work
  • Smaller community than the Aries lineage projects

5. SpruceID

Best For: Rust and multi-language credential tooling with strong standards fidelity.

Overview

SpruceID develops open-source credential tooling with a focus on standards correctness, including DIDKit and related libraries that expose credential issuance and verification across several languages through a Rust core. The company has been involved in US state mobile driving licence work, which shows in its attention to the mdoc side of the ecosystem alongside W3C credentials.

Key Features

  • Rust core with bindings for multiple languages
  • W3C Verifiable Credentials and Data Integrity proofs
  • mdoc and ISO 18013-5 related tooling
  • Standards-track participation reflected in implementation fidelity
  • Components usable independently

License Apache 2.0 and MIT across the project family.

Pros

  • Strong standards fidelity, which matters for interoperability testing
  • Rust core suits embedded and performance-sensitive deployments
  • Involvement in real government credential programmes

Cons

  • Lower-level than the full-stack frameworks, so more assembly
  • Documentation assumes standards familiarity
  • Project family is spread across several repositories

6. CREDEBL

Best For: Running a multi-tenant credential platform rather than a single issuer.

Overview

CREDEBL, hosted under LF Decentralized Trust, is an open-source platform for managing decentralized identity and verifiable credentials at organization scale, with multi-tenancy, an issuer and verifier console, and supporting mobile wallet components. It targets deployments where many organizations issue credentials through shared infrastructure, which is the shape most national and sector schemes actually take.

Key Features

  • Multi-tenant platform for many issuing organizations
  • Web console for issuance and verification management
  • Mobile wallet components (ADEYA) built on Credo
  • Ledger and DID method flexibility
  • Foundation-hosted governance

License Apache 2.0, under LF Decentralized Trust.

Pros

  • Platform-shaped rather than library-shaped, which fits scheme operators
  • Console reduces the amount of custom UI work
  • Neutral governance

Cons

  • Heavier deployment than a framework
  • Younger than ACA-Py or Credo
  • Overkill for a single-issuer use case

7. Sphereon

Best For: OpenID4VC building blocks for issuers and verifiers in TypeScript.

Overview

Sphereon maintains a set of open-source TypeScript libraries implementing OpenID4VCI, OpenID4VP, SIOPv2, and related specifications, widely used as the protocol layer inside other products including Credo. If you need standards-conformant OpenID4VC handling and want to build the rest yourself, these are the libraries most likely already underneath the framework you were considering.

Key Features

  • OpenID4VCI, OpenID4VP, and SIOPv2 implementations
  • Presentation Exchange support for credential query
  • SD-JWT VC handling
  • Modular libraries usable independently
  • Used as the protocol layer by other frameworks

License Apache 2.0.

Pros

  • Close tracking of the OpenID4VC specifications
  • Composable libraries with no framework lock-in
  • Already proven inside other projects

Cons

  • Libraries, not a product: you build the surrounding system
  • Requires reading the specifications to use well
  • Documentation is developer-terse

How to choose

Start from the protocol stack. If your target is the EUDI Wallet, a national scheme, or anything issuing to a government wallet, build on OpenID4VCI and OpenID4VP with SD-JWT and mdoc. walt.id, Sphereon, and Credo are the strongest options there.

Choose AnonCreds deliberately, not by default. Zero-knowledge predicate proofs and unlinkable presentations are genuinely better for privacy, and ACA-Py with AnonCreds is the mature path. But you take on separate revocation machinery and a smaller ecosystem, and it is not what the European stack chose.

Use did:web until something forces you off it. It resolves through DNS and TLS, auditors understand it, and it works today. Ledger-anchored methods remove the DNS dependency and add infrastructure you now operate or trust. See DID methods compared.

Plan revocation and trust decisions from day one. These are the parts that get deferred and then block launch. A verifier needs to know which issuers to trust, which is a governance question requiring a trust registry, and it needs to check revocation without phoning the issuer, which is what status lists exist for.

The open-source identity landscape

This is one of a series covering open-source tooling across every identity category:

Frequently asked questions

What are the best open-source decentralized identity tools in 2026?
The leading open-source decentralized identity tools in 2026 are Credo, ACA-Py, walt.id, Veramo, SpruceID, CREDEBL, and Sphereon. Credo is the TypeScript framework most mobile wallet work builds on, ACA-Py is the mature Python agent maintained with support from the Government of British Columbia, and walt.id, Veramo, SpruceID, and Sphereon provide issuer and verifier tooling across the OpenID4VC stack.
Which credential format should we build on?
SD-JWT and mdoc, unless you have a specific reason otherwise. The EU Digital Identity Wallet standardized on them, ISO/IEC 18013-5 mdoc is what mobile driving licences use, and national schemes are converging on the same choices. AnonCreds remains the strongest option for zero-knowledge predicate proofs and unlinkable presentations, but it carries its own revocation machinery and a smaller tooling ecosystem.
What replaced Hyperledger Aries?
The projects moved under LF Decentralized Trust, the rebranded Hyperledger foundation, and the naming changed. Aries Framework JavaScript became Credo under the Open Wallet Foundation, and Aries Cloud Agent Python is now ACA-Py. The code lineage is continuous; the governance and branding changed, which causes confusion when reading older documentation.
Do I need a blockchain to issue verifiable credentials?
No, and most production deployments do not use one. A verifiable credential needs a way for a verifier to find the issuer's public key, which did:web resolves through ordinary DNS and TLS. Ledger-anchored DID methods remove the DNS dependency at the cost of running or trusting ledger infrastructure. Start with did:web unless you have a specific requirement it cannot meet.
What is the hardest part of a decentralized identity deployment?
Revocation and trust decisions, not issuance. Issuing a credential is straightforward; deciding which issuers a verifier should trust requires a governance framework or trust registry, and checking whether a credential has been revoked without phoning the issuer reintroduces exactly the surveillance channel the model removes. Status lists are the pragmatic compromise most schemes use.
Last reviewed By SWI Community TeamSuggest a correctionHow we research

Related on Start with Identity

Independent editorial review, no sponsorship. See more in our articles and rankings.