Hyperledger Indy

Type	Class
Resource	urn:ngm:class:hyperledger-indy
Domain	blockchain
Status	stable
Maturity	established
Quality	0.52
Is a	Network Component Blockchain Verifiable Data Registry Permissioned Distributed Ledger Decentralized Identifier Method Byzantine Fault Tolerant System Hyperledger Project
Has part	AnonCreds Credential Definition Credential Schema Revocation Registry Plenum Indy Node Indy VDR Indy Credx Aries Askar Steward Node Genesis Transaction File
Requires	Cryptographic Accumulator Hyperledger Aries Public Key Infrastructure Steward Network Genesis Pool Configuration Secure Wallet Storage
Enables	Offline Credential Verification Selective Disclosure Predicate Proof Unlinkable Credential Presentation Revocation without Correlation Issuer-Holder-Verifier Triangle Offline Credential Verification Multi-Tenant Identity Ledger
Generated	by: process:vault-migrate/1.0 · at: 2026-09-22T12:41:39.024503178Z
Contrasts with	did:web did:webvh did:key did:plc did:ion did:ethr did:peer SD-JWT VC mDoc ISO mDL 18013-5 Atala PRISM Microsoft Entra Verified ID ION (Sidetree on Bitcoin)
Depends on	Camenisch-Lysyanskaya Signature Pedersen Commitment Cryptographic Accumulator Practical Byzantine Fault Tolerance RBFT Consensus Aardvark BFT Pairing-Friendly Elliptic Curve BLS12-381
Implemented in layer	LedgerLayer CredentialLayer ConsensusLayer CryptographicPrimitiveLayer
Implements	Trust over IP Stack W3C Decentralized Identifier Specification W3C Verifiable Credentials Data Model Self Sovereign Identity W3C Decentralized Identifier Specification Sovrin Trust Framework ZKP-Based Anonymous Credentials
Legacy term id	BC-0435
Links	Aardvark BFT Allen 2016 The Path to Self-Sovereign Identity AnonCreds AnonCreds Specification v1.0 Aries Askar Aries Cloud Agent Python Aries Cloud Agent Python Atala PRISM Aublin Mokhtar Quéma 2013 ICDCS RBFT BC Wallet Bifold Wallet BLS12-381 Boneh Boyen Shacham 2004 CRYPTO Short Group Signatures Byzantine Fault Tolerant System Camenisch Drijvers Lehmann 2016 TRUST Anonymous Attestation Camenisch Kohlweiss Soriente 2009 PKC Accumulator Anonymous Credentials Camenisch Lysyanskaya 2002 SCN Signature Scheme Camenisch Lysyanskaya 2004 CRYPTO Bilinear Maps Camenisch-Lysyanskaya Signature Cameron 2005 The Laws of Identity Castro Liskov 1999 OSDI Practical Byzantine Fault Tolerance Clement Wong Alvisi Dahlin 2009 NSDI Aardvark ConsensusLayer Credential Definition CredentialLayer Credential Schema Credo Cross-Border Credential Recognition Cryptographic Accumulator CryptographicPrimitiveLayer CryptographyDomain Decentralized Identifier Method Decentralized Identity Foundation did:ethr did:indy Method Specification did:ion did:key did:peer did:plc did:sov Method Specification did:web did:webvh Distributed Hash Table Routing DistributedSystemsDomain eIDAS Article 6a Wallet Trust Model esatus AG European Commission 2024 EUDI Wallet ARF v1.3 Findy GDPR Data Minimisation Genesis Pool Configuration Genesis Transaction File Government Digital Identity Government of British Columbia VON OrgBook Case Studies Hyperledger Aries Hyperledger Foundation Hyperledger / LF Decentralized Trust Indy Project Documentation Hyperledger Project Hyperledger Ursa IATA Travel Pass IdentityDomain IDnow IDUnion IDUnion eG Production Network Documentation IETF SD-JWT-VC Internet Draft Indicio Indicio Network Indy Credx Indy Node Indy Plenum Indy VDR ION (Sidetree on Bitcoin) ISO/IEC 18013-5 (mDL) ISO/IEC 18013-5 mDL ISO mDL 18013-5 ISO mDL 18013-5 Issuer-Holder-Verifier Triangle JSON-LD Lamport Shostak Pease 1982 Byzantine Generals LedgerLayer LF Decentralized Trust Linux Foundation Linux Foundation Public Health Good Health Pass Blueprint mDoc MATTR Microsoft Entra Verified ID Multi-Signature Cryptographic Schemes Multi-Tenant Identity Ledger Offline Credential Verification Open Identity Exchange OpenWallet Foundation OpenWallet Foundation Credo Bifold ACA-Py Documentation OrgBook BC Pairing-Friendly Elliptic Curve Pedersen 1991 CRYPTO Verifiable Secret Sharing Pedersen Commitment Permissioned Distributed Ledger Plenum Plenum Consensus Predicate Proof Predicate Proofs Preukschat Reed 2021 Self-Sovereign Identity Manning Privacy-Preserving Compliance Python 3.6+ RBFT Consensus Reed Law Hardman 2017 The Inevitable Rise of Self-Sovereign Identity Regulation EU 2024-1183 eIDAS 2.0 Revocation Registry Revocation without Correlation RocksDB SD-JWT VC Secure Wallet Storage Selective Disclosure Sovrin Foundation Sovrin Governance Framework v2 Sovrin Token (deprecated) Sovrin Trust Framework Steward Network Steward Node Trust over IP Foundation Trust over IP Foundation Trust over IP Foundation Technology Stack Trust over IP Stack Trust over IP Technology Stack Unlinkable Credential Presentation Verifiable Organizational Credentials Verifiable Organizations Network W3C W3C 2022 DID Core 1.0 Recommendation W3C 2024 Verifiable Credentials Data Model v2.0 W3C Decentralized Identifier Specification W3C DID Core 1.0 W3C DID Specification Registries did:indy 2022 W3C Verifiable Credentials W3C Verifiable Credentials Data Model W3C Verifiable Credentials Data Model v2.0 Windley 2018 Sovrin Protocol Token White Paper ZeroMQ ZKP-Based Anonymous Credentials BlockchainDomain Practical Byzantine Fault Tolerance Practical Byzantine Fault Tolerance Public Key Infrastructure Rust Self-Sovereign Identity Verifiable Data Registry
Page resource	urn:visionflow:page:bc50e32aa9540e73af92b54b682a78ab0b2188deb4acf2b1d2c5884d64fb4dc8
Related to	Decentralized Identity Foundation Hyperledger Aries LF Decentralized Trust Trust Over IP Foundation Hyperledger Ursa Aries Cloud Agent Python Credo Bifold Wallet OpenWallet Foundation Sovrin Foundation Indicio IDUnion
Standardized by	AnonCreds Specification v1.0 did:indy Method Specification ISO-IEC 18013-5 mDL Trust over IP Technology Stack W3C DID Core 1.0 W3C Verifiable Credentials Data Model v2.0 did:indy Method Specification did:sov Method Specification Sovrin Governance Framework v2 Trust over IP Technology Stack AnonCreds Specification v1.0
Supports	GDPR Data Minimisation Government Digital Identity Privacy-Preserving Compliance Verifiable Organizational Credentials Verifiable Organizational Credentials Cross-Border Credential Recognition GDPR Data Minimisation eIDAS Article 6a Wallet Trust Model
Uses	Distributed Hash Table Routing Multi-Signature Cryptographic Schemes Python 3.6+ RocksDB Rust Systems Programming Language Plenum Consensus ZeroMQ Python 3.6+ Indy Plenum Sovrin Token (deprecated) Multi-Signature Cryptographic Schemes Distributed Hash Table Routing

Hyperledger Indy is the purpose-built, permissioned, Byzantine-fault-tolerant distributed-ledger project hosted by the Linux Foundation-resident Hyperledger Foundation (now consolidated under the LF Decentralized Trust umbrella since June 2024) that provides the canonical reference implem…

Semantic Classification

Content

Compositional Relationships (Components)

SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:hasPart blockchain:Plenum))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:hasPart blockchain:IndyNode))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:hasPart blockchain:IndyVDR))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:hasPart blockchain:IndyCredx))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:hasPart blockchain:AriesAskar))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:hasPart blockchain:AnonCreds))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:hasPart blockchain:RevocationRegistry))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:hasPart blockchain:CredentialSchema))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:hasPart blockchain:CredentialDefinition))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:hasPart blockchain:StewardNode))

## Dependency Relationships
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:requires blockchain:StewardNetwork))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:requires blockchain:PublicKeyInfrastructure))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:requires blockchain:GenesisPoolConfiguration))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:requires blockchain:HyperledgerAries))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:requires blockchain:SecureWalletStorage))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:dependsOn blockchain:CamenischLysyanskayaSignature))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:dependsOn blockchain:PedersenCommitment))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:dependsOn blockchain:CryptographicAccumulator))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:dependsOn blockchain:PracticalByzantineFaultTolerance))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:dependsOn blockchain:RBFTConsensus))

## Capability Relationships
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:enables blockchain:SelectiveDisclosure))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:enables blockchain:PredicateProof))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:enables blockchain:UnlinkableCredentialPresentation))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:enables blockchain:RevocationWithoutCorrelation))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:enables blockchain:OfflineCredentialVerification))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:enables blockchain:MultiTenantIdentityLedger))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:supports blockchain:GovernmentDigitalIdentity))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:supports blockchain:VerifiableOrganizationalCredentials))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:supports blockchain:CrossBorderCredentialRecognition))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:supports blockchain:GDPRDataMinimisation))

## Implementation Relationships
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:implements blockchain:SelfSovereignIdentity))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:implements blockchain:W3CDecentralizedIdentifier))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:implements blockchain:W3CVerifiableCredentials))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:implements blockchain:SovrinTrustFramework))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:implements blockchain:TrustOverIPStack))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:implements blockchain:ZKPAnonymousCredentials))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:uses blockchain:PlenumConsensus))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:uses blockchain:RocksDB))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:uses blockchain:ZeroMQ))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:uses blockchain:Python))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:uses blockchain:Rust))

## Reduction Relationships
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:reduces blockchain:CredentialIssuerSurveillance))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:reduces blockchain:IdentityHoneypotRisk))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:reduces blockchain:CorrelationRisk))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:reduces blockchain:UnnecessaryAttributeDisclosure))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:reduces blockchain:CentralizedIdentityProviderDependency))

