What is a Soulbound Token? - ERC-5114 & ERC-5484

At the end of this article, you should have a clear understanding of what soulbound tokens (SBTs),, ERC-5114 and ERC-5484 are the differences between them and Non-Fungible Tokens (NFTs), and their potential use cases.

‍

What is a Soulbound token?

Soulbound tokens are assets (tokens) bound to an individual’s personal digital identity that cannot be exchanged, moved, or transferred. Puja Ohlhaver, Glen Weyl, and Vitalik Buterin originally developed the idea in their paper Decentralized Society: Finding Web3’s Soul. 

A Soulbound token sounds like something you would acquire in a game of Dungeons and Dragons, like a magic item linked to your soul for eternity. This is not far from the truth. The inspiration for Soulbound tokens came from the popular MMORPG World of Warcraft, where some items are permanently attached to your character without the ability to sell them.

In practice, Soulbound tokens are a type of token that is permanently bound to a wallet or “Soul.” Technically, “Souls” are not the same as wallets because they are designed to represent a persistent digital identity, encompassing credentials, affiliations, and social relationships. Whereas a traditional wallet is primarily focused on managing and transferring digital assets.However, all Ethereum Improvement Proposals (EIPs) and implementations of Soulbound tokens thus far are designed for regular wallets running on Ethereum. So, for the rest of the article, we will focus on SBTs stored and managed within standard Ethereum wallets.

‍

‍

The difference between Soulbound tokens and non-fungible tokens

Soulbound Tokens (SBTs) are based on the same principles as Non-fungible Tokens (NFTs). They are not fungible and, therefore, unique and not interchangeable with each other. Both Soulbound tokens and Non-fungible Tokens have a Token URI to store metadata such as a description, image, and other details.

The core difference between SBTs and NFTs is transferability. Soulbound tokens are non-transferable. Once minted to a wallet, a token cannot be transferred to another account, sold, or listed as a tradable asset.

‍

Example of a Soulbound token

Since the primary difference between SBTs and NFTs is non-transferability, we can create an SBT using a standard ERC-721 token and override the transfer function. 

For example: 

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

import "@openzeppelin/contracts/token/ERC721/ERC721.sol";

contract LameSBT is ERC721 {
    constructor() ERC721("LameSBT", "LSBT") {}

    function mint(address to, uint256 tokenId) external {
        _mint(to, tokenId);
    }

// 👇👇👇 OVERRIDING FUNCTION HERE 👇👇👇
    function transferFrom(
        address from,
        address to,
        uint256 tokenId
    ) public override {
        revert("LameSBT: Tokens are non-transferable");
    }

    function safeTransferFrom(
        address from,
        address to,
        uint256 tokenId,
        bytes memory _data
    ) public override {
        revert("LameSBT: Tokens are non-transferable");
    }
}

The removal of transferability transforms a standard ERC-721 NFT into a Soulbound Token. However, this is an incomplete implementation, especially because many use cases of SBTs require more than just preventing token transfers. 

One big concern is that bad actors might issue Soulbound tokens to a user wallet without consent and permanently attach the wallet to it, so extra functions like renouncing ownership are desirable. Let's explore its use cases to understand what other features might be required for a Soulbound Token.

‍

Soulbound token use cases

Any scenario that requires a non-transferable certification of authenticity and information storage is a potential use case for Soulbound tokens. Let’s explore some popular examples.

‍

1. Soulbound token use case: Academic history and certifications

High schools, colleges, trade schools, certification programs, and any other institution can issue Soulbound tokens upon successfully completing a field of study. In addition to paper certificates, students could receive diplomas or certificates of completion as a Soulbound token, making the student’s credentials easily verifiable worldwide for any process or requirement, like applying for a master's degree in another country.

In this scenario, the SBT contract would require some sort of revoke or update mechanism for cases where the institution discovers fraud, unethical practices, or other disqualifying events. 

‍

2. Soulbound token use case: Medical records

Doctors and hospitals can share medical records, treatment recommendations, and test results as SBTs to ensure privacy, accessibility, and data ownership. The SBT contract must also include strict access controls, allow updates and corrections, and support time-limited access for healthcare professionals to facilitate treatment programs. 

