What Are Soulbound Tokens? Uses, Standards, and Risks

In 2022, Ethereum co-founder Vitalik Buterin borrowed a mechanic from World of Warcraft, where certain powerful items bind permanently to one character and can never be traded, and asked what that idea would look like for real-world credentials. With Glen Weyl and Puja Ohlhaver, he described soulbound tokens (SBTs) as a building block for a decentralized society (DeSoc), where non-transferable records could represent a person’s education, work history, memberships, and reputation onchain.

Four years later, soulbound tokens are no longer only a thought experiment. Several related standards have reached Final status, and a handful of production systems use non-transferable tokens directly. At the same time, the technology never became the single universal identity layer the original framing implied, and many identity products now use attestations or verifiable credentials instead of visible tokens.

This guide covers where SBTs actually stand as of August 2026: which standards are finalized, which products use non-transferable credentials in production, why many teams choose attestations or verifiable credentials instead, and how a business should decide which architecture fits its own use case.

What are soulbound tokens?

A soulbound token is a non-transferable blockchain record, usually built on a non-fungible token standard, bound to a single wallet and representing a credential, achievement, membership, or reputation signal that the holder cannot sell or hand off to someone else.

The concept comes from the May 2022 whitepaper “Decentralized Society: Finding Web3’s Soul,” by Vitalik Buterin, E. Glen Weyl, and Puja Ohlhaver. In that paper, a “Soul” is an account or identity representation belonging to a person, a company, or another entity, not, as sometimes assumed, a name for the process of issuing a credential. A single Soul can hold multiple soulbound tokens issued by different parties: a university, an employer, a DAO, a KYC provider.

By 2026, “Soul” and “DeSoc” are less common in product documentation. Current implementations usually use more specific terms such as non-transferable tokens, account-bound tokens, attestations, or verifiable credentials. The whitepaper remains useful background, but its vocabulary is not universal across the market.

Where soulbound tokens stand in 2026

Soulbound tokens moved from a largely theoretical concept in 2022 to a specialized credential mechanism in 2026: real, but only one of several approaches used in digital identity products.

The core idea, a non-transferable record tied to one account, is alive and in production use. What hasn’t happened is a single universal DeSoc identity layer that every wallet, issuer, and verifier plugs into. Instead, several approaches run side by side: an actual non-transferable NFT, an onchain or offchain attestation through a shared registry, or a W3C verifiable credential that never touches a public blockchain and references a status registry only when needed. Some products combine two or all three inside the same system.

The label varies with the architecture. Current product documentation often uses more specific, functional terms:

• account-bound token
• non-transferable NFT
• onchain attestation
• verifiable credential
• reusable identity proof
• proof of personhood

Not every non-transferable credential is technically an SBT, and not every blockchain identity product needs to issue a visible token. An attestation or an offchain credential can often do the same job with a smaller onchain footprint.

For a business evaluating this space in 2026, the practical question is “what credential architecture gives us the trust, privacy, portability, and revocation model this use case needs?” SBTs are one valid answer.

How do soulbound tokens work?

A soulbound token works like a standard NFT with one core rule enforced at the contract level: once issued to a wallet, it can’t be transferred, sold, or gifted to another wallet. Everything beyond that rule depends on the specific standard and issuer. Implementing consent, burn, expiration, and recovery mechanics often requires custom NFT smart contract development services rather than relying on the base ERC interface alone.

An issuer, such as a university, exchange, employer, DAO, or certification body, mints the token directly to a specific wallet, sometimes only after the owner agrees to receive it. The token typically carries metadata describing what it certifies, such as a credential type, issue date, or reference to supporting data.

Non-transferability is enforced by the token contract, typically by making ERC-721 transfer functions revert. ERC-5192 adds a machine-readable locked(tokenId) interface so wallets and marketplaces can detect the token’s locked state before attempting a transfer.