## Association Relationships
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:relatedTo blockchain:HyperledgerAries))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:relatedTo blockchain:HyperledgerUrsa))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:relatedTo blockchain:SovrinFoundation))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:relatedTo blockchain:TrustOverIPFoundation))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:relatedTo blockchain:OpenWalletFoundation))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:contrastsWith blockchain:DIDWeb))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:contrastsWith blockchain:DIDKey))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:contrastsWith blockchain:DIDPLC))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:contrastsWith blockchain:SDJWTVC))
SubClassOf(blockchain:HyperledgerIndy
  ObjectSomeValuesFrom(blockchain:contrastsWith blockchain:MDoc))

## Data Properties (Characteristics)
DataPropertyAssertion(blockchain:hasIdentifier blockchain:HyperledgerIndy "BC-0435"^^xsd:string)
DataPropertyAssertion(blockchain:authorityScore blockchain:HyperledgerIndy "0.87"^^xsd:decimal)
DataPropertyAssertion(blockchain:contributedYear blockchain:HyperledgerIndy "2017"^^xsd:integer)
DataPropertyAssertion(blockchain:foundingFoundation blockchain:HyperledgerIndy "Sovrin Foundation"^^xsd:string)
DataPropertyAssertion(blockchain:consensusProtocol blockchain:HyperledgerIndy "Plenum (RBFT/Aardvark)"^^xsd:string)
DataPropertyAssertion(blockchain:didIndyRegisteredYear blockchain:HyperledgerIndy "2022"^^xsd:integer)
DataPropertyAssertion(blockchain:sdkDeprecatedYear blockchain:HyperledgerIndy "2022"^^xsd:integer)
DataPropertyAssertion(blockchain:bcOrgBookCredentialCount blockchain:HyperledgerIndy "525000"^^xsd:integer)

## Property Constraints
SubClassOf(blockchain:HyperledgerIndy
  DataMinCardinality(1 blockchain:hasDIDMethod xsd:string))
SubClassOf(blockchain:HyperledgerIndy
  DataMinCardinality(4 blockchain:hasStewardCount xsd:integer))
SubClassOf(blockchain:HyperledgerIndy
  DataAllValuesFrom(blockchain:isPermissioned xsd:boolean))
SubClassOf(blockchain:HyperledgerIndy
  DataSomeValuesFrom(blockchain:supportsAnonCredsVersion xsd:string))

## Annotations
AnnotationAssertion(rdfs:label blockchain:HyperledgerIndy "Hyperledger Indy"@en)
AnnotationAssertion(rdfs:comment blockchain:HyperledgerIndy "Purpose-built permissioned BFT distributed ledger and reference verifiable data registry for Self-Sovereign Identity, originated by Sovrin Foundation 2016, contributed to Hyperledger 2017, implementing Plenum (RBFT/Aardvark BFT) consensus across steward-operated validator nodes storing only public DIDs (did:sov, did:indy), credential schemas, credential definitions and revocation accumulators, supporting AnonCreds v1 (Camenisch-Lysyanskaya signatures with Pedersen commitments and zero-knowledge selective-disclosure + predicate proofs + non-revocation accumulators) and AnonCreds v2 migration to BBS+ signatures over BLS12-381; deployed on Sovrin MainNet, Indicio Network, IDUnion (Germany), Findy (Finland), CANdy, BCovrin; canonical production ecosystem includes BC Wallet + OrgBook BC (525,000 business credentials), IDUnion, Indicio, MATTR, esatus; companion Hyperledger Aries provides DIDComm peer-protocol stack and ACA-Py / Credo / Bifold agent frameworks; faces structural competition 2023-2025 from did:web/did:webvh/did:key/did:plc/did:ion lighter DID methods and from EUDI Wallet ARF selecting SD-JWT VC + mDoc over AnonCreds, alongside Indy SDK deprecation, Trinsic pivot away from Indy 2023, OpenWallet Foundation emergence, and Hyperledger Foundation consolidation into LF Decentralized Trust June 2024."@en)
AnnotationAssertion(dcterms:identifier blockchain:HyperledgerIndy "BC-0435"^^xsd:string)
AnnotationAssertion(dcterms:subject blockchain:HyperledgerIndy "Self-Sovereign Identity, Decentralized Identifiers, Verifiable Credentials, AnonCreds, Plenum BFT, Sovrin, Hyperledger Aries, Trust over IP"@en)

)

Property Characteristics

AsymmetricObjectProperty(blockchain:requires) AsymmetricObjectProperty(blockchain:enables) AsymmetricObjectProperty(blockchain:implements) AsymmetricObjectProperty(blockchain:contrastsWith) TransitiveObjectProperty(blockchain:dependsOn) FunctionalDataProperty(blockchain:contributedYear) FunctionalDataProperty(blockchain:consensusProtocol)

About Hyperledger Indy

Hyperledger Indy is the purpose-built distributed ledger project of what is now LF Decentralized Trust (the renamed successor to the Hyperledger Foundation, consolidated under that brand by the Linux Foundation in June 2024) providing the reference implementation of a Verifiable Data Registry (VDR) — a ledger optimised exclusively for the cryptographic anchoring of identity-related public objects (Decentralized Identifiers, credential schemas, credential definitions, and revocation accumulators) rather than general-purpose smart-contract execution or value transfer. Indy is the canonical infrastructure layer for the Self-Sovereign Identity (SSI) paradigm, in which natural persons, legal entities, and connected devices control their own identifiers and credential portfolios in personally-controlled wallets without dependence on a centralised identity provider (such as a national identity database, a social-login provider like Google or Facebook, or a federated identity broker).
The project’s intellectual lineage runs from the 2015 Rebooting the Web of Trust community (Christopher Allen’s “The Path to Self-Sovereign Identity” essay, April 2016, articulating the ten SSI principles), through the Sovrin Foundation (Utah non-profit incorporated September 2016 by Phil Windley as founding chair, Jason Law as CTO, Drummond Reed as Chief Trust Officer, and a board including Christopher Allen, John Jordan and Heather Vescent), which developed the Sovrin Trust Framework — a multi-party governance instrument defining steward responsibilities, transaction author/endorser separation, and economic incentives for permissioned validator operation. Sovrin contributed the foundational codebase to the Linux Foundation in September 2017 under the name “Hyperledger Indy,” joining Hyperledger Fabric (IBM), Sawtooth (Intel), Iroha (Soramitsu), and Burrow (Monax) as the fifth top-level Hyperledger project. Indy became the first Hyperledger project explicitly dedicated to identity rather than general-purpose enterprise blockchain.
In May 2019 the Hyperledger Aries project was spun out of Indy to allow agent/protocol development that was ledger-agnostic — recognising that the peer-to-peer credential exchange protocols, secure messaging (DIDComm), and wallet/agent reference implementations should not be coupled to a single VDR. This split is the most important architectural decision in Indy’s history: it positioned Indy as one of several possible verifiable data registries (alongside did:web, did:key, did:peer, and later did:webvh, did:plc, did:ion) that an Aries agent could resolve against, decoupling the credentialing protocols from the ledger choice. Hyperledger Ursa (later evolved into the Aries Shared Components — indy-vdr, indy-credx, askar, bbs-rs, anoncreds-rs) provided the shared cryptographic library spanning Indy, Aries and Fabric.
In April 2022 the new multi-network DID method did:indy was registered with the W3C DID Specification Registries (replacing the single-network did:sov method which had been increasingly seen as conflating the DID method with one specific network operator), enabling the did:indy:<namespace>:<id> format to address DIDs across federated Indy instances — did:indy:sovrin:Th7MpTaRZVRYnPiabds81Y, did:indy:indicio:6KTfb4d..., did:indy:idunion:eP7uK... — and ending the implicit equivalence between Indy and Sovrin that had constrained ecosystem development. Subsequent governance evolution included Sovrin Foundation transitioning to a more sustainable steward economic model, the emergence of Indicio (founded by Heather Dahl, Ken Ebert and Sam Curren in late 2020 from Evernym staff after Evernym was acquired by Avast in 2021 and subsequently absorbed into Gen Digital with the Indy/Aries product line effectively wound down by 2023) as a commercial steward operator, and the launch of the IDUnion German consortium production network (operated by IDunion eG cooperative from 2022 onwards under German Federal Ministry for Economic Affairs and Climate Action funding).
The deprecation of the original Indy SDK (“libindy”), announced October 2022 and completed by December 2023, marked a major code-base modernisation: the legacy monolithic C-callable shared object (which exposed Indy ledger, AnonCreds credential operations, and wallet storage through a single Python/Java/.NET/Go FFI surface) was replaced by the Aries Shared Components — a set of Rust-native libraries (indy-vdr for ledger interaction, indy-credx for AnonCreds v1 credential operations, askar for secure storage, anoncreds-rs for emerging AnonCreds v2 operations) that are individually composable, agent-framework-independent, and migrating progressively to a memory-safe systems-language foundation.
The contemporary stack (May 2026) comprises Indy Node (Python 3.6+ validator daemon implementing the Plenum consensus state machine), Indy VDR (Rust read-write client), Indy Credx (Rust AnonCreds v1 issuer/holder/verifier operations), Aries Askar (Rust secure-storage wallet replacing legacy libindy wallet), anoncreds-rs (forthcoming AnonCreds v2 implementation with BBS+ signatures over BLS12-381), and the Aries agent layer (ACA-Py for cloud issuers/verifiers, Credo / Aries Framework JavaScript for cross-platform agents, Bifold / Aries Mobile Agent React Native for citizen-facing wallets such as BC Wallet, Ontario’s wallet pilots, the IDUnion citizen wallet, and the Findy holder agent in Finland).

Architecture and Components

Hyperledger Indy implements a layered architecture in which the on-ledger state is deliberately minimal and the off-ledger state (private credentials, wallet contents, peer DIDs, agent-to-agent message traffic) is correspondingly rich. The architecture’s design rationale is explicit privacy-by-construction: nothing personally identifiable is ever written to the ledger.

Plenum Consensus Layer

Plenum is the Byzantine-fault-tolerant consensus protocol underlying Indy Node, implemented in Python and derived from the PBFT family (Castro-Liskov 1999). Plenum incorporates two key resilience improvements over canonical PBFT:

RBFT (Redundant BFT), drawn from Aublin-Mokhtar-Quéma 2013 (RBFT: Redundant Byzantine Fault Tolerance, ICDCS), which runs multiple protocol instances in parallel on each replica with one designated “master” and others “backup,” automatically electing a new master when the current one underperforms — providing liveness even when an adversarial primary throttles throughput maliciously.
Aardvark (Clement-Wong-Alvisi-Dahlin 2009, Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults, NSDI), which provides view-change resilience against denial-of-service from compromised replicas.