‍

3. Soulbound token use case: Credit history

Financial institutions or credit agencies can issue Soulbound tokens to reflect a user’s credit history, including scores and repayment records. The contract must allow updates to reflect changes in credit status and provide mechanisms to revoke or correct erroneous data. Alternatively, SBTs of this type can be designed to “expire” or provide data only as a snapshot in time, requiring an individual to request a new SBT whenever a new credit report is needed.

‍

4. Other Soulbound token use cases

• Voting and Election Participation 
• Residency and Citizenship Verification 
• Insurance 
• Criminal Record and Background Checks 
• Intellectual Property, Copyright, and Patent Ownership

‍

There are many use cases for Soulbound Tokens and all require unique approaches to deliver use case-specific functionality beyond simply preventing transfers. 

Since the solution is more complex than just overriding the transfer function of an NFT contract, multiple Soulbound token standard proposals have been submitted by the Ethereum community. 

‍

ERC-5114 & ERC-5484

The Ethereum community introduced two standards for Soulbound Tokens to account for the nuance noted above: ERC-5114 and ERC-5484. These standards address different use cases and offer unique features for implementing non-transferable tokens.

‍

ERC-5114 Soulbound Badge

ERC-5114 introduces a "Soulbound Badge," a token permanently bound to a specific NFT when minted. This badge is non-transferable and serves as a persistent identifier of credentials or achievements. The standard ensures the immutability of the token's metadata and URI, making it ideal for applications like digital certifications, where permanence is critical.

The badge is designed to be permanently attached to an existing NFT, directly linking it to the holder's identity or assets, ensuring that it remains associated with the original NFT for its entire lifecycle.

‍

‍Specification

interface IERC5114 {
	
	event Mint(uint256 indexed badgeId, address indexed nftAddress, uint256 indexed nftTokenId);

	
	function ownerOf(uint256 badgeId) external view returns (address nftAddress, uint256 nftTokenId);
	function collectionUri() external pure returns (string collectionUri);
	function badgeUri(uint256 badgeId) external view returns (string badgeUri);
	function metadataFormat() external pure returns (string format);
}

‍

ERC-5484: Consensual Soulbound tokens

ERC-5484 defines a framework for creating SBTs that require mutual consent before issuance and specify immutable burn authorization. This standard builds upon the ERC-721 interface, ensuring compatibility with existing NFT infrastructure. 

The key feature of ERC-5484 is the predefined burn rights, which allow the token to be destroyed under conditions agreed upon at the time of issuance. For example, the user can resign ownership if needed, or an institution can burn the token if it was obtained by cheating. This makes ERC-5484 suitable for use cases like credit history or membership records, where the token's existence might need to be revoked or updated based on predefined rules.

‍

ERC-5484 Soulbound Token specification

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.0;

interface IERC5484 {
    enum BurnAuth {
        IssuerOnly, // Just the Token Creator can Burn it.
        OwnerOnly, // Just the owner can burd it.
        Both, // both the owner and the issuer can burn it.
        Neither // once minted is linked to your soul forever.
    }
    event Issued (
        address indexed from,
        address indexed to,
        uint256 indexed tokenId,
        BurnAuth burnAuth
    );
    function burnAuth(uint256 tokenId) external view returns (BurnAuth);
}

The interface defines the burn authorization depending on the position of the enum, so the ERC standard offers wide flexibility on how it’s managed. 

‍

Conclusion

In this guide we learned what Soulbound crypto tokens are, how they work, and their use cases. Soulbound Tokens represent a significant evolution in how blockchain technology can be used beyond financial assets. SBTs introduce a new paradigm for digital identity, certifications, reputation management, and more. Implementing standards like ERC-5114 and ERC-5484 allows developers to create tokens that are both non-transferable and inherently linked to a user's digital identity in ways traditional NFTs cannot.

For developers looking to master smart contract development and security, including other advanced protocols like Uniswap, Cyfrin Updraft offers top-tier courses led by industry experts. 

Updraft provides the resources and knowledge you need to excel in the industry, whether you're just starting or you want to refine your skills.

‍

‍