@goplausible/algorand-mcp 3.0.7

package/dist/resources/knowledge/taxonomy/arcs:specs:arc-0062.md

@@ -0,0 +1,339 @@
+---
+arc: 62
+title: ASA Circulating Supply
+description: Getter method for ASA circulating supply
+author: Cosimo Bassi (@cusma)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/302
+status: Final
+type: Standards Track
+category: Interface
+sub-category: Asa
+created: 2024-06-12
+requires: 2, 4, 22
+---
+
+## Abstract
+
+This ARC introduces a standard for the definition of circulating supply for Algorand
+Standard Assets (ASA) and its client-side retrieval. A reference implementation is
+suggested.
+
+## Motivation
+
+Algorand Standard Asset (ASA) `total` supply is _defined_ upon ASA creation.
+
+Creating an ASA on the ledger _does not_ imply its `total` supply is immediately
+“minted” or “circulating”. In fact, the semantic of token “minting” on Algorand is
+slightly different from other blockchains: it is not coincident with the token units
+creation on the ledger.
+
+The Reserve Address, one of the 4 addresses of ASA Role-Based-Access-Control (RBAC),
+is conventionally used to identify the portion of `total` supply not yet in circulation.
+The Reserve Address has no “privilege” over the token: it is just a “logical” label
+used (client-side) to classify an existing amount of ASA as “not in circulation”.
+
+According to this convention, “minting” an amount of ASA units is equivalent to
+_moving that amount out of the Reserve Address_.
+
+> ASA may have the Reserve Address assigned to a Smart Contract to enforce specific
+> “minting” policies, if needed.
+
+This convention led to a simple and unsophisticated semantic of ASA circulating
+supply, widely adopted by clients (wallets, explorers, etc.) to provide standard
+information:
+
+```text
+circulating_supply = total - reserve_balance
+```
+
+Where `reserve_balance` is the ASA balance hold by the Reserve Address.
+
+However, the simplicity of such convention, who fostered adoption across the Algorand
+ecosystem, poses some limitations. Complex and sophisticated use-cases of ASA, such
+as regulated stable-coins and tokenized securities among others, require more
+detailed and expressive definitions of circulating supply.
+
+As an example, an ASA could have “burned”, “locked” or “pre-minted” amounts of token,
+not held in the Reserve Address, which _should not_ be considered as “circulating”
+supply. This is not possible with the basic ASA protocol convention.
+
+This ARC proposes a standard ABI _read-only_ method (getter) to provide the circulating
+supply of an ASA.
+
+## Specification
+
+The keywords "**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://datatracker.ietf.org/doc/html/rfc2119">RFC 2119</a>.
+
+> Notes like this are non-normative.
+
+### ABI Method
+
+A compliant ASA, whose circulating supply definition conforms to this ARC, **MUST**
+implement the following method on an Application (referred as _Circulating Supply
+App_ in this specification):
+
+```json
+{
+  "name": "arc62_get_circulating_supply",
+  "readonly": true,
+  "args": [
+    {
+      "type": "uint64",
+      "name": "asset_id",
+      "desc": "ASA ID of the circulating supply"
+    }
+  ],
+  "returns": {
+    "type": "uint64",
+    "desc": "ASA circulating supply"
+  },
+  "desc": "Get ASA circulating supply"
+}
+```
+
+The `arc62_get_circulating_supply` **MUST** be a _read-only_ ([ARC-22](./arc-0022.md))
+method (getter).
+
+### Usage
+
+Getter calls **SHOULD** be _simulated_.
+
+Any external resources used by the implementation **SHOULD** be discovered and
+auto-populated by the simulated getter call.
+
+#### Example 1
+
+> Let the ASA have `total` supply and a Reserve Address (i.e. not set to `ZeroAddress`).
+>
+> Let the Reserve Address be assigned to an account different from the Circulating
+> Supply App Account.
+>
+> Let `burned` be an external Burned Address dedicated to ASA burned supply.
+>
+> Let `locked` be an external Locked Address dedicated to ASA locked supply.
+>
+> The ASA issuer defines the _circulating supply_ as:
+>
+> ```text
+> circulating_supply = total - reserve_balance - burned_balance - locked_balance
+> ```
+>
+> In this case the simulated read-only method call would auto-populate 1 external
+> reference for the ASA and 3 external reference accounts (Reserve, Burned and Locked).
+
+#### Example 2
+
+> Let the ASA have `total` supply and _no_ Reserve Address (i.e. set to `ZeroAddress`).
+>
+> Let `non_circulating_amount` be a UInt64 Global Var defined by the implementation
+> of the Circulating Supply App.
+>
+> The ASA issuer defines the _circulating supply_ as:
+>
+> ```text
+> circulating_supply = total - non_circulating_amount
+> ```
+>
+> In this case the simulated read-only method call would auto-populate just 1 external
+> reference for the ASA.
+
+### Circulating Supply Application discovery
+
+> Given an ASA ID, clients (wallet, explorer, etc.) need to discover the related
+> Circulating Supply App.
+
+An ASA conforming to this ARC **MUST** specify the Circulating Supply App ID.
+
+> To avoid ecosystem fragmentation this ARC does not propose any new method to specify
+> the metadata of an ASA. Instead, it only extends already existing standards.
+
+If the ASA also conforms to any ARC that supports additional `properties` ([ARC-3](./arc-0003.md),
+[ARC-19](./arc-0019.md), [ARC-69](./arc-0069.md)),
+then it **MUST** include a `arc-62` key and set the corresponding value to a map,
+including the ID of the Circulating Supply App as a value for the key `application-id`.
+
+#### Example
+
+```json
+{
+  //...
+  "properties": {
+    //...
+    "arc-62": {
+      "application-id": 123
+    }
+  }
+  //...
+}
+```
+
+## Rationale
+
+The definition of _circulating supply_ for sophisticated use-cases is usually ASA-specific.
+It could involve, for example, complex math or external accounts’ balances, variables
+stored in boxes or in global state, etc..
+
+For this reason, the proposed method’s signature does not require any reference
+to external resources, a part form the `asset_id` of the ASA for which the circulating
+supply is defined.
+
+Eventual external resources can be discovered and auto-populated directly by the
+simulated method call.
+
+The rational of this design choice is avoiding fragmentation and integration overhead
+for clients (wallets, explorers, etc.).
+
+Clients just need to know:
+
+1. The ASA ID;
+1. The Circulating Supply App ID implementing the `arc62_get_circulating_supply`
+method for that ASA.
+
+## Backwards Compatibility
+
+Existing ASA willing to conform to this ARC **MUST** specify the Circulating Supply
+App ID as [ARC-2](./arc-0002.md) `AssetConfig` transaction note field, as follows:
+
+- The `<arc-number>` **MUST** be equal to `62`;
+- The **RECOMMENDED** `<data-format>` are <a href="https://msgpack.org/">MsgPack</a>
+(`m`) or <a href="https://www.json.org/json-en.html">JSON</a> (`j`);
+- The `<data>` **MUST** specify `application-id` equal to the Circulating Supply
+App ID.
+
+> **WARNING**: To preserve the existing ASA RBAC (e.g. Manager Address, Freeze Address,
+> etc.) it is necessary to **include all the existing role addresses** in the `AssetConfig`.
+> Not doing so would irreversibly disable the RBAC roles!
+
+### Example - JSON without version
+
+```text
+arc62:j{"application-id":123}
+```
+
+## Reference Implementation
+
+> This section is non-normative.
+
+This section suggests a reference implementation of the Circulating Supply App.
+
+An Algorand-Python example is available [here](../assets/arc-0062).
+
+### Recommendations
+
+An ASA using the reference implementation **SHOULD NOT** assign the Reserve Address
+to the Circulating Supply App Account.
+
+A reference implementation **SHOULD** target a version of the AVM that supports
+foreign resources pooling (version 9 or greater).
+
+A reference implementation **SHOULD** use 3 external addresses, in addition to the
+Reserve Address, to define the not circulating supply.
+
+The **RECOMMENDED** labels for not-circulating balances are: `burned`, `locked`
+and `generic`.
+
+> To change the labels of not circulating addresses is sufficient to rename the
+> following constants just in `smart_contracts/circulating_supply/config.py`:
+> ```python
+> NOT_CIRCULATING_LABEL_1: Final[str] = "burned"
+> NOT_CIRCULATING_LABEL_2: Final[str] = "locked"
+> NOT_CIRCULATING_LABEL_3: Final[str] = "generic"
+> ```
+
+### State Schema
+
+A reference implementation **SHOULD** allocate, at least, the following Global State
+variables:
+
+- `asset_id` as UInt64, initialized to `0` and set **only once** by the ASA Manager
+Address;
+- Not circulating address 1 (`burned`) as Bytes, initialized to the Global `Zero Address`
+ and set by the ASA Manager Address;
+- Not circulating address 2 (`locked`) as Bytes, initialized to the Global `Zero Address`
+and set by the ASA Manager Address;
+- Not circulating address 3 (`generic`) as Bytes, initialized to the Global `Zero Address`
+and set by the ASA Manager Address.
+
+A reference implementation **SHOULD** enforce that, upon setting `burned`, `locked`
+and `generic` addresses, the latter already opted-in the `asset_id`.
+
+```json
+"state": {
+    "global": {
+        "num_byte_slices": 3,
+        "num_uints": 1
+    },
+    "local": {
+        "num_byte_slices": 0,
+        "num_uints": 0
+    }
+},
+"schema": {
+    "global": {
+        "declared": {
+            "asset_id": {
+                "type": "uint64",
+                "key": "asset_id"
+            },
+            "not_circulating_label_1": {
+                "type": "bytes",
+                "key": "burned"
+            },
+            "not_circulating_label_2": {
+                "type": "bytes",
+                "key": "locked"
+            },
+            "not_circulating_label_3": {
+                "type": "bytes",
+                "key": "generic"
+            }
+        },
+        "reserved": {}
+    },
+    "local": {
+        "declared": {},
+        "reserved": {}
+    }
+},
+```
+
+### Circulating Supply Getter
+
+A reference implementation **SHOULD** enforce that the `asset_id` Global Variable
+is equal to the `asset_id` argument of the `arc62_get_circulating_supply` getter
+method.
+
+> Alternatively the reference implementation could ignore the `asset_id` argument
+> and use directly the `asset_id` Global Variable.
+
+A reference implementation **SHOULD** return the ASA _circulating supply_ as:
+
+```text
+circulating_supply = total - reserve_balance - burned_balance - locked_balance - generic_balance
+```
+
+Where:
+
+- `total` is the total supply of the ASA (`asset_id`);
+- `reserve_balance` is the ASA balance hold by the Reserve Address or `0` if the
+address is set to the Global `ZeroAddress` or not opted-in `asset_id`;
+- `burned_balance` is the ASA balance hold by the Burned Address or `0` if the address
+is set to the Global `ZeroAddress` or is not opted-in `asset_id`;
+- `locked_balance` is the ASA balance hold by the Locked Address or `0` if the address
+is set to the Global `ZeroAddress` or not opted-in `asset_id`;
+- `generic_balance` is the ASA balance hold by a Generic Address or `0` if the address
+is set to the Global `ZeroAddress` or not opted-in `asset_id`.
+
+## Security Considerations
+
+Permissions over the Circulating Supply App setting and update **SHOULD** be granted
+to the ASA Manager Address.
+
+> The ASA trust-model (i.e. who sets the Reserve Address) is extended to the generalized
+> ASA circulating supply definition.
+
+## Copyright
+
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.

