On-chain storage is economically impossible for most credentials. Storing a single KB of data on Ethereum costs ~$1-5, which makes issuing millions of credentials for identity or loyalty programs a non-starter. This cost structure forces a move off-chain.
decentralized-identity-did-and-reputation
Blog
Why Verifiable Credentials Demand a Tiered Storage Approach
The naive approach of putting everything on-chain will kill decentralized identity. The W3C VC data model reveals a smarter path: a tiered architecture separating credentials, revocation, and issuer identity for scalable, private, and usable systems.
introduction
THE STORAGE TRAP
Introduction
Verifiable Credentials (VCs) fail at scale because their data model is incompatible with monolithic storage.
Off-chain storage creates a verifiability crisis. Storing data in centralized servers or IPFS breaks the cryptographic guarantee of the VC model. The credential's proof is only as reliable as its data availability, creating a single point of failure.
The solution is a tiered storage architecture. This separates the immutable proof (stored on-chain or in decentralized networks like Arweave) from the mutable data payload (stored in cost-effective, high-availability systems). This mirrors how rollups like Arbitrum separate execution from data availability on Ethereum.
Evidence: The W3C Verifiable Credentials Data Model standard explicitly defines a credentialStatus field, which is a built-in mechanism for implementing this tiered approach, pointing to an external registry for revocation and updates.
key-trends
WHY VERIFIABLE CREDENTIALS DEMAND A TIERED STORAGE APPROACH
The On-Chain Storage Trap
Storing all credential data on-chain is a naive and economically unsustainable design that cripples scalability and user experience.
01
The Gas Fee Death Spiral
Storing a single KB of data on Ethereum L1 can cost $50+ during congestion. For a system issuing millions of credentials, this creates a prohibitive cost barrier for users and issuers alike, making mass adoption impossible.\n- Cost: 1000x more expensive than decentralized storage.\n- Scale: A single credential issuance can cost more than its lifetime utility.
$50+
Per KB Cost
1000x
More Expensive
02
The Privacy Paradox
On-chain data is public and immutable. Writing personal credentials (e.g., diplomas, KYC data) directly to a public ledger is a catastrophic privacy failure, exposing users to permanent surveillance and data leaks.\n- Risk: Permanent exposure of sensitive PII.\n- Compliance: Violates GDPR/CCPA right to erasure by design.
0%
Privacy
Permanent
Exposure Risk
03
The Scalability Bottleneck
Blockchains are consensus engines, not databases. Forcing them to store bulk data cripples throughput and bloats state size, harming the network for all other users (see: Ethereum's state growth issues).\n- Throughput: Limits issuance to ~10-100 TPS on high-performance L2s.\n- State Bloat: Increases sync times and hardware requirements for nodes.
~100 TPS
Max Throughput
TB+
State Bloat
04
Solution: The Ceramic & IPFS Model
Decouple storage from consensus. Anchor only a cryptographic commitment (e.g., a Merkle root) on-chain while storing the credential data on decentralized networks like IPFS or Ceramic. This preserves verifiability without the cost.\n- Cost: Store 1MB for <$0.01.\n- Verifiability: Hash anchoring provides the same cryptographic guarantee.
<$0.01
Per MB Cost
Same
Verifiability
05
Solution: Layer-2 Credential Rollups
Use purpose-built L2s or app-chains (e.g., using Arbitrum Orbit, OP Stack) as a cost-optimized settlement layer. Batch thousands of credential updates into a single L1 proof, achieving ~$0.001 per transaction while inheriting Ethereum's security.\n- Cost: 10,000x cheaper than L1 settlement.\n- Security: Inherits Ethereum's consensus.
$0.001
Per Tx Cost
10,000x
Cheaper
06
Solution: Dynamic Storage Tiers
Implement a tiered system based on credential value and frequency of use. High-value, frequently verified credentials (e.g., DAO membership) live on an L2. Low-frequency, bulk data (e.g., audit logs) points to IPFS. This mirrors how Filecoin, Arweave, and Ethereum are used in practice.\n- Efficiency: Optimizes for both cost and access speed.\n- Flexibility: Protocol can adapt storage based on economic constraints.
Tiered
Optimization
Adaptive
Cost Control
thesis-statement
THE ARCHITECTURAL IMPERATIVE
Thesis: W3C's Model is a Blueprint for Tiering
The W3C Verifiable Credentials data model inherently requires a tiered storage architecture to separate proof from data.
Proofs require minimal, permanent storage. A Verifiable Credential's cryptographic proof must be stored on-chain or in a persistent decentralized network like Arweave or Filecoin for indefinite verification.
User data demands mutable, private storage. The credential's personal data payload belongs off-chain in user-controlled storage like Ceramic or a private server, enabling GDPR compliance and selective disclosure.
This separation defines the tiers. The W3C standard creates a natural bifurcation: Tier 1 for immutable proof anchors and Tier 2 for mutable, private data payloads.
Evidence: Ethereum's state growth problem demonstrates why storing all credential data on-chain is unsustainable; solutions like EIP-4844 proto-danksharding are explicitly designed for scalable data availability, not on-chain execution.
VERIFIABLE CREDENTIALS INFRASTRUCTURE
Tiered Storage Architecture: A Feature Matrix
Comparing storage strategies for verifiable credentials (VCs) and decentralized identifiers (DIDs), balancing cost, privacy, and verifier performance.
| Feature / Metric | On-Chain Storage | Decentralized Storage (IPFS/Arweave) | Centralized Cloud API |
|---|---|---|---|
Data Availability Guarantee | |||
Censorship Resistance | |||
Verifier Lookup Latency | 12-30 sec (block time) | 1-3 sec (pinned gateway) | < 200 ms |
Storage Cost per 1KB VC (1yr) | $5-15 (Ethereum L1) | $0.02-0.10 | $0.0002-0.001 |
Supports Selective Disclosure (ZKP) | |||
Requires Ongoing Trust Assumption | Smart contract security | Storage provider liveness | API operator honesty & uptime |
Revocation Mechanism | Smart contract update | Status List VC on storage | API flag update |
Interoperability with W3C DID Core | did:ethr, did:ion | did:web, did:key | did:web, Proprietary |
deep-dive
THE ARCHITECTURE
Building the Tiers: From Revocation Registries to Private Vaults
Verifiable Credentials require a multi-layered storage architecture to balance transparency, privacy, and cost.
On-chain revocation registries are mandatory. The trust anchor for a VC system is a public, immutable record of credential status. This requires a public, permissionless ledger like Ethereum or Solana to provide global, censorship-resistant verification.
Private claim data stays off-chain. Storing sensitive personal data on a public ledger violates privacy laws like GDPR. The credential payload resides in a user-controlled wallet or a decentralized storage layer like IPFS or Ceramic.
Hybrid systems use selective disclosure. Protocols like Iden3's zkProofs or Polygon ID allow users to prove credential validity without revealing the underlying data. This zero-knowledge layer bridges the public registry and private vault.
Cost dictates the tiered model. Storing 1KB of data on Ethereum L1 costs ~$1.50; storing it on Arweave costs ~$0.0005. The architecture separates cheap, permanent storage for proofs from expensive, mutable storage for state.
protocol-spotlight
THE DATA LAYER
Protocols Building the Tiered Future
Verifiable credentials and on-chain identity require a data architecture that separates ephemeral proofs from permanent attestations, creating a natural market for tiered storage.
01
The Problem: On-Chain is a Costly Ledger of Last Resort
Storing every credential's full data on-chain is economically impossible. A single 1MB soulbound token would cost ~$10,000+ on Ethereum L1. This forces a trade-off between decentralization and utility.
- Cost Prohibitive for mass adoption of rich identity data.
- State Bloat chokes node operators and increases sync times.
- Privacy Nightmare if all personal data is permanently public.
~$10k
Per 1MB File
1000x
Cost Multiplier
02
The Solution: Ceramic's Composable Data Streams
Ceramic Network provides off-chain mutable data streams anchored to a blockchain, creating a natural tiered system. The chain stores the pointer and update proofs; Ceramic nodes host the mutable data.
- Mutable & Versioned Data for credentials that expire or update.
- Decentralized Storage via a p2p network of nodes, not a single host.
- Interoperable Standards (DID, JSON-LD) enable composability across Disco, Gitcoin Passport.
>100k
Streams
-99%
vs On-Chain Cost
03
The Solution: Ethereum Attestation Service (EAS) Schema Economy
EAS decouples the attestation (a lightweight on-chain proof) from the attested data. The on-chain record is a hash pointer, while the detailed data lives off-chain (IPFS, Ceramic, private servers).
- Chain as Verifier: The immutable proof is cheap and permanent.
- Flexible Data Layer: Integrators choose their own cost/availability tier.
- Schema Registry creates a marketplace for reusable credential types, used by Optimism, Base, Gitcoin.
~$0.10
Per Attestation
2.5M+
Attestations
04
The Arbiter: Arweave's Permaweb as the Final Tier
For credentials that must be immutable and permanently available (e.g., academic degrees, foundational KYC), Arweave provides the final storage tier. Its endowment model guarantees one-time payment for eternal storage.
- Permanent Proof of Record: The credential's core hash is stored forever.
- Bundling Economics: Protocols like Bundlr batch data for cost efficiency.
- Settles to Base Layer: Acts as the decentralized hard drive for the credential stack.
~$5
Per GB (Forever)
100+ TB
Stored
counter-argument
THE VERIFIABILITY CONSTRAINT
Counterpoint: Isn't This Just Recreating Centralized Databases?
Verifiable Credentials require a tiered storage architecture because on-chain data is too expensive and off-chain data is not inherently trustworthy.
The core requirement is verifiability. A centralized database is opaque; you trust the operator. A Verifiable Credential's value is its cryptographic proof of authenticity, which requires an immutable anchor point. This forces a hybrid model where proofs live on-chain and bulk data lives off-chain.
On-chain storage is economically prohibitive. Storing a 1KB JSON credential directly on Ethereum costs ~$10. Storing millions of credentials for a national ID system is impossible. The solution is off-chain storage with on-chain verification, a pattern proven by systems like Arbitrum's data availability committee and IPFS with Filecoin proofs.
This creates a new trust spectrum. The system's security is not binary. It depends on the data availability layer and the proof system. Using a centralized HTTPS server for data is weak. Using Celestia or EigenDA for data availability with a zk-proof of custody is robust. The architecture is defined by this trade-off.
Evidence: The W3C Verifiable Credentials Data Model standard explicitly separates the credential (data) from the proof (signature). Implementations like Microsoft's ION use the Bitcoin blockchain for anchoring decentralized identifiers (DIDs), while credential data is stored in a user-controlled hub, demonstrating the tiered model in production.
takeaways
ARCHITECTURE PATTERNS
Key Takeaways for Builders
Verifiable Credentials (VCs) are not a monolith; their utility and security are dictated by the data layer. A one-size-fits-all storage model is a critical design flaw.
01
The On-Chain Fallacy: Why Full Storage Fails
Storing all credential data on-chain is a naive solution that destroys scalability and privacy. It treats a ~1KB proof the same as its ~10MB underlying dataset (e.g., KYC documents, medical images).\n- Cost Prohibitive: Storing 1MB on Ethereum L1 costs ~$10k+ at $20/gas, making mass adoption impossible.\n- Privacy Catastrophe: Immutable public ledgers leak PII, violating GDPR and CCPA by design.
10,000x
Cost Diff
0%
Privacy
02
The Tiered Data Stack: Proofs, Pointers, Payloads
Separate the cryptographic proof, the data pointer, and the data payload into distinct layers with appropriate security guarantees. This mirrors how zkRollups (like zkSync) separate proof verification from data availability.\n- Layer 1 (Proof): Anchor the cryptographic hash & proof on-chain. This is the ~1KB trust root.\n- Layer 2 (Pointer): Use a decentralized storage pointer (e.g., IPFS CID, Arweave TX ID).\n- Layer 3 (Payload): Store the full credential data in cost-appropriate storage (Ceramic, Filecoin, private servers).
1KB
On-Chain
10MB+
Off-Chain
03
Selective Disclosure Demands Selective Retrieval
Zero-Knowledge Proofs (ZKPs) for VCs require fetching only specific data attributes to generate a proof, not the entire credential blob. A tiered model enables this efficiently.\n- ZK-Circuit Efficiency: Fetch only the specific JSON-LD field needed for the proof from the off-chain payload, minimizing I/O.\n- Gateway Abstraction: Implementers can use services like Tableland for structured querying or Lit Protocol for conditional decryption, without altering the core storage architecture.
~100ms
Proof Gen
ZK
Privacy
04
The Interoperability Mandate: W3C & DIF Standards
Storage choices must not create walled gardens. Adherence to W3C Verifiable Credentials Data Model and DIF's Sidetree protocol (used by ION) ensures credentials are portable across chains and issuers.\n- Universal Resolvers: Builders should support Decentralized Identifiers (DIDs) that resolve to documents across storage backends.\n- Avoid Vendor Lock-in: A credential stored via this tiered model should be verifiable by any compliant verifier, whether the payload is on IPFS, AWS S3, or a personal server.
W3C
Standard
DID
Portable
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