Plenum operates with a configurable steward quorum — typically f = 1 (4 stewards tolerating 1 fault) at minimum, scaling to f = 7 (25 stewards) for mature production networks like Sovrin MainNet. The quorum requirement is 3f + 1 total nodes to tolerate f Byzantine failures, consistent with the BFT impossibility result (Lamport-Shostak-Pease 1982).

Indy Node and Validator Operations

Indy Node is the Python 3.6+ daemon executing the Plenum state machine. Each steward operates one or more Indy Node instances on hardened infrastructure (typically Linux VMs with dedicated key-management hardware modules, geographic distribution across data centres, and 24/7 operations staffing). Indy Node persists ledger state in RocksDB, communicates between validators via ZeroMQ message-oriented transport, and exposes a read/write API to authorised clients via the Indy VDR client library.

Validator nodes — called stewards in Indy terminology — are admitted to the network through a governance process defined by the network’s trust framework. The Sovrin Governance Framework v2 (latest revision 2023) specifies steward qualifications including legal status (incorporated entity in good standing), technical capability (hardware specifications, operational staff, geographic distribution), agreement to the Sovrin Trust Framework Master Agreement, and execution of legal agreements binding stewards to operate honestly and transparently. Sovrin MainNet stewards historically have included IBM, Cisco, Deutsche Telekom, the Government of British Columbia, ATB Financial, the Republic of Estonia (briefly), the State of Illinois, and approximately two dozen other universities, enterprises and non-profits.

Ledger Object Types

Indy’s on-ledger state comprises four object families, each addressable by a deterministic identifier:
NYM (DID) transactions: register a public DID with its associated verification keys. NYMs may carry a role field (TRUSTEE, STEWARD, ENDORSER, NETWORK_MONITOR, or null for ordinary identity owners) that gates further write permissions under the network’s transaction authorization framework.
SCHEMA transactions: register a credential schema (a tuple of attribute names) published by an issuer. Schemas are versioned by (issuerDID, name, version) triples and are immutable once published.
CRED_DEF transactions: register a credential definition (an issuer’s CL-Signature public-key material bound to a specific schema, optionally with revocation support). CRED_DEFs allow holders and verifiers to retrieve the cryptographic parameters needed to construct or verify ZK proofs against credentials issued under that definition.
REVOC_REG_DEF and REVOC_REG_ENTRY transactions: register a revocation registry (the configuration of a cryptographic accumulator) and successive accumulator state updates as credentials are revoked. The accumulator design (drawn from Camenisch-Kohlweiss-Soriente 2009 Dynamic Accumulators and Applications to Efficient Revocation of Anonymous Credentials) enables verifiers to confirm a presented credential is not revoked without learning which specific credential was revoked.

Indy VDR and Client Libraries

Indy VDR (Verifiable Data Registry) is the modern Rust-language client library — superseding the deprecated Indy SDK — providing read/write access to Indy ledgers. Indy VDR exposes language bindings to Python, JavaScript, .NET, and Go via FFI, and is paired with indy-credx (for AnonCreds v1 credential operations) and aries-askar (for secure key/credential storage). The migration from libindy to the modular Aries Shared Components was completed across major agent frameworks by early 2024.

AnonCreds Protocol

AnonCreds (Anonymous Credentials) is the cryptographic credential protocol that distinguishes Indy from other VDRs. AnonCreds v1 is built around three primitives:
CL-Signatures (Camenisch-Lysyanskaya 2002, A Signature Scheme with Efficient Protocols, SCN): an RSA-based signature scheme supporting efficient ZK proofs of signature possession over committed attributes.
Pedersen Commitments (Pedersen 1991): for binding attribute values without disclosure.
Cryptographic Accumulators (Camenisch-Lysyanskaya 2002, dynamic variant Camenisch-Kohlweiss-Soriente 2009): for revocation state tracking with constant-size membership proofs.

The protocol enables a holder to construct a presentation that proves: (i) possession of a valid credential signed by a known issuer over a specified schema; (ii) selective disclosure of chosen attributes; (iii) predicate proofs over numeric attributes (e.g. age >= 18); and (iv) non-revocation as of a specified accumulator state — all without revealing any blinding factor, credential index, or non-disclosed attribute, and with cryptographic unlinkability across presentations to the same or different verifiers.

AnonCreds v2 (specification in working draft under the LF Decentralized Trust + DIF AnonCreds Specification Working Group, anticipated v2.0 release 2025-2026) replaces CL-Signatures with BBS+ signatures (Boneh-Boyen-Shacham 2004, Short Group Signatures, CRYPTO; refined Camenisch-Drijvers-Lehmann 2016 Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited, TRUST) operating over the BLS12-381 pairing-friendly elliptic curve. BBS+ enables substantially smaller proof sizes (~1KB versus several KB for CL-based proofs), faster verification, native multi-message signing, and improved holder-binding semantics; the migration also positions AnonCreds for interoperability with W3C Verifiable Credentials Data Model v2.0 (Recommendation May 2024) and DIF’s BBS+ Signature 2020 / BBS+ Signature 2023 cryptosuites.

Hyperledger Aries Companion Stack

Hyperledger Aries (split from Indy May 2019) provides the off-ledger components: the DIDComm secure messaging protocol (v1 over HTTP/WebSocket, v2 as a transport-agnostic envelope standardised at DIF in 2022), reference agent frameworks (ACA-Py, Credo (formerly Aries Framework JavaScript), Aries Framework .NET, Aries Mobile Agent / Bifold), and the Aries Interop Profiles that govern protocol compatibility between agent implementations.

Aries protocols (RFCs maintained at github.com/hyperledger/aries-rfcs, now github.com/openwallet-foundation/aries-rfcs) define peer-to-peer interaction patterns including Connection Protocol (DID-based pairwise relationship establishment), Issue Credential Protocol (issuer-to-holder credential delivery), Present Proof Protocol (verifier-to-holder proof request and holder-to-verifier proof presentation), and DIDComm Trust Ping, Out-of-Band, and Mediator/Coordination protocols for routing.

OpenWallet Foundation and Credo

Following the emergence of the OpenWallet Foundation in June 2023 (hosted by Linux Foundation Europe, founding members including Accenture, CVS Health, Deutsche Telekom T-Labs, Esatus, Futurewei, Gen Digital, IBM, Indicio, Ping Identity, SecureKey/Avast, Visa), the JavaScript-language Aries Framework was migrated to OpenWallet Foundation and renamed Credo (formerly Aries Framework JavaScript / AFJ). The Bifold mobile wallet (the React Native reference implementation underlying BC Wallet, Ontario Digital Identity wallet pilots, and several European deployments) was similarly migrated to OpenWallet Foundation governance, reducing direct dependency on Hyperledger Foundation infrastructure.

Use Cases / Major Families

Hyperledger Indy production deployments cluster into six dominant use-case families, each with distinctive governance, scale and economic characteristics.

Government Identity and Business Registration

The VON programme led by the Government of British Columbia (since 2017 under John Jordan, Stephen Curran, Cam Parra and team) is the canonical Indy production deployment. OrgBook BC publishes verifiable credentials for approximately 525,000 active legal entities in British Columbia, issued automatically when businesses incorporate or renew registrations with the BC Corporate Registry. Each credential anchors business name, incorporation number, jurisdiction, status, type, and (post-2023) selected officer attestations. The BC Wallet mobile holder agent (built on Aries Mobile Agent / Bifold) enables citizens and business representatives to receive and present credentials. Ontario, Alberta, and Quebec have launched parallel pilots; the federal Canadian Centre for Cybersecurity has endorsed the Pan-Canadian Trust Framework (PCTF) that aligns Indy/Aries deployments across provinces.

Internationally, the German IDUnion consortium (BMWK-funded, 35+ enterprise and federal-agency members) operates a production Indy network underpinning the citizen wallet pilot with multiple Länder (German federal states), corporate credentials from Deutsche Telekom, Daimler, Siemens, Bosch, and identity credentials linkable to the German national eID scheme. The Finnish Findy network (operated by the OP Lab / DIMECC consortium) supports cross-border credentials across the Nordic identity ecosystem.

Healthcare and Public Health Credentials

Indy/Aries was extensively deployed during the COVID-19 pandemic for vaccination credentials, test result credentials, and digital health passes. The Linux Foundation Public Health project, the Good Health Pass Collaborative (over 80 member organisations 2021), and ToIP Good Health Pass Drafting Group produced interoperability profiles. Notable deployments included IATA Travel Pass (initial Indy-based architecture, later evolved), SITA Health Protect, the Aruba Health App, several Caribbean nation pilots, and NHS Scotland exploratory pilots. Many jurisdictions ultimately adopted simpler barcode-based credentials (EU Digital COVID Certificate using JWS, SMART Health Cards), but the Indy-based pilots demonstrated technical scaling capability and informed subsequent EUDI Wallet architecture.

Aviation and Travel

IATA Travel Pass (developed 2020-2022 in partnership with Evernym/SecureKey and now-defunct entities) demonstrated air-travel credential flows over Indy. SITA (Société Internationale de Télécommunications Aéronautiques, the global aviation IT cooperative) maintains ongoing R&D into Indy-based air-traveller credentials. US Department of Homeland Security Science & Technology Directorate funded multiple SVIP (Silicon Valley Innovation Programme) cohorts including Indicio’s air-traveller credential pilot.

Enterprise Onboarding and KYC

Enterprise B2B onboarding scenarios — where one company verifies the regulatory and operational credentials of a counterparty — represent a strong Indy use case. esatus AG (Germany) provides enterprise SSI consultancy and the SeLF wallet, with deployments at major German manufacturers and financial institutions. MATTR (New Zealand) offers a hybrid Indy + did:web SSI platform. IDnow (Munich, listed firm) provides identity verification integrated with Indy/Aries flows. Trinsic (US) was a leading Indy SaaS provider until its 2023 pivot toward did:web + SD-JWT VC + mDoc; its migration is widely cited as evidence of market drift away from AnonCreds for general enterprise SSI.

Education and Professional Credentials

