Soulbound Tokens (SBTs) (Complete Guide)
Soulbound tokens are non-transferable NFTs that stay attached to a wallet, turning a token into a durable on-chain signal. They can represent course completion, memberships, contributor roles, and eligibility gates that apps can read without a centralized API. This guide explains what SBTs are, where they fit compared to NFTs and verifiable credentials, and how to design for consent, revocation, privacy minimization, and recovery so you do not create permanent harm by accident.
TL;DR
- SBTs are non-transferable NFTs. Transfers revert. That single rule turns tokens into durable identity signals.
- Use SBTs when a claim can be public and composable and needs to be readable by wallets and smart contracts.
- Do not store personal data on-chain. Keep metadata minimal and put sensitive facts in verifiable credentials off-chain.
- Prevent harassment and spam by requiring recipient consent or a self-claim flow before minting.
- Plan for change with a status model (Active, Suspended, Revoked) and optional expiry for time-bound claims.
- Plan for loss with a reissue policy and a clear recovery runbook for wallet rotation or compromise.
An SBT is a public signal. If a piece of information could harm someone if it becomes permanently searchable, do not put it on-chain. Use a minimal badge on-chain and keep sensitive details in verifiable credentials that the user can present privately when needed.
1) What soulbound tokens are and why people keep building them
Soulbound tokens (SBTs) are non-transferable NFTs. Unlike a typical NFT, you cannot sell, gift, or move an SBT to another address. That constraint changes the meaning of ownership. Instead of representing an asset designed to move, the token becomes a durable on-chain signal attached to a wallet.
This is useful when you want claims like “completed a course,” “is a verified contributor,” “is a member in good standing,” or “holds a steward role” to be readable by apps, DAOs, and dashboards without an API gatekeeper.
2) The model: why non-transferability changes the meaning
Most SBTs are implemented as an ERC-721-like token where transfers revert. The “soul” is the holder address, which might represent a person, a team multisig, or a service identity. Non-transferability reduces the chance that reputation is bought, rented, or outsourced.
- Discoverable: wallets and apps can check for badges without a vendor API.
- Composable: contracts can gate actions using a simple “has badge” check.
- Auditable: mints and status updates produce events that indexers can track.
The tradeoff is correlation. Public ledgers make it easy to link signals together. That is why safe SBT design treats on-chain data as a minimal badge, and keeps rich or sensitive details in off-chain verifiable credentials.
3) Good use cases: when SBTs fit
SBTs work best when the ecosystem benefits from a public, contract-readable signal and the claim does not expose sensitive data.
- Education badges: completion or attendance signals. Keep grades and transcripts private.
- Membership and roles: contributor, reviewer, maintainer, steward.
- Eligibility gates: early access, rate limits, allowlists, program admission.
- Proof of contribution: bounties, hackathons, grant reviews, long-term work.
- Institutional controls: auditor or upgrade steward roles for sensitive functions.
- Event participation: non-tradable mementos that unlock community perks.
If a smart contract must verify a claim without trusting an API, an SBT can help. If the claim should be private by default, use verifiable credentials and privacy-preserving proofs instead.
4) SBTs vs NFTs vs attestations vs verifiable credentials
In practice, identity primitives overlap. The right choice depends on whether the claim should be tradable, private, or enforced on-chain.
| Primitive | Best for | Main risk | Safety move |
|---|---|---|---|
| Transferable NFT | Assets designed to move | Reputation can be purchased | Avoid for identity roles |
| SBT | Public, contract-readable signals | Correlation, spam, permanence | Consent, status model, minimal metadata |
| Verifiable Credential | Private attributes and selective disclosure | Integration complexity | Use standard formats + status lists |
5) Design rules: consent, status, revocation, UX
SBTs can become harassment vectors if anyone can mint sticky labels to any wallet. Good design gives recipients agency, makes validity readable, and minimizes public data.
A) Consent before mint
- Recipient signature: require an EIP-712 signed consent authorizing a specific badge or token ID.
- Self-claim: issuer allowlists addresses, recipients call
claim()to mint to themselves. - Opt-out window: for large drops, publish the list and allow opt-outs before minting.
B) Status, revocation, and expiry
- Status registry: Active, Suspended, Revoked.
- Expiry: for time-bound claims like training validity or compliance checks.
- Issuer burn: only if your policy requires removal rather than lifecycle state.
C) Metadata minimization
- Store only what must be public: badge label, issuer, a policy pointer, and optional integrity hash.
- Never store names, emails, phone numbers, addresses, IDs, birthdates, or doxxing hints on-chain.
- If you need deeper verification, keep details in VCs and ask for private presentation when needed.
SBT design checklist
- Consent via signature or self-claim.
- Status model for incidents and lifecycle clarity.
- Optional expiry for claims that decay.
- Minimal metadata, no personal data.
- Recovery policy for rotation and compromise.
6) Privacy and anti-harassment: reduce correlation risk
Even harmless badges can enable profiling when combined. Design for an adversary that scrapes wallets, clusters addresses, and builds dossiers across apps.
- Wallet separation: encourage a dedicated identity wallet separate from trading and high-value holdings.
- Private gating: for sensitive eligibility, use proofs (for example, membership proofs against a Merkle root with nullifiers).
- Commitment not disclosure: if you must reference something, prefer a salted hash commitment, not plaintext.
- Spam prevention: default to consent-first issuance and publish a takedown or appeals path.
A badge can say “verified by issuer X” without revealing who the person is. If a verifier needs details, users should present a private credential off-chain and disclose only what is necessary.
7) Implementation patterns: making SBTs practical
Many SBTs extend familiar NFT standards and simply disallow transfers. The engineering goal is a simple read path: check ownership, then check status and validity.
A) Minimal non-transferable ERC-721 pattern
B) Safe-by-default metadata
Keep metadata compact and free of personal data. If you host anything off-chain, add integrity fields so clients can detect tampering.
C) Read paths for apps
- Check if the address holds the badge (ownership or registry check).
- Read status and optional validity timestamps.
- Cache results briefly and invalidate on events (mint, status change, burn).
8) Copyable blueprints with clear tradeoffs
A) Education badge with renewal
Goal: signal course completion with a validity window. Flow: student signs consent, issuer mints badge with a validity timestamp, indexers track events. Renewal: refresher completed, issuer renews or reissues. Privacy: transcripts remain off-chain.
B) DAO role badge
Goal: maintainers can call privileged functions only when they hold an Active badge. Incident response: set Suspended during emergencies, then restore or revoke after review.
C) Verification indicator (public flag, private details)
Goal: show “verified by issuer X” without revealing identity. Flow: issuer verifies off-chain, issues a VC, then mints a minimal badge for quick gating. Verifiers request VC presentation only for deeper checks.
D) Event participation badge
Goal: non-tradable badge that also unlocks community access. Flow: attendees scan, sign consent, self-claim. Abuse controls: one claim per wallet, rate limits, minimal public metadata.
9) Operations and recovery: treat SBTs like production infrastructure
The contract can be small, but the signal can be powerful. Issuers and holders need a runbook.
- Issuer key hygiene: multisig or MPC for issuer roles, documented emergency switches, staff-change rotation.
- Versioning: publish migration notes so indexers know where to read status over time.
- Reissue policy: define how holders recover from wallet loss or compromise.
- Monitoring: alert on unusual mint spikes, revocation bursts, and admin changes.
- Policy docs: publish consent, revocation, appeals, and data retention in plain language.
Recovery runbook (minimum viable)
- Holder requests recovery and proves continuity (approved off-chain proof or older key evidence).
- Issuer marks the old badge Revoked (or burns, per policy) and emits an event.
- Issuer mints a new badge to the recovery wallet and emits a linking event.
- Apps treat the newest Active badge as authoritative for gating.
10) Anti-patterns that cause real harm
- Minting without consent: unsolicited labels enable harassment. Always require opt-in.
- Putting personal data on-chain: correlation is irreversible. Keep identity data out.
- No status model: burn-or-nothing makes incident response harder. Add lifecycle states.
- Using SBTs for secrets: private facts belong in VCs and proofs, not on-chain metadata.
- Single hot issuer key: compromises become catastrophic. Use hardened ops and change logs.
FAQs
Can I move an SBT to a new wallet if I rotate keys?
Not by transferring. The common approach is reissue: the issuer revokes the old badge and mints a new badge to the new wallet after you prove continuity under the recovery policy.
What if someone mints a defamatory SBT to my address?
This is why consent matters. Prefer systems that require your signature or self-claim. The best fix is preventing unsolicited mints at the contract level.
Do SBTs improve sybil resistance?
They can help when badges require real work, time, or verification rather than money. They are not a silver bullet. Combining multiple signals and rate limits is stronger.
Is it safe to put verification results on-chain?
Avoid identity details on-chain. If you need a public signal, mint a minimal badge that references a policy and revocation mechanism, and present real details privately with verifiable credentials.
Which wallet should hold SBTs?
Use a dedicated identity wallet separate from high-value holdings. For teams, role badges often belong on a multisig, with operational accounts using separate wallets.
What is the simplest safe SBT design?
Self-claim or recipient signed consent, a status registry (Active, Suspended, Revoked), minimal metadata, and a published recovery policy.
References
Official and reputable starting points for deeper study:
- EIP-721: Non-Fungible Token Standard
- EIP-712: Typed Structured Data Hashing and Signing
- W3C Verifiable Credentials Data Model
- EIP-4973: Account-Bound Tokens
Build safer identity signals with minimal disclosure
If you are designing badges, roles, allowlists, or verification indicators, treat consent, status, and privacy minimization as requirements. Keep badges public but lightweight, and use verifiable credentials for sensitive details when deeper checks are needed.
Conclusion: SBTs work when you design for agency and change
Soulbound tokens are simple in code and heavy in consequences. The reliable pattern is consistent: recipients opt in, validity is explicit, on-chain data stays minimal, and recovery is planned. When you do that, SBTs become a useful identity primitive that apps and contracts can read safely.
A simple action plan:
- Use SBTs only for public, non-sensitive, contract-readable claims.
- Require recipient consent or self-claim to prevent spam and harassment.
- Implement status and optional expiry so validity is clear without deleting history.
- Keep metadata minimal and move sensitive details to verifiable credentials.
- Publish a recovery policy and operate issuer keys with multisig discipline.
Next: decentralized identifiers and verifiable credentials for private, portable identity. Open the next guide.
