ERC-5192 is the minimal standard for soulbound tokens (SBTs): ERC-721 NFTs that are locked to the address that holds them. It adds a single view function, locked(tokenId), plus Locked and Unlocked events, so wallets and marketplaces know a token cannot be transferred. Soulbound tokens are ideal for things that should belong to one person or organisation — credentials, certifications, memberships and attestations.
Key takeaways
- One function:
locked(tokenId) → bool; eventsLocked/Unlocked. - Built on ERC-721, so existing tooling can display SBTs.
- ERC-5484 adds consensual issuance and a burn-authorisation model (issuer, holder, both or neither can burn).
- For investor eligibility in security tokens, claim-based identity such as ONCHAINID (used by ERC-3643) is usually more flexible than SBTs.
How it works
interface IERC5192 {
event Locked(uint256 tokenId);
event Unlocked(uint256 tokenId);
function locked(uint256 tokenId) external view returns (bool);
}
When locked returns true, all ERC-721 transfer functions must revert. Issuers typically mint SBTs directly to the recipient and may retain the ability to revoke (burn) them.
Use cases
- Professional and accreditation credentials — e.g. “qualified investor” status issued by a licensed verifier.
- Certificates — training, audits, quality or origin certificates tied to a company wallet.
- Memberships — DAO or club membership that should not be sold.
- Reputation — on-chain track records for borrowers or service providers.
- Device identity — in IoT projects, a soulbound credential can mark a registered meter (we used W3C DIDs and Verifiable Credentials in our solar PPA platform).
SBTs vs claims vs verifiable credentials
| Approach | Strengths | Watch-outs |
|---|---|---|
| ERC-5192 SBT | Simple, visible in wallets | Public by default; revocation must be designed |
| ONCHAINID claims (ERC-3643) | Multiple issuers and topics, expiry, revocation, used by token compliance | More contracts |
| W3C Verifiable Credentials | Rich, privacy-preserving, off-chain by default | Needs verifier infrastructure |
For regulated tokenization we generally keep personal data off-chain and put only signed claims or hashes on-chain. See KYC, AML and on-chain identity.
Privacy considerations
SBTs are public. A token saying “accredited investor” permanently associates that status with an address. Prefer claims that reveal the minimum (e.g. “eligible for offering X”) and consider zero-knowledge proofs or private credentials for sensitive attributes. Never put personal data in token metadata.
Example implementation
// Illustrative soulbound credential — not audited.
contract InvestorCredential is ERC721, AccessControl, IERC5192 {
bytes32 public constant ISSUER_ROLE = keccak256("ISSUER_ROLE");
mapping(uint256 => uint64) public expiresAt;
function issue(address to, uint256 id, uint64 expiry) external onlyRole(ISSUER_ROLE) {
_mint(to, id); expiresAt[id] = expiry; emit Locked(id);
}
function revoke(uint256 id) external onlyRole(ISSUER_ROLE) { _burn(id); }
function locked(uint256) external pure returns (bool) { return true; }
function _update(address to, uint256 id, address auth) internal override returns (address) {
address from = _ownerOf(id);
require(from == address(0) || to == address(0), "soulbound"); // only mint or burn
return super._update(to, id, auth);
}
function isValid(uint256 id) external view returns (bool) {
return _ownerOf(id) != address(0) && block.timestamp < expiresAt[id];
}
}
Credential lifecycle
| Event | Action |
|---|---|
| Verification passed | Issuer mints credential with expiry |
| Status change (e.g. accreditation lapses) | Issuer revokes (burns) |
| Expiry reached | Credential treated as invalid; re-verification required |
| Wallet lost | Revoke old credential, issue to new verified wallet |
| Data subject request | Off-chain data deleted; on-chain token carries no personal data |
Using SBTs with security tokens
A token’s compliance logic can check whether a receiver holds a valid credential from an approved issuer. This works, but compare it with claim-based identity in ERC-3643, which supports multiple claim topics, multiple issuers and multiple wallets per identity more naturally.
Frequently asked questions
Not while locked returns true. Some implementations allow issuers to unlock or re-issue tokens, for example after wallet loss.
The issuer revokes the old SBT and issues a new one to the recovered wallet after re-verification.
They can represent KYC status, but claim-based identity with expiry and revocation is generally more practical for security tokens.
ERC-5192 only signals locking. ERC-5484 adds consensual minting and defines who is allowed to burn the token.
The base standard doesn’t define expiry, but implementations commonly store expiry timestamps and treat expired credentials as invalid.
Yes, if they contain no personal data. The link between an address and a person must stay off-chain.
NUVZ is the RWA and Web3 engineering brand of ESS ENN Associates (est. 1993). Our team has designed and shipped tokenization platforms for real estate, education loans, solar PPAs, energy, carbon credits, bank deposits and trade documents. About us · Case studies
This article is for general information only and is not legal, tax or investment advice. Token standards evolve — always confirm the current status of an ERC at eips.ethereum.org and take advice from qualified counsel in each jurisdiction before issuing tokens.