Universities and professional bodies have piloted Indy-based diploma credentials, micro-credentials, and professional licence credentials. The Digital Credentials Consortium (MIT-led, including UC Berkeley, Harvard, TU Delft, University of California Irvine) initially explored Indy and later pivoted to W3C VC + did:web for broader interoperability. Open Badges 3.0 (1EdTech specification) aligns with W3C VC but is not specifically Indy-coupled. Healthcare professional credentialing pilots exist at NHS Scotland, the Royal College of Physicians (UK exploratory work), and several European medical regulators.

Supply Chain and Provenance

Supply-chain credentialing — where suppliers prove regulatory compliance, sustainability attestations, and product provenance to downstream buyers — is an emerging Indy use case. The Trust Your Supplier (TYS) network operates a hybrid Hyperledger Fabric + Indy architecture for supplier credentialing. GS1 (the global product-identifier standards body) has explored Indy/Aries integration for product authenticity credentials. Anti-counterfeiting in pharmaceuticals, luxury goods, and industrial parts represents an active R&D area.

Cryptographic Foundations

Indy/AnonCreds depends on a specific stack of cryptographic primitives whose details determine the privacy and performance properties of the system. Understanding these primitives is essential for evaluating Indy against alternative credential formats.

CL-Signatures (AnonCreds v1)

Camenisch-Lysyanskaya signatures (CL-Sigs, Camenisch-Lysyanskaya 2002) are RSA-modulus-based signatures over multiple message blocks that admit efficient zero-knowledge proofs of signature possession. The CL signature is computed as σ = (A, e, v) where the signer commits to messages (m_1, ..., m_l) and outputs a triple satisfying A^e ≡ Z · S^v · R_1^{m_1} · ... · R_l^{m_l} (mod n) where n is an RSA modulus and (S, Z, R_i) are issuer public-key elements. A holder presenting a credential proves knowledge of (A, e, v, m_1, ..., m_l) satisfying this relation, optionally revealing some m_i while keeping others hidden via Pedersen commitments and Schnorr-style Σ-protocols.

CL-Sigs have the practical disadvantage of substantial proof size (8-15 KB per presentation), slow verification (typically 100-500 ms for a small attribute set), and reliance on RSA-modulus parameters that are less standardised than modern elliptic-curve cryptography.

BBS+ Signatures (AnonCreds v2)

BBS+ signatures (Boneh-Boyen-Shacham 2004, refined Camenisch-Drijvers-Lehmann 2016, with the IETF/DIF “BBS Signature Scheme” draft formalisation) operate over pairing-friendly elliptic curves (typically BLS12-381 — the curve used by Ethereum 2.0, Filecoin, Zcash Sapling, and Algorand) achieving compact proof sizes (~1 KB), fast verification (~5-15 ms), and native support for multi-message signing with selective disclosure. The BBS+ signature is σ = (A, e, s) over a pairing target group, with the verification equation e(A, X · g_2^e) = e(g_1 · h_0^s · ∏ h_i^{m_i}, g_2). Presentation proofs use Σ-protocols and the Fiat-Shamir heuristic for non-interactivity.

BBS+ enables AnonCreds v2 to interoperate with W3C VC v2 JSON-LD presentations using the BBS+ Signature 2023 Cryptosuite or Data Integrity BBS+ Cryptosuite profile, opening pathways for credentials that are simultaneously AnonCreds-compatible (for Indy verifiers) and W3C-VC-compatible (for did:web/did:key/did:webvh verifiers).

Pedersen Commitments

Pedersen Commitments (Pedersen 1991, Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing, CRYPTO) bind a value m to a commitment C = g^m · h^r where r is a random blinding factor. The commitment is information-theoretically hiding (perfectly conceals m) and computationally binding (cannot be opened to two different values without solving the discrete log problem). Pedersen commitments are used throughout AnonCreds to commit to attribute values during proof construction without revealing them.

Cryptographic Accumulators for Revocation

AnonCreds uses dynamic cryptographic accumulators (Camenisch-Kohlweiss-Soriente 2009) maintaining a compact representation V of the set of currently-valid credential indices. When a credential is issued, an index i is added to the accumulator; when revoked, it is removed. A holder maintains a witness W_i corresponding to their credential, which they can update against successive accumulator states (downloaded from the ledger’s REVOC_REG_ENTRY transactions). During presentation, the holder generates a ZK proof of membership of i in V without revealing i. The verifier learns “the credential is not revoked as of accumulator state V” but not which specific credential is being presented.

Accumulator-based revocation provides strong privacy properties (no revocation list correlation) but imposes operational burden on holders (witness updates require periodic ledger queries) and on issuers (tails files must be maintained and distributed). Recent AnonCreds v2 work explores accumulator alternatives including status lists (W3C VC Status List 2021) and tree-based revocation registries for simpler implementation at the cost of some unlinkability.

Networks and Ecosystem

Indy operates under a multi-network model where independent organisations operate parallel ledgers each governed by their own trust framework. As of May 2026 the major production and pilot networks include:

Sovrin Networks

Sovrin MainNet: The original public-permissioned production network, operational since 2017, governed by the Sovrin Foundation under the Sovrin Governance Framework v2 (2023 revision). Approximately 15-20 active stewards including IBM, Cisco, Deutsche Telekom (historically), ATB Financial, and university partners.
Sovrin StagingNet: Pre-production testing environment mirroring MainNet configuration.
Sovrin BuilderNet: Open-access development network for early-stage projects.

Indicio Networks

Operated by Indicio.tech (Washington DC, founded 2020 by Heather Dahl, Ken Ebert, Sam Curren after Evernym/Avast acquisition reorganisations):
Indicio MainNet: Production network supporting IATA, SITA, US DHS pilots, several Caribbean nation health credential systems, and enterprise customers.
Indicio TestNet and Indicio DemoNet.

IDUnion (Germany)

German consortium production network operated by IDunion eG (cooperative) since 2022, funded initially by the BMWK (Federal Ministry for Economic Affairs and Climate Action) Schaufenster Sichere Digitale Identitäten programme. Member organisations include Deutsche Telekom, Bosch, Daimler/Mercedes-Benz, Siemens, Robert Bosch, Festo, Allianz, Commerzbach, Deutsche Bahn, Spherity, esatus, Main Incubator. IDUnion is the leading European production Indy deployment and a key influence on EUDI Wallet architecture choices.

Findy (Finland)

Operated by the OP Lab (OP Financial Group, Finland’s largest financial-services cooperative) and DIMECC with academic partners VTT and University of Helsinki. Supports cross-Nordic identity pilots.

CANdy (Canada) and BCovrin (BC Government)

CANdy is the pan-Canadian production Indy network operated by the Canadian Working Group on SSI with stewards across federal and provincial governments. BCovrin is the British Columbia Government’s test network supporting OrgBook BC, the BC Wallet, and Canadian provincial pilots.

Other Regional and Vertical Networks

Including the Greenlight Network (US enterprise), Indy Builder Networks for development, various university-operated test networks (TU Delft, Imperial, UCL exploratory deployments), and corporate-internal Indy ledgers operated for specific consortium use cases.

Comparison with Alternative DID Methods and Credential Formats

Indy/AnonCreds occupies a specific niche in the DID method and credential format landscape. Understanding the trade-offs against alternatives is essential for architecture decisions.

vs. did:web

did:web is the registry-light alternative most directly competing with did:indy for organisational issuer scenarios. did:web resolves DIDs via HTTPS GET requests against https://<domain>/.well-known/did.json, leveraging existing TLS PKI and web-hosting infrastructure. Advantages over Indy: zero ledger operational cost, immediate deployment, no governance framework required, alignment with prevailing web identity infrastructure. Disadvantages: trust depends on TLS certificate authority and web-host operational security (single domain compromise corrupts all DIDs under that domain); no native unlinkable credentials (correlation prevention requires extra cryptographic machinery); historical key versions are not cryptographically anchored unless paired with did:webvh extensions; no public-permissioned governance to constrain issuer behaviour. Recommended where the issuer is itself a well-known authority (government department, accredited university, regulated financial institution) and unlinkability is not a hard requirement.

vs. did:webvh

did:webvh (did:web with verifiable history, standardised under OpenWallet Foundation 2024) extends did:web with a cryptographically verifiable log of key rotations and DID document updates, addressing the key-rotation auditability gap. The resolver verifies the entire history chain rather than only the current state, providing tamper-evidence for historical credential issuance contexts. did:webvh has emerged 2024-2026 as the preferred alternative for organisational issuers requiring history verifiability without operating a dedicated ledger.

vs. did:key and did:peer

did:key encodes a public key directly in the DID string (no resolution required), suitable for ephemeral and connection-specific scenarios. No key rotation, no revocation, no service endpoints. did:peer extends did:key with off-ledger pairwise DID document exchange for stable connection-specific identifiers. Both are widely used within Aries DIDComm for connection establishment and ephemeral interactions but are not substitutes for an issuer-anchoring registry.

vs. did:plc

did:plc (Public Ledger of Credentials) is the AT Protocol DID method underlying Bluesky’s federated social network. Currently single-operator (Bluesky PBC) but architected for distribution. did:plc provides DID key rotation and history but operates under a different governance model (commercial federated social media) than Indy’s public-permissioned identity infrastructure framing. Not directly competitive in enterprise identity scenarios but illustrates the diversity of DID method governance models.

vs. did:ion and Sidetree

did:ion is Microsoft’s Sidetree-on-Bitcoin DID method (Layer 2 protocol using Bitcoin as anchoring layer for batched DID operations). Microsoft Entra Verified ID (formerly Azure AD Verifiable Credentials) launched on did:ion in 2022. did:ion provides decentralised anchoring with Bitcoin’s security model but inherits Bitcoin’s throughput limitations and operational complexity. Microsoft Entra Verified ID uses W3C VC + JWS format (not AnonCreds), reflecting Microsoft’s strategic alignment with W3C/IETF rather than Hyperledger.

vs. did:ethr

did:ethr registers DIDs against an Ethereum smart contract registry. Used in the uPort / Veramo lineage and various decentralised identity wallets. Inherits Ethereum’s transaction-cost model (gas fees) and smart-contract programmability. Different governance and economic model from Indy’s permissioned-validator approach.

vs. SD-JWT VC

SD-JWT VC (Selective Disclosure JWT for Verifiable Credentials, IETF draft by Fett-Yasuda-Campbell) represents a credential as a JWT with a mechanism for selective disclosure of individual claims. Advantages over AnonCreds: standard IETF infrastructure (JWT, JWS, JWK), broad library support, simpler implementation, no specialised cryptography beyond JWS. Disadvantages: presentations are linkable across verifiers (no unlinkability), requires issuer-side per-presentation disclosure-instructions or holder-side salt management for true selective disclosure, no native predicate proofs. SD-JWT VC was selected for the EUDI Wallet primary VC format, marking the most significant strategic event for AnonCreds positioning.

