Trust Registry

A trust registry enables decentralized identifiers (DIDs) and verifiable credentials (VCs) to be issued and verified on-chain. Issuers (e.g., accredited bodies) sign credentials, while verifiers can check their validity and status directly against the registry's smart contracts, removing reliance on a single database.

• Example: A DAO uses a registry to issue membership badges. Any dApp can instantly verify a user's membership status by querying the registry.

All credential lifecycle events—issuance, suspension, revocation, and expiration—are recorded as immutable transactions on the underlying blockchain. This creates a transparent and tamper-proof history for compliance and auditing.

• Key Mechanism: Revocation is typically managed via a revocation registry (like a smart contract holding a list of revoked credential hashes) rather than deleting data.

Trust is governed by on-chain logic encoded in smart contracts. These policies automatically enforce rules for who can issue credentials, under what conditions they are valid, and how they can be used.

• Examples:
  • A credential is only valid if the issuer's own accreditation is current.
  • A credential automatically expires after 365 days.
  • Access is granted only to credentials of a specific type (e.g., KYC Level 2).

Effective trust registries are built on open standards like W3C Verifiable Credentials and Decentralized Identifiers (DIDs). This ensures credentials issued in one ecosystem (e.g., a corporate identity system) can be understood and verified in another (e.g., a DeFi protocol), preventing vendor lock-in.

• Foundation: Standards define the data model, cryptographic proofs, and discovery protocols.

Supports zero-knowledge proofs (ZKPs) and selective disclosure, allowing users to prove a claim derived from a credential without revealing the underlying document. This minimizes data exposure and enhances user privacy.

• Use Case: Proving you are over 21 from a driver's license credential without revealing your birth date or address.

Provides real-time, on-chain mechanisms to check if a credential is active, suspended, or revoked. This is critical for dynamic trust, where an issuer must be able to invalidate credentials (e.g., for a compromised key or lost license) without relying on the credential holder to update their data.

• Contrast: This solves the limitation of static, self-contained credentials that cannot reflect revoked status.

Financial institutions and DeFi protocols use trust registries to manage compliance credentials. A regulator or licensed entity can issue Verifiable Credentials (VCs) attesting that a user has passed Know Your Customer (KYC) or Anti-Money Laundering (AML) checks.

• The registry lists accredited issuers.
• Protocols can programmatically check for valid credentials before allowing transactions.
• This creates a reusable, privacy-preserving compliance layer across multiple services.

In supply chain management, a trust registry authorizes participants (e.g., farms, certifiers, shippers) to issue credentials about products.

• An organic certification body is listed as a trusted issuer.
• It can issue VCs for batches of goods, proving origin, organic status, or fair-trade compliance.
• Each step in the chain adds verifiable attestations, creating an immutable audit trail from source to consumer.

DAOs use trust registries to manage membership and voting rights securely.

• The registry defines which Soulbound Tokens (SBTs) or credentials constitute a valid membership.
• It can tier members based on verified contributions or expertise.
• This prevents Sybil attacks by ensuring each vote is linked to a unique, verified identity, enabling one-person-one-vote systems instead of one-token-one-vote.

Trust registries can serve as a decentralized alternative to centralized business registries. National governments or international bodies can be listed as issuers for Legal Entity Identifiers (LEIs).

• Companies receive a cryptographically verifiable credential proving their legal existence and registration details.
• This facilitates cross-border trade and finance by providing a universal, tamper-proof source of truth for entity data, interoperable across jurisdictions.

A Trust Registry acts as a single source of truth for decentralized identity and authorization. It is typically implemented as a smart contract or a Verifiable Data Registry that stores and manages lists of trusted DIDs (Decentralized Identifiers) or public keys. Participants can query the registry to verify if an entity is authorized to issue a specific type of credential (e.g., a KYC attestation) or perform an action (e.g., validate a transaction). This replaces centralized, opaque whitelists with transparent, auditable rules.

Trust Registries are built upon foundational standards from the World Wide Web Consortium (W3C) and Decentralized Identity Foundation (DIF).

• W3C Verifiable Credentials Data Model: Defines the structure of cryptographically verifiable attestations.
• DID (Decentralized Identifier): A standard URI that points to a DID Document containing public keys and service endpoints.
• DIF Trust Establishment: Working groups define patterns for how registries are discovered, updated, and governed across different networks.

Who controls the registry is a critical design choice, defining its trust model.

• Permissioned/Consortium-Based: A pre-defined group of governing entities (e.g., banks in a financial network) vote on additions/removals. Used in enterprise blockchain consortia.
• Algorithmic/Token-Curated: Registry membership is determined by staking and voting by token holders, as seen in some Decentralized Autonomous Organizations (DAOs).
• Self-Sovereign: Entities can self-register, but their status is subject to community reputation systems or challenge periods. This aligns with SSI (Self-Sovereign Identity) principles.

Trust Registries are essential for scalable Verifiable Credential (VC) ecosystems. For example, a university ecosystem might have a registry listing all accredited institutions authorized to issue digital diplomas. A verifier (like an employer) can check the registry to confirm the issuer's DID is listed before trusting the diploma's authenticity. This enables interoperability between different issuers and verifiers without bilateral agreements, forming the backbone of digital identity networks like European Digital Identity (EUDI) Wallet architectures.

In Decentralized Finance (DeFi), Trust Registries can address regulatory compliance. For enforcing the Travel Rule (FATF Recommendation 16), a registry could maintain a list of Virtual Asset Service Providers (VASPs) that have completed required KYC/KYB checks. A DeFi protocol could query this registry before allowing a transaction, ensuring it only interacts with compliant counterparties. This demonstrates how registries can bridge decentralized protocols with regulated financial infrastructure.

Technically, a registry is queried on-chain or off-chain to resolve an entity's status.

• On-Chain Lookup: A smart contract calls a registry contract's isTrustedIssuer(DID, credentialType) function, returning a boolean. This is gas-intensive but fully decentralized.
• Off-Chain with Proofs: The registry state is anchored to a blockchain (e.g., via a Merkle root). Entities can provide a Merkle proof that their credential is in the latest attested root, allowing for efficient, scalable verification. This pattern is used by frameworks like Hyperledger AnonCreds.

A critical function of a trust registry is managing the lifecycle of credentials, particularly revocation. It provides a mechanism for verifiers to check if an issued credential is still valid. Common patterns include:

• Revocation Registries: Lists of revoked credential identifiers.
• Status Lists: Bitstring-based status lists (W3C standard).
• Smart Contract Registries: On-chain revocation checks. This prevents reliance on the original issuer being online for status checks.

A Schema Registry is a specific type of trust registry that publishes the definitions for verifiable credential schemas. It ensures all ecosystem participants (issuers, holders, verifiers) share a common understanding of a credential's data format. For example, a "University Degree" schema would define the required fields (e.g., degreeType, awardDate, institutionName). This enables interoperability and automated processing of credentials across different systems.