A Status List is a cryptographically secured, machine-readable data structure—typically implemented as a bitstring—that encodes the revocation or suspension status of a batch of Verifiable Credentials (VCs). Instead of checking a centralized database for each credential, a verifier can download a single, compact status list and use a credential's unique index position to check a single bit, where 0 often means 'valid' and 1 means 'revoked'. This approach, defined in the W3C's Status List 2021 specification, enables efficient, decentralized status checks without revealing which specific credential is being validated, enhancing both performance and privacy.
LABS
Glossary
Status List
A status list is a verifiable credential or dedicated registry used to publish the revocation status (e.g., revoked, suspended) of other verifiable credentials.
Chainscore © 2026
definition
VERIFIABLE CREDENTIALS
What is a Status List?
A technical standard for managing the revocation or suspension status of digital credentials in a privacy-preserving and scalable manner.
The core mechanism relies on linking a credential to the status list via a statusListCredential, which is a special Verifiable Credential itself. This credential contains the URI of the status list, the cryptographic digest of the list's contents, and the index position assigned to the holder's credential. When a verifier receives a credential, they fetch the status list credential, verify its integrity using its own proof, and then check the bit at the specified index in the referenced list. This creates a trust chain from the issuer's signature on the status list credential down to the individual status bit, ensuring the status information is as trustworthy as the issuer.
Status Lists solve critical scalability problems inherent in earlier revocation methods like individual credential revocation lists. By batching thousands of statuses into a single, compressed file, they drastically reduce bandwidth and processing overhead for both issuers and verifiers. Common implementations store the bitstring in a gzip-compressed JSON or base64-encoded string, making it efficient to transmit. This design is particularly vital for ecosystems issuing high volumes of credentials, such as digital driver's licenses, educational certificates, or employee badges, where real-time, privacy-respecting status verification is required.
key-features
STATUS LIST
Key Features
A Status List is a cryptographic data structure, often implemented as a Verifiable Credential, that provides a compact, privacy-preserving, and efficient mechanism for managing the revocation or suspension status of a large set of items, such as digital credentials or tokens.
01
Bitstring Compression
At its core, a Status List encodes statuses as a bitstring, where each bit represents the active (e.g., 0) or revoked/suspended (e.g., 1) state of a single item. This compressed representation is stored in a JSON Web Token (JWT) or as a JSON-LD Verifiable Credential, enabling the status of thousands of items to be conveyed in a few kilobytes of data.
02
Selective Disclosure
A holder can prove the status of a specific credential without revealing the status of any others in the list. This is achieved by providing a cryptographic proof (like a Merkle proof or a bitstring index) that verifies the state of a single bit. This preserves privacy and minimizes data exposure during verification.
03
Decentralized Issuer Control
The issuer of the credentials maintains sole authority to publish and update the Status List. Updates are signed with the issuer's private key, ensuring integrity and authenticity. Verifiers fetch the list directly from a trusted URI provided in the credential, avoiding reliance on a centralized revocation registry.
05
Contrast with Traditional Revocation
- OCSP/CRL: Traditional PKI uses Online Certificate Status Protocol or Certificate Revocation Lists, which are query-based and can leak privacy.
- Blockchain Revocation: Some systems use on-chain transactions for revocation, which is public and can incur fees.
- Status List Advantage: Provides a privacy-enhancing, offline-verifiable, and issuer-controlled alternative that is scalable and cost-effective.
06
Common Use Cases
- Educational Credentials: Revoking a diploma if fraud is discovered.
- Professional Licenses: Suspending a medical license.
- Membership Cards: Denoting lapsed membership status.
- Access Tokens: Invalidation of a specific access pass without affecting others issued from the same batch.
how-it-works
MECHANISM
How a Status List Works
A technical breakdown of the mechanism for managing credential revocation and suspension using a verifiable data registry.
A Status List is a cryptographically secured, machine-readable list, typically published to a verifiable data registry like a blockchain, that indicates the current status—such as revoked or suspended—of a set of verifiable credentials. It functions as a shared reference point where verifiers can check if a credential presented to them is still valid, without needing to contact the original issuer directly for each transaction. This decouples the act of issuance from the ongoing lifecycle management, enabling scalable and privacy-preserving revocation checks.
The core innovation is the bitstring status list, defined in the W3C standard. In this model, each credential is mapped to a specific index position in a large array of bits. A bit value of 0 typically indicates the credential is valid, while a 1 indicates it is revoked or suspended. The issuer creates and signs this compressed bitstring, publishing its cryptographic digest (a hash) to an immutable ledger. The actual bitstring is distributed via a URL or other method, allowing any verifier to fetch it, confirm its integrity against the on-chain hash, and check the status bit for a given credential index.
For example, a university issuing digital diplomas would include a credentialStatus property in each credential pointing to a specific index in its master status list. If a student's degree is rescinded, the university flips the bit at that index from 0 to 1 and publishes an updated, signed bitstring. When a potential employer verifies the diploma, their wallet fetches the current list, verifies its signature and on-chain hash, and checks the relevant bit to confirm the credential's active status. This process is efficient, as a single list can manage the status for thousands of credentials.
This architecture offers significant advantages over traditional certificate revocation lists (CRLs). It minimizes on-chain data storage by only committing a tiny hash, reduces issuer load by eliminating direct query endpoints, and enhances privacy for the holder—the verifier requests only the specific list needed, without revealing which exact credential they are checking. The integrity guaranteed by the blockchain anchor makes the list tamper-evident, ensuring verifiers trust the status information provided by the issuer.
examples
STATUS LIST
Examples & Implementations
Status Lists are implemented across various ecosystems to manage credential revocation and suspension. These examples showcase different technical approaches and real-world applications.
TECHNICAL COMPARISON
Status List vs. Traditional Revocation
A comparison of the Status List 2021 specification against conventional certificate revocation methods.
| Feature | Status List 2021 | Certificate Revocation List (CRL) | Online Certificate Status Protocol (OCSP) |
|---|---|---|---|
Revocation Data Location | Embedded in Verifiable Credential | Centralized CRL Distribution Point | Centralized OCSP Responder |
Verification Query | Local bitmask check | Download and parse full CRL | Online request to responder |
Network Dependency | Offline-capable | Online for list updates | Online for every check |
Privacy Exposure | Minimal (no query to issuer) | High (reveals queried certificate) | High (reveals queried certificate) |
Revocation Granularity | Per credential | Per certificate | Per certificate |
Scalability for Issuer | High (static, cacheable list) | Low (growing CRL file size) | Medium (server load per request) |
W3C VC Standardization | |||
Typical Latency | < 10 ms | 100-1000 ms | 50-200 ms |
security-considerations
STATUS LIST
Security & Privacy Considerations
A Status List is a privacy-preserving mechanism for managing credential revocation and suspension. These cards detail the core security models, privacy trade-offs, and implementation considerations for developers.
01
Bitstring vs. List-Based Models
Two primary data structures define Status List security:
- Bitstring (Bitmask): A compact, encoded string where each bit represents the status (e.g., 0=valid, 1=revoked) of a credential at a specific index. Offers efficient verification but requires index management.
- List-Based: A simple array of credential identifiers (like
did:example:123#key-1) marked as revoked. More intuitive but less space-efficient for large-scale systems. The choice impacts gas costs on-chain, verifier lookup complexity, and the potential for correlation if list contents are exposed.
02
Selective Disclosure & Correlation
A core privacy challenge is preventing verifiers from correlating holders. Key considerations:
- Index Revelation: Sharing a credential's position in a public list can be a correlation point. Techniques like salted hashes or dynamic index assignment mitigate this.
- List Access Patterns: Frequent queries for the same status list entry from the same IP address can reveal holder activity.
- Zero-Knowledge Proofs (ZKPs): Advanced models allow proving a credential is not on a revocation list without revealing which credential is being checked, offering the strongest privacy.
03
Decentralized Storage & Integrity
Where and how the Status List is stored is critical for security and availability.
- On-Chain Storage: Stores the list (or its hash) on a blockchain (e.g., Ethereum, Polygon). Provides tamper-proof integrity and high availability but can incur significant gas costs for updates.
- Off-Chain Storage with On-Chain Anchor: The list is hosted off-chain (e.g., IPFS, HTTPS), with its cryptographic hash (Merkle root) periodically committed to a blockchain. This balances cost and integrity but introduces a liveness dependency on the off-host.
- Verifiable Data Registries (VDRs): Use purpose-built decentralized networks like ION or Ceramic for managing status data.
04
Revocation Authority & Trust
The entity controlling list updates defines the trust model.
- Issuer-Held: The credential issuer (e.g., a university) controls revocation. Simple but creates a central point of failure and requires the issuer to remain operational.
- Holder-Held: The credential holder can prove revocation status themselves, often via a signed cryptographic commitment. Enhances privacy and reduces issuer dependency but is complex to implement securely.
- Decentralized Identifier (DID) Controllers: Revocation authority is linked to a DID, allowing key rotation and delegated management without changing the credential's identifier.
05
Implementation Risks & Mitigations
Common pitfalls in Status List deployments include:
- Replay Attacks: Using a stale, cached status response. Mitigated by including a timestamp or nonce in the status proof.
- Denial of Service (DoS): If the status list is hosted on a single endpoint, it becomes a target. Decentralized hosting or CDN caching of immutable lists can help.
- Size Explosion: Unbounded list growth. Implement expiration policies or compaction techniques (e.g., archiving old entries).
- Schema Incompatibility: Different W3C VC implementations may handle status list URLs or proof formats differently, breaking interoperability.
06
W3C Standard & Interoperability
The W3C Verifiable Credentials Status List 2021 specification provides a standardized data model. Key security aspects of the standard:
- Defines the
statusListCredential, a special VC whosecredentialSubjectcontains the encoded bitstring. - Uses a statusListIndex to link a verifiable credential to its specific bit position.
- Mandates the cryptographic binding of the status list VC to ensure its integrity is verifiable independently. Adherence to the standard ensures interoperability across different issuers, wallets, and verifiers in the ecosystem.
STATUS LIST
Common Misconceptions
Status lists are a foundational component of verifiable credentials, yet their technical implementation is often misunderstood. This section clarifies key points about their purpose, mechanics, and limitations.
A status list is a cryptographically verifiable data structure, typically implemented as a bitstring, used to check the revocation or suspension status of a verifiable credential (VC). It works by associating each credential with a unique index position in the list. A value of 0 at that index indicates the credential is valid, while a 1 indicates it is revoked. The list itself is published as a verifiable credential (a StatusList2021 credential), allowing any verifier to check the integrity of the list via its digital signature and then query the specific bit for the credential in question.
STATUS LIST
Frequently Asked Questions
Status Lists are a foundational component of the W3C Verifiable Credentials ecosystem, enabling the efficient revocation and suspension of credentials. This FAQ addresses common technical questions about their implementation and use.
A Status List is a cryptographically secured, machine-readable list used to check the revocation or suspension status of a Verifiable Credential (VC). It works by associating each credential with a unique index position on a public list. The credential's metadata includes a credentialStatus property pointing to the list's URI and the credential's index. A verifier fetches the list, checks the bit at the specified index (e.g., 0 for valid, 1 for revoked), and determines the credential's current status without contacting the issuer directly. This mechanism decouples status checking from the issuer's availability.
Key components:
- Status List Credential: A VC whose subject is the status list itself.
- Bitstring: A compact array of bits where each position corresponds to a credential's status.
- Index: The unique position a credential occupies on the list.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall