From 2160bc05a6f73f9b066e804d691b35317ae710f6 Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 11 Oct 2024 14:37:44 +0300 Subject: [PATCH] Update by Stephane --- ARCs/arc-0071.md | 39 ++++++++++++++++++++------------------- 1 file changed, 20 insertions(+), 19 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 40e0c690d..771855fac 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -2,7 +2,7 @@ arc: 71 title: Consensual Soul Bound ASA description: Interface Soul Bound Algorand Standard Asset -author: Stéphane BARROSO (@SudoWeezy), MG (@emg110) +author: Stéphane BARROSO (@SudoWeezy), MG (@emg110), Rob Moore (@robdmoore), Tasos Bitsios (@tasosbit) discussions-to: https://github.com/algorandfoundation/ARCs/issues/179 status: Draft type: Standards Track @@ -11,31 +11,32 @@ created: 2023-03-17 requires: 4, 20 --- -# Interface & Conventions for Soul Bound Algorand Standard Asset - ## 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 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 RFC-2119. - There are 2 SBT actor roles: **Issuer** and **Holder**. -- There are 3 SBT ASA states, **Issued** , **Held** and **Revoked**. +- 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. - +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 @@ -46,15 +47,16 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - 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 `ZeroAddress`. - 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 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`. @@ -63,14 +65,17 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - The Reserve parameter **MUST** be set to either ARC19 metadata or SBT Issuer's address. #### Revoked SoulBound ASA + - The Manager parameter **MUST** be set to `ZeroAddress`. ## Rationale -### SoulBound ASA NFT + +### 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. @@ -88,19 +93,15 @@ In contrast, burning would not allow for these records to be maintained, and wou 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. - -## Contributions -Many thanks to Tasos Bitsios and Rob Moore for fundamentally contributing to the improvement of this PR by directing it to more correct path. - ## Backwards Compatibility -ARC-3, ARC-69, ARC-19 ASAs can be converted into a SBT ASA, only if the manager address & freeze address are still available. +[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 CCO. \ No newline at end of file + +Copyright and related rights waived via CCO.