Verifiable Credentials (VCs) vs. Soulbound Tokens (SBTs): The Architect’s Guide

In 2022, Vitalik Buterin, Glen Weyl, and Puja Ohlhaver published a paper titled "Decentralized Society: Finding Web3's Soul," introducing the concept of Soulbound Tokens (SBTs). The idea was poetic: non-transferable tokens that represent your commitments, credentials, and reputation—your "digital soul" on-chain.

For the crypto community, it was a revelation. For enterprise architects and privacy engineers, it was a red flag.

As an architect designing a decentralized identity system, you face a binary choice at the foundation level:

1. Soulbound Tokens (SBTs): Public, on-chain tokens that bind identity to a wallet address permanently.
2. Verifiable Credentials (VCs): Private, off-chain data objects that live in a user's wallet and are selectively disclosed.

This is not just a syntax difference; it is a fundamental difference in identity management philosophy. SBTs optimize for public reputation and composability within smart contracts. VCs optimize for data privacy, regulatory compliance, and data minimization.

Choosing the wrong primitive is not a tech debt you can refactor later; it is a permanent architectural flaw that can render your system hard to defend under GDPR or unsafe for high-value use cases like electronic health records.

Unlike traditional systems that require users to log in through a centralized provider, VC-based identity lets the user present a signed proof directly to the verifier. This shifts control back to the edge, but it demands rigorous architectural planning.

This guide is the decision framework for CTOs. We will tear down the architecture of both standards, analyze their data storage and security posture, and provide a clear checklist for when to use which.

The Architectural Decision: A Framework for Builders

We are moving beyond definitions to operational reality. Before writing a single line of code, you must answer three questions: Where does the data live? Who controls the key? And what happens when (not if) a key is compromised?

What Problem Are You Solving: Access Control, Reputation, or Compliance?

If your goal is reputation—showing off a POAP (Proof of Attendance Protocol) or a "DAO Voter" badge—public visibility is a feature. You want people to scrape the blockchain technology and see that this wallet is active.

If your goal is compliance or access control—proving a user is accredited, over 18, or an employee—public visibility is a bug. You cannot broadcast personal data to a global ledger.

The Core Constraint: Data Security and Minimization vs. On-Chain Permanence

The core conflict is between data security (keeping secrets) and on-chain permanence.

• SBTs inherit the properties of the blockchain: they are immutable and public by default.

• VCs inherit the properties of secure messaging: they are private and transient.

  An architect must decide: Does this data need to be on a public ledger? If the answer is "no," placing it there introduces unnecessary liability.

Quick Decision Matrix: When VCs Win, When SBTs Win

