What is a Soulbound Token?

Introduction

Soulbound tokens are blockchain tokens designed to stay attached to one account instead of being freely traded. That sounds like a small change to the usual token model, but it changes the meaning of the token completely: a transferable token usually says who controls an asset right now, while a soulbound token tries to say something about the holder that should not simply be bought and sold.

That distinction is the reason the concept exists. Many things people want to represent on-chain are not assets in the ordinary sense. A degree, a membership, proof that you attended an event, an identity verification, a professional credential, or a reputation signal all lose much of their value if anyone can purchase them from someone else. If a token can move as easily as money, it stops being reliable evidence of personal history.

The term comes from games, where a “soulbound” item is bound to a character once acquired and cannot be transferred to another player. In crypto, the idea was developed into a broader design for on-chain credentials and social identity, especially in the whitepaper Decentralized Society: Finding Web3’s Soul. That paper describes Souls as accounts or wallets that hold publicly visible, non-transferable tokens, called Soulbound Tokens or SBTs, representing commitments, credentials, and affiliations.

The interesting part is not just the label “non-transferable.” The real question is what problem non-transferability solves, what assumptions it relies on, and where those assumptions fail. A soulbound token is useful only if it preserves a meaningful link between a token and a person, group, or persistent account. That turns an ordinary token-design question into a much harder question about identity.

Why are transferable tokens unsuitable for representing credentials?

A normal fungible token is optimized for interchangeability. One unit is meant to be as good as another, and transfer is the whole point. An ordinary NFT is different in that each token can be unique, but it still inherits the market logic of transferability: whoever controls the token can sell it, gift it, or move it elsewhere. That makes NFTs excellent for collectibles, tickets, and digital property. It makes them much less reliable as proof of personal history.

Consider an attendance badge. If the badge is transferable, then seeing it in a wallet does not tell you whether the wallet owner attended the event. It only tells you the owner controls a token that once represented attendance. The gap matters because the signal people care about is not possession in the abstract. It is personal participation.

The same mechanism explains why transferable tokens create trouble in governance and reputation systems. If voting power is easily purchasable, then governance tends to drift toward whoever can buy enough influence. If a credential can be sold, then the token no longer distinguishes earned trust from acquired access. In both cases, transferability weakens the connection between token ownership and the underlying fact the system hoped to measure.

So the core idea behind soulbound tokens is straightforward: remove transferability when transferability destroys meaning. Not every token should be soulbound. In fact, most should not. The point is to use a different primitive for a different job.

What is a soulbound token and how does it work?

At the conceptual level, a soulbound token is a token that is bound to a single account and cannot be transferred in the normal way. Depending on the design, it may still be revocable by the issuer, removable by the holder, or recoverable through a special process if the holder loses access to the account. Those extra rules matter because “non-transferable” alone does not answer practical questions like revocation, consent, or wallet migration.

In the original SBT framing, the account is called a Soul. A Soul is just a wallet or account used as a persistent identity container. It need not correspond to a legal identity, and one person might use more than one Soul for different contexts. What matters is that other parties can issue tokens to it that represent some relationship: a university could issue a degree, an employer could issue a work credential, a community could issue a badge, or a protocol could issue proof of participation.

Mechanically, that means the smart contract either omits transfer functionality or makes transfers revert under defined conditions. On Ethereum, a minimal standard for this idea is ERC-5192, “Minimal Soulbound NFTs.” It is an extension of ERC-721, the standard NFT interface. ERC-5192 adds a locked(tokenId) view function and defines that when locked(tokenId) returns true, the ERC-721 transfer functions for that token must throw. It also uses ERC-165 feature detection so wallets and applications can recognize that the contract supports this soulbound behavior.

That minimality is intentional. ERC-5192 tells software how to detect that a token is non-transferable, but it does not settle every design choice. It does not fully specify who may lock or unlock a token, whether locking is permanent, or how revocation and recovery should work. It solves the interoperability problem of signaling soulbound status, not the broader social problem of what such a token should mean.

