SBT Revocation

SBTs can be revoked through several technical methods, each with different trust assumptions and on-chain footprints. Key approaches include:

• Burn Function: The issuer calls a function to destroy the token, removing it from the holder's address. This is permanent and on-chain.
• Revocation List: The issuer maintains an on-chain or off-chain list (like a revocation registry) of invalidated token IDs. Verifiers must check this list to confirm status.
• Expiry Timestamp: The token contains a built-in expiry time, after which it is considered invalid without a direct revocation transaction.
• Pausable Contracts: The issuer can pause the entire smart contract, freezing all state changes or rendering all tokens temporarily invalid.

EIP-4973 (Account-bound Tokens) is a proposed standard that explicitly includes a revoke function. This function can only be called by the token's issuer, burning the token and emitting a Revoke event. This standardizes revocation at the smart contract level, providing a clear, auditable record of when and by whom a credential was invalidated. It contrasts with transferable ERC-721 tokens, where revocation is not a native concept.

Frameworks like Ethereum Attestation Service (EAS) handle revocation differently. An attestation (the core credential) is immutable, but the issuer can create a separate, linked revocation attestation. Verifiers must query the schema to check for an active revocation. This keeps the original record intact but flags it as invalid, which is useful for compliance and audit trails where a history of status changes is required.

The requirement for revocation emerges from real-world credential management:

• Membership Termination: Revoking an SBT when a member leaves a DAO or community.
• Credential Expiry: Invalidating a license, certification, or proof-of-attendance that is no longer valid.
• Key Compromise: Removing access credentials if a wallet is suspected to be compromised.
• Compliance & Legal Orders: Enforcing takedowns or sanctions required by law.
• Error Correction: Revoking an attestation issued incorrectly or based on false information.

Simple on-chain revocation can leak privacy by broadcasting the revocation event. Advanced systems use zero-knowledge proofs (ZKPs). A holder can prove they possess a valid, unrevoked SBT from a set without revealing which specific token they hold or triggering a public revocation check against their address. This balances the need for issuer control with holder privacy.

The security model shifts responsibility to the verifier. Simply checking for token ownership is insufficient. A verifier's application logic must actively check the revocation status by:

1. Querying the smart contract's revocation state.
2. Checking an on-chain revocation registry.
3. Verifying there is no revocation attestation in a framework like EAS. Failure to perform this check is a critical security flaw, as it accepts invalidated credentials.

The most common model where the entity that minted the SBT (the issuer) retains exclusive control to revoke it. This is typically enforced via an owner or admin role in the smart contract. Revocation permanently burns the token or flags it as invalid in a registry.

• Use Case: Revoking a credential for misconduct or expired membership.
• Trust Assumption: Requires trust in the issuer's judgment and key management.

A self-revoking mechanism where an SBT automatically becomes invalid after a predefined timestamp or block height. The expiry logic is encoded directly into the token's smart contract.

• Use Case: Temporary access passes, subscription credentials, or event tickets.
• Security Benefit: Eliminates the need for a manual revocation transaction, reducing issuer overhead and potential key compromise risk.

A design pattern that separates the proof of validity from the token itself. A separate on-chain revocation registry (like a smart contract or a merkle tree) maintains a list of revoked token identifiers. Verifiers must check this registry to confirm an SBT's current status.

• Use Case: Scalable systems where many issuers or verifiers are involved.
• Example: The W3C Verifiable Credentials model often uses revocation registries.

A user-centric model where the token holder (the "soul") can destroy their own SBT. This is a key feature for privacy and self-sovereignty, allowing users to sever links or withdraw consent.

• Trust Implication: Shifts control from issuer to holder, aligning with decentralized identity principles.
• Consideration: May conflict with systems requiring immutable records for compliance.

Revocation authority is distributed across a decentralized autonomous organization (DAO) or a set of trusted guardians. A vote or multi-signature scheme is required to approve a revocation.

• Use Case: Community-issued reputation badges or decentralized identity attestations.
• Security Model: Mitigates single-point-of-failure risks but introduces governance complexity and potential attack vectors.

Key security considerations for any revocation system:

• Centralization Risk: An issuer's private key is a single point of failure.
• State Bloat: Maintaining large revocation lists on-chain can be expensive.
• Privacy Leaks: Checking a public registry for revocation can reveal when and why a specific SBT was invalidated.
• Liveness Requirement: Relies on the underlying blockchain's availability for revocation transactions to be processed.

A Soulbound Token (SBT) is a non-transferable, non-financialized token representing credentials, affiliations, or commitments bound to a single wallet or "Soul." It is the fundamental unit that revocation mechanisms act upon. Key characteristics include:

• Non-Transferable: Cannot be sold or traded, ensuring the credential stays with the entity that earned it.
• Publicly Verifiable: Stored on-chain, allowing for permissionless verification of claims.
• Composable: Can be combined with other SBTs to form complex identity graphs.

A Revocation Registry is an on-chain or off-chain data structure that maintains a list of revoked credentials, such as SBTs or Verifiable Credentials. It is the authoritative source that verifiers check against. Common implementations include:

• On-Chain Bitmaps: A smart contract storing a compact bitmap where each bit represents the revocation status of an SBT ID.
• Accumulator Schemes: Cryptographic structures like RSA accumulators or Merkle trees that allow proving non-revocation without revealing the specific credential ID.
• InterPlanetary File System (IPFS): Used to store off-chain revocation lists with on-chain pointers for integrity.

A Verifiable Credential (VC) is a W3C standard for tamper-evident digital credentials that can be cryptographically verified. SBTs are often considered an on-chain implementation of VCs. The revocation paradigm differs:

• VC Revocation: Typically uses a status list or revocation registry referenced in the credential's proof. The holder presents the VC and a separate non-revocation proof.
• SBT Revocation: The status is often checked directly against the state of the smart contract or an on-chain registry, as the token itself is the primary artifact.

A Zero-Knowledge Proof (ZKP) is a cryptographic method allowing one party to prove knowledge of a secret or the truth of a statement without revealing the information itself. It is crucial for privacy-preserving revocation in SBT systems. Applications include:

• Proving Non-Revocation: Generating a ZKP that an SBT is not on a revocation list without disclosing the SBT's identifier.
• Selective Disclosure: Revealing only specific attributes from an SBT (e.g., "over 18") while keeping the token ID and other data private, even during revocation checks.

An Attestation is a signed statement or claim made by an issuer about a subject. In SBT systems, the minting of an SBT is an on-chain attestation. Revocation is the act of retracting that attestation. Key aspects are:

• Issuer Sovereignty: The entity that issued the SBT typically holds the exclusive right to revoke it, enforced by smart contract logic.
• Temporal Validity: Attestations can have expiration times, making revocation implicit after a certain date.
• Social Recovery: Some systems allow a decentralized network of peers (e.g., other Souls) to attest to the invalidity of a credential, triggering revocation.

Account Abstraction (ERC-4337) enables smart contract wallets with customizable logic. It introduces new models for managing and revoking SBT-bound identities. Relevant features include:

• Session Keys: Granting temporary authority to applications, which can be revoked without changing the core wallet, affecting how SBT-gated access is managed.
• Recovery & Guardians: Social recovery mechanisms where designated guardians can help recover or, in extreme cases, revoke access to an account's identity assets.
• Atomic Revocation Bundles: Allowing complex operations—like revoking multiple SBTs across different contracts—to be executed in a single user transaction.