vs. mDoc / mDL (ISO/IEC 18013-5)

mDoc (mobile document, generalising the mobile driving licence) is the ISO/IEC standardised credential format for high-assurance government identity documents. Uses CBOR (Concise Binary Object Representation) encoding with COSE signatures, supports selective disclosure via salted hashes of individual data elements, and provides device-binding via secure-element-resident keys. mDoc is the standard for digital driving licences globally (US states issuing under AAMVA mDL specification, EU member states under EUDI Wallet) and provides high-assurance ISO-certified deployment with smart-card-vendor ecosystem integration (Bundesdruckerei, Thales, IDEMIA). Like SD-JWT VC, mDoc presentations are linkable across verifiers; the cryptographic profile prioritises performance and verifier ecosystem compatibility over unlinkability.

vs. Atala PRISM

Atala PRISM is Input Output Global’s (IOG, the Cardano blockchain developer) DID method anchored on Cardano. Functionally similar to did:indy in scope but operating on the Cardano UTXO ledger rather than a dedicated identity-purpose ledger. Adoption has been limited, with Atala PRISM more visible in IOG-led pilots (Ethiopia education credentialing 2021-2023) than in independent enterprise deployments.

Choosing Between Options

The architectural decision framework as of 2026:

Choose Indy/AnonCreds when (i) holder unlinkability across verifiers is a hard requirement (high-privacy government identity, sensitive health credentials, regulated industries with anti-discrimination concerns), (ii) predicate proofs over numeric attributes are needed (age verification without birthdate disclosure), (iii) the deployment can sustain operational complexity of a permissioned validator network, and (iv) integration with existing Aries-based ecosystems (BC Wallet, IDUnion, Indicio) provides leverage.
Choose SD-JWT VC + did:web/did:webvh when (i) the issuer is a well-known web authority, (ii) implementation simplicity outweighs unlinkability, (iii) IETF/W3C standardisation alignment is essential (EU EUDI Wallet, IETF privacy-preserving identity), or (iv) integration with general-purpose JWT/OAuth infrastructure is required.
Choose mDoc / mDL when high-assurance ISO-certified government identity is required (driver’s licence, national identity, age verification at point-of-sale) and secure-element device-binding is critical.

Implementation Considerations

Deploying Hyperledger Indy in production requires careful attention to technical, organisational, and operational dimensions.

Technical Requirements

Validator (Steward) Infrastructure: Each steward requires dedicated server infrastructure typically comprising 8-16 CPU cores, 32-64 GB RAM, 1-4 TB SSD storage, 1-10 Gbps network connectivity, with 24/7 monitoring and 99.5%+ availability commitments. Geographic distribution across regions is required by most Indy network governance frameworks to ensure fault-tolerance. Hardware costs typically range £2,000-£10,000 monthly per steward node when fully loaded (infrastructure + operations + insurance + governance participation).
Cryptographic Operations: AnonCreds v1 credential issuance requires CL-Signature operations on the issuer side (computationally moderate, RSA-modulus operations); proof generation on the holder side is heavier (several hundred ms for typical attribute sets on smartphone hardware); verification on the verifier side is comparable to issuance. AnonCreds v2 with BBS+ reduces all three costs by approximately 10x.
Wallet Storage: Holder wallets must securely store private keys, link secrets (the holder-side master secret used in AnonCreds credential binding), credentials, and connection records. Aries Askar provides encrypted SQLite-backed storage with optional integration with hardware security modules (HSMs), iOS Keychain / Secure Enclave, Android KeyStore, or platform secure-element APIs.
Agent Frameworks: Production deployments typically use ACA-Py (cloud issuers and verifiers), Credo (cross-platform client-side agents), and Bifold (mobile holder wallets). Each framework requires version management, security patching, and dependency tracking.

Organisational Readiness

SSI represents a significant paradigm shift from centralised or federated identity. Organisations adopting Indy/Aries must:
Educate Stakeholders: SSI concepts (holder control, issuer-verifier separation, unlinkability) differ substantially from centralised identity. Internal training for product managers, security architects, legal counsel, compliance officers, and operations staff is essential. Industry training programmes (ToIP Foundation training, Indicio’s “SSI Bootcamp”, LFDT educational content) provide foundations.
Develop Issuer Policies: Define which credentials to issue, attribute schemas, refresh and revocation policies, dispute resolution, and liability boundaries. Policies must address holder credential loss, key recovery, and re-issuance scenarios.
Plan Verifier Integration: Verifiers must integrate proof-request flows into existing business processes (account opening, age verification, regulatory compliance checks). Integration complexity varies from simple REST API calls into Aries verifier agents to deep embedding in identity-and-access management platforms.
Governance Participation: Joining an existing Indy network (Sovrin, Indicio, IDUnion) requires legal agreement to that network’s governance framework, including financial obligations and operational commitments.

Cost Considerations
Network operators (stewards): Infrastructure £2,000-£10,000 monthly per validator + staffing for operations (typically 0.5-1.0 FTE per steward) + governance participation costs (steward fees, legal review, audit). Total cost-of-ownership £100,000-£500,000 annually per steward at production scale.
Credential issuers: Development cost £50,000-£500,000 depending on scope, plus ongoing maintenance (10-25% of initial cost annually). Wallet provider costs typically £5-25 per active user annually for cloud-hosted wallet-as-a-service.
Verifiers: Implementation cost £25,000-£250,000 depending on existing identity infrastructure. Per-verification transaction costs typically zero or nominal.
Transaction fees on Indy ledgers: Sovrin MainNet historically used Sovrin Tokens but the tokenised access model was deprecated in favour of fee-free operation funded by stewards’ altruistic / mission-aligned participation. Most Indy networks operate fee-free at the ledger layer.

Timeline

Typical Indy production deployment timelines:
Proof-of-concept (issuer + holder + verifier flows on a test network): 4-8 weeks with experienced team.
Pilot deployment (small user population, controlled scenarios): 6-12 months.
Production deployment at scale: 12-24 months including governance framework integration, security audit, regulatory compliance review, and user onboarding ramp.
Network operator deployment (new steward joining an existing network): 3-6 months from agreement to operational steward status.

Challenges and Limitations

Hyperledger Indy faces persistent technical, organisational, and strategic challenges that constrain adoption.

Technical Challenges

Cryptographic Complexity: AnonCreds v1 cryptography is sophisticated and not widely understood outside specialist communities. The CL-Signature stack involves RSA-modulus parameters, Schnorr-style Σ-protocols, Pedersen commitments, and accumulator constructions — each requiring careful security analysis. Bugs in cryptographic implementations have material privacy consequences. The migration to AnonCreds v2 with BBS+ improves but does not eliminate this complexity.
Key Management for Holders: Loss of wallet private keys means loss of credential access. Recovery mechanisms (cloud backup, social recovery using Shamir Secret Sharing or threshold signatures, custodial recovery via trusted parties) exist but introduce trade-offs between security and recoverability. The mobile-wallet UX challenge is significant and remains under active development.
Throughput Limitations: Plenum consensus scales to dozens of transactions per second for writes (DID/schema/cred-def/revocation registry updates) — substantially below high-throughput permissioned ledgers (Fabric, Quorum) and far below registry-light alternatives. Reads scale well through caching but write capacity constrains large-issuer deployments.
Revocation Operational Complexity: AnonCreds revocation accumulators require holder-side witness updates (periodic ledger queries to fetch accumulator state) and issuer-side tails-file maintenance and distribution. Operational complexity has limited adoption of revocable credentials versus simpler non-revocable issuance, with status-list alternatives gaining traction.

Organisational and Adoption Challenges
Chicken-and-Egg Network Effects: SSI ecosystems require simultaneous adoption by issuers (motivating wallet adoption), holders (motivating verifier integration), and verifiers (motivating issuer participation). Early adopters face limited utility until critical mass is achieved. Government-led deployments (BC Gov, IDUnion) have demonstrated bootstrap pathways but commercial-only ecosystems have struggled.
User Experience Complexity: Wallet management, credential backup, key rotation, and credential presentation flows present user-interface challenges substantially harder than centralised identity (where the user simply logs into a familiar provider). Sustained UX investment is required, with most projects underestimating effort.
Governance Coordination: Multi-stakeholder networks (stewards, issuers, holders, verifiers, governance authorities) require coordination across competing interests. The Sovrin Foundation’s challenges sustaining steward economic viability illustrate the governance-economics tension.
Regulatory Uncertainty: Many jurisdictions have not explicitly addressed SSI in their identity regulatory frameworks. EU EUDI Wallet provides clarity but at the cost of selecting non-AnonCreds formats. UK DIATF is progressive but does not specifically endorse AnonCreds.

Strategic and Ecosystem Challenges
EUDI Wallet AnonCreds Exclusion: The most significant strategic challenge. EUDI Wallet rollout (mandatory November 2026) establishes SD-JWT VC + mDoc as the European identity standard, materially reducing AnonCreds addressable market in the largest single SSI deployment globally.
Trinsic Pivot Signal: Trinsic’s 2023 decision to move away from Indy/AnonCreds was widely interpreted as a market signal favouring lighter stacks for general enterprise SSI.
Light DID Method Competition: did:web, did:webvh, did:key, did:peer, did:plc, did:ion, did:ethr all reduce the rationale for a dedicated Indy ledger in scenarios where unlinkability is not the dominant privacy requirement.
Hyperledger Foundation Consolidation: The June 2024 rebrand to LF Decentralized Trust signals strategic broadening that could either revitalise Indy (positioning alongside W3C/IETF/ISO trust technologies) or marginalise it (subsumed into broader VDR abstraction layers).

Security and Privacy Concerns
Compromised Issuer Risk: An issuer with compromised credential-definition private keys can mint fraudulent credentials indistinguishable from legitimate ones. Issuer reputation systems, governance frameworks, and revocation mechanisms mitigate but do not eliminate this risk.
Quantum Computing Threats: Both CL-Signatures (RSA-based) and BBS+ (pairing-based) are vulnerable to large-scale quantum computers via Shor’s algorithm. Long-term cryptographic migration to post-quantum anonymous credentials is required but specifications are not yet mature.
Correlation Attacks: Malicious verifiers attempting cross-presentation correlation through metadata, timing, or out-of-band channels can partially defeat AnonCreds unlinkability. User-interface design and verifier behavioural constraints are required complements to cryptographic unlinkability.
Validator Collusion: Although BFT consensus tolerates f of 3f+1 Byzantine validators, collusion among more than f stewards could compromise the ledger. Governance frameworks address this through validator diversity requirements but residual risk exists.

