Revocation

What it is

Revocation is a mechanism that lets whoever issued (or in some designs, whoever holds) an onchain credential — an attestation, a badge, a soulbound token — later mark it as invalid. Blockchains are append-only, so you usually can't erase history, but you can add a new piece of state that says "this claim is no longer trusted," and any application checking the credential is expected to check that flag before relying on it.

How it works

1. An issuer creates an attestation or token that makes a claim about a subject — "this wallet completed KYC," "this address is a verified developer," "this NFT represents membership."
2. The issuing contract stores, alongside the claim itself, either a revocation flag (a boolean that starts false) or a separate revocation registry that maps credential IDs to revoked/not-revoked status.
3. Some designs also record who is allowed to revoke: often only the original issuer, sometimes the subject themselves (self-revocation, e.g. renouncing a soulbound token), sometimes a DAO vote or admin multisig.
4. When a revocation is triggered — because the issuer discovers fraud, the underlying real-world condition changes, or the subject requests it — the revoker calls a revoke function, flipping the stored flag or adding an entry to the registry.
5. This action is itself an onchain event, emitting a log that off-chain indexers and other contracts can watch for.
6. Any consumer of the credential — a dApp checking eligibility, a game checking a badge — is supposed to query the current revocation status, not just check that the credential was originally issued, before granting access or benefits.
7. Because the original attestation record usually still exists on-chain (immutable history), revocation doesn't erase the past; it only changes what's considered currently valid.

Why designers use it

• Lets issuers correct mistakes or respond to fraud after a credential has already been granted, without needing to rewrite history.
• Supports time-limited or conditional trust: a credential can represent "valid as of last check" rather than "valid forever," matching how most real-world credentials work (licenses expire, memberships lapse).
• Enables compliance use cases (e.g., revoking access after a KYC status changes) that pure immutable, unrevokable claims can't support.

Failure modes

• Stale consumers: if a downstream app caches credential status or forgets to check the revocation flag, users can keep benefiting from a credential that's already been revoked.
• Centralization of revocation power: if only a single admin key can revoke, that key becomes a single point of failure — either it's abused to censor legitimate holders, or it's lost and revocation becomes impossible when actually needed.
• Race conditions: a credential can be used in a transaction in the same block or shortly before it's revoked, letting a bad actor front-run their own revocation.
• False sense of permanence: users may assume a badge or attestation is a permanent, portable proof, not realizing it can silently become worthless if the issuer revokes it later.
• Indexer lag: off-chain services that display credential status may not immediately reflect an on-chain revocation, creating a window of stale trust.

What to check before using it

• Confirm who holds revocation rights and under what process (single key, multisig, DAO vote, or self-revocation only).
• Check whether every consumer of the credential actually re-verifies current status onchain rather than trusting a cached "was issued" check.
• Look at whether revocation is total or supports partial/graduated states (e.g., suspended vs. permanently revoked).
• Verify there's an event log or subgraph that makes revocations easily indexable, so integrators aren't caught by surprise.
• Ask what happens to value or access already granted based on the credential before it was revoked — is it clawed back, or only future access blocked?