Final Update

ARCs/arc-0071.md

@@ -28,16 +28,13 @@ This ARC envisions soulbound ASA as specialized NFTs that will play the roles of
 ## 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 3 SBT ASA states,  **Issued** , **Claimed** and **Revoked**. 
+- 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 1: In current settings the SBT can still be closed out to ASA creator address.
-
-Note 2: Heavy discussions and development is ongoing to address Note 1. WIP! Proposed active solutions:
-
-- To create an atomic transaction group starting with a rekey from holder to issuer, then issuer creating the ASA using holder's address as creator, then freezing the asset and setting freeze address to ZeroAddress then rekeying back to holder. This will ensure that the holder cannot close out the ASA and soulbound ASA stays in holder's account forever. The Issuer provides the ASA params and metadata and controls the process in between rekey and rekey back transactions (This approach is inspired by ARC58 approach). This method is not wallet friendly as rekey will raise wallet alerting to user and therefore effects UX negatively.
+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.
 
 
 
@@ -46,12 +43,11 @@ Note 2: Heavy discussions and development is ongoing to address Note 1. WIP! Pro
 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 Reserve address to `ZeroAddress`.
+- 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`.
@@ -66,8 +62,8 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT
 - The Manager parameter **MUST** be set to Issuer's address.
 - The Reserve parameter **MUST** be set to either ARC19 metadata or SBT Issuer's address.
 
-> In case of Revoked SoulBound:
-- The Reserve parameter **MUST** be set to `ZeroAddress`.
+#### Revoked SoulBound ASA
+- The Manager parameter **MUST** be set to `ZeroAddress`.
 
 ## Rationale
 ### SoulBound ASA NFT 
@@ -79,7 +75,7 @@ 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 reserve address of the token to the ZeroAddress, effectively signaling that the token is no longer valid without removing it from the wallet.
+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.