package/dist/resources/knowledge/taxonomy/arcs:specs:arc-0065.md

@@ -0,0 +1,169 @@
+---
+arc: 65
+title: AVM Run Time Errors In Program
+description: Informative AVM run time errors based on program bytecode
+author: Cosimo Bassi (@cusma), Tasos Bitsios (@tasosbit), Steve Ferrigno (@nullun)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/315
+status: Final
+type: Standards Track
+category: ARC
+created: 2024-10-09
+---
+
+## Abstract
+
+This document introduces a convention for rising informative run time errors on
+the Algorand Virtual Machine (AVM) directly from the program bytecode.
+
+## Motivation
+
+The AVM does not offer native opcodes to catch and raise run time errors.
+
+The lack of native error handling semantics could lead to fragmentation of tooling
+and frictions for AVM clients, who are unable to retrieve informative and useful
+hints about the occurred run time failures.
+
+This ARC formalizes a convention to rise AVM run time errors based just on the program
+bytecode.
+
+## Specification
+
+The keywords "**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://datatracker.ietf.org/doc/html/rfc2119">RFC 2119</a>.
+
+> Notes like this are non-normative.
+
+### Error format
+
+> The AVM programs bytecode have limited sized. In this convention, the errors are
+> part of the bytecode, therefore it is good to mind errors' formatting and sizing.
+
+> Errors consist of a _code_ and an optional _short message_.
+
+Errors **MUST** be prefixed either with:
+
+- `ERR:` for custom errors;
+- `AER:` reserved for future ARC standard errors.
+
+Errors **MUST** use `:` as domain separator.
+
+It is **RECOMMENDED** to use `UTF-8` for the error bytes string encoding.
+
+It is **RECOMMENDED** to use _short_ error messages.
+
+It is **RECOMMENDED** to use <a href="https://en.wikipedia.org/wiki/Camel_case/">camel case</a>
+for alphanumeric error codes.
+
+It is **RECOMMENDED** to avoid error byte strings of _exactly_ 8 or 32 bytes.
+
+### In Program Errors
+
+When a program wants to emit informative run time errors, directly from the bytecode,
+it **MUST**:
+
+1. Push to the stack the bytes string containing the error;
+1. Execute the `log` opcode to use the bytes from the top of the stack;
+1. Execute the `err` opcode to immediately terminate the program.
+
+Upon a program run time failure, the Algod API response contains both the failed
+_program counter_ (`pc`) and the `logs` array with the _errors_.
+
+The program **MAY** return multiple errors in the same failed execution.
+
+The errors **MUST** be retrieved by:
+
+1. Decoding the `base64` elements of the `logs` array;
+1. Validating the decoded elements against the error regexp.
+
+### Error examples
+
+> Error conforming this specification are always prefixed with `ERR:`.
+
+Error with a _numeric code_: `ERR:042`.
+
+Error with an _alphanumeric code_: `ERR:BadRequest`.
+
+Error with a _numeric code_ and _short message_: `ERR:042:AFunnyError`.
+
+### Program example
+
+The following program example raises the error `ERR:001:Invalid Method` for any
+application call to methods different from `m1()void`.
+
+```teal
+#pragma version 10
+
+txn ApplicationID
+bz end
+
+method "m1()void"
+txn ApplicationArgs 0
+match method1
+byte "ERR:001:Invalid Method"
+log
+err
+
+method1:
+b end
+
+end:
+int 1
+```
+
+Full Algod API response of a failed execution:
+
+```json
+{
+    "data": {
+        "app-index":1004,
+        "eval-states": [
+            {
+                "logs": ["RVJSOjAwMTpJbnZhbGlkIE1ldGhvZA=="]
+            }
+        ],
+        "group-index":0,
+        "pc":41
+    },
+    "message":"TransactionPool.Remember: transaction ESI4GHAZY46MCUCLPBSB5HBRZPGO6V7DDUM5XKMNVPIRJK6DDAGQ: logic eval error: err opcode executed. Details: app=1004, pc=41"
+}
+```
+
+The `logs` array contains the `base64` encoded error `ERR:001:Invalid Method`.
+
+The `logs` array **MAY** contain elements that are not errors (as specified by the
+regexp).
+
+It is **NOT RECOMMENDED** to use the `message` field to retrieve errors.
+
+### AVM Compilers
+
+AVM compilers (and related tools) **SHOULD** provide two error compiling options:
+
+1. The one specified in this ARC as **default**;
+1. The one specified in [ARC-56](./arc-0056.md) as fallback, if compiled bytecode
+size exceeds the AVM limits.
+
+> Compilers **MAY** optimize for program bytecode size by storing the error prefixes
+in the `bytecblock` and concatenating the error message at the cost of some extra
+opcodes.
+
+## Rationale
+
+This convention for AVM run time errors presents the following PROS and CONS.
+
+**PROS:**
+- No additional artifacts required to return informative run time errors;
+- Errors are directly returned in the Algod API response, which can be filtered
+with the specified error regexp.
+
+**CONS:**
+- Errors consume program bytecode size.
+
+## Security Considerations
+
+> Not applicable.
+
+## Copyright
+
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.

