The rise of SoulBound Tokens (SBTs) has introduced a fascinating concept where tokens, representing identities, credentials, or other personal attributes, are permanently bound to a user's account (cryptographic identity).
Algorand's ARC-71 proposal PR for SoulBound Algorand Standard Assets (SBT ASAs) takes this idea further, offering a thoughtful implementation of SBTs while maintaining key principles of decentralization, user sovereignty, and flexibility. In this article, we will explore how ARC-71 delivers on the promise of SBTs while respecting unique features of Algorand like the ability for users to close out a token to the creator, even if the token is frozen, without violating the SBT core properties of non-transferability, non-sellability, permanency, and non-burnability.
SBTs are non-transferable, non-sellable digital tokens and are designed to stay permanently under an Algorand account (EOA or Escrow), best suited to represent concepts like self sovergin identity, credentials, certifications, or loyalty programs. Unlike typical assets that can be transferred, sold, or burnt, SBTs are designed to be "soul bound" to an individual's account. The term SoulBound comes from the famous game, world of warcraft, within which some tokens were soulbound.
The ARC-71 proposal, defines an interface for SoulBound ASAs on the Algorand blockchain, compatible with standards like ARC-3 and ARC-19 for Algorand assets. The intention is to create a standard way for wallets, explorers, and dApps to recognize and interact with SoulBound tokens.
In brief, ARC-71 proposes to use non-fractional assets with total of 1 and freez asset to holder and set freeze address to ZeroAddress. This way no authority can detach the token from user's account, token is not transferrable, burnable or sellable. The ARC-71 token can only be closed back to creator after being held.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119.
- There are 2 SBT actor roles: Issuer and Holder.
- There are 3 SBT ASA states, Issued , Held and Revoked.
- Claimed and Revoked SBTs reside in the holder's wallet after claim , forever!
- The ASA parameter decimal places Must be 0 (Fractional NFTs are not allowed)
- The ASA parameter total supply Must be 1 (true non-fungible token).
Note : On Algorand in order to prioritize the end users and power the decentralization, the end call to hold any ASA is given to the user so unless the user is the creator (which needs token deletion) the user can close out the token back to creator even if the token is frozen. After much discussions and feedbacks and many great proposed solutions by experts on the field, in respect to Algorand design, this ARC embraces this convention and leaves the right even to detach SoulBound ASA and close it back to creator and it holds true even in case of real soul bound as well. As a summary ARC-71 SBT respects the account holder's right to close out the ASA back to creator address.
"in Order to have a 100% guaranteed to be undetachable soul bound token, the Creator should be equal to the Holder address. This is not a requirement or concern of this ARC but a recommendation"
The Issued state is the starting state of the ASA.The claimed state is when SBT is sent to destination wallet (claimed) and The Revoked state is the state where the SBT ASA is revoked by issuer after issuance and therefore no longer valid for any usecase except for provenance and historical data reference.
- SBTs with Revoked state are no longer valid and cannot be used as a proof of any credentials.
- Manager address is able to revoke the SBT ASA by setting the Manager address to
ZeroAddress. - Issuer MUST be an Algorand Smart Contract Account.
- The Creator parameter, the ASA MAY be created by any addresses.
- The Clawback parameter MUST be the
ZeroAddress. - The Freeze parameter MUST be set to the Issuer's address.
- The Manager parameter MAY be set to any address but is RECOMMENDED to be the Issuer.
- The Reserve parameter MUST be set to either ARC19 metadata or SBT Issuer's address.
- The Creator parameter, the ASA MAY be created by any addresses.
- The Clawback parameter MUST be the
ZeroAddress. - The Freeze parameter MUST be set to the
ZeroAddress. - The asset must be frozen for holder (claimer) account address.
- The Manager parameter MAY be set to any address but is RECOMMENDED to be the Issuer.
- The Reserve parameter MUST be set to either ARC19 metadata or SBT Issuer's address.
- The Manager parameter MUST be set to
ZeroAddress.
- Issuer and Holder Roles: Two primary roles in managing an SBT - the Issuer (who creates the token) and the Holder (who owns it).
- State Transitions: The token can have a one-way transition between three states: Issued, Held (Claimed), and Revoked, with the token staying in the holder's wallet permanently.
- Revocation Instead of Burning: Tokens that are expired or not valid anymore can be marked as "Revoked," but remain in the user's wallet to preserve provenance and historical data, without being destroyed, burnt or removed.
- Souls can only close out to the creator, so does soulbounds: Within context of ARC-71, inherited from Algorand design conventions, the option for holder's account to close out the asset , only to creator, is open. This leaves the door open for many identity and credentials or even utility SBT scenarios to be able to be agreed upon Issuer and Holder to close out SBT back to creator account.
ARC-71 is an interface for wallets and dApps to be able to recodgnize and interact with SBTs and does not include a methodology, hence it includes a security recommendation on how to bypass Algorand native design pattern of account's ultimate right to close out the asset back to creator only. The method should provide a way to make sure that the holder address is the creator address for SBT asset. This is beyond ARC-71 interface and should be followed under implmentation and deployment. ARC-71 leaves the option open for developers to either make SBTs 100% permanent and override the principal of "The end user's right to hold or not-hold" by simply arrange the implmentation so that the holder creates the SBT , or staying faithful to Algorand design pattern.
One of the unique features of Algorand's SBT implementation under ARC-71 is the ability for a user to close out the token back to the creator. While this might initially appear to contradict the SoulBound concept, it actually serves a higher purpose rooted in the decentralized philosophy of giving ultimate control to the user.
- Non-transferability: The token remains non-transferable to any third party, meaning it cannot be sold, traded, or transferred to other wallets. The only exception is that the holder can return it to the creator - this is not a form of transfer in the traditional sense but rather a return to the issuer. This feature ensures that users maintain control over the assets in their wallets.
- Permanence: The token stays in the user's wallet unless the user consciously decides to close it out and return it by consent. This is in line with the idea that individuals should have the ultimate right to decide which tokens they hold, reflecting the decentralized principle that users have full sovereignty over their wallets.
- Return is different than transfer: As we have returnable non-transferable bonds in traditional finance, non-transferability of soulbound tokens is the same in difference with returnability. Soulbound tokens can be only closed-out and returned to creator of token while being 100% non-transferable to any other account.
- Philosophical Alignment with SoulBound: In a broader, more philosophical sense, this feature resonates with the idea of human souls. Just as one may conceptualize the human soul as having the potential to return to its creator, the close-out mechanism reflects this philosophical notion in a decentralized system - the user retains the authority over their "soul" (the token), even to the extent of choosing to return it to its originator.
This approach reflects the ethos of decentralization: the user has sovereignty over their own assets and the ultimate decision to hold or close out a token. In the context of a blockchain where assets like ASAs can be frozen, ARC-71 acknowledges that the final decision rests with the user, allowing them to return the asset to the creator if they choose. This not only aligns with decentralization but also provides a balanced way to ensure SBTs are bound to identity without stripping the user of their rights.
One of the standout features of ARC-71 is the revocation mechanism. In traditional systems, revoking a token often implies burning it or removing it from circulation. However, burning fundamentally contradicts the idea of SoulBound Tokens, which are meant to remain bound to the holder's identity. Instead, ARC-71 introduces a revocation method that preserves the token's presence in the holder's wallet but marks it as revoked, rendering it inactive for further use.
- Historical Provenance: Even after revocation, the token remains in the wallet, preserving its provenance and historical data. This aligns with real-world credentialing systems, where even expired or invalidated credentials can still provide historical context (e.g., a revoked certificate may no longer be valid, but it still provides proof that it once existed).
- Immutable Attachment: The token doesn't leave the wallet, ensuring that it remains part of the holder's identity but simply marked as revoked. This system ensures that SoulBound tokens maintain their non-transferable and non-burnable properties while still allowing for revocation, making it possible for credentials and achievements to evolve without losing their historical connection to the holder.
The ARC-71 proposal on Algorand provides a simple yet powerful and flexible base for implementing SoulBound ASAs that fully aligns with the core principles of SBTs. By offering features like user sovereignty through the close-out mechanism, revocation without burning, and clear roles for issuers and holders, ARC-71 preserves the non-transferable, non-sellable, and non-burnable nature of SoulBound Tokens.
The reference production level implementation of this proposal pull request is available at GoPlausible platform. The SBTs based on this PR are currently on TESTNET dApp instance. Soon those will be available on MAINNET but first the ARC-71 needs to get to final status.
GoPlausible delivers W3C DIDs, Verifiable Credentials and Utility NFTs , powered by Algorand and AI.
All artworks are generated using GoPlausible GenAI Minter .