SBTs are static records. They are non-transferable NFTs that permanently attest to a credential, like a diploma or DAO membership. This permanence creates a reputation prison, where past actions cannot be contextually weighted or expire.
account-abstraction-fixing-crypto-ux
Blog
Why Soulbound Tokens Are Not Enough
Soulbound tokens (SBTs) are a foundational but flawed primitive for on-chain identity. A dynamic reputation economy requires the granularity, programmability, and composability unlocked by Account Abstraction and smart accounts.
introduction
THE IDENTITY GAP
Introduction: The Static Soul Problem
Soulbound Tokens (SBTs) are immutable reputation ledgers, but their static nature fails to capture the dynamic, composable identity required for modern on-chain systems.
Dynamic systems require mutable state. Protocols like Aave and Compound need real-time creditworthiness, not a binary 'graduated' flag. A static SBT cannot reflect a user's fluctuating collateralization ratio or repayment history.
Composability demands machine-readable logic. An SBT standard like ERC-721 or ERC-1155 lacks the embedded logic for automated systems to interpret and act upon its data. This limits integration with DeFi primitives and zk-proof attestation systems.
Evidence: Vitalik Buterin's original SBT paper acknowledges this, stating static tokens would require a 'forgetting' mechanism or layered validity conditions to be practical, a problem projects like Sismo's zkBadges are now tackling.
thesis-statement
THE ON-CHAIN IDENTITY FLAW
The Core Argument: Reputation is a State, Not an Asset
Soulbound Tokens (SBTs) treat reputation as a transferable asset, which is a fundamental design error for decentralized systems.
SBTs are misapplied assets. The ERC-721/1155 standard underpinning SBTs is designed for ownership transfer. Reputation is a non-transferable state derived from historical actions, not a token you hold.
State is dynamic, assets are static. A user's reputation score on Aave or Compound updates with each interaction. An SBT is a snapshot that becomes stale, requiring constant re-issuance.
Reputation requires context. A governance SBT from Uniswap is meaningless for a lending protocol's risk engine. True reputation is a context-specific state queried from a verifiable history.
Evidence: The failure of POAPs as reputation. They became collectibles, not credentials, proving that on-chain artifacts without stateful logic devolve into tradable NFTs.
key-trends
WHY SOULBOUND TOKENS ARE NOT ENOUGH
The Three Fatal Flaws of Static SBTs
Static, non-transferable tokens fail to capture the dynamic, composable nature of real-world identity and reputation.
01
The Problem: Static Data is a Dead End
A one-time mint creates a data tombstone. Real-world reputation is a live stream of context, not a snapshot.
- No on-chain proof-of-life for credentials or affiliations.
- Zero composability with DeFi, DAOs, or gaming states.
- Creates data rot as profiles become stale and irrelevant.
0%
Dynamic Data
100%
Static Mint
02
The Problem: The Privacy-Scalability Trade-Off
Revealing your entire SBT graph for a single verification is overkill and dangerous. It's the web2 data leak model on-chain.
- All-or-nothing access forces oversharing.
- No selective disclosure for specific claims (e.g., prove age >18, not DOB).
- ZK-proofs for SBTs are computationally heavy and not natively supported.
1 Claim
Needed
All Data
Exposed
03
The Solution: Dynamic Attestation Frameworks
Shift from tokens to verifiable, updatable credentials with revocation. Think Ethereum Attestation Service (EAS) or Verax.
- Live attestations from issuers can be updated or revoked.
- Modular schema design for any data type.
- Native portability across chains via layerzero or hyperlane messaging.
Live
Attestations
Multi-Chain
Portable
04
The Solution: Programmable Reputation Primitives
Reputation must be a computable input, not a display picture. This enables under-collateralized lending and sybil-resistant governance.
- Reputation scores that adjust based on on-chain activity.
- Composable with DeFi legos like Aave, Compound.
- Context-specific graphs (e.g., Gitcoin Passport for grants, Layer3 for quests).
Input
For DeFi
Context-Aware
Scoring
05
The Solution: Zero-Knowledge Credential Wallets
User-owned proving systems that enable selective, minimal disclosure. The Sismo ZK Badge model, not the SBT ledger model.
- Prove attributes without revealing the source SBT.
- Aggregate credentials into a single, private proof.
- Off-chain verification with on-chain settlement, similar to UniswapX intents.
ZK
Proofs
Selective
Disclosure
06
The Entity: Ethereum Attestation Service (EAS)
The leading infrastructure proving the thesis. It's a schema registry and attestation engine, not a token factory.
- ~2.5M attestations created, showcasing real demand.
- Permissionless schemas enable infinite use cases.
- Onchain & offchain data support, bridging the gap.
2.5M+
Attestations
Permissionless
Schemas
WHY SOULBOUND TOKENS ARE NOT ENOUGH
SBTs vs. Smart Account Reputation: A Feature Matrix
A first-principles comparison of on-chain identity primitives, highlighting the functional limitations of static SBTs versus dynamic, composable reputation systems.
| Feature / Metric | Soulbound Tokens (SBTs) | Smart Account Reputation (e.g., ERC-4337, ERC-7579) | Hybrid Model (SBT + Reputation) |
|---|---|---|---|
Data Mutability | Immutable (append-only) | Fully Mutable (stateful) | Semi-Mutable (SBT anchors, mutable state) |
Composability & Portability | |||
Real-time State Updates | |||
Gas Cost for State Update | ~50k-100k gas (mint new SBT) | ~5k-20k gas (update storage slot) | ~55k-120k gas (combined) |
Fraud/Abuse Recovery Mechanism | None (permanent record) | Temporal slashing, score decay | Limited (SBT permanence, state recovery) |
Integration with DeFi & Account Abstraction | Read-only (e.g., token-gating) | Executable (e.g., gas sponsorship, credit limits) | Executable with verifiable history |
Standardization (ERC) | ERC-5114, ERC-4973 (fragmented) | Emerging (ERC-7579, custom modules) | Requires custom implementation |
deep-dive
THE IDENTITY GAP
The Path Forward: Account Abstraction as Reputation Infrastructure
Soulbound tokens (SBTs) create static identity artifacts, but Account Abstraction (AA) enables dynamic, programmable reputation systems.
SBTs are static ledgers. They record immutable credentials but lack the logic to interpret or act on them. An SBT proves you graduated; it cannot calculate a credit score or manage a subscription.
AA enables programmable identity. Smart accounts execute logic, allowing reputation to be a live computation. A wallet's transaction history with Uniswap and Aave becomes a dynamic risk score for undercollateralized loans.
Reputation requires context. An SBT is a fact; AA provides the 'if-then' rules. Ethereum's ERC-4337 standard lets a DAO gatekeep membership based on a user's proven contributions across Snapshot and Coordinape.
Evidence: The Safe{Wallet} ecosystem processes over 30M user operations, demonstrating the infrastructure for complex, multi-signature logic that SBTs alone cannot provide.
protocol-spotlight
WHY SOULBOUND TOKENS ARE NOT ENOUGH
Building the Reputation Stack: Key Protocols
Soulbound Tokens (SBTs) provide static, on-chain attestations but fail to create dynamic, composable reputation. A functional stack requires protocols for verification, aggregation, and programmability.
01
The Problem: Static Data, Dynamic World
SBTs are immutable records of past actions, but real-world reputation is contextual and evolves. A static NFT cannot reflect a user's current creditworthiness or recent contributions.
- No Context: An SBT from a DAO vote in 2022 says nothing about 2024 reliability.
- No Aggregation: Reputation is multi-faceted; a single token cannot synthesize data from Gitcoin, Optimism, and Aave.
- No Computation: Cannot trigger automated actions (e.g., undercollateralized loans) based on a live reputation score.
0
Live Updates
1-D
Data Dimension
02
The Solution: Verifiable Credential Protocols (E.g., Verax, Ethereum Attestation Service)
These protocols provide a schema-based registry for off-chain and on-chain attestations, creating a rich, updateable graph of claims.
- Context-Rich: Attestations can be revoked, expired, or updated, reflecting current state.
- Composable: Builders can create custom schemas for DeFi, governance, or social graphs.
- Portable: Credentials are not locked to a single app; they form a user-centric data layer usable across Ethereum, Optimism, Arbitrum.
1000+
Attestation Schemas
Multi-Chain
Portability
03
The Solution: Reputation Aggregators & Oracles (E.g., Gitcoin Passport, Spectral)
These protocols aggregate disparate signals (SBTs, VC attestations, off-chain data) into a single, machine-readable score, solving the data synthesis problem.
- Multi-Source: Pulls data from BrightID, ENS, Proof of Humanity, Snapshot.
- Programmable Output: Outputs a non-transferable NFT or a verifiable score that DeFi protocols can query.
- Sybil-Resistance: Creates cost for attackers by requiring aggregation of multiple, hard-to-fake identities.
10+
Data Sources
1 Score
Unified Output
04
The Solution: Programmable Reputation Layers (E.g., Noox, Galxe)
These platforms turn reputation into a programmable primitive, enabling on-chain actions and rewards based on proven behavior.
- Action-Triggered: Mint badges (SBTs) for specific, verifiable on-chain actions.
- Campaign Engine: Protocols like Aave, Uniswap use them to design loyalty and governance programs.
- Developer SDK: Provides tools to integrate reputation-based logic directly into dApp workflows, moving beyond mere display.
5M+
Badges Minted
Plug & Play
Integration
counter-argument
THE DATA IS NOT THE NETWORK
Counterpoint: Aren't SBTs Just the Data Layer?
Soulbound Tokens provide attestations, but they lack the execution and incentive layers required for a functional trust network.
SBTs are static attestations. They are a data standard, like an ERC-721, that stores credentials on-chain. This creates a public, immutable record but does nothing to govern how that data is used, verified, or incentivized.
The network is the application. A functional reputation system requires dynamic state updates, slashing mechanisms for bad actors, and fee markets for computation. SBTs, like those proposed by Vitalik Buterin, are the database, not the protocol.
Contrast with live systems. Compare SBTs to EigenLayer's cryptoeconomic security or Chainlink's oracle networks. These are active, staked networks with defined penalties and rewards. An SBT alone cannot slash a malicious validator or pay for a data fetch.
Evidence: Gitcoin Passport. This SBT-based system aggregates credentials but outscores trust to centralized providers like BrightID. The scoring algorithm and data sources are the actual trust mechanism; the SBT is merely the output receipt.
FREQUENTLY ASKED QUESTIONS
Frequently Asked Questions
Common questions about the limitations of Soulbound Tokens (SBTs) and their role in decentralized identity.
Soulbound Tokens (SBTs) are static, on-chain records that cannot capture dynamic, off-chain identity and reputation. They are a foundational primitive, like a digital passport, but lack the context and computation needed for real-world trust. Systems like Verax for attestations or Ethereum Attestation Service (EAS) are required to make SBTs useful by linking them to verifiable, updatable claims.
takeaways
BEYOND SBTs
TL;DR: Key Takeaways for Builders
Soulbound Tokens (SBTs) are a primitive, not a product. Here's what you actually need to build.
01
The Problem: SBTs Are Just a Data Format
An SBT is a non-transferable NFT. That's it. It doesn't solve attestation, revocation, or privacy. Building a reputation system with raw SBTs is like building a website with raw TCP packets.
- Key Gap: No built-in logic for expiration or social recovery.
- Key Gap: On-chain data is public by default, exposing sensitive traits.
- Key Gap: No standard for cross-chain or off-chain verification.
0
Native Privacy
ERC-5114
Proposal Stage
02
The Solution: Attestation Frameworks (EAS, Verax)
You need a system to make, store, and verify claims. Ethereum Attestation Service (EAS) and Verax provide the schema registry and on-chain ledger that SBTs lack.
- Key Benefit: Decouples data (attestation) from the token (SBT). Enables updates and revocations.
- Key Benefit: Supports off-chain attestations with on-chain proofs, crucial for cost and privacy.
- Key Benefit: Portable reputation; a user's attestations can be referenced by any app, not locked to one NFT.
10M+
Attestations (EAS)
L2 Native
Low Cost
03
The Problem: On-Chain Reputation is a Privacy Nightmare
Permanent, public SBTs for credit scores or employment history create immutable surveillance. This is a regulatory and user adoption non-starter.
- Key Risk: Data breaches are permanent. A leaked SBT revealing a user's salary cannot be 'deleted'.
- Key Risk: Enables perfect discrimination and targeting by adversaries or competitors.
100%
Public Data
GDPR
Non-Compliant
04
The Solution: Zero-Knowledge Proofs & zkCerts
Use ZKPs to prove properties of your credentials without revealing the underlying data. Projects like Sismo and Polygon ID's zkCerts are the essential privacy layer.
- Key Benefit: User proves they are 'over 18' or 'has a credit score > 700' without revealing their birthdate or exact score.
- Key Benefit: Selective disclosure and data minimization become possible, enabling regulatory compliance.
- Key Benefit: Proofs can be generated from off-chain or private data sources.
~2s
Proof Gen (Client)
ZK
Trust Assumption
05
The Problem: Static SBTs Lack Economic Context
A token saying you're a 'qualified borrower' is meaningless without risk models, payment history, and dynamic scoring. DeFi needs programmable, context-aware identity.
- Key Gap: No linkage to real-time financial behavior or on-chain activity graphs.
- Key Gap: Cannot model trust decay or performance over time.
Static
Data Model
0
Risk Engine
06
The Solution: Programmable Attestations & HyperOracle
Pair attestations with on-chain automation and oracles to create living credentials. Use HyperOracle's zkOracle to compute attestations based on verifiable off-chain logic (e.g., 'has made 12 consecutive loan payments').
- Key Benefit: Credentials can auto-expire, update, or tier-up based on verifiable events.
- Key Benefit: Enables complex underwriting and 'proof-of-*' systems that react to real-world data.
- Key Benefit: Moves beyond static identity to dynamic, behavior-based reputation.
zk-Proof
Compute Integrity
Dynamic
Credential
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