Revocation Using Nonce vs Revocation Using Blocklist

Pro: Stateless & Scalable

• No global registry to maintain or query.
• Gas costs are predictable and low, as only the issuer updates a single on-chain nonce.
• Ideal for high-volume, low-latency scenarios like event tickets or session keys where checking a centralized list is a bottleneck.

Con: Issuer-Dependent & Coarse

• Requires trust in the issuer's endpoint to provide the current valid nonce.
• Revocation is all-or-nothing; you cannot revoke a single credential without invalidating all others in the same batch (shared nonce).
• Poor fit for credentials requiring individual, granular revocation like employee badges or compromised wallet attestations.

Pro: Granular & Verifiable

• Enables per-credential revocation by adding its unique identifier (e.g., credential hash) to an on-chain registry.
• State is decentralized and independently verifiable by any verifier without contacting the issuer.
• Ideal for high-value, long-lived credentials like KYC attestations or professional licenses where selective revocation is critical.

Con: Stateful & Costly

• Requires on-chain storage and updates, leading to higher and less predictable gas fees for the issuer.
• Verifier overhead increases with list size, requiring efficient data structures (like Merkle trees in Ethereum Attestation Service or Verax) to manage cost.
• Poor fit for mass-market applications where minimizing verifier cost and complexity is the top priority.

Stateless revocation: Each credential is bound to a unique, incrementing nonce. Revocation is a simple on-chain transaction updating the nonce (e.g., in a smart contract registry). This eliminates the need to store and query a persistent list. Ideal for high-throughput, cost-sensitive environments like Ethereum L2s (Optimism, Arbitrum) where storage is expensive.

Fixed-cost operations: The gas fee for issuing or revoking is constant and predictable, as it's a single state update. No scaling cost with the total number of revoked credentials. Critical for protocols like Polygon zkEVM or Base that prioritize stable transaction fees for mass adoption of attestations.

Real-time revocation: Adding a credential's unique identifier (e.g., credential hash) to an on-chain or off-chain list provides instant, per-credential revocation. Essential for high-security, compliance-driven use cases like KYC/AML credentials (Circle's Verite) or asset tokenization where a specific credential must be invalidated immediately.

Selective disclosure: Using zero-knowledge proofs (ZKPs), a verifier can check a credential against a blocklist without revealing the credential's ID. Supported by frameworks like zkSNARKs (Circom) or zk-STARKs. Best for identity protocols (iden3, Sismo) requiring user privacy during revocation checks.

Global state dependency: All verifiers must query the latest nonce from the authoritative source (e.g., a specific smart contract). This creates a central point of failure and requires reliable RPC connections to networks like Ethereum Mainnet or Solana. Problematic for offline or intermittently connected verification scenarios.

Linear cost growth: The gas cost and storage burden of maintaining the list scales with the number of revoked items. On Ethereum Mainnet, this can become prohibitively expensive. Challenging for large-scale credential systems (e.g., event ticketing for 1M+ users) where revocation events are frequent.

Immediate Invalidation: A credential is revoked the moment its identifier (e.g., DID) is added to the on-chain blocklist. This is critical for high-security, time-sensitive applications like KYC/AML checks or physical access control where a compromised credential must be invalidated instantly.

Simplified Verification Logic: Verifiers only need to check a single, current on-chain state ("is this ID on the list?"). This avoids complex logic to track and validate nonce sequences, reducing gas costs and smart contract complexity for protocols like Ethereum Attestation Service (EAS) or Verax.

No Public Correlation: Revocation is checked via a hidden, incremented nonce. Verifiers see only a zero-knowledge proof of validity, not the credential's unique identifier. This is essential for privacy-first applications using zk-proofs (e.g., Sismo, World ID) where user activity must remain unlinkable.

Bounded On-Chain State: Only a single nonce value per issuer/credential schema is stored on-chain, regardless of how many credentials are issued. This provides massive scalability advantages for issuers like universities or DAOs deploying millions of credentials, avoiding the unbounded growth of a blocklist.

Unbounded Gas Costs & Storage: Adding entries incurs recurring write costs. Large blocklists become expensive to maintain and query. On networks like Ethereum Mainnet, this can be prohibitive for large-scale credential programs, creating a scaling bottleneck.

Inherent Latency: A credential remains valid until its next attestation uses the incremented nonce. This creates a revocation window where a compromised credential could still be used. Unsuitable for scenarios requiring guaranteed, instantaneous revocation.