What's On-Chain for a Verifiable Credential (and What Isn't)

Open explorer.solidus.network/credential/1 and you'll see a full credential detail view: an issuer DID and a holder DID, a credential type and issuance date, a credential hash, an on-chain transaction reference, a revocation-status flag, and a cryptographic proof block. One honest note before anything else: as of this check, the route renders the same worked example, a demo identity credential, at any ID you give it, including numbers that don't correspond to a real issued credential. Read what follows as an accurate map of the mechanics this page teaches, not a claim that credential 1 belongs to a real person named on the page.

That worked example is still useful, because it's built to show exactly the distinction this page is about: a Verifiable Credential itself, the full claims document, lives with its holder. It is never stored on-chain. What the chain does carry is small, specific, and checkable, and the live page's own layout draws the line for you.

What a status entry actually is

The problem a status entry solves is old: an issuer signs a credential once, at issuance time, but "is this still valid" is a question that can change the next day. A document expires early, a license gets suspended, a prior verification result is reversed. Calling the issuer every time a verifier wants to check is slow and it leaks information (the issuer learns exactly which credential, and by extension which relying party, just asked). The fix the identity standards world settled on is a compact, indexable flag: the issuer publishes one small structure covering many credentials at once, each credential gets an index into it, and a verifier checks one bit instead of placing a call.

Two specs define how that flag actually looks on the wire, and Solidus designed neither of them. Credential Status is the W3C Verifiable Credentials Working Group's extension point, the credentialStatus property inside the VC Data Model, that names which concrete mechanism an issuer uses. The two mechanisms it can point at are Status List entries: the W3C VC Working Group's Bitstring Status List, built for JSON-LD/Data-Integrity credentials, and the IETF's separate Token Status List draft, built for JWT- and CWT-based credentials that don't carry a JSON-LD context to hang a bitstring off of. Both do the same job, one compact, checkable flag per credential, over a different wire format matched to how the credential itself is secured. Revocation is the older, broader concept both specs serve: an issuer taking back a credential's validity before it naturally expires, the same problem certificate authorities have handled for TLS certificates since the 1990s with CRLs and OCSP.

What's on-chain, precisely, as this page renders it

The live detail route separates its fields the same way the standard does. A section labeled "On-Chain Record" carries a transaction reference and an issuance timestamp, the anchor for the credential's existence. Sitting alongside it, in its own field, is a revocation-status flag: valid or revoked, the single bit a verifier actually needs. And the issuer and holder fields each carry a DID reference, resolvable the same way any did:solidus identifier resolves (see Resolve a DID Yourself for that mechanism directly). That's the whole on-chain footprint this page confirms: a DID reference, a hash/transaction anchor, and a status flag, not the claims themselves.

The rest of what renders on the page, a name, a country, an age-over-18 check, with a birthdate and a document ID shown masked, sits under a separately labeled "Attributes (Subject Claims)" panel, grouped apart from the on-chain section. That's the credential document's own content, illustrated here for the demo credential; it is not what the on-chain record stores. Note one honest limit on the status-list side specifically: no independently-browsable public status-list URL has been confirmed live as a separately fetchable endpoint as of this check, what's confirmed is the flag rendered on this detail page, tied to the on-chain anchor above it.

What revocation checking actually buys a relying party

Set the mechanics against the plain compliance question a relying party actually has: can I confirm this credential is still good without calling the issuer every single time? A status entry answers that directly. Instead of a live API call to the issuer, with its latency, its uptime dependency, and its privacy leak (the issuer now knows exactly who's checking, and when): a relying party reads one indexed bit against a compact structure the issuer publishes once. That's a real operational difference for anyone building a verification flow: fewer calls to an issuer that may be slow, unavailable, or simply unwilling to answer per-query, and a cheaper way to keep a "still valid" check current instead of trusting the state a credential was in at issuance. It is a mechanics claim, not a reuse pitch: nothing here argues that a credential checked this way should travel across unrelated relying parties; that's a separate question this page doesn't make.

Where this fits next to what a DID anchor can't hold

This page and its sibling make the same honest point from two directions. Why an Identity Anchor Can Never Hold or Send Value shows what's structurally absent from a DID anchor, no balance, no fee history, enforced by a consensus rule. This page shows what's deliberately present for a credential instead: a DID reference, an anchor transaction, and a status flag, and nothing more from the chain's side.