The original 2022 framing suggested SBTs would stay tied to a user for life. In practice, non-transferability is a separate property from permanence:

• Revocation. The credential remains identifiable but is marked as no longer valid through issuer-specific logic or a status registry. Binance BAB, for example, has its own revoke-and-reissue flow.
• Burning. The token is destroyed by the issuer, the holder, or both, depending on the contract’s rules. ERC-5484 is the standard that governs who is authorized to do this.
• Expiration. The credential stops being valid after a set date. This can be implemented through custom logic or a standard such as ERC-7858.
• Reissuance. A new token replaces an old one after revocation or burning. Binance users can mint a replacement BAB after a 72-hour lock period.
• Wallet migration and key rotation. The issuer may revoke or burn the old credential and issue a replacement to a new wallet. There is no universal migration model.

A non-transferable token is not automatically an irrevocable one. Which of these mechanisms apply depends entirely on the standard chosen and the issuer’s own policy.

Selected soulbound token standards and credential technologies

Which ERC standard, if any, applies depends on what a product needs: a minimal transferability lock, a consent-and-burn model, or a mechanism that isn’t a token at all. Statuses below reflect the official Ethereum ERC repository as of August 2026.

ERC-5192: Minimal Soulbound NFTs (Final)

A minimal extension of ERC-721, the standard NFT interface. It adds a locked(tokenId) check and Locked/Unlocked events so wallets and marketplaces can detect whether a token is bound. When locked() returns true, the contract’s transfer functions must throw. ERC-5192 doesn’t define privacy, recovery, expiration, or credential status; it is a lightweight option when applications need a standard way to recognize that an NFT is currently non-transferable.

ERC-5484: Consensual Soulbound Tokens (Final)

Requires the issuer and recipient to agree on the token’s metadata and immutable burn authorization before issuance. The burn setting, IssuerOnly, OwnerOnly, Both, or Neither, is fixed when the token is issued. ERC-5484 standardizes who may burn the token; it doesn’t define credential revocation, expiration, or status checking.

ERC-7858: Expirable NFTs and SBTs (Final)

Standardizes expiration for ERC-721 NFTs and soulbound tokens. It lets applications determine whether a token has expired without assuming that expiration removes the token or erases its history. This is useful for licenses, memberships, certifications, and other credentials with a defined validity period.

ERC-4973: Account-bound Tokens (Review)

Proposes a broader non-transferable token interface with built-in minting, assignment, revocation, and disassociation. It remains in Review, so it should be treated as a non-finalized proposal rather than a settled standard.

ERC-4671: Non-Tradable Tokens (Stagnant)

An earlier attempt at a non-tradable “badge” standard for diplomas, licenses, and similar credentials. Its Stagnant status makes it useful as standardization history rather than a current recommendation.

Why many identity systems use attestations instead of tokens

A token is an asset-like object with an owner and, usually, a transfer function, even a deliberately disabled one. An attestation is simpler: a signed statement an issuer makes about an address, person, organization, or event, without necessarily minting anything. A verifiable credential standardizes the issuer-holder-verifier relationship: an issuer signs it, a holder stores it, often offchain, and later presents some or all claims to a verifier. The verifier receives the disclosed information and checks the proof and credential status. Selective disclosure depends on the credential and proof format used.

This matters for architecture, not just terminology. One credential can be issued as a verifiable credential that never touches a public chain, referenced by an attestation recording only the issuer, schema, and status, and represented as an SBT only where a visible non-transferable asset genuinely helps. Many identity products blend two or three of these layers within a single system rather than committing to one.

W3C Verifiable Credentials Data Model 2.0. The specification became a W3C Recommendation in May 2025, giving the issuer-holder-verifier pattern a formal, vendor-neutral definition. It addresses data minimization, credential status, selective disclosure, and correlation risk. However, selective disclosure is not automatic; it requires a compatible credential and cryptographic proof format.

