Non-Transferable ASA | Algorand Developer Portal

Non-Transferable ASA

Abstract

The goal is to make it simpler for block explorers, wallets, exchanges, marketplaces, and more generally, client software to identify & interact with a Non-transferable ASA (NTA).

This defines an interface extending ARC-3 & ARC-69 non fungible ASA to create Non-transferable 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 to create an updatable Non-transferable ASA.

Motivation

The idea of Non-transferable ASAs has garnered significant attention, inspired by the concept of Soul Bound Tokens. However, without a clear definition, Non-transferable ASAs cannot achieve interoperability. Developing universal services targeting Non-transferable ASAs remains challenging without a minimal consensus on their implementation and lifecycle management.

This ARC envisions Non-transferable ASAs as specialized assets, akin to Soul Bound ASAs, that will serve as identities, credentials, credit records, loan histories, memberships, and much more. To provide the necessary flexibility in these use cases, Non-transferable ASAs must feature an application-specific burn method and a distinct way to differentiate themselves from regular ASAs.

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 NTA actor roles: Issuer and Holder.
There are 3 NTA ASA states, Issued, Held, and Revoked.
Claimed and Revoked NTAs 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 Non-transferable ASA and close it back to creator. As a summary ARC-71 NTA 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 NTA is sent to destination wallet (claimed) and the Revoked state is the state where the NTA ASA is revoked by issuer after issuance and therefore no longer valid for any use case except for provenance and historical data reference.

NTAs with Revoked state are no longer valid and cannot be used as a proof of any credentials.
Manager address is able to revoke the NTA ASA by setting the Manager address to ZeroAddress.
Issuer MUST be an Algorand Smart Contract Account.

Issued Non-transferable 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 Issuer Address.
The Manager parameter MAY be set to any address but is RECOMMENDED to be the Issuer.
The Reserve parameter MUST be set to either ARC-19 metadata or NTA Issuer’s address.

Held (claimed) Non-transferable 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 holder (claimer) account address.
The Manager parameter MAY be set to any address but is RECOMMENDED to be the Issuer.
The Reserve parameter MUST be set to either ARC-19 metadata or NTA Issuer’s address.

Revoked Non-transferable ASA

The Manager parameter MUST be set to ZeroAddress.

Rationale

Non-transferable ASA NFT

Non-transferable ASA serves as a specialized subset of the existing ASAs. The advantage of such design is seamless compatibility of Non-transferable ASA with existing NFT services. Service providers can treat Non-transferable 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 Non-Transferable ASAs (NTAs):

The concept of Non-Transferable ASAs (NTAs) is rooted in permanence and attachment to the holder. Introducing a “burn” mechanism for NTAs 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 Non-Transferable philosophy and established W3C standards, particularly in the context of Verifiable Credentials (VCs). Revocation allows for NTAs 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 NTA 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 NTA 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: NTAs 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 token does not leave the wallet, making it clear that the NTA 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 NTA by removing the token from the holder’s possession entirely, which defeats the core idea behind NTAs.

In summary, revocation offers a more interoperable alternative to burning for NTAs. It ensures that NTAs remain Non-Transferable 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 NTA ASA, only if the manager address & freeze address are still available.

Security Considerations

Claiming/Receiving a NTA 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.