Quick Answer: A soulbound token is one you can't sell — it stays in the wallet it was issued to, which is exactly what you want for a credential, a proof-of-attendance, or a contributor badge. This guide covers what non-transferability actually buys you, the ERC-5192 minimal soulbound standard, the design choices that matter (revocable vs. expiring vs. permanent), the UX problems a token-you-can't-trade creates — issuance, revocation, expiry, and wallet recovery — and how communities pair non-transferable credentials with transferable membership NFTs instead of replacing them. It also covers the privacy trade-offs and the honest limits: on-chain badges are public, wallets can be shared, and a credential is only as trustworthy as whoever issued it.
What "soulbound" actually means — and why non-transferability matters
A normal NFT is a bearer asset. Whoever holds it, owns it, and can sell it to anyone. That's correct behaviour for a collectible or a transferable membership pass — the whole point is that it can change hands. It's the wrong behaviour for a credential. If your "verified contributor" badge can be bought on a marketplace, it stops meaning "this person contributed" and starts meaning "this person had 0.02 ETH." The signal collapses the moment the token is tradable.
A soulbound token (SBT) is an NFT that is bound to a wallet and cannot be transferred. The term comes from a 2022 concept paper by Vitalik Buterin and co-authors, borrowing the word from a game mechanic — items that bind to your character and can't be traded. The idea is narrow but useful: some things should not be financial assets. A diploma, a proof you attended an event, a record that you completed a course, a badge for a role you hold — these are facts about a person, not goods. Making them non-transferable keeps them attached to the person the fact is about.
This is the line that separates a soulbound credential from a membership NFT. Membership NFTs are about tiers and access — often deliberately transferable, because access is something you can grant or pass along. Soulbound credentials are about proof and reputation — non-transferable on purpose, because the entire value is that they can't be bought. The two are complements, not substitutes, and a healthy community usually runs both. We'll come back to how they pair.
The ERC-5192 minimal soulbound standard
You don't need a custom contract to make a token non-transferable, and you shouldn't write one from scratch. ERC-5192 is a finalized Ethereum standard that defines the minimal interface for a soulbound token. It's deliberately small: it builds on ERC-721 (so every wallet, explorer, and tool that already understands NFTs understands these too) and adds a single function, locked(tokenId), that returns whether a token is bound. A locked token reverts on transfer. That's the whole standard.
The smallness is the feature. Because ERC-5192 is just ERC-721 plus a lock flag, an SBT shows up in any standard NFT wallet, indexer, or block explorer without special support. Marketplaces that respect the standard won't list a locked token for sale. And a token can be locked at mint or locked later, which leaves room for the revocable and time-bound designs below. Some projects roll their own non-transferable ERC-721s, but ERC-5192 is the one to reach for: standardized, minimal, and with very little surface area to get wrong.
What ERC-5192 deliberately does not do is solve identity, privacy, or revocation policy. It locks a token. Everything else — who can mint, when a credential expires, what happens when status changes — is design you layer on top. A small, boring standard for the hard part, and explicit policy decisions for everything that depends on your use case.
Soulbound vs. revocable vs. expiring: pick the lifecycle
"Non-transferable" is one decision. The lifecycle of the credential is a separate set of decisions, and getting them wrong is the most common mistake we see. Three patterns, and when each is right:
- Permanent soulbound. The token is minted, locked, and never changes. This is correct for facts that don't expire: "attended ETHToronto 2026," "completed the Solidity 101 course," "was a founding member." A proof-of-attendance badge should almost always be permanent — the event happened, and it will always have happened. Don't add an expiry to history.
- Revocable. The issuer retains the ability to burn or invalidate the credential. This is correct for status rather than history: "current core contributor," "active moderator," "verified partner." Status changes. Someone steps down, gets removed, or loses access, and the badge needs to reflect that. Revocability is what makes a credential honest about the present rather than frozen in the past.
- Expiring. The credential carries a validity window and is treated as invalid after a set date, with optional renewal. This is correct for things that should be re-earned: an annual certification, a season-bound role, a 12-month membership-adjacent credential that requires renewed activity. Expiry forces the credential to stay current without anyone manually auditing the holder list.
The trap is choosing permanence for everything because it's the simplest to ship. A community that mints permanent "moderator" badges ends up, two years later, with a roster of on-chain moderators who quit long ago. The token is supposed to be the source of truth, and now it's lying. Match the lifecycle to whether you're recording a fact or a status. Facts are permanent. Statuses need revocation, expiry, or both.
Use cases: attendance, contribution, education, roles, and sybil resistance
Soulbound credentials earn their keep wherever you need a claim that can't be bought. The concrete categories:
Proof-of-attendance. The POAP product category ("Proof of Attendance Protocol") popularized this — a small token minted to everyone who showed up at an event, online or in person. As a soulbound design it's even cleaner: the badge proves you were there, not that you bought a badge from someone who was. Communities use attendance history to gate alumni channels, weight votes by participation, or simply build a durable record of who showed up over time.
Contributor history. A non-transferable record that says "this person shipped real work in this season" is a reputation primitive that compounds across communities. It pairs naturally with the vesting and reward patterns covered in the DAO membership guide — there, contributor NFTs carry financial logic; here, the soulbound version carries just the attribution, which a contributor can carry into the next community they join.
Completion and education certificates. A course, a bootcamp, a workshop, a training program — issue a soulbound certificate on completion. Because it's bound to the learner's wallet and can't be transferred, it can't be sold or lent, which is exactly the property a certificate needs. Verifiers check the issuer and the token, not a PDF that could be Photoshopped.
Role and credential badges. "Verified builder," "grant recipient," "official partner." Revocable soulbound tokens make role status portable and machine-checkable across Discord, Snapshot, a portal, and a partner's site — all reading the same token.
Sybil resistance and reputation. A "sybil attack" is when one person spins up many wallets to look like many people — to farm an airdrop, sway a vote, or inflate a metric. Reputation built from soulbound credentials is harder to fake, because the credentials can't be bought and concentrated into fresh wallets. A wallet with a year of attendance badges and a contributor record is expensive to fabricate; a thousand empty wallets are cheap. SBTs don't solve sybil resistance — nothing does cleanly — but they raise the cost of faking a reputation, which is most of the practical battle.
The hard part: issuance, revocation, expiry, and recovery
A token you can't trade needs a fundamentally different UX than a token you can, and this is where most credential projects underestimate the work. Four problems, none of them optional:
Issuance — who mints into someone's wallet? With a collectible, the holder mints. With a credential, the issuer mints into the holder's wallet, because the whole point is that the holder can't grant themselves a credential. So you need an issuance policy: an event organizer who can mint attendance proofs to a check-in list, an instructor who can issue certificates to a class, a multi-sig that signs off on "core contributor" status. The minting authority is the trust anchor — be deliberate about who holds it.
Revocation — when status changes. With a transferable token you'd just move it. You can't move a soulbound one, so the issuer needs an explicit ability to burn or invalidate. This has to be designed in at deploy time (a permanent, irrevocable token genuinely cannot be revoked), and it should be logged so revocation is auditable rather than silent. Decide up front: is this credential revocable, and by whom?
Expiry — time-bound credentials. For anything that should be re-earned, bake the validity window into the token and have downstream tools treat expired credentials as inactive. The alternative — manually auditing who's still valid — is exactly the spreadsheet problem on-chain credentials are supposed to eliminate.
Recovery — the genuinely hard one. If a holder loses access to their wallet, you can't just transfer the credential to a new one, because it's non-transferable. This trade-off has no perfect answer. The practical options: a custodial or email-first wallet where account recovery is handled for the user (so losing a seed phrase isn't catastrophic); an issuer-side re-issuance policy where the original issuer revokes the lost token and mints a fresh credential to a verified new wallet; or social-recovery patterns at the wallet layer. Recovery is a policy you must choose, not a feature you get for free — and for non-technical holders, custodial recovery is usually the humane default.
Privacy: proving something without doxxing yourself
On-chain credentials are public by default. Anyone can read which tokens a wallet holds, which means a stack of soulbound badges can quietly become a profile — every event you attended, every group you're in, every certificate you hold, all linkable to one address. For a public-facing builder that might be fine. For a lot of people it isn't, and credential systems that ignore this end up doxxing their own users.
The first mitigation is data minimalism: put as little as possible on-chain. The token proves the fact ("holds a course-completion credential from issuer X"); the personal details stay off-chain. The badge doesn't need the holder's legal name, email, or grade — it needs to be checkable. Keep the on-chain footprint to the issuer, the credential type, and a validity flag, and you've proven the claim without publishing a dossier.
The second is recognizing the difference between a badge and an identity system. A soulbound attendance token is a single, scoped claim. A full identity system — verified personhood, KYC, a unified profile — is a much heavier thing with serious privacy and regulatory weight, and most communities neither need it nor should build it. Cryptographic approaches like zero-knowledge proofs (prove "I hold a valid credential" without revealing which one or who you are) point at a more private future, but they're not yet turnkey for most teams. The honest near-term posture: issue scoped, single-purpose credentials; resist building a surveillance graph; and let holders use separate wallets for separate contexts when privacy matters. For Canadian communities, the same PIPEDA-aligned consent and retention discipline you'd apply to any member data applies here — a public token is not an excuse to skip consent on the off-chain record behind it.
How communities, DAOs, events, and educators actually deploy these
The pattern that works in practice is layered: soulbound credentials underneath, transferable membership on top. A few concrete shapes:
A community running both. Transferable membership NFTs handle tiers and access — Member, Contributor, Core — as in the DAO membership playbook. Soulbound credentials run alongside as the proof layer: attendance badges from every event, a contributor-history token per season, a revocable "moderator" badge for current staff. Discord reads the membership tier for access; Snapshot can weight votes by both tier and verified participation. The membership says what you can do today; the credentials say what you've actually done.
An event series. Each event mints a permanent soulbound attendance badge to every check-in. Over a year, a regular attendee's wallet becomes a verifiable history that can gate an alumni space, qualify someone for a "regular" role, or simply exist as a record. The transferable layer here might be the ticket; the soulbound layer is the proof you came.
An educator or training program. Soulbound completion certificates per course, optionally expiring for certifications that need renewal. A learner accumulates a portable, verifiable transcript that no marketplace can sell and no third party can forge — far stronger than a PDF, and checkable by anyone willing to verify the issuer.
A collaboration across communities. When two groups co-host or co-build — the kind of partnership covered in the guide to NFT collaboration for Canadian creators — soulbound co-attendance or co-contributor badges create a shared, tamper-resistant record of who participated on both sides, without either side having to trust the other's spreadsheet.
The throughline: credentials are the substrate of reputation a community accumulates over time; membership is the current-access layer on top. Build them as separate primitives that read cleanly from each other, and the broader community-building strategies for Canadian creators get easier — trust becomes something you can point at on-chain instead of re-litigating every season.
How RAPIT supports non-transferable credentials without Solidity
RAPIT is a Canadian NFT creation platform, and issuing soulbound credentials is a first-class part of it — without writing a contract. The relevant pieces:
- Non-transferable by configuration. When you deploy a credential collection, you choose non-transferable, and RAPIT applies the ERC-5192 lock on standard, audited ERC-721 contracts. You don't write or audit the soulbound logic yourself — you toggle it.
- Issuer-controlled minting. Credentials are minted into holders' wallets by an authorized issuer — an event organizer, an instructor, or a multi-sig — not claimed open-season. You set the minting authority, including routing it through a Gnosis Safe so issuance is a governed action.
- Revocation and expiry as settings. Per credential type, choose permanent, revocable, or expiring. Revocations are logged; expiring credentials carry their validity window in metadata so downstream tools can honour it.
- Attendance proofs. Mint POAP-style soulbound badges to a check-in list — via QR, signature, or an uploaded attendee list — so an event leaves a durable, non-transferable record.
- Email-first custodial wallets for recovery. Because recovery is the hard problem with non-transferable tokens, RAPIT's email-first custodial option means a holder who loses a device isn't permanently locked out — account recovery is handled for them, with self-custody export available for power users who want it.
- Gas-efficient L2 deployment. Credentials are usually issued in volume — every attendee, every graduate — so they go out on a Layer 2 to keep per-mint cost low, with Canadian support on the platform side.
You can configure all of this for your community on RAPIT for Communities, or start building credentials on RAPIT directly.
Common questions
Can a soulbound token ever be transferred? Not by the holder — that's the point. Under ERC-5192 a locked token reverts on transfer. The issuer can still burn a revocable one, and an issuer-side recovery policy can revoke-and-reissue to a new wallet, but there's no marketplace sale and no peer-to-peer transfer.
What happens if someone loses their wallet? You can't transfer the credential out, so recovery is a policy decision: custodial/email-first wallets handle account recovery for the user, or the issuer revokes the lost token and reissues a fresh one to a verified new wallet. Decide this before you launch, not after a holder emails you in a panic.
Are soulbound tokens private? No — on-chain holdings are public. Keep the on-chain data minimal (issuer, type, validity), keep personal details off-chain, and treat a scoped badge as one claim, not an identity system.
Be honest — how trustworthy is an on-chain badge? Only as trustworthy as its issuer. The chain proves a token exists and who minted it; it does not prove the issuer was honest, that the right person controls the wallet, or that the wallet isn't shared. SBTs raise the cost of faking reputation — they don't make a bad issuer credible.
Ready to launch with us? Build credentials on RAPIT for Communities →