Another Ethereum approach is ERC-4973, which uses the term account-bound token or ABT. Here the focus is slightly different. Rather than taking an ERC-721 and disabling transfers, ERC-4973 defines a minimal API for tokens that are bound to an account and do not implement the canonical ERC-721 transfer interface. It also includes a notable requirement: the owner must be able to call unequip to publicly disassociate from the token. That design reflects an important idea many people miss on first contact: if a credential can be issued to you, there should often also be a way for you to reject or renounce it.

How does a soulbound token work in practice (university diploma example)?

Imagine a university wants to issue diplomas on-chain. If it mints ordinary NFTs, graduates can sell them. A buyer could then display the token and appear, at least on-chain, to hold that degree. The token would still be scarce and authentic as a digital object, but it would fail as a credential.

Now imagine the university issues a soulbound token instead. The graduate’s wallet receives a token whose transfer functions are disabled. A wallet, block explorer, or application can inspect the contract and see that this token is locked or otherwise account-bound. The token can still carry metadata saying which institution issued it and which program it represents. But crucially, the holder cannot simply move it to another account for sale in the ordinary way.

This changes what the token communicates. It is no longer primarily a tradable object with collectible value. It is a claim by the issuer about a continuing relationship to the holder’s account. If the university later discovers fraud, it might revoke the token, depending on the contract design. If the graduate wants to prove degree ownership privately, the system might keep detailed data off-chain and expose only a hash or a zero-knowledge proof. The token is doing less as property and more as attestation.

That same mechanism is why soulbound tokens are often discussed alongside verifiable credentials, identity systems, and reputation systems rather than alongside speculative collectibles. The central operation is not exchange. It is attestation.

What are common use cases for soulbound tokens?

The most natural use of soulbound tokens is to represent credentials, affiliations, and participation. Event badges are the simplest case. This is why discussions of soulbound tokens often start from POAPs, the “Proof of Attendance Protocol.” A POAP says something meaningful only if observers believe the current holder personally attended. If a secondary market can cheaply separate attendance from possession, the token’s signal weakens.

The same logic extends to professional and social credentials. A DAO might want to know who contributed over time, not who bought a token yesterday. A community might want badges that signal moderation history, builder status, or long-term membership. A protocol might want to identify wallets that completed a training course, passed a verification process, or participated in a security review. In all of these cases, the token works because it is trying to preserve a link between an account and a fact.

The original SBT paper also emphasizes provenance. An artist could issue an NFT from a Soul that already carries meaningful credentials or affiliations. Buyers would then have a stronger basis for believing that the NFT came from the real artist rather than an imitator. Here the soulbound tokens are not replacing transferable NFTs. They are adding a reputation layer that helps the market interpret them.

Another major proposed use is uncollateralized or undercollateralized lending. DeFi usually relies on overcollateralization because blockchain addresses reveal little durable information about borrowers. If an account accumulates credible attestations about education, work history, repayment history, or community standing, lenders may be willing to rely less on posted collateral. This is one of the most ambitious SBT use cases because it tries to use non-transferable reputation to substitute for locked capital.

Governance is another area where the mechanism matters. If governance rights are transferable, they can be bought and concentrated. A soulbound governance design tries to preserve voting power as a function of participation, role, or reputation rather than raw purchasing power. The SBT paper goes further and proposes computing over a Soul’s constellation of tokens, using not just whether a wallet has one badge, but the broader pattern of credentials it holds.

This is also where the paper introduces the idea of a correlation score. The basic intuition is that if many apparently distinct wallets supporting a proposal are highly correlated in their SBT holdings, they may not represent genuinely plural support. A governance system could discount votes or funding matches from highly correlated groups to reduce sybil behavior and collusion. Whether particular formulas work well remains an open research problem, but the motivation is clear: non-transferable credentials might help systems reason not just about how much support exists but about how independent that support is.

If a token is non-transferable on-chain, can people still sell or rent the credential?

