Soulbound Tokens Explained: Buterin's Wallet Credential Idea

Soulbound tokens, usually shortened to SBTs, are non-transferable tokens recorded on a blockchain. They follow the same basic structure as other NFTs, a unique token ID with metadata, but the token cannot be sent from one wallet to another after it is issued. It stays with the wallet that received it.

That single change alters what a token can mean. A regular NFT says that someone owns an item, and the owner can sell it. An SBT says that a specific wallet has a particular attribute, such as having completed a course, attended an event, or holding a credential issued by an organization. Because it cannot be bought or sold, it is harder to fake by purchase and more closely tied to the account it describes.

The term describes a design rather than a single product. A project can issue SBTs under its own rules, and the wallet owner usually has no way to hand the token to someone else. Some implementations let the holder burn or give up the token, while others keep it permanent. Read the contract rules for any SBT before relying on it.

In short, an SBT is a verifiable record attached to a wallet. It is a building block for reputation and credentials, not a copy of an identity document.

The concept was proposed by Vitalik Buterin, a co-founder of Ethereum, in 2022. He described soulbound tokens in a paper written with researchers E. Glen Weyl and Puja Ohlhaver, titled Decentralized Society: Finding Web3's Soul. The name was borrowed from the video game World of Warcraft, where soulbound items become tied to a character once picked up and cannot be traded.

The authors argued that much of web3 was built around financial assets, which can be bought by anyone with enough money. They wanted tools that reflect what a wallet has done or what others have confirmed about it. Their examples included credentials such as diplomas, membership in a group, work history, and records that help show a wallet is run by a real and distinct participant.

Search coverage of the idea repeatedly describes it as an extended resume, a way to build social identity, and a tool to fight scams. Those descriptions match the original intent. The proposal was a research direction, not a finished product, and it has been discussed and refined since then.

If you read about SBTs today, keep the source in mind. Many articles summarize the 2022 concept, while implementations differ widely. Check whether a claim refers to the original paper, a technical standard, or a specific project.

Headlines sometimes describe the idea as a passport on the blockchain. That phrase is a loose metaphor, and it can mislead. An SBT is not a government passport, is not issued by a state, and does not replace any official identity document. Nothing in the original proposal or the search coverage reviewed says otherwise.

What the idea does cover is a set of portable, wallet-bound statements. A wallet might hold a token saying it passed a particular exam, another saying it belongs to a community, and another saying a verifier checked a fact. Each statement comes from an issuer that the reader must trust or verify. A passport carries a government's authority; an SBT carries only the authority of whoever issued it.

This matters for everyday use. A university could issue a degree token, but an employer should only accept it after confirming the university and the contract address. A verifier should check the issuer's address, the token's metadata and whether the token has been revoked, if the standard allows revocation.

The honest summary is this: SBTs aim to make certain claims about a wallet checkable on-chain. They do not prove that a person is who they say they are, unless a trusted issuer did that check off-chain and recorded the result.

Most SBTs use the ERC-721 or a similar NFT structure on Ethereum and compatible networks, with one key rule added: transfers are disabled. Some implementations use a minimal interface such as ERC-5192, which signals that a token is locked to the wallet that received it. Other projects write their own rules, so the exact behavior depends on the contract.

A typical lifecycle has four parts:

• An issuer decides a wallet qualifies and mints a token to it.
• The token records metadata, such as a type, a date and a reference to supporting data.
• Other applications read the token from the wallet and decide whether to trust it.
• The issuer or holder may revoke, burn or update the token, if the contract allows it.

Because the token is public by default, anyone can read it with a block explorer. Sensitive details usually stay off-chain, with only a hash or a reference stored in the token. Applications can then request proof from the holder without exposing the underlying file.

Wallet recovery is a practical issue. If a wallet is lost, its SBTs usually cannot be moved to a new wallet, since that would break the binding. Some designs offer recovery processes, but they add trust assumptions. Check how the specific system handles lost keys before relying on it.

The original paper and later discussions point to several uses. None of them is guaranteed to work at scale, and some depend on privacy tools that are still developing.

Common proposed uses include:

• Education records, such as course completions or certificates.
• Professional credentials, such as licences or employment history confirmed by an employer.
• Community membership, where a group recognizes long-term participants.
• Reputation for lending or governance, where a history of repayment or participation affects access.
• Sybil resistance, helping systems tell a unique participant apart from many wallets controlled by one person.

The last point is often considered the strongest case. Airdrops, voting and rewards are easier to abuse when one person controls many wallets. A non-transferable record can make such abuse more costly, though it cannot prove uniqueness on its own.

These uses share one requirement: someone trusted must issue the token. Without a credible issuer, a soulbound badge is just a label. Before accepting one, ask who issued it and which standard they followed.

SBTs carry real risks, and they are easy to overlook because the design sounds clean.

Main concerns:

• Public history. Anything written on a public blockchain can be read by anyone. A token that reveals a membership or a qualification can expose more than the holder intended.
• Linkability. A wallet used for many activities can be connected to a single profile over time.
• Permanence. A token that cannot move may stay attached to a wallet even after the holder's circumstances change, unless the design allows revocation.
• Issuer error or abuse. A mistaken or dishonest issuer can mint tokens that look official.
• Lost keys. Losing access to a wallet can mean losing the token with no simple way to restore it.
• Pressure to share. Some services may require proof of a credential, which can push people to reveal more than they need to.

Privacy designs such as zero-knowledge proofs aim to let a holder prove a statement, like being over a certain age, without showing the underlying data. These tools exist, but their use with SBTs is still evolving and varies by project.

For personal wallets, avoid writing government ID numbers, full legal names or private records into token metadata. If you consider using credentials at all, keep them in a wallet separate from your main funds.

The honest status is that SBTs remain a mix of research, standards work and experimental projects. Several projects have issued non-transferable tokens for communities, events and credentials. The search material reviewed does not show a national identity system or a large platform built on SBTs as a standard identity layer.

Because activity changes quickly, do not rely on any article's claim about how many SBTs exist or which project leads. Check these places instead:

• The contract address and its verified source code on a block explorer, to see whether transfers are blocked.
• The issuer's official website and documentation for its criteria and revocation policy.
• Public Ethereum standards discussions for the current interface definitions.
• Recent reporting from reputable outlets that names the project and gives a date.

NFT marketplaces generally do not support trading SBTs, since the token cannot change hands. A marketplace listing that claims to sell a soulbound token should be treated with caution until you confirm how it works.

If you want to follow the topic, track the standards and the issuers you trust, rather than the buzz around the term.

If you are curious about SBTs or work with digital credentials, a careful approach keeps you safer.

Practical steps:

• Learn the issuer before you trust the token. Look for a named organization, a public contract and a way to verify the claim.
• Keep sensitive documents off-chain. Store the real file with the issuer or in your own encrypted storage, and share it only when needed.
• Use a dedicated wallet for credentials, separate from your main funds, and keep unrelated activity out of it.
• Back up your seed phrase offline and never type it into a website. Anyone who gets it controls the wallet and its tokens.
• Be wary of messages that promise free soulbound badges in exchange for connecting a wallet or signing a transaction. A signature can grant permissions you did not intend.
• Read every signature request before approving. Check the network, the contract address and what the signature allows.

If an issuer asks you to verify yourself, confirm that the request comes from its official channel. Phishing copies of real projects are common.

Soulbound tokens may become a useful part of digital identity, but they come with tradeoffs. Treat them as one signal among many, not as proof of who a person is.