A soulbound token is a token bound to one account and not transferable, used to represent something that would lose its meaning if it could be bought: a credential, an affiliation, a record of participation. The term comes from World of Warcraft, where powerful items cannot be traded once picked up. The hard part is not making transfers fail; it is deciding who can take the credential back, and on what evidence.
Non-transferability is easy to implement and weak on its own, because a holder can put the token in a wallet contract and sell control of the wallet. What makes a credential stick is a revocation path, and revocation is a governance decision that no token standard makes for you.
Two Buterin documents, four months apart, arguing different things
These get cited interchangeably and they should not be. The first is a solo post titled Soulbound, published 26 January 2022. It borrows the World of Warcraft mechanic, where an item once picked up cannot be transferred or sold, and asks what happens if NFTs work the same way. Its argument is about signalling: because NFTs are tradable, a large part of what they signal is wealth, and if someone holds a token obtainable by doing X, you cannot tell whether they did X or paid someone who did.1 Governance gets the same treatment, since transferable voting power flows toward concentrated interests and toward whoever most wants to rule.1
The second is a co-authored paper, Decentralized Society: Finding Web3's Soul, by Weyl, Buterin and Ohlhaver, dated 10 May 2022 and posted to SSRN the following day. It is a broader construction: accounts called Souls hold non-transferable soulbound tokens representing commitments, credentials and affiliations, which together encode the trust networks of the real economy and enable community wallet recovery, sybil-resistant governance and markets with decomposable shared rights, in an ecosystem the authors call Decentralized Society.2
One is a design observation about tradability. The other is a social architecture. If a project brief cites the May paper and describes the January post, someone has read a summary rather than either document.
What the standard actually specifies, and what it leaves out
EIP-5192 is the minimal version and the one most implementations reach for. It extends EIP-721 with a single view function, locked(tokenId), and the rule is that when locked returns true, all EIP-721 functions of the contract that transfer the token from one account to another must throw. Detection runs through EIP-165, so a wallet can ask the contract whether it is soulbound rather than inferring it from a failed call.3
The motivation section explains why a standard was needed at all: developers were simply throwing errors on invocation of transfer functionality, which over the long term produces fragmentation and less composability.3 The standard is an interoperability fix, and it should be read as exactly that.
Now read what it does not cover. It says nothing about who may issue, on what evidence, or under what conditions a credential can be removed, corrected or reissued. Those are the decisions that determine whether the credential means anything, and the standard is deliberately silent on all of them. Picking EIP-5192 answers a wallet-compatibility question and leaves the design question entirely open.
Non-transferability is weaker than it sounds
Buterin flagged the hole in the January post. The security of non-transferability implemented naively is not very strong, because a user can create a wrapper account that holds the token and then sell ownership of that account.1 Locking the token does not lock the person; it locks an address, and addresses are themselves transferable when they are contracts.
The empirical case he cites is POAP, which made a deliberate decision not to block transfers, partly because users have legitimate reasons to migrate assets between wallets for security. The result was predictable: POAPs have frequently been bought and sold where an economic rationale existed, and an Adidas POAP released free to fans that granted priority access at a merchandise sale recorded more transfers than items.1
The counterexample he offers is instructive for the opposite reason. Proof-of-humanity profiles are effectively soulbound not because transfer is blocked but because the protocol has a revocation feature: the original owner can request removal, a Kleros court decides whether the request came from the same person, and a successfully removed profile can be reapplied for.1 The binding comes from the ability to take the credential away, not from the transfer restriction.
Scroll to see the full diagram
Deployments land on the revocation question
Optimism's RetroPGF 3 round is a useful primary-source example because the rules were published on the collective's own governance forum. Voting badges were offered to 208 community members, distributed partly by existing badgeholders and partly by top recipients of the previous round. Badgeholders represent individual members and may not represent a project or company in that capacity, and there is a rule against distributing a badge to a co-worker at a project where you spend a large share of your working hours, written explicitly to counteract concentration of voting badges among a small number of projects.
Then the line that matters here: badgeholders must abide by the rules and the code of conduct, and in case of a violation the voting badge that has been distributed may be revoked.4 The credential is issued to a person, is not meant to be a tradable governance asset, and can be withdrawn by the issuer for conduct reasons. That is a complete design position, and every part of it lives in governance documentation rather than in a contract interface.
Which is the pattern across serious deployments. The token standard handles the wallet's question. The issuer's policy handles the reader's question, which is whether the credential can be trusted.
What to settle before you mint a credential
Four decisions, in this order, and none of them are Solidity. Who is permitted to issue, and what evidence they must hold. Who may revoke, on what grounds, and whether the holder gets notice or an appeal. What happens when a key is lost or a wallet is compromised, since a credential bound to an address the holder no longer controls is worse than no credential. And whether the fact should be publicly visible on-chain at all, because a permanent public record of an affiliation is a privacy decision made once and never reversed.
The design consequence for tokenomics work specifically: a soulbound credential is not a supply-side instrument. It has no float, no market and no price, so it cannot be a value-accrual mechanism and should never be modelled as one. What it can do is gate access, weight governance or condition rewards, and each of those makes the issuer a permanent operational dependency for as long as the credential is honoured.
That dependency is the real cost, and it is worth pricing before launch. Someone has to run the issuance queue, the revocation process and the appeals, every year, forever. In our experience it is the part of the design nobody staffs, and an unmaintained credential system stops meaning anything long before anyone announces that it has.
Common questions
What is a soulbound token?
A soulbound token is a non-fungible token bound to a single account, where transfer functions are disabled so it cannot be sold or moved. EIP-5192 specifies the minimal form: a locked function that returns true, after which every EIP-721 transfer function on the contract must throw, with detection through EIP-165.3 The name comes from World of Warcraft items that cannot be traded once picked up.1
Did Vitalik Buterin invent soulbound tokens?
He wrote two of the founding documents, and they are separate. The solo post Soulbound, dated 26 January 2022, introduces the idea by way of the World of Warcraft mechanic and the signalling problem with tradable NFTs.1 The co-authored paper Decentralized Society: Finding Web3's Soul, with Weyl and Ohlhaver, dated 10 May 2022, sets out Souls and SBTs inside a wider social architecture.2
Can a soulbound token be revoked?
That depends entirely on the issuer, because the standard does not address it. EIP-5192 specifies only that transfers throw when the token is locked.3 Real deployments answer it in policy: Optimism's RetroPGF 3 rules state that a distributed voting badge may be revoked in case of a code-of-conduct violation.4 Decide the grounds, the process and the appeal before minting anything.
Why is blocking transfers not enough to make a token soulbound?
Because a holder can place the token in a wallet contract and sell control of that contract instead, so naive non-transferability is not very strong.1 POAP declined to block transfers for this reason among others, and an Adidas POAP given free to fans recorded more transfers than items.1 Durable binding comes from a revocation path, as in proof-of-humanity profiles.
See Tokenomics Design for how this applies in practice.
Sources
- Soulbound
Vitalik Buterin, vitalik.eth.limo, 2022
Dated 26 January 2022 on the page itself. The solo post: the World of Warcraft mechanic, the NFT signalling problem, transferable governance power, the wrapper-account weakness in naive non-transferability, the POAP and Adidas transfer examples, and proof-of-humanity revocation. Read 3 August 2026. Distinct from source 2, and not the same document. - Decentralized Society: Finding Web3's Soul
E. Glen Weyl, Vitalik Buterin and Puja Ohlhaver, SSRN abstract 4105763, 2022
Date written 10 May 2022, posted 11 May 2022, last revised 6 Feb 2024, 37 pages. Introduces Souls holding non-transferable soulbound tokens encoding commitments, credentials and affiliations, enabling community recovery, sybil-resistant governance and decomposable shared rights within Decentralized Society. SSRN returns a challenge to automated clients; abstract and metadata confirmed 3 August 2026 against the Wayback snapshot at web.archive.org/web/20260731104523. - EIP-5192: Minimal Soulbound NFTs
Ethereum Improvement Proposals, 2022
Extension of EIP-721 adding locked(tokenId); when it returns true every transfer function on the contract must throw, with feature detection via EIP-165. The motivation cites developers throwing errors ad hoc, causing fragmentation. Read 3 August 2026: the specification covers transferability only and does not address issuance, revocation or recovery. - RetroPGF 3: Voting Badge Distribution
Optimism Collective, official governance forum, 2023
Primary-source deployment policy. Read 3 August 2026: voting badges offered to 208 community members, badgeholders represent individuals rather than projects, a rule against distributing to close co-workers to prevent concentration, and the statement that a distributed voting badge may be revoked in case of a code-of-conduct violation. The post does not itself characterise the badge as on-chain non-transferable, so no such claim is made here.
Last reviewed 2026-08
More in Token Types and Classification
Know the terms but not sure how they apply to your project? That is what an engagement is for. We design, document, and stress-test the whole token economy inside the Tokenomics Data Room.
80+ projects advised. Complete tokenomics in 4 to 6 weeks.