Reusable Credentials
The traditional identity verification model forces users to undergo repetitive KYC (Know Your Customer) or verification checks for every new service they use. This creates friction for the user, increases drop-off rates for the service provider, and unnecessarily duplicates sensitive data across multiple databases.
zkMe’s Credential System solves this through Reusable Credentials, allowing a user to verify their identity once and prove it infinitely across the Web3 ecosystem.
The “Verify Once, Prove Anywhere” Paradigm
When a user completes a verification process (e.g., scanning a passport, verifying a bank account) through zkMe, the underlying data is not sent to the requesting application. Instead, it is processed to create a Verifiable Credential (VC).
This credential is encrypted and stored locally in the user’s Self-Sovereign Identity (SSI) Wallet. The cryptographic commitment to this credential is then anchored on-chain via a Sparse Merkle Tree managed by the State Contract.
From that point forward, the user owns a reusable asset.
How Reuse Works in Practice
User Bob wants his AI Financial Advisor to apply for a DeFi lending protocol that requires Proof-of-Credit Score (PCS).
Initial Issuance
User Alice wants to join Protocol A, which requires KYC. She goes through the zkMe flow: her passport is scanned, her facial features are verified via FHE, and a zkKYC credential is issued to her wallet. Protocol A receives a zero-knowledge proof that she passed. The credential's cryptographic commitment is anchored on
Benefits of Reusable Credentials
For Users
Frictionless Experience. Eliminates the annoyance of repeated document uploads and selfie scans. One-click onboarding becomes a reality for compliance-gated applications.
Enhanced Privacy. Raw data is never shared. By reusing a credential via ZKPs, users maintain complete control over their personal information. Each proof reveals only the minimum necessary claim.
Data Sovereignty. The user holds the credential. If they decide to stop using a service, that service does not retain a copy of their passport or any PII.
For Developers / Verifiers
Higher Conversion Rates. Removing the KYC bottleneck drastically improves user acquisition and conversion metrics. Users who already hold a valid zkMe credential can onboard in seconds instead of minutes.
Reduced Compliance Costs. Verifiers do not need to pay a KYC provider for every user if the user already holds a valid zkMe credential. They only pay the minimal gas cost of verifying the proof on-chain.
Zero Data Liability. Because the Verifier only receives a cryptographic proof (a boolean result), they do not store PII, significantly reducing their regulatory burden and risk of data breaches.
Technical Implementation of Reuse
Reusability is technically enforced through the combination of the W3C Verifiable Credentials standard, Sparse Merkle Trees, and Zero-Knowledge Proofs. Understanding the underlying mechanism requires familiarity with the Credential System Core Concepts, particularly the Claim Tree model and the on-chain State Contract.
Claim Tree and Merkle Commitment
When a credential is issued, its individual claims (e.g., “age > 18”, “citizenship = US”, “not_sanctioned = true”) are inserted as leaves into a Sparse Merkle Tree using the Poseidon hash function. The root of this tree, the Claim Tree Root, is the single cryptographic commitment that represents the entire credential.
This Claim Tree Root is then published to the on-chain State Contract, which maintains a global Identity State Tree mapping each user’s DID to their current Claim Tree Root.
The critical insight for reusability is: the Claim Tree Root is chain-agnostic. It is a pure mathematical value (a hash) that does not depend on which blockchain it is stored on. This means the same credential commitment can be verified against any chain where the State Contract (or a relay of it) is deployed.
Context-Specific Proof Generation
While the underlying credential is the same, every proof generated from it is unique to the specific verification context. This is achieved through several mechanisms:
Verifier-Specific Challenge (Nonce). Each Verifier provides a unique challenge nonce when requesting a proof. The ZK circuit includes this nonce as a public input, binding the proof to the specific Verifier and interaction. A proof generated for Protocol A cannot be intercepted and replayed to Launchpad B, because the nonce will not match.
Timestamp Binding. The proof includes a timestamp that is checked against the credential’s expiration date and the current block time. This prevents the use of stale proofs.
Selective Claim Disclosure. The user can choose which claims from the Claim Tree to include in the proof. When reusing a credential for a different Verifier, the user may disclose different claims. For example, Protocol A may require proof of age, while Launchpad B may require proof of jurisdiction. Both proofs are generated from the same credential, but they reveal different (and minimal) information.
For details on how selective claim disclosure works at the circuit level, see Selective Disclosure.
Cross-Chain Portability via Delegate Contracts
The zkMe smart contract architecture includes a Delegate contract pattern that enables cross-chain credential portability:
State Contract (Source Chain). The authoritative source of the user’s Claim Tree Root. This is where the credential was originally anchored (e.g., Polygon).
Cross-Chain Relay. A message-passing mechanism that propagates the Claim Tree Root from the source chain to target chains. This can use native bridge protocols or third-party relay services.
Delegate Contract (Target Chain). A lightweight contract deployed on the target chain that caches the relayed Claim Tree Root. When a Verifier on the target chain requests proof verification, the Verification Contract checks the proof against the Delegate Contract’s cached root.
This architecture means the user does not need to re-anchor their credential on every chain they want to use. The credential is issued once, anchored on one chain, and the root is relayed to all supported chains.
For the full list of chains where zkMe contracts are deployed, see Supported Chains. For details on the smart contract architecture, see Smart Contracts.
Proof Verification Flow (Cross-Chain)
When a Verifier on a target chain requests proof from a user:
Revocation and Expiration
Reusability requires robust lifecycle management. If a credential becomes invalid, it must cease to be reusable across all chains and all Verifiers simultaneously.
Expiration
Credentials have built-in expiration dates derived from the underlying document (e.g., a passport expiration date) or from the Issuer’s policy (e.g., “KYC valid for 12 months”). The expiration timestamp is embedded as a claim in the Claim Tree and is checked by the ZK circuit during proof generation.
Client-side enforcement: The SSI Wallet checks the expiration before generating a proof. If the credential is expired, the wallet refuses to generate a proof and prompts the user to re-verify.
Circuit-level enforcement: Even if a malicious client bypasses the wallet check, the ZK circuit itself validates the expiration timestamp against the current time. An expired credential will produce an invalid proof.
Revocation
If an Issuer discovers a credential was issued fraudulently or needs to be invalidated (e.g., a passport is reported stolen), they can revoke it by updating the on-chain Revocation Tree in the State Contract. The revocation is propagated to all Delegate Contracts via the cross-chain relay.
When the user (or an agent acting on the user’s behalf) attempts to reuse the credential:
The Verification Contract queries the Revocation Tree.
If the credential’s revocation nonce is found in the tree, the verification fails.
The revocation is effective across all chains simultaneously (subject to relay latency).
For details on the Revocation Tree data structure, see Core Concepts.
Reusable Credentials in the Agent Economy
Reusable Credentials are particularly powerful in the Agent Economy. When a user delegates authority to an AI agent via Agent-Ready Credentials, the agent can reuse the user’s underlying credential across multiple platforms in a single session.
Example: A user authorizes an AI trading agent to operate across three DeFi protocols. The agent connects to each protocol, and for each one, the Agent Trust Gateway generates a context-specific proof from the same underlying credential. The user verified once; the agent proves three times, on three different platforms, potentially on three different chains, all within a single automated workflow.
Last updated