This is the most important caveat in the whole topic. A soulbound token can be made non-transferable at the smart-contract level. That does not guarantee the underlying credential cannot be sold, rented, or shared in practice.

The simplest way around non-transferability is to sell the whole account. If the token is stuck to an address, and I can transfer control of the address, then the credential may still be alienable in economic terms even if the token never moves on-chain. This is why soulbound systems are really about binding to control of an account, not magically binding to a human being.

And the problem goes deeper. Some systems rely on the assumption that one account is controlled by one principal. Research such as Liquefaction shows ways private keys can be encumbered and shared through trusted execution environments, allowing a single address’s assets or credentials to be rented, pooled, or jointly controlled with little visible on-chain evidence. If that becomes practical at scale, many soulbound-token assumptions weaken sharply. A wallet displaying a credential may still not correspond to a single person exercising independent judgment.

This does not make soulbound tokens useless. It means they are not self-authenticating. Their value depends on the surrounding system: wallet security, recovery design, issuer procedures, social verification, anti-sybil mechanisms, and the cost of account sharing. A soulbound token is best understood as making some kinds of cheating harder and more legible, not as eliminating them.

Privacy is not an add-on; it is part of the design

A public token that says “this account holds credential X” is easy for applications to verify. It is also easy for everyone else to inspect. That is the central privacy tension.

Public visibility can be useful. Reputation systems, governance weighting, and provenance checks often require others to see at least some credentials. But the same visibility can expose sensitive information. Medical status, financial distress, political affiliation, or stigmatized memberships are obvious examples. Even benign credentials can become dangerous when combined across contexts.

The SBT paper treats this as a core design problem and suggests several approaches. One is to keep detailed data off-chain and put only a hash or reference on-chain. Another is to use zero-knowledge proofs, which let a person prove a statement about their credentials without revealing the credentials themselves. Instead of showing an entire credential set, you might prove “I hold a valid degree issued by an accredited institution” or “I have at least three qualifying attestations,” without exposing every token. The paper also mentions designated-verifier proofs and related techniques under the broader idea of programmable plural privacy.

The tradeoff is unavoidable. More publicity makes composability easier: contracts and communities can compute directly on visible tokens. More privacy protects people, but may reduce what can be checked automatically. There is no single correct point on this spectrum because different applications need different balances. A public conference badge and a public health credential are not the same design problem.

How should recovery, revocation, and consent be handled for soulbound tokens?

If a soulbound token is meant to persist like a credential, what happens when a user loses their keys? Ordinary tokens solve this by letting users move assets to a new wallet before disaster, or by accepting loss. But a soulbound token is supposed to remain attached, which makes wallet migration and recovery unusually delicate.

This is why many practical implementations soften the pure notion of non-transferability. Some systems allow issuer revocation and reissuance. Some give the holder a right to renounce the token. Some propose social recovery, where a community or guardian set helps rebind credentials to a new account. Research on Polkadot and Kusama has explored soulbound tokens alongside social recovery for digital inheritance and post-loss recovery, which makes sense: once a token represents identity or standing rather than wealth, persistent access matters more than perfect immobility.

But recovery creates a paradox. If recovery is too easy, then the token starts looking transferable through an administrative side door. If recovery is too hard, users lose irreplaceable credentials when keys are lost or compromised. The same tension appears in revocation. Issuer-controlled revocation helps correct fraud and mistakes, but it also creates trust and censorship concerns. Holder-controlled removal protects autonomy, but it may let people discard negative but accurate credentials.

A good way to think about these features is that they do not weaken the concept of a soulbound token. They define what kind of social object the token is. A university degree, a KYC badge, a club membership, and a court-issued sanction should not all have the same revocation model.

How do other blockchains implement non-transferable tokens (Solana, BNB, etc.)?

The general idea is broader than any one chain. Ethereum has the most visible standards discussion, including ERC-5192 and ERC-4973, along with several other SBT-related EIPs in the registry. But the underlying design problem appears elsewhere too.