Ethereum Attestation Service. EAS is open-source infrastructure for creating and verifying onchain and offchain attestations, not an SBT marketplace or token launchpad. Anyone can define a schema and issue signed claims such as identity checks, employment records, academic achievements, or compliance status. Onchain attestations can provide a publicly verifiable record, while offchain models reduce the amount of claim data written to the blockchain.

Sign Protocol. Another attestation infrastructure project designed for multi-chain use. Like EAS, it provides attestation infrastructure that other products can build on rather than functioning as a soulbound token platform. When issuers, registries, wallets, and verifier applications need to work together as a single product, blockchain integration services can connect these layers to existing systems and offchain data flows.

SBTs vs NFTs, attestations, and verifiable credentials

These mechanisms aren’t mutually exclusive. A single product can combine an offchain verifiable credential, an onchain attestation, and a non-transferable token, using each where it fits.

Real-world soulbound token and credential examples

Products in this space move quickly. Confirm current documentation directly with each project before making an architecture decision.

Binance Account Bound Token (BAB)

Non-transferable token, issued by Binance on BNB Chain, revocable and reissuable.

BAB is a credential for eligible Binance users who completed identity verification. It’s often called the first SBT ever created, but the narrower and more accurate claim is that it was the first SBT issued by Binance itself on BNB Chain. Each Binance user can hold one active BAB at a time. If a user loses wallet access, they can revoke the token through their Binance account and mint a replacement after a 72-hour lock period. BAB acts as a verification marker rather than a store of KYC documents. Third-party applications may use it as a Binance-issued signal, subject to their own compliance and risk requirements.

Coinbase Onchain Verification

Attestation, built on the Ethereum Attestation Service, on Base.

Coinbase links a self-custodial EVM wallet to a verified Coinbase account through an attestation rather than a dedicated token, illustrating an attestation-based alternative to SBTs. The verification is non-transferable and user-revocable, though a historical record that the link once existed may persist after revocation, and full KYC data isn’t published onchain. It provides a reusable verification signal for Base applications that integrate the attestation, provided they’re willing to recognize Coinbase itself as the trusted issuer behind it.

Human Passport (formerly Gitcoin Passport)

Verifiable credentials, zero-knowledge proofs, attestations, and network-specific SBTs.

Human Passport uses several credential models rather than one universal SBT architecture. Passport Stamps are collections of verifiable credentials issued by identity providers and aggregated into a Unique Humanity Score for Sybil-resistance use cases.

Individual Verifications use zero-knowledge proofs to confirm identity-related properties without publishing the underlying personal data. On Optimism and Base, verification results can be recorded through Sign Protocol attestations. On Stellar, the current integration uses non-transferable SBTs implemented through Soroban. Human Passport labels its earlier EVM SBT flow as legacy, but Stellar SBTs remain current. No single verification signal fully prevents Sybil behavior.

Adjacent comparison: POAP

Transferable NFT, not soulbound by default.

POAP issues NFTs as digital mementos for shared experiences and events. It remains a useful comparison because POAPs are not inherently soulbound, and holding one is different from proving that the current wallet owner attended in person. A business that needs non-transferable attendance credentials would require a separate contract design that blocks transfers and a reliable issuance process that confirms attendance. Non-transferability alone does not prove physical presence.

Soulbound token use cases

Common use cases include the following six areas.

KYC and eligibility proofs

Non-transferable credentials or attestations can confirm a wallet passed KYC, meets jurisdiction requirements, qualifies as an accredited investor, or is eligible for a specific program. The credential should confirm status, not publish the underlying KYC file. For regulated products, crypto compliance solutions can connect reusable verification signals with KYC/AML controls, status updates, and existing onboarding systems.

Education and professional credentials

Diplomas, certificates, course completions, licenses, and employer-issued skill badges fit naturally: the point is proving something earned and non-transferable. A signed credential proves the issuer said so; the verifier still must check current status.

Memberships and access rights