package/dist/resources/knowledge/taxonomy/arcs:specs:arc-0069.md

@@ -0,0 +1,183 @@
+---
+arc: 69
+title: ASA Parameters Conventions, Digital Media
+description: Alternatives conventions for ASAs containing digital media.
+author: Chris Antaki (@ChrisAntaki), AlgoKittens (@algokittens), TommyAlex79 (@TommyAlex79)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/64
+status: Final
+type: Standards Track
+category: ARC
+sub-category: Asa
+created: 2021-08-07
+---
+
+# Community Algorand Standard Asset Parameters Conventions for Digital Media Tokens
+
+We introduce community conventions for the parameters of Algorand Standard Assets (ASAs) containing digital media.
+
+## Abstract
+
+The goal of these conventions is to make it simpler to display the properties of a given ASA. This ARC differs from [ARC-3](./arc-0003.md) by focusing on optimization for fetching of digital media, as well as the use of onchain metadata. Furthermore, since asset configuration transactions are used to store the metadata, this ARC can be applied to existing ASAs.
+
+While mutability helps with backwards compatibility and other use cases, like leveling up an RPG character, some use cases call for immutability. In these cases, the ASA manager MAY remove the manager address, after which point the Algorand network won't allow anyone to send asset configuration transactions for the ASA. This effectively makes the latest valid [ARC-69](./arc-0069.md) metadata immutable.
+
+
+## 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>.
+
+An ARC-69 ASA has an associated JSON Metadata file, formatted as specified below, that is stored on-chain in the note field of the most recent asset configuration transaction (that contains a note field with a valid ARC-69 JSON metadata).
+
+### ASA Parameters Conventions
+
+The ASA parameters should follow the following conventions:
+
+* *Unit Name* (`un`): no restriction.
+* *Asset Name* (`an`): no restriction.
+* *Asset URL* (`au`): a URI pointing to digital media file. This URI:
+    * **SHOULD** be persistent.
+    * **SHOULD** link to a file small enough to fetch quickly in a gallery view.
+    * **MUST** follow <a href="https://www.ietf.org/rfc/rfc3986.txt">RFC-3986</a> and **MUST NOT** contain any whitespace character.
+    * **SHOULD** specify media type with `#` fragment identifier at end of URL. This format **MUST** follow: `#i` for images, `#v` for videos, `#a` for audio, `#p` for PDF, or `#h` for HTML/interactive digital media.  If unspecified, assume Image.
+    * **SHOULD** use one of the following URI schemes (for compatibility and security): *https* and *ipfs*:
+        * When the file is stored on IPFS, the `ipfs://...` URI **SHOULD** be used. IPFS Gateway URI (such as `https://ipfs.io/ipfs/...`) **SHOULD NOT** be used.
+    * **SHOULD NOT** use the following URI scheme: *http* (due to security concerns).
+* *Asset Metadata Hash* (`am`): the SHA-256 digest of the full resolution media file as a 32-byte string (as defined in <a href="https://doi.org/10.6028/NIST.FIPS.180-4">NIST FIPS 180-4</a> )
+    * **OPTIONAL**
+* *Freeze Address* (`f`):
+    * **SHOULD** be empty, unless needed for royalties or other use cases
+* *Clawback Address* (`c`):
+    * **SHOULD** be empty, unless needed for royalties or other use cases
+
+
+There are no requirements regarding the manager account of the ASA, or the reserve account. However, if immutability is required the manager address **MUST** be removed.
+
+Furthermore, the manager address, if present, **SHOULD** be under the control of the ASA creator, as the manager address can unilaterally change the metadata. Some advanced use cases **MAY** use a logicsig as ASA manager, if the logicsig only allows to set the note fields by the ASA creator.
+
+### JSON Metadata File Schema
+
+```json
+{
+    "title": "Token Metadata",
+    "type": "object",
+    "properties": {
+        "standard": {
+            "type": "string",
+            "value": "arc69",
+            "description": "(Required) Describes the standard used."
+        },
+        "description": {
+            "type": "string",
+            "description": "Describes the asset to which this token represents."
+        },
+        "external_url": {
+            "type": "string",
+            "description": "A URI pointing to an external website. Borrowed from Open Sea's metadata format (https://docs.opensea.io/docs/metadata-standards)."
+        },
+        "media_url": {
+            "type": "string",
+            "description": "A URI pointing to a high resolution version of the asset's media."
+        },
+        "properties": {
+            "type": "object",
+            "description": "Properties following the EIP-1155 'simple properties' format. (https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1155.md#erc-1155-metadata-uri-json-schema)"
+        },
+        "mime_type": {
+            "type": "string",
+            "description": "Describes the MIME type of the ASA's URL (`au` field)."
+        },
+        "attributes": {
+            "type": "array",
+            "description": "(Deprecated. New NFTs should define attributes with the simple `properties` object. Marketplaces should support both the `properties` object and the `attributes` array). The `attributes` array follows Open Sea's format: https://docs.opensea.io/docs/metadata-standards#attributes"
+        }
+    },
+    "required":[
+        "standard"
+    ]
+}
+```
+The `standard` field is **REQUIRED** and **MUST** equal `arc69`. All other fields are **OPTIONAL**. If provided, the other fields **MUST** match the description in the JSON schema.
+
+The URI field (`external_url`) is defined similarly to the Asset URL parameter `au`.
+However, contrary to the Asset URL, the `external_url` does not need to link to the digital media file.
+
+#### MIME Type
+
+In addition to specifying a data type in the ASA's URL (`au` field) with a URI fragment (ex: `#v` for video), the JSON Metadata schema also allows indication of the URL's MIME type (ex: `video/mp4`) via the `mime_type` field.
+
+#### Examples
+
+##### Basic Example
+
+An example of an ARC-69 JSON Metadata file for a song follows. The properties array proposes some **SUGGESTED** formatting for token-specific display properties and metadata.
+
+```json
+{
+  "standard": "arc69",
+  "description": "arc69 theme song",
+  "external_url": "https://www.youtube.com/watch?v=dQw4w9WgXcQ",
+  "mime_type": "video/mp4",
+  "properties": {
+    "Bass":"Groovy",
+    "Vibes":"Funky",
+    "Overall":"Good stuff"
+  }
+}
+```
+
+An example of possible ASA parameters would be:
+
+* *Asset Name*: `ARC-69 theme song` for example.
+* *Unit Name*: `69TS` for example.
+* *Asset URL*: `ipfs://QmWS1VAdMD353A6SDk9wNyvkT14kyCiZrNDYAad4w1tKqT#v`
+* *Metadata Hash*: the 32 bytes of the SHA-256 digest of the high resolution media file.
+* *Total Number of Units*: 1
+* *Number of Digits after the Decimal Point*: 0
+
+#### Mutability
+
+##### Rendering
+
+Clients **SHOULD** render an ASA's latest ARC-69 metadata. Clients **MAY** render an ASA's previous ARC-69 metadata for changelogs or other historical features.
+
+##### Updating ARC-69 metadata
+
+If an ASA has a manager address, then the manager **MAY** update an ASA's ARC-69 metadata. To do so, the manager sends a new `acfg` transaction with the entire metadata represented as JSON in the transaction's `note` field.
+
+##### Making ARC-69 metadata immutable
+
+Managers MAY make an ASA's ARC-69 immutable. To do so, they MUST remove the ASA's manager address with an `acfg` transaction.
+
+##### ARC-69 attribute deprecation
+
+The initial version of ARC-69 followed the Open Sea attributes format https://docs.opensea.io/docs/metadata-standards#attributes. As illustrated below:
+```
+"attributes": {
+"type": "array",
+"description": "Attributes following Open Sea's attributes format (https://docs.opensea.io/docs/metadata-standards#attributes)."
+}
+```
+This format is now deprecated. New NFTs **SHOULD** use the simple `properties` format, since it significantly reduces the metadata size.
+
+To be fully compliant with the ARC-69 standard, both the `properties` object and the `attributes` array **SHOULD** be supported.
+
+## Rationale
+
+These conventions take inspiration from <a href="https://docs.opensea.io/docs/metadata-standards">Open Sea's metadata standards</a> and <a href="https://github.com/ethereum/EIPs/blob/master/EIPS/eip-1155.md#erc-1155-metadata-uri-json-schema">EIP-1155</a>
+
+to facilitate interoperobility.
+
+The main differences are highlighted below:
+
+* Asset Name, Unit Name, and URL are specified in the ASA parameters. This allows applications to efficiently display meaningful information, even if they aren't aware of ARC-69 metadata.
+* MIME types help clients more effectively fetch and render media.
+* All asset metadata is stored onchain.
+* Metadata can be either mutable or immutable.
+
+## Security Considerations
+
+None.
+
+## Copyright
+
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.