From e4ca63481d0c8781e71abcc7f549cc3f84b0f596 Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 9 Oct 2024 18:42:43 +0300 Subject: [PATCH 01/42] ARC-0071 Consensual Soul Bound ASA --- ARCs/arc-0071.md | 106 +++++++++++++++++------------------------------ 1 file changed, 38 insertions(+), 68 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 1fdc4f9fa..6da6cdb38 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) +author: Stéphane BARROSO (@SudoWeezy), MG (@emg110) discussions-to: https://github.com/algorandfoundation/ARCs/issues/179 status: Draft type: Standards Track @@ -14,106 +14,76 @@ 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. +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. +The idea of [ARC-71](arc-0071.md) 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 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. ## 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. -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 ASA states, **Issued** and **Revoked**. +- **Issued** 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 is strongly **RECOMMENDED** to be 1 (true non-fungible token) but **MAY** be more than 1 in case of **OPTIONAL** utility NFTs with no monetary or exclusive identity restricted values (General credentials , like general proof of presence for olympics). + +### ASA Parameters Conventions -### ASA Addresses Parameters +The Issued state is the default state of the ASA. 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. -### ASA Parameters Conventions -We can differenciates 2 Soulbound ASA, Burnable and not Burnable: -- Burnable Soulbound ASA -- Non-Burnable Soulbound ASA +- SBTs with Revoked state are no longer valid and cannot be used as a proof of any credentials. Those ASAs have their manager address set to the zero address. +- The Manager parameter **MUST** be set to `ZeroAddress` in revoked SBT. +- The Reserve parameter **MAY** be set to either ARC19 metadata or SBT Issuer vault address. -#### Not Burnable Soulbound ASA -- The `DefaultFrozen` **MUST** be set to true. +#### 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 anything. - The Reserve parameter **MAY** be set to anything. -> In case of Not Burnable Soulbound, not application is requried. +> In case of Revoked Soulbound: +- The Manager parameter **MUST** be set to `ZeroAddress`. + -#### 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`. ## 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. +### 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 technically sound and philosophically consistent 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 SBT ASA, only 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. ## Security Considerations -Creating/Receiving a non-burnable SBD ASA will lock Algo forever. +Claiming/Receiving a SBT ASA will lock Algo forever. ## Copyright Copyright and related rights waived via CCO. \ No newline at end of file From 2ce28fa767bdf13f482bb7bfef4e7b33afe0762c Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 9 Oct 2024 20:18:57 +0300 Subject: [PATCH 02/42] Fix of flaw in design --- ARCs/arc-0071.md | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 6da6cdb38..83a51857e 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -35,21 +35,27 @@ The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL ### ASA Parameters Conventions -The Issued state is the default state of the ASA. 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. +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. Those ASAs have their manager address set to the zero address. -- The Manager parameter **MUST** be set to `ZeroAddress` in revoked SBT. -- The Reserve parameter **MAY** be set to either ARC19 metadata or SBT Issuer vault address. - +- The Reserve parameter **MUST** be set to `ZeroAddress` in revoked SBT. + #### 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 anything. -- The Reserve parameter **MAY** be set to anything. +- The Manager parameter ***MAY** be set to any address. +- The Reserve parameter **MAY** be set to either ARC19 metadata or **SHOULD** be SBT Issuer's vault address. + +#### Landed (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 **MUST** be set to `ZeroAddress`. +- The Reserve parameter **MAY** be set to either ARC19 metadata or SBT Issuer vault address in issued SBTs. > In case of Revoked Soulbound: -- The Manager parameter **MUST** be set to `ZeroAddress`. +- The Reserve parameter **MUST** be set to `ZeroAddress`. @@ -64,7 +70,7 @@ Soulbound token serves as a specialized subset of the existing ASAs. The advanta 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. +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. 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. From 312570d11e6dcd13cdabbdbe437ecac88c325af4 Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 9 Oct 2024 21:44:36 +0300 Subject: [PATCH 03/42] Minor fix --- ARCs/arc-0071.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 83a51857e..88405dbae 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -28,8 +28,8 @@ 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 RFC-2119. -- There are 2 SBT ASA states, **Issued** and **Revoked**. -- **Issued** and **Revoked** SBTs reside in the holder's wallet after claim , forever! +- There are 3 SBT ASA states, **Issued** , **Claimed** 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 is strongly **RECOMMENDED** to be 1 (true non-fungible token) but **MAY** be more than 1 in case of **OPTIONAL** utility NFTs with no monetary or exclusive identity restricted values (General credentials , like general proof of presence for olympics). From 73017e7ab9416b3cd179c7df5138ae9e1b5af7d7 Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 9 Oct 2024 23:33:41 +0300 Subject: [PATCH 04/42] Contributions --- ARCs/arc-0071.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 88405dbae..70ba18b83 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -83,6 +83,8 @@ In contrast, burning would not allow for these records to be maintained, and wou In summary, revocation offers a more technically sound and philosophically consistent 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 and implementation of SoulBound ASA 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. From 8713905f20d6af7a01a73e97451dd940746dc37f Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 9 Oct 2024 23:35:17 +0300 Subject: [PATCH 05/42] TODO --- ARCs/arc-0071.md | 4 ++++ 1 file changed, 4 insertions(+) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 70ba18b83..75351e26a 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -83,6 +83,10 @@ In contrast, burning would not allow for these records to be maintained, and wou In summary, revocation offers a more technically sound and philosophically consistent 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. +## TODO + +The only remaining gap which enables a claimer to be able to close out the SBT back to creator address needs to be addressed. This is WIP. + ## Contributions Many thanks to Tasos Bitsios and Rob Moore for fundamentally contributing to the improvement of this PR and implementation of SoulBound ASA by directing it to more correct path. From f80ab93d3dcc49580e71c1e6cb10d9c714dabfe7 Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 9 Oct 2024 23:41:45 +0300 Subject: [PATCH 06/42] Find another flaw! --- ARCs/arc-0071.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 75351e26a..fc406363a 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -41,6 +41,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - The Reserve parameter **MUST** be set to `ZeroAddress` in revoked SBT. #### 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`. @@ -56,6 +57,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT > In case of Revoked Soulbound: - The Reserve parameter **MUST** be set to `ZeroAddress`. + From b251380fb3b76de4056ac5a8e1607578b1ee13ba Mon Sep 17 00:00:00 2001 From: MG Date: Wed, 9 Oct 2024 23:42:58 +0300 Subject: [PATCH 07/42] Fix Typo --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index fc406363a..72d718b07 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -57,7 +57,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT > In case of Revoked Soulbound: - The Reserve parameter **MUST** be set to `ZeroAddress`. - + From 13a3758311ed19094a8603a983fb3a8e1ac189f4 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 09:55:06 +0300 Subject: [PATCH 08/42] Update (address some flaws) --- ARCs/arc-0071.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 72d718b07..2e7a27151 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -37,12 +37,16 @@ The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL 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. Those ASAs have their manager address set to the zero address. -- The Reserve parameter **MUST** be set to `ZeroAddress` in revoked SBT. +- SBTs with Revoked state are no longer valid and cannot be used as a proof of any credentials. +- In current settings the SBT can only be closed out to ASA creator address. +- In current settings Manager address will be able to revoke the SBT ASA by setting the Reserve address to `ZeroAddress`. +- This ARC assumes a basic trust to be existing between Issuer and Receiver and that Issuer is trusted by Receiver to play fair. + #### Issued Soulbound ASA - The Creator parameter, the ASA **MAY** be created by any addresses. +- The DefaultFrozen parameter of the ASA **MAY** be set to anything. - 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. @@ -52,12 +56,13 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - 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 **MUST** be set to `ZeroAddress`. -- The Reserve parameter **MAY** be set to either ARC19 metadata or SBT Issuer vault address in issued SBTs. +- The asset must be frozen for claimer account address. +- The Manager parameter **MAY** be set to any address except claimer address. +- The Reserve parameter **MAY** be set to either ARC19 metadata or SBT Issuer's vault address. > In case of Revoked Soulbound: - The Reserve parameter **MUST** be set to `ZeroAddress`. - +- The Manager parameter **MAY** be set to any address except claimer address. From d70f02d1b0b48013a79ec08df83e4ddc44a22a9f Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 11:08:59 +0300 Subject: [PATCH 09/42] Add Noted Issues --- ARCs/arc-0071.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 2e7a27151..24be0cdbf 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -38,9 +38,13 @@ The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL 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. -- In current settings the SBT can only be closed out to ASA creator address. - In current settings Manager address will be able to revoke the SBT ASA by setting the Reserve address to `ZeroAddress`. -- This ARC assumes a basic trust to be existing between Issuer and Receiver and that Issuer is trusted by Receiver to play fair. + +Note 1: In current settings the SBT can only be closed out to ASA creator address. + +Note 2: This ARC assumes a basic trust to be existing between Issuer and Receiver and that Issuer is trusted by Receiver to play fair. + +Note 3: Heavy discussions and development is ongoing to address these 2 noted items. WIP. #### Issued Soulbound ASA From e85c31d12252686a6e583a3ca510341e83be8c1d Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 11:09:21 +0300 Subject: [PATCH 10/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 24be0cdbf..245a36cf4 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -42,7 +42,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT Note 1: In current settings the SBT can only be closed out to ASA creator address. -Note 2: This ARC assumes a basic trust to be existing between Issuer and Receiver and that Issuer is trusted by Receiver to play fair. +Note 2: In current status this ARC assumes a basic trust to be existing between Issuer and Receiver and that Issuer is trusted by Receiver to play fair. Note 3: Heavy discussions and development is ongoing to address these 2 noted items. WIP. From 918ae88f99227a94367b752c8bf688a34ea0020c Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 12:34:57 +0300 Subject: [PATCH 11/42] Add active solution for closeout issue --- ARCs/arc-0071.md | 22 ++++++++++++---------- 1 file changed, 12 insertions(+), 10 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 245a36cf4..21fcc8dec 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -31,23 +31,25 @@ The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL - There are 3 SBT ASA states, **Issued** , **Claimed** 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 is strongly **RECOMMENDED** to be 1 (true non-fungible token) but **MAY** be more than 1 in case of **OPTIONAL** utility NFTs with no monetary or exclusive identity restricted values (General credentials , like general proof of presence for olympics). +- The ASA parameter total supply is strongly **RECOMMENDED** to be 1 (true non-fungible token) but **MAY** be more than 1 in case of **OPTIONAL** utility NFTs with no monetary or exclusive identity restricted values (General credentials , like general proof of presence for some event). ### 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. -- In current settings Manager address will be 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 Reserve address to `ZeroAddress`. -Note 1: In current settings the SBT can only be closed out to ASA creator address. +Note 1: In current settings the SBT can still be closed out to ASA creator address. -Note 2: In current status this ARC assumes a basic trust to be existing between Issuer and Receiver and that Issuer is trusted by Receiver to play fair. +Note 2: In current status this ARC assumes a basic trust to be existing between Issuer and Receiver and that Issuer is trusted by Receiver. -Note 3: Heavy discussions and development is ongoing to address these 2 noted items. WIP. +Note 3: Heavy discussions and development is ongoing to address these 2 noted items. WIP. Proposed active solution for item 1: +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 transferring the ASA to holder, 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. -#### Issued Soulbound ASA + +#### Issued SoulBound ASA - The Creator parameter, the ASA **MAY** be created by any addresses. - The DefaultFrozen parameter of the ASA **MAY** be set to anything. @@ -56,7 +58,7 @@ Note 3: Heavy discussions and development is ongoing to address these 2 noted it - The Manager parameter ***MAY** be set to any address. - The Reserve parameter **MAY** be set to either ARC19 metadata or **SHOULD** be SBT Issuer's vault address. -#### Landed (claimed) Soulbound ASA +#### 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`. @@ -64,7 +66,7 @@ Note 3: Heavy discussions and development is ongoing to address these 2 noted it - The Manager parameter **MAY** be set to any address except claimer address. - The Reserve parameter **MAY** be set to either ARC19 metadata or SBT Issuer's vault address. -> In case of Revoked Soulbound: +> In case of Revoked SoulBound: - The Reserve parameter **MUST** be set to `ZeroAddress`. - The Manager parameter **MAY** be set to any address except claimer address. @@ -72,9 +74,9 @@ Note 3: Heavy discussions and development is ongoing to address these 2 noted it ## 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. +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 From f92b158f1324b0c4e5d0710591e166a50d891af8 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 12:35:45 +0300 Subject: [PATCH 12/42] Format --- ARCs/arc-0071.md | 14 +++++++------- 1 file changed, 7 insertions(+), 7 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 21fcc8dec..30e009b14 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -32,14 +32,7 @@ The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL - **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 is strongly **RECOMMENDED** to be 1 (true non-fungible token) but **MAY** be more than 1 in case of **OPTIONAL** utility NFTs with no monetary or exclusive identity restricted values (General credentials , like general proof of presence for some event). - -### 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 Reserve address to `ZeroAddress`. - Note 1: In current settings the SBT can still be closed out to ASA creator address. Note 2: In current status this ARC assumes a basic trust to be existing between Issuer and Receiver and that Issuer is trusted by Receiver. @@ -47,6 +40,13 @@ Note 2: In current status this ARC assumes a basic trust to be existing between Note 3: Heavy discussions and development is ongoing to address these 2 noted items. WIP. Proposed active solution for item 1: 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 transferring the ASA to holder, 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. + +### 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 Reserve address to `ZeroAddress`. #### Issued SoulBound ASA From c74c39a6a1a887ff324dad714e3638986d56b413 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 12:43:38 +0300 Subject: [PATCH 13/42] Update --- ARCs/arc-0071.md | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 30e009b14..2e5dc1be0 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -35,9 +35,7 @@ The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL Note 1: In current settings the SBT can still be closed out to ASA creator address. -Note 2: In current status this ARC assumes a basic trust to be existing between Issuer and Receiver and that Issuer is trusted by Receiver. - -Note 3: Heavy discussions and development is ongoing to address these 2 noted items. WIP. Proposed active solution for item 1: +Note 2: Heavy discussions and development is ongoing to address Note 1. WIP! Proposed active solution for item 1: 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 transferring the ASA to holder, 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. @@ -70,9 +68,6 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - The Reserve parameter **MUST** be set to `ZeroAddress`. - The Manager parameter **MAY** be set to any address except claimer address. - - - ## Rationale ### SoulBound ASA NFT From 5d2a0d6ea2276d74bb2938cd07d272a24df92e79 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 12:43:55 +0300 Subject: [PATCH 14/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 2e5dc1be0..8355738bf 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -35,7 +35,7 @@ The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL 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 solution for item 1: +Note 2: Heavy discussions and development is ongoing to address Note 1. WIP! Proposed active solution: 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 transferring the ASA to holder, 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. From e50de745b3a3505e137297ed0f5ee07929aeb52c Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 13:40:33 +0300 Subject: [PATCH 15/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 8355738bf..316427c92 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -37,7 +37,7 @@ Note 1: In current settings the SBT can still be closed out to ASA creator addre Note 2: Heavy discussions and development is ongoing to address Note 1. WIP! Proposed active solution: -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 transferring the ASA to holder, 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. +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. ### ASA Parameters Conventions From b510823b800c1f38cc7bb4dcbbe5a665af002d9e Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 13:43:46 +0300 Subject: [PATCH 16/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 316427c92..3a68a165d 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -37,7 +37,7 @@ Note 1: In current settings the SBT can still be closed out to ASA creator addre Note 2: Heavy discussions and development is ongoing to address Note 1. WIP! Proposed active solution: -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. +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. ### ASA Parameters Conventions From 5ab265365a076657635bc2f3b3a5cf4ed4a763ca Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 13:45:47 +0300 Subject: [PATCH 17/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 3a68a165d..3c9f2c2f2 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -37,7 +37,7 @@ Note 1: In current settings the SBT can still be closed out to ASA creator addre Note 2: Heavy discussions and development is ongoing to address Note 1. WIP! Proposed active solution: -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. +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). ### ASA Parameters Conventions From a9ba323b4cefe5f70bf74dae3eac7ce09a5ddb3b Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 13:47:30 +0300 Subject: [PATCH 18/42] Change requirements --- ARCs/arc-0071.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 3c9f2c2f2..baf23228f 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -54,7 +54,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - 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. -- The Reserve parameter **MAY** be set to either ARC19 metadata or **SHOULD** be SBT Issuer's vault address. +- The Reserve parameter **MUST** be set to either ARC19 metadata or **SHOULD** be SBT Issuer's vault address. #### Held (claimed) SoulBound ASA - The Creator parameter, the ASA **MAY** be created by any addresses. @@ -62,7 +62,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - The Freeze parameter **MUST** be set to the `ZeroAddress`. - The asset must be frozen for claimer account address. - The Manager parameter **MAY** be set to any address except claimer address. -- The Reserve parameter **MAY** be set to either ARC19 metadata or SBT Issuer's vault address. +- The Reserve parameter **MUST** be set to either ARC19 metadata or SBT Issuer's vault address. > In case of Revoked SoulBound: - The Reserve parameter **MUST** be set to `ZeroAddress`. From 0bdf1dfc2d827cf2c473349b41a8e9f2c1e372c7 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 13:49:29 +0300 Subject: [PATCH 19/42] Update requirements --- ARCs/arc-0071.md | 9 ++++----- 1 file changed, 4 insertions(+), 5 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index baf23228f..b630ad4be 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -53,20 +53,19 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - The DefaultFrozen parameter of the ASA **MAY** be set to anything. - 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. -- The Reserve parameter **MUST** be set to either ARC19 metadata or **SHOULD** be SBT Issuer's vault address. +- The Manager parameter ***MUST** be set to Issuer's address. +- The Reserve parameter **MUST** be set to either ARC19 metadata or **SHOULD** be 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 claimer account address. -- The Manager parameter **MAY** be set to any address except claimer address. -- The Reserve parameter **MUST** be set to either ARC19 metadata or SBT Issuer's vault address. +- 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`. -- The Manager parameter **MAY** be set to any address except claimer address. ## Rationale ### SoulBound ASA NFT From 75f6cb780c25d8ef9284c1b26e0f04f85a6b3969 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 16:34:11 +0300 Subject: [PATCH 20/42] Update Solutions --- ARCs/arc-0071.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index b630ad4be..9441775ab 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -30,14 +30,16 @@ The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL - There are 3 SBT ASA states, **Issued** , **Claimed** 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 is strongly **RECOMMENDED** to be 1 (true non-fungible token) but **MAY** be more than 1 in case of **OPTIONAL** utility NFTs with no monetary or exclusive identity restricted values (General credentials , like general proof of presence for some event). +- 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 solution: +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). +- 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). + +- Other solution is not to use rekeys and instead have user create the ASA and use the dApp to manage the process in one atomic transaction group. User asset creation, ABI call with issuer optin inner transaction, asset send to issuer, set issuer as manager, issuer send ASA back to holder,issuer freeze asset, set freeze address to ZeroAddress. This approach is more user friendly but requires more user interaction and dApp development. ### ASA Parameters Conventions @@ -45,6 +47,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - 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`. +- Issuer **MUST** be an Algorand Smart Contract Account. #### Issued SoulBound ASA From 7e12faad88244c27a8e6489327a7521246e21870 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 16:48:23 +0300 Subject: [PATCH 21/42] Update second approach --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 9441775ab..3a59fb01a 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -39,7 +39,7 @@ Note 2: Heavy discussions and development is ongoing to address Note 1. WIP! Pro - 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). -- Other solution is not to use rekeys and instead have user create the ASA and use the dApp to manage the process in one atomic transaction group. User asset creation, ABI call with issuer optin inner transaction, asset send to issuer, set issuer as manager, issuer send ASA back to holder,issuer freeze asset, set freeze address to ZeroAddress. This approach is more user friendly but requires more user interaction and dApp development. +- Other solution is not to use rekeys and instead have user create the ASA and use the dApp to manage the process in one atomic transaction group. Managed by dApp, A transaction group is created including: A transaction for asset creation by holder, a config transaction to set issuer as manager and freeze addresses (and reserve if not ARC19), ABI call with inner transaction from issuer to freeze asset and another inner txn to set freeze address to ZeroAddress. This approach is more wallet friendly but requires more user interaction and dApp development. ### ASA Parameters Conventions From ec0950966738742308ae67382951d474a02a8e41 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 17:09:28 +0300 Subject: [PATCH 22/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 3a59fb01a..b9fe8d594 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -39,7 +39,7 @@ Note 2: Heavy discussions and development is ongoing to address Note 1. WIP! Pro - 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). -- Other solution is not to use rekeys and instead have user create the ASA and use the dApp to manage the process in one atomic transaction group. Managed by dApp, A transaction group is created including: A transaction for asset creation by holder, a config transaction to set issuer as manager and freeze addresses (and reserve if not ARC19), ABI call with inner transaction from issuer to freeze asset and another inner txn to set freeze address to ZeroAddress. This approach is more wallet friendly but requires more user interaction and dApp development. +- Other solution is not to use rekeys and instead have user create the ASA and use the dApp to manage the process in one atomic transaction group. Managed by dApp, A transaction group is created including: A transaction for asset creation by holder, a config transaction to set issuer as manager and freeze addresses (and reserve if not ARC19), ABI call with inner transaction from issuer to freeze asset and another inner txn to set freeze address to ZeroAddress. This approach is more wallet friendly but requires more dApp development. ### ASA Parameters Conventions From 0ef9d5e308273c31ef17fb670b4860d87f77d4b2 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 17:10:45 +0300 Subject: [PATCH 23/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index b9fe8d594..0fe501eaf 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -57,7 +57,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - The Clawback parameter **MUST** be the `ZeroAddress`. - The Freeze parameter **MUST** be set to the `ZeroAddress`. - The Manager parameter ***MUST** be set to Issuer's address. -- The Reserve parameter **MUST** be set to either ARC19 metadata or **SHOULD** be SBT Issuer's address. +- The Reserve parameter **MUST** be set to either ARC19 metadata or SBT Issuer's address. #### Held (claimed) SoulBound ASA - The Creator parameter, the ASA **MAY** be created by any addresses. From 1a8f278a0208731fbb97198560a0124ef34f950d Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 17:12:22 +0300 Subject: [PATCH 24/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 0fe501eaf..c9bd93ca1 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -76,8 +76,8 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT 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): -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. From 1408a9361aa8f1f79193362d7eaba7bd57128329 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 17:13:32 +0300 Subject: [PATCH 25/42] Update wordings --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index c9bd93ca1..b20e7bd16 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -91,7 +91,7 @@ Re-usability and Compatibility: SBTs with revocation fit well into W3C and DIF s 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 technically sound and philosophically consistent 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. +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. ## TODO From 93f83c2bde2ec947bcc9e66d63030fda1d28b498 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 17:21:17 +0300 Subject: [PATCH 26/42] Update: solution 2 eliminated --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index b20e7bd16..d176a864b 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -39,7 +39,7 @@ Note 2: Heavy discussions and development is ongoing to address Note 1. WIP! Pro - 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). -- Other solution is not to use rekeys and instead have user create the ASA and use the dApp to manage the process in one atomic transaction group. Managed by dApp, A transaction group is created including: A transaction for asset creation by holder, a config transaction to set issuer as manager and freeze addresses (and reserve if not ARC19), ABI call with inner transaction from issuer to freeze asset and another inner txn to set freeze address to ZeroAddress. This approach is more wallet friendly but requires more dApp development. + ### ASA Parameters Conventions From 173a971ebddbc431792b8e5b17f7606becbaa66d Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 17:22:28 +0300 Subject: [PATCH 27/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index d176a864b..fe190d916 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -37,7 +37,7 @@ Note 1: In current settings the SBT can still be closed out to ASA creator addre 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). +- 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. From 5ad1ecfe50a5b5946b434838583ef5554ccbfb20 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 17:31:23 +0300 Subject: [PATCH 28/42] Update --- ARCs/arc-0071.md | 1 - 1 file changed, 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index fe190d916..81fa43803 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -53,7 +53,6 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT #### Issued SoulBound ASA - The Creator parameter, the ASA **MAY** be created by any addresses. -- The DefaultFrozen parameter of the ASA **MAY** be set to anything. - The Clawback parameter **MUST** be the `ZeroAddress`. - The Freeze parameter **MUST** be set to the `ZeroAddress`. - The Manager parameter ***MUST** be set to Issuer's address. From cc6d27a00561261d241b2b81721320740aec13a4 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 18:01:03 +0300 Subject: [PATCH 29/42] Final Update --- ARCs/arc-0071.md | 18 +++++++----------- 1 file changed, 7 insertions(+), 11 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 81fa43803..6405f4670 100644 --- a/ARCs/arc-0071.md +++ b/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 RFC-2119. -- 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. From 9d13361449709c2701be5d1d1d2d205bf2559afa Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 18:04:33 +0300 Subject: [PATCH 30/42] Update --- ARCs/arc-0071.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 6405f4670..8df12c717 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -51,7 +51,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - 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 ***MUST** be set to 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. #### Held (claimed) SoulBound ASA @@ -59,7 +59,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - The Clawback parameter **MUST** be the `ZeroAddress`. - The Freeze parameter **MUST** be set to the `ZeroAddress`. - The asset must be frozen for claimer account address. -- The Manager parameter **MUST** be set to 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. #### Revoked SoulBound ASA From e19ab747581421396d8543d6d951301c81ebdbf0 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 18:06:01 +0300 Subject: [PATCH 31/42] Update --- ARCs/arc-0071.md | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 8df12c717..794bda088 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -37,7 +37,6 @@ The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL 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. - ### 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. @@ -58,7 +57,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - 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 claimer account address. +- 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. From 5da7172048205f4e48e25b208bfbf99a33d79360 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 18:06:57 +0300 Subject: [PATCH 32/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 794bda088..2e30ba034 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -92,7 +92,7 @@ In summary, revocation offers a more interoperable alternative to burning for SB The only remaining gap which enables a claimer to be able to close out the SBT back to creator address needs to be addressed. This is WIP. ## Contributions -Many thanks to Tasos Bitsios and Rob Moore for fundamentally contributing to the improvement of this PR and implementation of SoulBound ASA by directing it to more correct path. +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. From 6a8d2b869831ceecfda596a788ae9c7161e50835 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 18:22:11 +0300 Subject: [PATCH 33/42] Update Security Considerations --- ARCs/arc-0071.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 2e30ba034..a1b8afba3 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -99,7 +99,9 @@ ARC-3, ARC-69, ARC-19 ASAs can be converted into a SBT ASA, only if the manager ## Security Considerations -Claiming/Receiving a SBT 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 tracable onchain. +- 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. ## Copyright Copyright and related rights waived via CCO. \ No newline at end of file From 373bd84ef630f10df585f2667b44552d0ae9b1f5 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 18:23:25 +0300 Subject: [PATCH 34/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index a1b8afba3..6708ed82f 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -100,7 +100,7 @@ ARC-3, ARC-69, ARC-19 ASAs can be converted into a SBT ASA, only if the manager ## 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 tracable onchain. +- 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. - 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. ## Copyright From edaa3a21f598a3df190b5ee257dce087e0888c96 Mon Sep 17 00:00:00 2001 From: MG Date: Thu, 10 Oct 2024 18:27:03 +0300 Subject: [PATCH 35/42] Update --- ARCs/arc-0071.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 6708ed82f..e7e2e41b4 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -36,6 +36,7 @@ The key words "**MUST**", "**MUST NOT**", "**REQUIRED**", "**SHALL**", "**SHALL 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" ### ASA Parameters Conventions @@ -101,7 +102,8 @@ ARC-3, ARC-69, ARC-19 ASAs can be converted into a SBT ASA, only if the manager ## 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. -- 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. + + ## Copyright Copyright and related rights waived via CCO. \ No newline at end of file From 045643c42d9610f10a9e1bf399ab877f26563296 Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 11 Oct 2024 12:06:34 +0300 Subject: [PATCH 36/42] Update --- ARCs/arc-0071.md | 11 ++++------- 1 file changed, 4 insertions(+), 7 deletions(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index e7e2e41b4..09557ee8e 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -16,14 +16,14 @@ 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 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 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. +The idea of [ARC-71](arc-0071.md) 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 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. +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. ## 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. @@ -68,7 +68,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT ## 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. +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): @@ -88,9 +88,6 @@ 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. -## TODO - -The only remaining gap which enables a claimer to be able to close out the SBT back to creator address needs to be addressed. This is WIP. ## 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. From 6a042a58e7f2e258ab4902005335970c08b125fc Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 11 Oct 2024 12:07:36 +0300 Subject: [PATCH 37/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 09557ee8e..4e4b13765 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -21,7 +21,7 @@ This defines an interface extending [ARC-3](./arc-0003.md) & [ARC-69](./arc-0069 > 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 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. +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 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. From 8b9df734f9148e5a097476b4b37a59f74db74d9e Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 11 Oct 2024 12:08:11 +0300 Subject: [PATCH 38/42] Update content --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 4e4b13765..40e0c690d 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -23,7 +23,7 @@ This defines an interface extending [ARC-3](./arc-0003.md) & [ARC-69](./arc-0069 ## 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 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. +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. From 2160bc05a6f73f9b066e804d691b35317ae710f6 Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 11 Oct 2024 14:37:44 +0300 Subject: [PATCH 39/42] 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. From 9259b9d40fcd9267ef081d445e20e10522410a2c Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 11 Oct 2024 16:18:38 +0300 Subject: [PATCH 40/42] Fix Typo ARC19 --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 771855fac..0c9c1585f 100644 --- a/ARCs/arc-0071.md +++ b/ARCs/arc-0071.md @@ -62,7 +62,7 @@ The Issued state is the starting state of the ASA.The claimed state is when SBT - 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 Reserve parameter **MUST** be set to either ARC-19 metadata or SBT Issuer's address. #### Revoked SoulBound ASA From 3904c2abe76ad25a92d6747871627324c7164676 Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 11 Oct 2024 18:10:22 +0300 Subject: [PATCH 41/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index 0c9c1585f..a85f21605 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), Rob Moore (@robdmoore), Tasos Bitsios (@tasosbit) +author: Stéphane BARROSO (@SudoWeezy), MG (@emg110), Rob Moore (@robdmoore) discussions-to: https://github.com/algorandfoundation/ARCs/issues/179 status: Draft type: Standards Track From b80e3ecc56881d3b7dc274beeecc4609d89ce76d Mon Sep 17 00:00:00 2001 From: MG Date: Fri, 11 Oct 2024 18:19:23 +0300 Subject: [PATCH 42/42] Update --- ARCs/arc-0071.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/ARCs/arc-0071.md b/ARCs/arc-0071.md index a85f21605..6a828b7ca 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), Rob Moore (@robdmoore) +author: Stéphane BARROSO (@SudoWeezy), MG (@emg110) discussions-to: https://github.com/algorandfoundation/ARCs/issues/179 status: Draft type: Standards Track