Decentralized Storage in ZKID
Decentralized storage is a foundational component of ZKID’s architecture. Solana provides speed and execution, Bitcoin provides immutability, but neither chain is suited for storing large identity documents or credential metadata.
ZKID resolves this by using a hybrid decentralized storage model, optimized for:
cost-efficiency
permanence
verifiability
privacy
cross-chain consistency
ZKID storage covers all identity-related data, including:
DID Documents
VC metadata
ZK proof artifacts
issuer signatures
state snapshots for validators
Why ZKID uses decentralized storage
✅ 1. Efficiency
Storing full documents on-chain is not feasible. By storing only hashes on Solana, and documents off-chain:
the blockchain remains lean
the user retains data ownership
large identity data is distributed optimally
✅ 2. Privacy
Full DID documents may contain:
service endpoints
public key rotation history
VC references
credential issuance metadata
Storing this encrypted off-chain preserves confidentiality.
✅ 3. Scalability
Identity systems scale linearly with users. Solana supports it, but permanent data must not inflate account state.
Externally attached, cryptographically linked storage solves this.
ZKID Storage Architecture
+-------------------------------+
| Bitcoin Anchor Layer |
| - Immutable State Roots |
+-------------------------------+
│
▼
+-------------------------------+
| Solana Smart Contract Layer |
| - Hash references |
| - DID mappings |
| - VC validity flags |
+-------------------------------+
│
▼
+---------------------------------------+
| Decentralized Storage Layer |
| - Arweave (permanent) |
| - IPFS (redundant) |
| - Filecoin (pinned) |
| - encryption optional |
+---------------------------------------+
│
▼
+-------------------------------+
| Client Layer |
| - DID wallets |
| - VC holder apps |
| - dApps & verifiers |
+-------------------------------+Identity Storage Workflow (extended)
Step 1: DID Document Creation
Generated locally by the user:
keys
DID identifier
metadata
service endpoints
Stored temporarily in memory.
Step 2: Document Hashing
The client computes:
CID = SHA256(DID_Document)This CID becomes the reference stored on-chain.
Step 3: Off-Chain Upload
Depending on configuration:
Arweave → permanent
IPFS → fast, distributed
Filecoin → incentivized redundancy
Step 4: On-Chain Recording
Solana contract stores:
CID
timestamp
owner address
optional encryption reference
Step 5: Periodic Bitcoin Anchoring
Validators periodically submit a batched root of DIDs + CIDs.
Storage Format Example: DID Document JSON
{
"id": "did:zkid:12ab34",
"publicKeys": [
{
"id": "key-1",
"type": "ed25519",
"publicKeyBase58": "Cn2...8qz"
}
],
"service": [
{
"type": "Messaging",
"endpoint": "https://relay.zkid.io"
}
],
"updated": "2025-06-30T19:21:00Z"
}Smart Contract Example (Solana/Anchor)
#[account]
pub struct DidStorage {
pub cid: [u8; 32],
pub owner: Pubkey,
pub created_at: i64,
}
pub fn store_document(ctx: Context<StoreDocument>, cid: [u8; 32]) -> Result<()> {
let storage = &mut ctx.accounts.did_storage;
storage.cid = cid;
storage.owner = ctx.accounts.user.key();
storage.created_at = Clock::get()?.unix_timestamp;
Ok(())
}Security & Redundancy Strategy
ZKID includes:
multi-region Arweave redundancy
optional encrypted Blob format
automatic IPFS pinning
periodic validation sweeps
re-verification of CIDs vs stored content
Decentralized storage is not optional — it's essential.
ZKID uses:
Solana (hashes + references)
Arweave/Filecoin/IPFS (data)
Bitcoin (finality & anchoring)
Result: Efficient, private, distributed user-owned identity storage.
Last updated