Academic Context

Indy and AnonCreds occupy a distinctive position in the academic literatures of cryptography, distributed systems, identity, and digital rights.

Cryptographic Foundations

The CL-Signature scheme (Camenisch-Lysyanskaya 2002) and its predecessors (Camenisch-Stadler 1997, Brands 2000) form the academic backbone of AnonCreds v1, with subsequent extensions for delegation (Belenkiy-Camenisch-Chase 2009), constant-size proofs (Camenisch-Lysyanskaya 2004), and accumulator-based revocation (Camenisch-Kohlweiss-Soriente 2009). The BBS+ literature (Boneh-Boyen-Shacham 2004, Camenisch-Drijvers-Lehmann 2016) underpins AnonCreds v2.

Anonymous credentials research extends to U-Prove (Microsoft, drawn from Brands’ work, productised in Microsoft Identity Manager but largely dormant), Idemix (IBM, the original CL-credential implementation, productised in IBM Identity Mixer and contributed to Hyperledger Fabric for Fabric’s MSP), Privacy Pass (Cloudflare, IETF anonymous tokens), and the IETF Privacy-Preserving Measurement WG’s recent work on anonymous credentials for federated analytics.

Distributed Systems Theory

Plenum sits in the PBFT lineage (Castro-Liskov 1999, Yin et al. 2018 HotStuff, Buchman 2016 Tendermint, Buterin-Griffith 2017 Casper FFG) of leader-based partially-synchronous BFT consensus. The RBFT (Aublin-Mokhtar-Quéma 2013) and Aardvark (Clement et al. 2009) variants address fault-tolerance under faulty primaries. Recent BFT literature (e.g. Stathakopoulou et al. 2022 Mir-BFT, Gelashvili et al. 2022 Jolteon, Spiegelman et al. 2022 Bullshark, Danezis et al. 2022 Narwhal) has overtaken Plenum in throughput optimisation but Plenum remains a deployed reference for permissioned identity ledgers.

Self-Sovereign Identity Theory

Foundational SSI literature includes Christopher Allen’s “Path to Self-Sovereign Identity” (2016), Phil Windley’s “Sovrin: A Protocol and Token for Self-Sovereign Identity and Decentralized Trust” (2018 white paper), Drummond Reed and Manu Sporny’s W3C DID work (W3C DID Core 1.0 Recommendation July 2022), and Kim Cameron’s Laws of Identity (2005, foundational user-centric identity principles). The book “Self-Sovereign Identity: Decentralized Digital Identity and Verifiable Credentials” edited by Alex Preukschat and Drummond Reed (Manning 2021) is the most-cited canonical text.

Critical literature on SSI includes Bruce Schneier’s “Self-Sovereign Identity is Hard” (2020 blog series), Andrew Hughes’ critique of the SSI / federated-identity dichotomy, and the academic Aleecia McDonald and Lorrie Cranor work on usability of consent and credential UIs.

Privacy Economics

The economic case for unlinkable credentials draws on Acquisti-Brandimarte-Loewenstein (2015 Privacy and Human Behavior in the Age of Information, Science) and Solove’s “The Digital Person” (2004, foundational privacy law text). The Marc Rotenberg / EPIC advocacy lineage and Carissa Véliz’s “Privacy Is Power” (2020) inform regulatory discourse around AnonCreds-style data minimisation.

Current Landscape (2026)

As of May 2026, Hyperledger Indy occupies a complex strategic position: technically the most sophisticated production VDR for unlinkable credentials, but commercially under structural pressure from registry-light DID methods and the EUDI Wallet’s selection of SD-JWT VC and mDoc.

Hyperledger Foundation Consolidation into LF Decentralized Trust

In June 2024 the Linux Foundation consolidated Hyperledger Foundation, the Trust over IP Foundation infrastructure projects, and certain other identity-adjacent initiatives under a new umbrella brand, LF Decentralized Trust (LFDT). Indy remains a top-level project within LFDT alongside Hyperledger Fabric, Besu, Aries (now governed jointly with OpenWallet Foundation), and the Trust over IP technology stack projects. The rebrand reflects a strategic broadening from blockchain-centric framing toward “decentralized trust technologies” more broadly, including verifiable credentials, DIDs, secure messaging, and trust frameworks.

Indy SDK Deprecation Complete

The deprecation of the legacy Indy SDK (“libindy”) announced October 2022 was completed by December 2023, with the modular Aries Shared Components (indy-vdr, indy-credx, aries-askar, anoncreds-rs) replacing the monolithic library across major agent frameworks (ACA-Py, Credo, Bifold). Production deployments completed SDK migration through 2024-2025.

Migration to ACA-Py and OpenWallet Foundation Governance

The dominant agent framework Aries Cloud Agent Python (ACA-Py) — originally contributed by the Government of British Columbia in 2018, maintained by an international maintainer community — was migrated to OpenWallet Foundation governance in 2024, alongside the JavaScript framework Credo (formerly AFJ) and the Bifold mobile wallet. This shift moves operational governance away from Hyperledger Foundation while retaining technical interoperability with Indy ledgers.

Competition from Light DID Methods

Indy faces structural competition from DID methods that require no dedicated ledger:

did:web: HTTPS-resolved DIDs hosted on standard web servers. Trivial to deploy, no consensus required, but trust depends on TLS PKI and web-host operational security. Dominant for organisational issuers (universities, employers, governments) where the issuer already operates an authoritative web presence.
did:webvh (did:web with verifiable history): adds tamper-evident history log to did:web for resolver-side verification of key rotation. Standardised under OpenWallet Foundation, gaining traction 2024-2026.
did:key: ledger-free DIDs derived from a single public key. Used heavily for ephemeral and peer-pairwise scenarios. No revocation, no key rotation.
did:peer: off-ledger pairwise DIDs for connection-specific relationships. Aries native, used inside DIDComm.
did:plc: Bluesky’s AT Protocol public ledger of credential records. Federated, currently single-operator but designed for distribution.
did:ion: Microsoft’s Sidetree-on-Bitcoin DID method (Layer 2 over Bitcoin). Microsoft Entra Verified ID launched on did:ion in 2022.
did:ethr: Ethereum-based DID method. Used in uPort/Veramo lineage.

The market trend 2023-2026 has been toward registry-light DID methods for most use cases, with Indy retained for high-assurance unlinkable-credential scenarios where AnonCreds privacy properties justify operational complexity.

EUDI Wallet Architecture Reference Framework

The most significant strategic blow to AnonCreds adoption came from the European Digital Identity Wallet Architecture Reference Framework (ARF). Under Regulation (EU) 2024/1183 (eIDAS 2.0, in force May 2024, mandatory wallet rollout November 2026), each EU Member State must offer citizens an EUDI Wallet. The ARF (v1.3 published February 2024, subsequent updates through 2025) explicitly selected:
SD-JWT VC (Selective Disclosure JWT for Verifiable Credentials, IETF draft, Fett-Yasuda-Campbell) as the primary VC format for general identity attestations.
ISO/IEC 18013-5 mDoc / mDL (mobile driving licence / mobile documents) for high-assurance government identity attestations (PID, driver’s licence, age verification).

AnonCreds was not selected for the EUDI Wallet, reflecting (i) the standards-body preference for IETF/ISO over Hyperledger-originated specifications, (ii) the perceived operational complexity of AnonCreds accumulator-based revocation versus simpler status-list approaches, (iii) the lower performance of CL-signatures, and (iv) the political weight of national identity infrastructure providers (Bundesdruckerei, Thales, IDEMIA, Gemalto/Thales DIS) historically aligned with smart-card / mDoc cryptography. The decision substantially reduced the addressable market for AnonCreds-only deployments across the EU.

Trinsic Pivot and Market Signals

Trinsic (US SSI-as-a-service, founded 2019 by Riley Hughes and Tomislav Markovski as a spin-out from Evernym) announced in June 2023 a strategic pivot away from Indy and AnonCreds toward did:web + SD-JWT VC + mDoc, citing customer demand and EUDI Wallet alignment. The Trinsic pivot — widely covered in identity industry press and conference circuits — is the most-cited market signal of AnonCreds adoption headwinds. In late 2023 / 2024 Trinsic acquired Truvity (Dutch SSI startup) and continued evolving its platform on the lighter stack.

Indy/AnonCreds Defensive Positioning

Despite headwinds, Indy/AnonCreds retains material relevance in:
Government deployments with installed base (BC Gov, Ontario, Quebec, IDUnion German Länder).
High-assurance regulated industries (aviation, healthcare, regulated B2B onboarding) where AnonCreds unlinkability properties justify operational complexity.
Cross-border credential recognition scenarios where multiple national wallets must verify foreign-issued credentials with strong privacy.
AnonCreds v2 with BBS+ offering substantially improved performance and W3C VC v2 interoperability, potentially restoring competitiveness for scenarios where unlinkability is essential.

The strategic question through 2026-2028 is whether AnonCreds v2 + BBS+ + W3C VC v2 alignment can re-position Indy as a credible third pole alongside SD-JWT VC and mDoc, or whether AnonCreds will remain a niche scheme for specialised deployments while the mainstream consolidates on SD-JWT VC + mDoc.

UK Context: Academic Research, ToIP Foundation Members, and Industrial Pilots

The United Kingdom hosts a moderate but high-quality Indy/SSI research and pilot ecosystem concentrated in London, Edinburgh, Cambridge and Manchester.

Academic Research

Imperial College London (Centre for Cryptocurrency Research and Engineering, IC3RE): Active research on Bitcoin, Ethereum, smart-contract security, and identity. Researchers including William Knottenbelt (founding Director), Catherine Mulligan (CONNECT Centre Imperial-LSE-Westminster), Yvonne-Anne Pignolet (formerly DFINITY, now Imperial / DSO). Imperial’s Centre for Digital Finance hosts Lukasz Szpruch (also Programme Director at The Alan Turing Institute), Andrei Kirilenko (former CFTC Chief Economist), and Pasquale Della Corte with research touching corporate digital identity and verifiable credentials.

