Skip to content

Commit

Permalink
Update by Stephane
Browse files Browse the repository at this point in the history
  • Loading branch information
@emg110
emg110 committed Oct 11, 2024
1 parent 8b9df73 commit 2160bc0
Showing 1 changed file with 20 additions and 19 deletions.
39 changes: 20 additions & 19 deletions ARCs/arc-0071.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -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
Expand All @@ -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 <a href="https://www.ietf.org/rfc/rfc2119.txt">RFC-2119</a>.

- There are 2 SBT actor roles: **Issuer** and **Holder**.
- There are 3 SBT ASA states, **Issued** , **Held** and **Revoked**.
- 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
Expand All @@ -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`.
Expand All @@ -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.

Check failure on line 65 in ARCs/arc-0071.md

View workflow job for this annotation

GitHub Actions / ARC Walidator

proposals must be referenced with the form `ARC-N` (not `ARCN` or `ARC N`) 

error[markdown-re-arc-dash]: proposals must be referenced with the form `ARC-N` (not `ARCN` or `ARC N`)
  --> ARCs/arc-0071.md
   |
65 | - The Reserve parameter **MUST** be set to either ARC19 metadata or SBT Issuer's address.
   |
   = info: the pattern in question: `(?i)ARC[\s]*[0-9]+`

#### 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.
Expand All @@ -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 <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.

Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.

0 comments on commit 2160bc0

Please sign in to comment.