-
Notifications
You must be signed in to change notification settings - Fork 118
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #179 from algorandfoundation/ARC-71
ARC-0071: Soulbound ASA NFT
- Loading branch information
Showing
1 changed file
with
108 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,108 @@ | ||
| --- | ||
| arc: 71 | ||
| title: Consensual Soul Bound ASA | ||
| description: Interface Soul Bound Algorand Standard Asset | ||
| author: Stéphane BARROSO (@SudoWeezy), MG (@emg110) | ||
| discussions-to: https://github.com/algorandfoundation/ARCs/issues/179 | ||
| status: Last Call | ||
| last-call-deadline: 2025-02-15 | ||
| type: Standards Track | ||
| category: Interface | ||
| created: 2023-03-17 | ||
| requires: 4, 20 | ||
| --- | ||
|
|
||
| ## Abstract | ||
|
|
||
| The goal is to make it simpler for block explorers, wallets, exchanges, marketplaces, and more generally, client software to identify & interact with a soul bound NFT ASA. | ||
|
|
||
| This defines an interface extending [ARC-3](./arc-0003.md) & [ARC-69](./arc-0069.md) non fungible ASA to create SoulBound ASA. Before issuance, both parties (issuer and receiver), have to agree on who has (if any) the authorization to burn this ASA. | ||
|
|
||
| > This spec is compatible with [ARC-19](./arc-0019.md) to create an updatable SoulBound ASA. | ||
| ## Motivation | ||
|
|
||
| The idea of SoulBound ASAs has gathered significant attention. Without a standard interface, however, SoulBound ASAs cannot be interoperable. It is hard to develop universal services targeting at SoulBound ASAs without minimal consensus on the implementation of the ASAs and their lifecycle. | ||
|
|
||
| This ARC envisions SoulBound ASA as specialized assets that will play the roles of identities, credentials, credit records, loan histories, memberships, and many more. In order to provide the flexibility in these scenarios, SoulBound ASAs must have an application-specific burn method and a way to distinguish themselves from regular ASA. | ||
|
|
||
| ## Specification | ||
|
|
||
| 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 <a href="https://www.ietf.org/rfc/rfc2119.txt">RFC-2119</a>. | ||
|
|
||
| - 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](./arc-0071.md)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" | ||
|
|
||
| ### ASA Parameters Conventions | ||
|
|
||
| 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. | ||
|
|
||
| #### Issued SoulBound ASA | ||
|
|
||
| - 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 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 [ARC-19](./arc-0019.md) metadata or SBT Issuer's address. | ||
|
|
||
| #### Held (claimed) SoulBound ASA | ||
|
|
||
| - 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 ARC-19 metadata or SBT Issuer's address. | ||
|
|
||
| #### Revoked SoulBound ASA | ||
|
|
||
| - The Manager parameter **MUST** be set to `ZeroAddress`. | ||
|
|
||
| ## Rationale | ||
|
|
||
| ### SoulBound ASA NFT | ||
|
|
||
| SoulBound token serves as a specialized subset of the existing ASAs. The advantage of such design is seamless compatibility of SoulBound token with existing NFT services. Service providers can treat SoulBound ASA NFTs like other ASAs and do not need to make drastic changes to their existing codebase. | ||
|
|
||
| ### Revoking vs Burning | ||
|
|
||
| Rationale for Revocation Over Burning in SoulBound Tokens (SBTs): | ||
|
|
||
| The concept of SoulBound Tokens (SBTs) is rooted in permanence and attachment to the holder, much like a "soul" that cannot be broken or lost. Introducing a "burn" mechanism for SBTs fundamentally contradicts this concept because it involves removing the token from the holder’s wallet entirely. Burning suggests destruction and detachment, which is inherently incompatible with the idea of something being bound to the holder for life. | ||
|
|
||
| In contrast, a revocation mechanism aligns more closely with both the SoulBound philosophy and established W3C standards, particularly in the context of Verifiable Credentials (VCs). Revocation allows for SBTs to remain in the user’s wallet, maintaining provenance, historical data, and records of the token’s existence, while simultaneously marking the token as inactive or revoked by its issuer. This is achieved by setting the Manager address of the token to the ZeroAddress, effectively signaling that the token is no longer valid without removing it from the wallet. | ||
|
|
||
| For example, in cases where a Verifiable Credential (VC) issued as an SBT expires or needs to be invalidated (e.g., a driver's license), revocation becomes an essential operation. The token can be revoked by the issuer without being deleted from the user's wallet, preserving a clear record of its prior existence and revocation status. This is beneficial for provenance tracking and compliance, as historical records are crucial in many scenarios. Furthermore, the token can be used as a reference for re-issued or updated credentials without breaking its attachment to the holder. | ||
|
|
||
| This approach has clear benefits: | ||
|
|
||
| Provenance and Historical Data: Keeping the SBT in the wallet allows dApps and systems to track the history of revoked tokens, enabling insights into previous credentials or claims. | ||
| Re-usability and Compatibility: SBTs with revocation fit well into W3C and DIF standards around re-usable DIDs (Decentralized Identifiers) and VCs, allowing credentials to evolve (e.g., switching from one issuer to another) without breaking the underlying identity or trust models. | ||
| Immutable Attachment: The soul-like bound remains intact. The token does not leave the wallet, making it clear that the SBT is still part of the user’s identity, but with a revoked status. | ||
| In contrast, burning would not allow for these records to be maintained, and would break the "bound" nature of the SBT by removing the token from the holder's possession entirely, which defeats the core idea behind SBTs. | ||
|
|
||
| In summary, revocation offers a more interoperable alternative to burning for SBTs. It ensures that SBTs remain SoulBound while allowing for expiration, invalidation, or issuer changes, all while maintaining a record of the token’s lifecycle and status. | ||
|
|
||
| ## Backwards Compatibility | ||
|
|
||
| [ARC-3](./arc-0003.md), [ARC-69](./arc-0069.md), [ARC-19](./arc-0019.md) ASAs can be converted into a SBT ASA, only if the manager address & freeze address are still available. | ||
|
|
||
| ## Security Considerations | ||
|
|
||
| - Claiming/Receiving a SBT ASA will lock Algo forever until user decides to close it out back to creator address. | ||
| - For security critical implementations it is vital to take into account that according to Algorand design, the user has the right to close out the ASA back to creator address. This is certainly kept on chain transaction history and indexers. | ||
|
|
||
| ## Copyright | ||
|
|
||
| Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>. |