University College London (Centre for Blockchain Technologies, UCL CBT): Founded 2015 by Paolo Tasca, approximately 30 affiliated researchers across UCL Computer Science, Economics, and Laws. UCL CBT hosts the annual DLT Talks conference covering DID/VC topics with academic, regulatory and industry contributors. UCL Information Security Group (ISG) research on cryptographic protocols underpinning anonymous credentials.

University of Cambridge (Cambridge Centre for Alternative Finance, CCAF, at Judge Business School): World-leading academic centre founded 2015 by Bryan Zhang. The CCAF’s annual Global Cryptoasset Benchmarking Study and adjacent Digital Asset Map track production identity deployments globally. Cambridge Computer Laboratory cryptography group (Ross Anderson historically until 2024, Markus Kuhn) on identity and privacy protocols.

University of Edinburgh (Blockchain Technology Laboratory, Informatics): Aggelos Kiayias (Chair in Cyber Security and Privacy), Markulf Kohlweiss (co-author of the Camenisch-Kohlweiss-Soriente accumulator paper underpinning AnonCreds revocation, joined Edinburgh 2017). Kohlweiss’s presence at Edinburgh makes the institution a particularly important UK academic node for AnonCreds-specific cryptography. Recent EPSRC-funded research on anonymous credentials, blockchain privacy, and applied cryptography.

University of Manchester (Alliance Manchester Business School, AMBS): Research on digital identity policy and FinTech adoption. Connections to the Manchester Digital trade association and the Greater Manchester Combined Authority digital strategy.

King’s College London (Centre for Doctoral Training in Cybersecurity): Cryptographic research and policy intersections.

University of Leeds (Centre for Decentralised Digital Economy, CEDDE) and Leeds Beckett: Northern English centre for blockchain and SSI research with industry connections through FinTech North Leeds.

University of Sheffield (Centre for Information and Business Law): Legal and regulatory research on digital identity, GDPR compliance.

Newcastle University (Newcastle Cyber Security Centre): Aad van Moorsel (Director), Maryam Mehrnezhad on privacy, identity, and applied cryptography. Newcastle is part of the GCHQ Academic Centres of Excellence in Cyber Security Research network.

Northern English Industrial Context: Manchester, Leeds, Sheffield and Newcastle host an emerging FinTech industrial cluster — FinTech North (Manchester/Leeds), the Northern Powerhouse policy framework, Greater Manchester’s CyberFirst schools programme, and Newcastle’s National Innovation Centre for Data — that complements the London-centric financial services cluster. SSI pilots in Northern English cities are emerging in local-authority service delivery, NHS Trust patient credentials (Leeds Teaching Hospitals NHS Trust, Manchester University NHS Foundation Trust pilots exploring patient-controlled credential frameworks), and university student credentialing.

ToIP Foundation UK Members and Industry

The Trust over IP Foundation (ToIP, hosted by Linux Foundation since 2020 as the cross-vendor governance home for SSI technology and governance frameworks) has multiple UK members:

esatus UK (German-headquartered but with UK presence): Enterprise SSI consultancy and the SeLF wallet implementation.
Cheqd (UK headquarters, London): SSI infrastructure and tokenisation, founded by Fraser Edwards and Ankur Banerjee, ToIP active participant.
Condatis (Edinburgh): Identity software firm with FCAS-accredited identity proofing, ToIP working-group contributor.
Mattereum (London, Vinay Gupta): Asset-backed token and credentialing infrastructure.
PayDevs / PortalPay and assorted UK SSI startups.

Open Identity Exchange (OIX): London-headquartered identity industry body chaired (historically) by Don Thibeau and currently by Nick Mothershaw. OIX runs the Identity Trust Framework working groups and publishes the Global Identity Index annual report. OIX London events are the primary UK identity-industry convening venue. OIX members include major UK banks (HSBC, Barclays, Lloyds, NatWest), telecommunications operators (BT, Vodafone, EE), and government identity stakeholders (DCMS / DSIT Cabinet Office Digital Identity team).

UK Government Digital Identity (GOV.UK One Login and DIATF): The UK government’s One Login for Government programme (operated by Government Digital Service / GDS in the Cabinet Office, now Department for Science, Innovation and Technology, DSIT) does not use Hyperledger Indy directly; it implements an OAuth/OIDC-based identity scheme with selective integration of credential verification. However, the UK Digital Identity and Attributes Trust Framework (DIATF) — published in beta 2021 by DCMS and progressively refined through 2024-2025 — has accommodated SSI-style credential issuers within its certified provider pool, with OneID (UK bank-driven digital identity, with Tide, OakNorth, NatWest, Lloyds, HSBC participation) and other certified providers exploring SSI credential issuance modes including AnonCreds-compatible flows.

NHS Scotland Pilots: NHS Scotland has run exploratory SSI pilots with patient-controlled health credentials, working with Edinburgh academic partners and Scottish Government Digital Directorate.

UK FCA and Regulatory Stance

The Financial Conduct Authority (FCA) has not issued specific guidance on Indy/AnonCreds but the broader UK regulatory framework supports SSI deployment:
UK GDPR / Data Protection Act 2018: AnonCreds data-minimisation properties align with Article 5(1)(c) data-minimisation principle and Article 25 data-protection-by-design and by-default.
DIATF (Digital Identity and Attributes Trust Framework): Provides certification pathway for identity service providers including potential SSI verifier and issuer accreditation.
Information Commissioner’s Office (ICO): Published guidance on age verification and selective disclosure (2022-2024) recognising AnonCreds-style ZKP approaches favourably.

Future Directions (2026-2030)

Indy’s strategic trajectory through 2026-2030 is shaped by four overlapping vectors.

AnonCreds v2 Specification and BBS+ Migration

The AnonCreds v2 specification (under LF Decentralized Trust + DIF AnonCreds Specification Working Group) is anticipated to reach v2.0 release status in 2025-2026, with implementations in anoncreds-rs and integrated into ACA-Py, Credo and Bifold. The migration from CL-Signatures to BBS+ over BLS12-381 enables:

Proof size reduction (~1 KB versus 8-15 KB for v1).
Verification performance improvement (~5-15 ms versus 100-500 ms).
W3C VC v2 interoperability via BBS+ Signature 2023 Cryptosuite and Data Integrity BBS+ profiles, enabling AnonCreds credentials to be verified by W3C-VC verifiers without Indy-specific software.
Holder binding improvements addressing key-hijack scenarios.

The success of AnonCreds v2 in restoring Indy competitiveness depends critically on adoption by major government deployments (BC Gov, Ontario, IDUnion) and on parallel acceptance by EUDI Wallet member states for high-assurance use cases.

EUDI Wallet Interoperability Profiles

Through 2026-2028 the EUDI Wallet ARF will evolve to specify interoperability profiles for AnonCreds-compatible credentials issued by non-EU jurisdictions (e.g. Canadian provincial credentials, US state credentials, UK DIATF certified credentials) that may need to be presented to EUDI Wallet verifiers and vice versa. The ISO/IEC 18013-7 mDL Cross-Jurisdictional Recognition and parallel W3C VC + DIDComm protocols will shape Indy’s interoperability surface.

Hyperledger Foundation → LF Decentralized Trust Strategic Evolution

LFDT’s broader scope (decentralized trust technologies beyond blockchain) creates space for Indy/Aries to be positioned alongside non-ledger trust technologies (KERI, did:webvh, OpenID Federation 1.0) rather than competing solely within the blockchain frame. The strategic decision through 2026-2030 is whether Indy remains a discrete top-level LFDT project or is gradually absorbed into a broader “verifiable data registry” abstraction layer that supports multiple backend ledgers and registries.

Quantum Resistance and Long-Term Cryptography

Both CL-Signatures and BBS+ over BLS12-381 are vulnerable to large-scale quantum computers (Shor’s algorithm breaks RSA, ECDLP, and pairing-based cryptography). Long-term Indy planning must consider migration to post-quantum anonymous credentials — an active research area including lattice-based schemes (BBS Lattice variants), code-based credentials, and isotopic approaches. NIST’s post-quantum cryptography standardisation (FIPS 203/204/205 published 2024) provides post-quantum primitives but not yet anonymous-credential constructions; specialised research (e.g. del Pino-Lyubashevsky-Seiler 2018, Beullens-Dobson-Katsumata-Lai-Pintore 2021) is ongoing.

Sovereign Wallet Strategies and the Three-Pole Landscape

The strategic landscape through 2030 is likely to settle into three poles:
SD-JWT VC + mDoc (EUDI Wallet, ISO/IEC, IETF lineage): dominant for general European and ISO-aligned identity attestations, mDLs, age verification.
AnonCreds (Indy/Aries/LFDT): differentiated for unlinkable high-privacy credentials in regulated industries, government identity with strict privacy requirements, and cross-border recognition scenarios where holder-traceability is unacceptable.
did:web / did:webvh / W3C VC v2 with various cryptosuites: dominant for organisational issuers and ledger-light scenarios.

Whether Indy thrives, plateaus, or contracts depends on which pole captures the largest share of consumer wallet activations 2026-2030, with the EUDI Wallet mandatory rollout in November 2026 the largest single event shaping the equilibrium.

Research and Literature

Foundational Self-Sovereign Identity:

Allen, C. (2016). The Path to Self-Sovereign Identity. Life With Alacrity blog, 25 April 2016. [Foundational SSI principles essay]
Cameron, K. (2005). The Laws of Identity. Identityblog.com. [User-centric identity foundational principles]
Windley, P. (2018). Sovrin: A Protocol and Token for Self-Sovereign Identity and Decentralized Trust. Sovrin Foundation white paper, January 2018. [Sovrin design rationale]
Reed, D., Law, J., Hardman, D. (2017). The Inevitable Rise of Self-Sovereign Identity. Sovrin Foundation white paper. [SSI ecosystem positioning]
Preukschat, A., & Reed, D. (Eds.). (2021). Self-Sovereign Identity: Decentralized Digital Identity and Verifiable Credentials. Manning Publications. ISBN 978-1-6172-9659-1. [Canonical SSI textbook]