• Use SBTs when: The data is public by nature (e.g., "I attended ETHDenver"), the user wants it to be seen by everyone, and revocation is rare.
• Use VCs when: The data is private (e.g., Driver's License), the user needs to share it with specific verifiers only, or you need strict GDPR compliance.

Key Takeaways for Architects

• Storage: VCs live in user wallets (off-chain). SBTs live on the blockchain (on-chain).
• Cost: VCs are free to mint (just signing JSON). SBTs cost gas to mint.
• Privacy: VCs support selective disclosure via zero knowledge proofs. SBTs are all-or-nothing.

From a computer science perspective, the design is a trade-off between public composability and private verification. In self sovereign identity architectures, the core components are stable: identifiers, credentials, wallets, revocation, and verifier policy. The proposed system should prioritize user experience, because the best crypto primitives fail in the real world if the user flow is confusing.

Comparison Table: VCs vs. SBTs at a Glance

Verifiable Credentials (VCs): How They Work in Practice

Verifiable credentials are a widely adopted web standard for digital identity. They mimic physical credentials (like a passport) but are cryptographically secure.

VC Data Model: Claims, Issuer, Subject, Proof

A VC is a structured JSON-LD document containing:

• Issuer: The decentralized identifier (DID) of the entity signing the data (e.g., University).
• Subject: The DID of the user receiving the data.
• Claims: The actual data (e.g., "degree": "Bachelor of Science").
• Proof: The digital signature that makes it tamper-evident.

Digital Signature: What Is Actually Signed and Verified

The digital signature wraps the entire payload. The Issuer signs the hash of the claims using the issuer's private key.

When a Verifier receives a VC, they don't check a database. They verify the signature mathematically using the Issuer's public key (found in their DID document). This ensures data integrity without "phoning home" to the issuer.

VC Wallets and Secure Storage: Local Wallet vs Cloud Computing

VCs typically live in an identity wallet on the user's device (Edge Storage).

However, for enterprise use, they can be stored in cloud computing vaults or Encrypted Data Vaults (EDVs). The key distinction is that the User controls the access keys, not the cloud provider. This prevents the cloud host from seeing the private data.

Off-Chain Verification: Why Most VC Checks Happen Off-Chain First

99% of VC interactions happen off-chain.

The User sends the VC directly to the Verifier (via QR code, Bluetooth, or HTTPS). The blockchain is only used to resolve the DIDs. This creates a peer-to-peer trust model that scales infinitely because it doesn't congest the decentralized networks or require gas fees for verification.

Zero Knowledge Proofs: Selective Disclosure Without Exposing Underlying Data

Using Zero Knowledge Proofs (like BBS+ signatures or AnonCreds), VCs allow selective disclosure.

A user can prove they are "Over 18" derived from a Driver's License VC without revealing their actual birthdate or address. This is the holy grail of data minimization—proving a fact without revealing the underlying data.

Soulbound Tokens (SBTs): What They Are (and What They’re Not)

Soulbound tokens are non-transferable NFTs. They are standard ERC-721 or ERC-1155 tokens with the transfer function disabled.

SBTs as an On-Chain Badge: Benefits and Irreversible Exposure Risk

SBTs are powerful because they are "native" to Web3. Any smart contract can read an SBT without needing off-chain infrastructure.

However, this creates irreversible exposure risk. Once you mint an SBT saying "I am KYC'd," that link between your wallet and your real identity is permanent. You cannot "un-mint" history on a blockchain. Even if you burn the token, the historical record remains on archival nodes.

SBTs and Non-Fungible Tokens: Where the Lineage Overlaps (and Breaks)

SBTs share the lineage of non fungible tokens (NFTs). They use the same metadata standards and indexing tools (like The Graph or OpenSea).

This makes them easy to integrate but hard to govern. Unlike a VC, which expires or can be deleted, an SBT is a permanent artifact in the wallet.

Smart Contract Design Assumptions: Permanence, Public Visibility, Indexing

Smart contracts assume data is public. If you put pointers to an electronic health record or credit score in an SBT, bots will scrape them. Even if the data is encrypted, the metadata (e.g., "User received a diabetes-related token") leaks sensitive context.

The Mismatch with Regulated Identity: Consent, Revocation, Portability

Regulated identity requires:

1. Consent: The user must explicitly agree to share data.
2. Revocation: The issuer must be able to cancel the credential instantly.

3. Right to be Forgotten: The user must be able to delete the data.

   SBTs struggle with all three. You can't delete data from a blockchain (violating GDPR). You can't easily revoke a token without gas costs.

Where the data is intentionally public, SBTs can support censorship resistance: a badge or participation signal can remain verifiable without a central server or centralized authorities acting as gatekeepers.

Decentralized Identity Requirements (Architecture Checklist)

Decentralized Identity Is a System, Not a Token

Decentralized identity requires a full stack: Identifiers (DIDs), Credentials (VCs), and Wallets. Trying to compress this entire stack into a single token (SBT) forces compromises on privacy and scalability.

Decentralized Identifier (DID) as the Anchor, VC as the Payload

In a robust architecture, the decentralized identifier is the anchor. The VC is the payload attached to that anchor.

SBTs try to make the account address the anchor and the Token the payload. This is fragile because account addresses are not persistent (users lose keys, migrate wallets).

Trust Model: Issuer Credibility vs. Verifier Policy

Who do you trust?

In VCs, the trust is explicit: "I trust this Issuer's signature."

In SBTs, the trust is implicit: "I trust this smart contract address."

For identity management, explicit trust logic is safer and more flexible.

User Control: Key Custody, Rotation, Recovery Paths

What happens if keys are lost?

• VCs: User restores from backup or gets re-issued credentials to a new DID.
• SBTs: The tokens are stuck in the lost wallet forever. "Soul recovery" mechanisms exist (e.g., social recovery wallets), but they are complex to implement.

Consent and Disclosure Boundaries

The architect must define the "Red Line."

Social Security Numbers, physical addresses, medical diagnoses, and financial balances must never be on-chain, even encrypted. The risk of future decryption (quantum computing) is too high.

Identity Management: VC Stack vs. SBT Stack

Identity Management in VC Systems: Issuer/Holder/Verifier Separation

VC systems strictly separate roles. The Issuer does not know when the User presents the credential. The Verifier does not need to contact the Issuer.

This prevents the "Phone Home" problem of centralized identity management and ensures privacy.

Identity Management in SBT Systems: Token Issuer + Chain as Distribution Layer

In SBT systems, the Issuer mints the token directly to the Holder. The blockchain acts as the distribution layer.

This is simpler (no need for a wallet app that supports VCs), but it couples the Issuer to the Holder permanently.

VC Status, Revocation, and Expiration (What Verifiers Actually Check)

One of the most critical—and often overlooked—aspects of identity verification is revocation. How do you know a credential is still valid?

Expiry Dates and TTL (Time To Live)

Most VCs have an expirationDate.

• Short-Lived: A "Session VC" might last 1 hour.

• Long-Lived: A "University Degree VC" might never expire.

  Verifiers check this date first. If now > expirationDate, the credential is rejected immediately, without checking the blockchain.

Status Lists and Bitstrings

For revocation, we use a Revocation Registry.

The most efficient standard is Status List 2021.

1. The Issuer maintains a bitstring (e.g., 000100...) on IPFS or a smart contract.
2. Each VC is assigned an index (e.g., #3).
3. If the Issuer wants to revoke VC #3, they flip the bit at index 3 from 0 to 1.

4. The Verifier fetches the bitstring and checks the bit at index 3.

   This allows verifying revocation off-chain without leaking why it was revoked or who owns it.

Data Integrity and Regulatory Compliance

This mechanism is crucial for regulatory compliance.

If a driver's license is suspended, the digital version must be revoked instantly. Status Lists provide a globally scalable, privacy-preserving way to enforce data integrity across the network.

Three Common Architectures: Pure Off-Chain, ZKP Bridge, and Soulbound

To help you visualize the implementation, here are three distinct architectural patterns.

Pattern A: Pure Off-Chain (The "Face-to-Face" Model)

This is the most common pattern for decentralized identity systems.

1. Issuance: Issuer sends VC to User's Wallet (Off-chain).
2. Presentation: User presents VC to Verifier via QR Code (Off-chain).

3. Verification: Verifier checks DID on-chain, checks Status List, and validates signature.

   Best For: Physical access, Age verification, Employee login.

   Pros: Zero gas, high privacy, GDPR compliant.

   Cons: Not composable with smart contracts.

Pattern B: The "ZKP Bridge" (Off-Chain Data, On-Chain Proof)

This is the "Holy Grail" for DeFi.

1. Issuance: Issuer sends VC to User's Wallet (Off-chain).
2. Proof Generation: User generates a Zero-Knowledge Proof (ZKP) locally: "I have a valid VC from Issuer X."
3. Submission: User submits the ZKP to a Smart Contract Verifier.

4. Execution: Smart contract verifies the proof and grants access.

   Best For: DeFi permissioned pools, Airdrop sybil resistance.

   Pros: Privacy-preserving, on-chain composability.

   Cons: High gas cost for proof verification.

Pattern C: The "Soulbound" (Public Data)

This is the "Web3 Native" model.

1. Issuance: Issuer mints SBT to User's Wallet Address (On-chain).

2. Discovery: Smart contracts and indexers read the token balance.

   Best For: Gaming achievements, DAO voting rights, POAPs.

   Pros: Maximum composability, easy developer experience.

   Cons: Zero privacy, permanent history, high gas cost.

Data Storage: Where Verifiable Credentials vs. Soulbound Tokens Store Data

Understanding data storage is critical for compliance.

Data Storage in VC Systems: Wallet, Enclave, and Off Chain Storage Solutions

VCs are flexible and utilize off chain storage solutions.

• Local Storage: Credentials are stored locally in the user's mobile enclave (e.g., Secure Element).
• Encrypted Data Vaults (EDVs): User-controlled cloud databases (like Identity Hubs) for backup and sync.

• Decentralized Storage: Using IPFS or Arweave for large credential payloads, encrypted with the user's keys.

  The data storage is decoupled from the verification logic. This means you can store terabytes of credentials without paying gas fees.

In most deployments, credentials are stored off chain and selectively shared at presentation time. That “stored off chain” pattern is what keeps identity data out of global indexers and reduces accidental exposure.

SBT Storage Reality: Smart Contracts, Token Metadata, and Decentralized Storage

SBTs are limited by the blockchain's storage costs.

• On-Chain Storage: Storing data directly in the smart contract storage slots. Extremely expensive and public.
• Token Metadata: Storing a URI pointer (e.g., ipfs://...) in the token.

• Decentralized Storage: The actual data usually lives on IPFS.

  SBT storage reality is that everything is publicly queryable. Anyone running a node can call tokenURI(). If you store PII here, or even a pointer to PII, you have caused a global data breach. Even if the data is off-chain, the link to the data is public and immutable.

On-Chain Pointers vs. Off-Chain Payloads: What Is Safe to Anchor

The only safe thing to put on chain is a cryptographic anchor (a root hash).

SBTs often put the pointer to data on-chain. If that pointer leads to a public JSON file, the data is public. VCs keep the entire payload off-chain and only use the chain for DID resolution.

Data Minimization: Storing Only Proofs vs. Storing Raw Attributes

VCs allow you to store the raw attributes off-chain and only send zero knowledge proofs to the verifier.

SBTs force you to tokenize the attribute itself, making data minimization difficult. You cannot share "just the age" from an SBT; you share the whole token.

Centralized Databases vs Decentralized Database Designs in Identity Systems

Traditional identity relies on centralized databases (SQL).

VCs enable a decentralized database design where every user's wallet is a "shard" of the global database.

SBTs rely on the blockchain as a shared, public database.

For security posture, the VC model is superior because a breach of one "shard" (one user's wallet) does not compromise the entire system.

Encrypted Data and Breach Blast Radius

• VC Breach: If a user's phone is hacked, only their credentials are leaked. The breach is contained to one user.
• SBT Exposure: If the Issuer's private key is hacked, they can rogue-mint SBTs to anyone. If the contract is buggy, all encrypted data (if stored on-chain) could be exposed if the decryption key is leaked.

On-Chain vs. Off-Chain Verification: Smart Contracts and Access Permissions

This is the operational trade-off: Latency vs. Trust.

On-Chain Verification: Smart Contracts and Access Permissions

You only need on chain verification if a smart contract needs to make a decision autonomously.

• Business Logic: A DeFi pool's business logic requires checking "Is Accredited?" before allowing a deposit.

• Access Permissions: An NFT gate checks "Does wallet hold Token X?" before granting access.

  For these use cases, SBTs are native. They exist in the same state machine as the application. VCs require a "ZK Verifier" contract to verify the proof on-chain, which is gas-heavy.

Off-Chain Verification: The Default for Compliance-Grade Identity

Most compliance checks (Login, HR, Physical Access) happen off-chain.

• Off-Chain Verification: The Verifier is a server or a door lock. It checks the digital signature locally.
• No Gas Fees: Zero cost to verify.

• Privacy: No record of the verification event is written to the chain.

  Using a blockchain for these interactions is overkill. VCs map better to this requirement. The verification happens on the verifier's server or device.

Hybrid Flows: Off-Chain Verification + On-Chain Authorization Gates

The best pattern for complex apps is Hybrid:

1. Verify VC off-chain (privacy-preserving check).

2. Issue a temporary "Session Token" or "Auth SBT" on-chain for the session.

   This keeps the private data off-chain while allowing smart contract composability.

Latency and UX: Wallet Prompts, Session Proofs, Caching Strategies

VC verification is instant (milliseconds).

SBT verification requires reading the blockchain (latency depends on block time) and indexing.

User interactions in VC flows feel like Apple Pay (Touch ID to share). SBT flows feel like a crypto transaction (Sign, Wait for Block).

Failure Modes: Stale Proofs, Replay Risk, Revoked Credentials

• SBT: Always fresh (read from state).
• VC: Can be stale. Verifier must check the revocation registry.

Data Security Threat Model (What Breaks First)

Security is about the weakest link.

Data Security for VC Wallets: Device Compromise, Phishing, Backup Leakage

The weak point of VCs is the user's device. If they lose the phone without a backup, the identity is gone. Data protection relies on the user's hygiene.

Threat: A user installs a malicious app that scrapes their wallet.

Mitigation: Use hardware-backed enclaves (Secure Enclave) that prevent key extraction.

Data Security for SBTs: Correlation, Scraping, Permanent Profiling

The weak point of SBTs is correlation. By analyzing the graph of SBTs in a wallet, AI can de-anonymize the user. This is "Permanent Profiling."

SBTs facilitate "doxing" by aggregating too much public signal in one account address.

Threat: An attacker correlates your "DeFi Degen" SBT with your "KYC'd User" SBT to link your real identity to your trading history.

The risk is higher on widely monitored networks: ethereum addresses are heavily indexed, clustered, and labeled. If an identity signal is tied to ethereum addresses, correlation becomes easier and long-term profiling gets cheaper.

Smart Contract Security: Mint Authority, Upgrade Keys, and Governance Risk

SBTs introduce smart contract security risks.

• Mint Authority: If the admin key is stolen, the attacker can mint fake credentials.
• Upgrade Keys: If the contract is upgradeable, a malicious upgrade can change the business logic.
• Governance Risk: If a DAO controls the SBT contract, a governance attack could alter identity rules.

Private Keys and Digital Signature Flows in Identity Verification

Both systems rely on private keys.

• VCs: The user signs a presentation.

• SBTs: The user signs a transaction to burn/mint (if allowed).

  For high-value use cases like electronic health records, relying on a user to secure a key is risky. Enterprise MPC (Multi-Party Computation) wallets are required to prevent key loss.

Operational Controls: Monitoring, Incident Response, Revocation Playbooks

You need a playbook: "What if the Issuer key is compromised?"

With VCs, you rotate the DID key. With SBTs, you might need to redeploy the contract, breaking all integrations.

Regulated Use Cases (Where Architects Get Burned)

KYC/KYB Claims: Why “Proof of Verification” ≠ Publishing Identity

For KYC, never use SBTs.

If you issue an "Is KYC'd" SBT, you tag that wallet as a "Real Person." Hackers now know who to target. Use VCs for the check, and internal allowlists for granting access.

Electronic Health Record Credentials: When Privacy Requirements Are Non-Negotiable

Electronic health records are protected by HIPAA.

Placing health data (or pointers to it) on a public chain via SBTs presents a high risk of non-compliance due to the inability to strictly control access and deletion.

VC Architecture: The hospital issues a VC. The patient stores it in a secure wallet. The patient shares it with a specialist via a direct, encrypted channel.

SBT Architecture: (Dangerous) The hospital mints a token pointing to an IPFS file. The link is immutable. Access control relies on encryption keys that might be lost or leaked.

Enterprise Access: Employee Credentials and Role-Based Permissions

For Employee ID, VCs align closer with role-based access control. When an employee leaves, you revoke the VC.

With SBTs, the "Ex-Employee" carries the token history forever, which is a security risk for physical access control.

Supply Chain Management Credentials: When Public Verifiability Helps

In supply chain management, you might want public visibility (Provenance).

Here, SBTs or NFTs are acceptable because the "Identity" is a product, not a person. Products don't have privacy rights. Supply chain management benefits from the public transparency of blockchain technology to prove that a coffee bean came from a specific farm.

Cross-Platform Interoperability and Legal Defensibility

VCs are legally defensible as "Digital Documents." SBTs are legally ambiguous (are they property? data?). VCs allow for cross-platform interoperability because they are based on open web standards (W3C), not just Ethereum standards.

Compatibility With Blockchain Technology (Interoperability Reality)

Blockchain Technology Constraints: Composability vs. Privacy Leakage

Blockchain technology forces transparency. This is great for finance, bad for privacy.

SBTs embrace blockchain constraints to gain composability. VCs bypass them to gain privacy.

Across different blockchain platforms, the pressure is the same: smart contract logic wants public signals, while compliance wants private data. This is why the existing literature keeps converging on hybrid models rather than pushing everything into a single primitive.

Wallet Support: VC Wallets vs. Token Wallets (Tooling Maturity)

• Token Wallets: MetaMask, Phantom (Support SBTs natively).

• VC Wallets: Microsoft Entra, specialized apps (Support VCs).

  Tooling for SBTs is currently more mature in the crypto space, but VC wallet adoption is growing in enterprise.

Indexers and Analytics: Why Public Data Becomes Permanent Metadata

Once an SBT is indexed by Etherscan or Dune, it is permanent metadata. You cannot scrub it. This permanence is a feature for art, but a bug for identity.

Cross-Chain Portability: VC Advantage vs. SBT Fragmentation

VCs travel with the user. SBTs travel with the chain.

A VC in your phone works on any chain that supports DIDs. An SBT on Ethereum is stuck on Ethereum.

Standards Gravity: W3C VC vs. Ad-Hoc Token Standards

W3C VCs are a widely adopted web standard.

SBTs are a loose collection of Ethereum proposals (EIPs). For long-term corporate strategy, bet on W3C.

Implementation Checklist for Identity Architects

If you are building an identity stack, here is your roadmap.

Choose VC When You Need Consent + Revocation + Minimal Disclosure

• Check: Is PII involved?
• Check: Does the user need to carry this across apps?
• Check: Is GDPR a concern?
• Decision: Deploy W3C Verifiable Credentials.

Choose SBT When the Goal Is Public Reputation and Public Verifiability

• Check: Is this a "Badge of Honor"?
• Check: Is the data non-sensitive?
• Check: Do smart contracts need to read it directly?
• Decision: Deploy ERC-5192 Soulbound Tokens.

Decide Storage: Wallet-Only vs. Encrypted Vault vs. Cloud Backup (Cloud Computing)

Don't rely on the user's phone storage alone. Implement an Encrypted Data Vault (EDV) strategy using cloud computing for backup.

Decide Verification: On-Chain Gate vs. Off-Chain Policy Engine

If you can, verify off-chain. It's cheaper and faster. Only move to on-chain verification for high-value DeFi transactions.

Decide Recovery + Key Rotation (What Happens When Keys Are Lost)

Build for failure. Implement Social Recovery or MPC from day one. User empowerment comes from the ability to recover one's own identity without a central helpdesk.

Conclusion: The Clean Decision Frame

The choice between Verifiable Credentials and Soulbound Tokens is the single most important architectural decision in your identity stack.

SBTs are powerful tools for public reputation and community signalling. They are "loud" identity—perfect for showing the world what you have achieved.

VCs are the necessary infrastructure for private compliance and regulated access. They are "quiet" identity—perfect for proving who you are without revealing everything.

For the enterprise architect, the rule is simple: If it touches PII, data security, or regulation, use VCs. If it touches community, loyalty, or gaming, consider SBTs.

Do not confuse the two. Building a compliance system on SBTs is building a glass house in a public square: transparent, permanent, and shattered by the first privacy audit.

Frequently Asked Questions (FAQ)

What are verifiable credentials in plain terms?

Verifiable credentials are digital versions of physical cards (like a passport or driver's license) that live in your phone. They are cryptographically signed by the issuer, so anyone can verify they are real without calling the issuer.

Are soulbound tokens the same as NFTs?

Yes and no. SBTs are technically NFTs (Non-Fungible Tokens) but with the "Transfer" feature disabled. You cannot sell or trade them; they are bound to your wallet forever.

Can VCs be verified on-chain?

Yes, but it is expensive. To verify a VC on-chain, you typically need a Zero-Knowledge Proof (ZKP) verifier smart contract. This allows the chain to check the VC without revealing the private data inside it.

Where do VCs live (data storage)?

VCs primarily live in the user's digital wallet (local storage). For backup and sync, they can be stored in encrypted cloud vaults (like Identity Hubs) where only the user has the decryption key.

Are SBTs safe for compliance identity?

Generally, no. Because SBTs are public on the blockchain, using them for compliance (like KYC) exposes the user's wallet address as "Verified," which can make them a target for hackers. They also struggle with GDPR compliance.

What breaks interoperability most often?

Non-standard schemas. If one issuer calls a field birthDate and another calls it dob, the verifier breaks. Using standard schemas (like Schema.org) within VCs prevents this.

How do you revoke VCs vs "revoke" SBTs?

To revoke a VC, the issuer updates a cryptographic registry (Status List). The user's VC remains in their wallet but will fail verification. To revoke an SBT, the issuer must send a blockchain transaction to "burn" the token, effectively deleting it from the wallet.

What’s the best approach for electronic health record credentials?

Always use Verifiable Credentials with Zero-Knowledge Proofs. Never put health data on an SBT. Health data requires strict access control, the ability to be deleted, and should never be public—all properties that VCs support and SBTs do not.

Future Research: Zero Knowledge Proofs for On Chain Access Permissions

We have established the difference between VCs and SBTs. But the future is likely a hybrid.

Future research is focused on "ZK-SBTs"—tokens that live on-chain but contain only a zero-knowledge proof of a credential, not the data itself.

There are still research gaps. Many privacy preserving techniques look strong on paper but are harder to operationalize under latency, wallet UX constraints, and revocation checks. Closing these research gaps is what will decide how far ZK-based identity can go at scale.

This would allow us to have the composability of an SBT with the privacy of a VC.

Until then, we must rely on the Trust Triangle to manage these relationships off-chain.

What Comes Next

We have defined the container (VCs vs. SBTs). We have defined the address (DIDs).

Now, we need to connect the players. How does the Issuer trust the Holder? How does the Verifier trust the Issuer?

This relationship is defined by the Trust Triangle.

The ‘Trust Triangle’: Understanding the Issuer-Holder-Verifier Model