Associations, subscription communities, partner programs, and token-gated services can use non-transferable credentials instead of transferable membership NFTs, which get resold. The key decision: revocable or time-limited, rather than permanent.

Web3 reputation and Sybil resistance

Non-transferable or hard-to-fake credentials support proof of unique participation, governance eligibility, and fairer reward distribution. No single credential eliminates Sybil attacks; it raises the cost and reduces the scale of multi-account abuse. Projects that use credential-based eligibility in community governance may also need DAO development services to design voting, permissions, and dispute-handling logic around those signals.

Compliance and reusable verification

A user may be able to verify once and reuse the credential across participating applications instead of repeating the same checks. This only works where verifiers accept the issuer and schema, consent-based data flows are in place, status can be updated, and privacy requirements for the relevant jurisdiction are met.

Gaming and achievements

The use case closest to the term’s origin. Non-transferable achievements and identity-bound ranks can coexist with tradable items in the same game. Blockchain game development services can help separate soulbound achievements from transferable assets without disrupting the wider in-game economy.

Choosing an architecture for different SBT use cases

Benefits of soulbound tokens

Non-transferability as a feature

Blocking direct token transfers removes one straightforward resale route and makes an earned credential harder to imitate through a secondary-market purchase. It doesn’t prevent fraudulent issuance, compromised accounts, or the sale of control over the entire wallet.

Potentially reusable proof

A credential can be reused by applications that recognize its issuer, schema, network, and status mechanism, reducing repeated data collection where participating verifiers accept the same proof.

Tamper-evident record-keeping

Blockchain issuance makes it easy to confirm who issued a credential and whether it’s changed since, though not that the original claim was true.

Value beyond a secondary-market price

SBTs generally can’t be resold, so they lack a market price like a collectible NFT. Their utility may take the form of access, eligibility, governance participation, or inputs used in a broader risk assessment.

A building block, not a replacement, for existing trust

SBTs and attestations can reduce how often a user reshares sensitive data with a new counterparty, without removing the need for a trusted issuer.

Limitations and risks of soulbound tokens

Privacy and wallet linkability

A public SBT can create a durable, publicly observable association between a wallet and an employer, university, community, location, or affiliation. Burning or revoking the token may not erase the historical onchain record. Multiple credentials in the same wallet can combine into a detailed public profile, even when no single one looks sensitive alone.

Unwanted credentials

Without consent, an issuer could attach a negative or unwanted credential with no easy way to remove it. ERC-5484 addresses part of this risk through recipient consent and pre-agreed burn authorization, but hiding, disassociation, and dispute handling still depend on the wider system design.

Issuer trust

Blockchain doesn’t make an issuer honest, secure, or accurate. A system still has to define who can issue, how a verifier recognizes a trusted issuer, and how compromised keys or mistaken credentials get corrected.

Revocation and expiration

Licenses expire, employment ends, memberships lapse, and KYC needs refreshing. An architecture that can’t expire or revoke anything drifts out of sync with reality.

Wallet loss and key rotation

A credential bound to one account without a recovery path creates real operational risk: losing a private key can mean losing access to every credential tied to it unless the issuer provides a replacement process. Products that require social recovery, account abstraction, or wallet migration can incorporate these capabilities through crypto wallet development services, but the issuer still needs a clear reissuance policy.

Circumventing non-transferability

A person can still sell an entire wallet or transfer account-recovery rights without moving the token itself, so contract-level non-transferability doesn’t guarantee a credential stays linked to the same real person.

Interoperability

Different SBT contracts, attestation schemas, chains, and issuer registries don’t automatically recognize one another, so a credential working cleanly in one ecosystem may need real integration work in another.

Social scoring and discrimination

Reputation systems can produce opaque scoring, permanent penalties, or automated decisions with no appeal, and context collapses easily: a credential earned in a gaming community, say, can end up judging someone in an unrelated lending decision.

Regulatory considerations