AnonCreds and Anonymous Credentials Cryptography: 6. Camenisch, J., & Lysyanskaya, A. (2002). A Signature Scheme with Efficient Protocols. Security in Communication Networks (SCN 2002), LNCS 2576, 268-289. [CL-Signature foundational paper] 7. Camenisch, J., & Lysyanskaya, A. (2004). Signature Schemes and Anonymous Credentials from Bilinear Maps. CRYPTO 2004, LNCS 3152, 56-72. [Constant-size CL-based credentials] 8. Camenisch, J., Kohlweiss, M., & Soriente, C. (2009). An Accumulator Based on Bilinear Maps and Efficient Revocation for Anonymous Credentials. Public Key Cryptography (PKC 2009), LNCS 5443, 481-500. [AnonCreds revocation accumulator] 9. Boneh, D., Boyen, X., & Shacham, H. (2004). Short Group Signatures. CRYPTO 2004, LNCS 3152, 41-55. [BBS+ Signature foundational paper] 10. Camenisch, J., Drijvers, M., & Lehmann, A. (2016). Anonymous Attestation Using the Strong Diffie Hellman Assumption Revisited. TRUST 2016, LNCS 9824, 1-20. [BBS+ refinement underpinning AnonCreds v2] 11. Pedersen, T.P. (1991). Non-Interactive and Information-Theoretic Secure Verifiable Secret Sharing. CRYPTO 1991, LNCS 576, 129-140. [Pedersen Commitment foundational paper]

Byzantine Fault Tolerance and Plenum: 12. Castro, M., & Liskov, B. (1999). Practical Byzantine Fault Tolerance. OSDI 1999. [PBFT foundational paper underpinning Plenum] 13. Aublin, P.-L., Mokhtar, S.B., & Quéma, V. (2013). RBFT: Redundant Byzantine Fault Tolerance. ICDCS 2013. [Redundant BFT variant in Plenum] 14. Clement, A., Wong, E., Alvisi, L., Dahlin, M., & Marchetti, M. (2009). Making Byzantine Fault Tolerant Systems Tolerate Byzantine Faults. NSDI 2009. [Aardvark BFT view-change resilience] 15. Lamport, L., Shostak, R., & Pease, M. (1982). The Byzantine Generals Problem. ACM Transactions on Programming Languages and Systems, 4(3), 382-401. [Foundational BFT problem statement]

W3C Standards: 16. W3C (2022). Decentralized Identifiers (DIDs) v1.0: Core Architecture, Data Model, and Representations. W3C Recommendation, 19 July 2022. https://www.w3.org/TR/did-core/ [Authoritative DID specification] 17. W3C (2024). Verifiable Credentials Data Model v2.0. W3C Recommendation, 7 May 2024. https://www.w3.org/TR/vc-data-model-2.0/ [Authoritative VC v2 specification] 18. Hyperledger Indy / W3C DID Specification Registries (2022). did:indy Method Specification. Registered April 2022. [Multi-network Indy DID method]

EUDI Wallet and EU Digital Identity: 19. European Commission (2024). European Digital Identity Wallet Architecture Reference Framework (ARF) v1.3. February 2024 (updated through 2025). [EUDI Wallet technical architecture] 20. European Parliament and Council (2024). Regulation (EU) 2024/1183 (eIDAS 2.0) amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity Framework. Official Journal of the European Union, 30 May 2024. [Legal foundation for EUDI Wallet] 21. IETF (2024). SD-JWT-VC: Selective Disclosure for JWTs for Verifiable Credentials. IETF Internet-Draft (Fett, Yasuda, Campbell). [SD-JWT VC format selected for EUDI] 22. ISO/IEC 18013-5:2021. Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application. ISO/IEC. [mDL format selected for EUDI]

Production Deployments and Industry Case Studies: 23. Government of British Columbia (2017-2025). Verifiable Organizations Network (VON) and OrgBook BC: Production Deployment Case Studies. Province of BC Digital Trust documentation. [Reference Indy government deployment] 24. IDUnion (2022-2025). IDunion eG Production Network Documentation. https://idunion.org [German production Indy network] 25. Trust over IP Foundation (2020-2025). Trust over IP Technology Stack Specifications and Governance Stack Documentation. [Cross-vendor SSI governance framework] 26. Linux Foundation Public Health & Good Health Pass Collaborative (2021). Good Health Pass Interoperability Blueprint. [COVID-19 era Indy-influenced health credential architecture] 27. Hyperledger Foundation → LF Decentralized Trust (2017-2025). Hyperledger Indy Project Documentation, Annual Reports, and Project Health Metrics. https://wiki.hyperledger.org and https://lfdecentralizedtrust.org [Official project documentation] 28. OpenWallet Foundation (2023-2025). Credo, Bifold, and ACA-Py Project Documentation; Governance Charter and Roadmap. https://openwallet.foundation [Successor governance body for major Aries projects]

Metadata

Last Updated: 2026-05-16
Review Status: Comprehensive editorial review during Phase 6 enrichment sprint (Hyperledger Indy bulk-run worker assignment)
Verification: Technical architecture verified against Hyperledger Indy official documentation (indy.readthedocs.io), Indy Node and Indy Plenum GitHub repositories (github.com/hyperledger/indy-node, github.com/hyperledger/indy-plenum), Sovrin Governance Framework v2 (2023), and W3C DID Specification Registries did:indy entry (April 2022). Cryptographic primitives verified against Camenisch-Lysyanskaya 2002 SCN paper, Camenisch-Kohlweiss-Soriente 2009 PKC paper, Boneh-Boyen-Shacham 2004 CRYPTO paper, Pedersen 1991 CRYPTO paper. Standards verified against W3C DID Core 1.0 Recommendation July 2022, W3C VC Data Model v2.0 Recommendation May 2024, Regulation (EU) 2024/1183 (eIDAS 2.0), and EUDI Wallet ARF v1.3 (February 2024). Production deployments verified against BC Government Digital Trust documentation, IDUnion eG public materials, Indicio.tech production network documentation, and Trinsic public communications regarding 2023 strategic pivot
Regional Context: UK SSI ecosystem covered including academic research (Imperial College Centre for Cryptocurrency Research and Engineering, UCL Centre for Blockchain Technologies, Cambridge CCAF, Edinburgh Blockchain Technology Laboratory with Markulf Kohlweiss as AnonCreds-accumulator-paper co-author, Manchester Alliance Manchester Business School, Leeds Centre for Decentralised Digital Economy, Sheffield CIBUL, Newcastle Cyber Security Centre, King’s College London CDT); ToIP Foundation UK members (Cheqd London, Condatis Edinburgh, esatus UK, Mattereum); industry bodies (Open Identity Exchange London, FinTech North Manchester/Leeds); UK Government context (GOV.UK One Login, DIATF, OneID, NHS Scotland pilots); Northern English industrial cluster (Manchester, Leeds, Sheffield, Newcastle) detailed
Naming Note: Project name “Hyperledger Indy” retained per current top-level project designation under LF Decentralized Trust (June 2024 consolidation); preferred-term retained as “Hyperledger Indy” with alternative-terms covering “Indy”, “Indy Node”, “Indy VDR”, “Sovrin Indy”, “Plenum-based identity ledger”
Production-Ready: Complete OWL formal semantics (44 axioms across compositional/dependency/capability/implementation/reduction/association), comprehensive content coverage (architecture and component-stack taxonomy, cryptographic foundations CL/BBS+/Pedersen/accumulators, multi-network deployment landscape, use case families government/health/aviation/enterprise/education/supply-chain, academic foundations, current landscape 2026 with EUDI Wallet competitive analysis, UK context with academic + ToIP + industry detail, future directions 2026-2030 with three-pole landscape thesis), 28 academic and primary-source citations
Authority Score: 0.87 (canonical reference verifiable-data-registry project, established 2017 ex-Sovrin Foundation contribution, foundational AnonCreds cryptographic protocol underpinning unlinkable selective-disclosure credentials, production deployments at BC Gov OrgBook BC ~525,000 credentials, IDUnion Germany, Indicio, Findy Finland, CANdy Canada, ongoing AnonCreds v2 BBS+ migration restoring competitive positioning, retained relevance despite EUDI Wallet selecting SD-JWT VC + mDoc over AnonCreds)

Provenance

naming-note: Project remains “Hyperledger Indy” under LF Decentralized Trust (Hyperledger Foundation rebrand June 2024); preferred-term retained

Narrative Goldmine

Explorer

Hyperledger Indy

Properties

Semantic Classification

Content

Compositional Relationships (Components)

Property Characteristics

About Hyperledger Indy

Architecture and Components

Plenum Consensus Layer

Indy Node and Validator Operations

Ledger Object Types

Indy VDR and Client Libraries

AnonCreds Protocol

Hyperledger Aries Companion Stack

OpenWallet Foundation and Credo

Use Cases / Major Families

Government Identity and Business Registration

Healthcare and Public Health Credentials

Aviation and Travel

Enterprise Onboarding and KYC

Education and Professional Credentials

Supply Chain and Provenance

Cryptographic Foundations

CL-Signatures (AnonCreds v1)

BBS+ Signatures (AnonCreds v2)

Pedersen Commitments

Cryptographic Accumulators for Revocation

Networks and Ecosystem

Sovrin Networks

Indicio Networks

IDUnion (Germany)

Findy (Finland)

CANdy (Canada) and BCovrin (BC Government)

Other Regional and Vertical Networks

Comparison with Alternative DID Methods and Credential Formats

vs. did:web

vs. did:webvh

vs. did:key and did:peer

vs. did:plc

vs. did:ion and Sidetree

vs. did:ethr

vs. SD-JWT VC

vs. mDoc / mDL (ISO/IEC 18013-5)

vs. Atala PRISM

Choosing Between Options

Implementation Considerations

Technical Requirements

Organisational Readiness

Cost Considerations

Timeline

Challenges and Limitations

Technical Challenges

Organisational and Adoption Challenges

Strategic and Ecosystem Challenges

Security and Privacy Concerns

Academic Context

Cryptographic Foundations

Distributed Systems Theory

Self-Sovereign Identity Theory

Privacy Economics

Current Landscape (2026)

Hyperledger Foundation Consolidation into LF Decentralized Trust

Indy SDK Deprecation Complete

Migration to ACA-Py and OpenWallet Foundation Governance

Competition from Light DID Methods

EUDI Wallet Architecture Reference Framework

Trinsic Pivot and Market Signals

Indy/AnonCreds Defensive Positioning

UK Context: Academic Research, ToIP Foundation Members, and Industrial Pilots

Academic Research

ToIP Foundation UK Members and Industry

UK FCA and Regulatory Stance

Future Directions (2026-2030)

AnonCreds v2 Specification and BBS+ Migration

EUDI Wallet Interoperability Profiles

Hyperledger Foundation → LF Decentralized Trust Strategic Evolution

Quantum Resistance and Long-Term Cryptography

Sovereign Wallet Strategies and the Three-Pole Landscape