Soulbound NFT

What it is

A soulbound NFT (or "SBT," for soulbound token) is a non-fungible token whose transfer function is deliberately disabled or restricted, so it cannot be sold, gifted, or moved off the wallet it was minted to. Instead of representing tradeable ownership like a normal NFT, it represents an attached fact about that specific wallet or identity — a credential, membership, achievement, or reputation marker that only means something because it can't be bought.

How it works

1. An issuer (a protocol, DAO, employer, or event organizer) defines criteria for who qualifies to receive the token — completing a course, attending an event, holding a role, passing a verification check, etc.
2. When a wallet meets the criteria, the issuer's contract mints a token directly to that wallet, often through a permissioned minting function only the issuer (or its designated minter role) can call.
3. The token contract overrides or removes the standard NFT transfer functions (like transferFrom), so the token has no transfer path available to the holder — it is bound to the wallet by code, not just convention.
4. Some designs still allow narrow exceptions: burning by the holder (giving up the credential), revocation by the issuer (e.g., if a membership lapses or a credential is found to be fraudulent), or a supervised re-binding process if a user proves wallet loss.
5. Other contracts, DAOs, or applications can read the presence of the soulbound token in a wallet as a signal — for example, gating a vote, an airdrop, or access to a feature to only wallets that hold a specific credential.
6. Because the token can't be sold, its presence is treated as a stronger signal of the underlying fact (attendance, contribution, verification) than a purchasable NFT would be, though the signal is only as trustworthy as the issuer's criteria and process.

Why designers use it

• Prevents credentials, reputation, or membership proofs from being commoditized and sold to people who didn't actually earn them.
• Enables on-chain systems (governance, airdrops, access control) to check facts about a wallet's history or standing without relying on a centralized database.
• Reduces Sybil attacks in reputation-weighted systems, since real credentials can't simply be purchased in bulk the way transferable tokens can.
• Creates a durable, publicly verifiable record of participation, contribution, or achievement that persists with the wallet over time.

Failure modes

• Wallet loss is much more damaging for soulbound assets than for normal ones: if a user loses their private key, the credential is gone with no recovery path unless the issuer supports re-issuance, and re-issuance itself requires trusting the issuer to correctly re-verify identity.
• "Soulbound" only prevents the token from moving — it doesn't prevent the underlying wallet itself from being rented, sold, or handed over off-chain, so credential markets can simply move to selling access to the whole wallet instead of the token.
• If issuance criteria are loose, automatable, or gamed (e.g., trivial on-chain actions), the token stops being a meaningful signal even though it's technically non-transferable.
• Centralized or opaque revocation power held by the issuer can be misused to strip credentials for reasons unrelated to the stated criteria, undermining trust in the system.
• Cross-chain or cross-wallet identity fragmentation means a person's reputation can end up split across multiple unlinked wallets, each holding partial credentials, weakening the signal any single wallet's SBTs provide.

What to check before using it

• Decide upfront whether any revocation, expiry, or re-issuance path exists, and who controls it — undocumented issuer power here is a real centralization risk.
• Model what happens on wallet loss: is there any recovery mechanism, or is the credential simply gone forever?
• Verify the issuance criteria are hard enough to game that the token remains a meaningful signal over time, not just a rubber stamp.
• Check whether the "non-transferable" guarantee is enforced at the smart-contract level (transfer function actually removed) versus just a social norm that a modified contract could bypass.
• Consider whether whole-wallet transfer (selling access to the wallet itself) undermines the intended non-transferability guarantee for your specific use case, and whether that risk is acceptable.