Not legal advice, but any team building here should evaluate, with qualified counsel, GDPR and similar frameworks, data minimization, the right to correction, retention rules, sector-specific privacy regulation, cross-border transfer rules, and whether blockchain immutability conflicts with required data-lifecycle controls. In July 2026, the European Data Protection Board finalized guidance recommending that organizations assess whether blockchain is necessary, generally avoid storing personal data directly onchain, and conduct a data protection impact assessment where processing is likely to create high risks.

How to design a soulbound credential solution

• Step 1: Define the claim. Start with what the credential needs to prove, not which blockchain or standard to use. “Completed KYC” and “holds an active license” require different architectures despite both sounding like identity verification.
• Step 2: Identify issuer, holder, and verifier. Map who verifies the original information, who issues it, who holds it, who can verify it later, and the trust relationship between them.
• Step 3: Choose the correct mechanism. Compare an SBT, an account-bound NFT, an onchain attestation, an offchain verifiable credential, and hybrids against the claim from Step 1. The comparison table above is a starting point.
• Step 4: Minimize onchain data. Personal data should generally remain offchain. When an onchain proof is necessary, assess whether a salted or keyed hash, a cryptographic commitment, or another privacy-preserving construction is appropriate. An unsalted hash of personal data is not automatically confidential.
• Step 5: Design consent and disclosure. Recipients should know, before issuance, what’s recorded, what becomes public, who can verify it, whether it can be hidden, and how long it stays valid.
• Step 6: Add revocation, expiration, and recovery from day one. Build these into the initial design, not as a patch after the first lost wallet or outdated credential.
• Step 7: Test wallet and verifier UX. Confirm the credential displays correctly across wallets, that users understand non-transferability, and that expired or revoked status is clear to both sides.
• Step 8: Audit contracts and data flows together. Before mainnet deployment, smart contract audit services should test the onchain logic for access-control, lifecycle, and transfer-restriction failures. An audit doesn’t replace a privacy review, threat modeling, issuer-security assessment, or compliance assessment; all of these belong before launch.

When an SBT is not the right choice

A soulbound token is usually the wrong tool when:

• the underlying asset needs to move freely between owners;
• the credential holds sensitive personal data that can’t be published, even in minimal form;
• the underlying data changes too often for reissuing a token to be practical;
• the use case needs private, selective disclosure rather than a visible onchain record;
• the holder needs the credential across unrelated contexts without them becoming linkable;
• a centralized, signed database record already solves the problem with less overhead;
• the credential must work for users and verifiers outside blockchain ecosystems;
• a token would add wallet and infrastructure complexity without real business value over a simpler alternative.

How PixelPlex can help

PixelPlex has been developing software since 2007, including blockchain, Web3, and smart contract projects. Relevant work includes 5N ID, a reference project for reusable KYC verification solutions built around one-time verification and consent-based data sharing through Daml smart contracts, and Blockcerts, a reference project for blockchain document verification that creates, issues, views, and audits digital records. Neither is a soulbound token implementation, but both are useful reference points for issuer-holder-verifier design.

If your team is evaluating whether a credential problem calls for an SBT, an attestation, a verifiable credential, or a hybrid, our blockchain development services can help scope the architecture, design the privacy and credential-lifecycle model, and build the resulting solution.

Conclusion

Soulbound tokens didn’t turn into the universal identity layer some early framing suggested, and they didn’t need to in order to be useful. In 2026, non-transferable credentials, whether implemented as SBTs, account-bound tokens, attestations, or verifiable credentials, are a working part of how some KYC, education, membership, and reputation systems operate.

What determines whether an SBT succeeds in a given product isn’t the token standard alone. It’s whether the team behind it designed real answers for issuer trust, consent, privacy, revocation, and recovery before launch, not after the first support ticket about a lost wallet or an unwanted credential. For a business choosing between soulbound tokens, attestations, and verifiable credentials, getting those five things right matters more than the standard itself.