Merge pull request #316 from GoPlausible/ARC-71

ARC-0071 Consensual Soul Bound ASA [New Approach]

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)
+author: Stéphane BARROSO (@SudoWeezy), MG (@emg110)
 discussions-to: https://github.com/algorandfoundation/ARCs/issues/179
 status: Draft
 type: Standards Track
@@ -11,109 +11,97 @@ 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 & interfact 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. 
+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 [ARC-71](arc-0071.md) soulbound ASAs has gathered significant attention. Without a standard interface, however, soulbound ASAs are incompatible. It is hard to develop universal services targeting at soulbound ASAs without minimal consensus on the implementation of the ASAs.
 
-This ARC envisions soulbound ASA as specialized NFTs that will play the roles of 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.
+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>.
 
-Non Burnable Soulbound ASA: An ASA that can not be remove from a wallet
-Burnable Soulbound ASA: An ASA that can be move from a wallet in order to be burn
-Burn Manager: The address allowed to call the burn method of associated soulbound token
+- 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).
 
-### ASA Addresses Parameters
+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
-We can differenciates 2 Soulbound ASA, Burnable and not Burnable: 
-- Burnable Soulbound ASA
-- Non-Burnable Soulbound ASA
-
-#### Not Burnable Soulbound ASA
-- The `DefaultFrozen` **MUST** be set to true.
+
+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 `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 [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 Manager parameter **MAY** be set to anything.
-- The Reserve parameter **MAY** be set to anything.
-
-> In case of Not Burnable Soulbound, not application is requried.
-
-#### Burnable Soulbound ASA
-> This is an implementation of the [ARC-20](./arc-0020.md) Smart ASA specification.
-- The `DefaultFrozen` **MUST** be set to true.
-- The Creator parameter, the ASA **MAY** be created from a Burn Manager Application.
-- The Clawback parameter **MUST** be the Burn Manager address.
-> Since the Burning relies on using the Clawback mechanism, the Clawback **MUST** not be set to the zero address. 
-- The Freeze parameter **MAY** be set to anything.
-- The Manager parameter **MUST** be set to the Burn Manager address.
-- The Reserve parameter **MAY** be set to anything.
-
-##### Burn Manager ABI Interface
-The Burn manager is the address that can burn the ASA.
-It should be set when the ASA is controlled by Managing Application. And **MUST NOT** be updatable.
-
-The application **MUST** implement the following ABI:
-
-```json
-{
-  "name": "ARC_0071",
-  "desc": "Interface for a burnable soulbound algorand standard asset",
-  "methods": [
-    {
-      "name": "get_burn_manager",
-      "desc": "Get burn manager address",
-      "readonly": true,
-      "args": [
-        { "type": "asset", "name": "asset", "desc": "The desired asset" },
-      ],
-      "returns": { "type": "address", "desc": "The address allowed to burn the asa." }
-    },
-    {
-      "name": "burn",
-      "desc": "Burn a given ASA after checking if the caller is the burn manager",
-      "args": [
-        { "type": "asset", "name": "asset", "desc": "The desired asset to burn" },
-      ],
-      "returns": { "type": "void" }
-    },
-  ]
-}
-```
-The SHA-512/256 hash of 'get_burn_manager(asset)address' is: 0x98364967
-The SHA-512/256 hash of 'burn(asset)void' is: 0xe5fd94d8
-
-The interface selector for this core interface is `0x98364967 XOR 0xe5fd94d8 = 0x7dcbddbf`.
+- 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.
 
-### Burn Authorization
-We want maximum freedom when it comes to interface usage. A flexible and predetermined rule to burn is crucial. Here are some sample scenarios for different burn authorizations:
-- IssuerOnly: Loan record
-- ReceiverOnly: Paid membership
-- Both: Credentials
-- Neither: Credit history
-Burn authorization is immutable after issuance. It is therefore important to inform the receiver and gain receiver’s consent before the token is issued.
+### 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-69, ARC-19 ASAs can be converted into a Non-Burnable SBD ASA if the manager address & freeze address are still available.
 
-ARC-3, ARC-69, ARC-19 ASAs can be converted into a Burnable SBD ASA if the manager address & freeze address & clawback 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
-Creating/Receiving a non-burnable SBD ASA will lock Algo forever.
+
+- 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>.
+
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.