On Solana, the Token-2022 program includes a NonTransferable extension. When initialized on a mint, it prevents tokens from being transferred between token accounts after minting. The tokens can still be minted, and the holder can still burn them, but ordinary transfers fail. This is the same basic mechanism expressed in Solana’s account-and-program model rather than Ethereum’s ERC interface model. The chain-specific APIs differ; the design principle does not.

BNB Chain’s Binance Account Bound or BAB token is another concrete example. It was launched as a KYC-linked proof-of-identity token for verified Binance users. That makes it an especially useful example because it shows both the promise and the controversy of soulbound systems. On one hand, the token can help gate participation, rewards, and anti-sybil measures. On the other hand, the credential depends on a centralized issuer and a sensitive identity-verification process. The mechanism is real, but the trust model is much less decentralized than the rhetoric around Web3 identity sometimes suggests.

These examples matter because they show that “soulbound” is not a single universal standard so much as a family of designs built around a common constraint: make transfer difficult or impossible because the token is supposed to function as a credential rather than a commodity.

Which assumptions must hold for soulbound tokens to work, and what fails if they don’t?

The biggest misunderstanding about soulbound tokens is treating them as a solved identity primitive. They are not. They are a design pattern for representing attestations under limited assumptions.

If issuers are unreliable, the tokens are unreliable. If wallets are routinely bought and sold, non-transferability loses force. If privacy is ignored, the system can become invasive or dangerous. If recovery is absent, the system becomes brittle. If recovery is too permissive, the binding becomes weak. If governance relies too heavily on visible credentials, people may game which credentials they seek or avoid. If communities use soulbound data to automate exclusion, the same tools built for trust can become tools of discrimination.

The original SBT paper is unusually explicit about this dual-use character. The same composable, visible credentials that might support reputation, plural governance, or community lending could also support red-lining, predatory screening, or social control. That is not a rhetorical flourish. It follows directly from the mechanism. A machine-readable social graph can coordinate inclusion, but it can also coordinate exclusion.

So the right question is rarely “Are soulbound tokens good?” It is “What fact is this token trying to represent, who gets to issue it, who can inspect it, who can revoke it, and what does the surrounding system assume about identity and control?” Those choices determine whether the design helps.

Conclusion

A soulbound token is a non-transferable token meant to represent a credential, affiliation, commitment, or reputation signal rather than a tradable asset. Its core insight is simple: some things lose their meaning when they can be bought and sold.

But the idea only works when paired with careful answers about identity, privacy, consent, revocation, and recovery. In practice, soulbound tokens are less like “NFTs that cannot move” and more like on-chain attestations with token-like interfaces. That is the part worth remembering tomorrow: the important change is not merely that transfer is blocked, but that the token is trying to stand for a relationship that markets alone cannot faithfully represent.

How do you evaluate a token before using or buying it?

Evaluate a token by checking its contract rules, the issuer’s authority, privacy and recovery models, and the token’s likely liquidity or governance effects. On Cube Exchange, do those checks first, then fund your account and use Cube’s market or approval flows to trade or interact with the token.

1. Open the token contract in a block explorer (Etherscan, Solscan, BscScan) and inspect the ABI and public read functions. Look specifically for non-transfer flags or standards (ERC-5192 locked(tokenId), ERC-4973/unequip, or Solana Token‑2022 NonTransferable).
2. Verify the issuer and admin functions. Check the contract’s owner/multisig addresses, and look for revoke/lock/unlock or unequip functions in the code or verified source.
3. Check privacy and recovery details in the project docs and contract: is metadata on-chain or off-chain, are ZK/designated-verifier proofs mentioned, and does the project document social recovery or reissuance procedures?
4. Fund your Cube account with fiat or a supported crypto, set precise token approval limits when approving an ERC-20, and place a limit order if the token shows low liquidity; after the trade, confirm the token’s metadata and issuer claims in Cube’s asset view.