@goplausible/algorand-mcp 3.0.7

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

@@ -0,0 +1,47 @@
+---
+arc: 11
+title: Algorand Wallet Reach Browser Spec
+description: Convention for DApps to discover Algorand wallets in browser
+author: DanBurton (@DanBurton)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/52
+status: Deprecated
+type: Standards Track
+category: Interface
+created: 2021-08-09
+---
+
+# Algorand Wallet Reach Browser Spec
+
+## Abstract
+
+A common convention for DApps to discover Algorand wallets in browser code: `window.algorand`.
+A property `algorand` attached to the `window` browser object, with all the features defined in [ARC-0010](./arc-0010.md#specification).
+
+## Specification
+
+```ts
+interface WindowAlgorand {
+  enable: EnableFunction;
+  enableNetwork?: EnableNetworkFunction;
+  enableAccounts?: EnableAccountsFunction;
+  signAndPostTxns: SignAndPostTxnsFunction;
+  getAlgodv2Client: GetAlgodv2ClientFunction;
+  getIndexerClient: GetIndexerClientFunction;
+  signTxns?: SignTxnsFunction;
+  postTxns?: SignTxnsFunction;
+}
+```
+
+With the specifications and semantics for each function as stated in [ARC-0010](./arc-0010.md#specification).
+
+## Rationale
+
+DApps should be unopinionated about which wallet they are used with. End users should be able to inject their wallet of choice into the DApp. Therefore, in browser contexts, we reserve `window.algorand` for this purpose.
+
+## Security Considerations
+
+None.
+
+## 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-0012.md

@@ -0,0 +1,158 @@
+---
+arc: 12
+title: Claimable ASA from vault application
+description: A smart signature contract account that can receive & disburse claimable Algorand Smart Assets (ASA) to an intended recipient account.
+author: Brian Whippo (@silentrhetoric), Joe Polny (@joe-p)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/131
+status: Withdrawn
+type: Standards Track
+category: ARC
+created: 2022-09-05
+withdrawal-reason: Not used, will be replaced by ARC-59
+---
+
+# Claimable Algorand Standard Assets (ASAs) from vault application
+
+## Abstract
+
+The goal of this standard is to establish a standard in the Algorand ecosytem by which ASAs can be sent to an intended receiver even if their account is not opted in to the ASA.
+
+A on-chain application, called a vault, will be used to custody assets on behalf of a given user, with only that user being able to withdraw assets. A master application will use box storage to keep track of the vault for any given Algorand account.
+
+If integrated into ecosystem technologies including wallets, epxlorers, and dApps, this standard can provide enhanced capabilities around ASAs which are otherwise strictly bound at the protocol level to require opting in to be received. This also enables the ability to "burn" ASAs by sending them to the vault associated with the global Zero Address.
+
+## Motivation
+
+Algorand requires accounts to opt in to receive any ASA, a fact which simultaneously:
+
+1. Grants account holders fine-grained control over their holdings by allowing them to select which assets to allow and preventing receipt of unwanted tokens.
+2. Frustrates users and developers when accounting for this requirement especially since other blockchains do not have this requirement.
+
+This ARC lays out a new way to navigate the ASA opt in requirement.
+
+### Contemplated Use Cases
+
+The following use cases help explain how this capability can enhance the possibilities within the Algorand ecosystem.
+
+#### Airdrops
+
+An ASA creator who wants to send their asset to a set of accounts faces the challenge of needing their intended receivers to opt in to the ASA ahead of time, which requires non-trivial communication efforts and precludes the possibility of completing the airdrop as a surprise.  This claimable ASA standard creates the ability to send an airdrop out to individual addresses so that the receivers can opt in and claim the asset at their convenience--or not, if they so choose.
+
+#### Reducing New User On-boarding Friction
+
+An application operator who wants to on-board users to their game or business may want to reduce the friction of getting people started by decoupling their application on-boarding process from the process of funding a non-custodial Algorand wallet, if users are wholly new to the Algorand ecosystem.  As long as the receiver's address is known, an ASA can be sent to them ahead of them having ALGOs in their wallet to cover the minimum balance requirement and opt in to the asset.
+
+#### Token Burning
+
+Similarly to any regular account, the global Zero Address also has a corresponding vault to which one can send a quantity of any ASA to effectively "burn" it, rendering it lost forever.  No one controls the Zero Address, so while it cannot opt into any ASA to receive it directly, it also cannot make any claims from its corresponding vault, which thus functions as an UN-claimable ASAs purgatory account.  By utilizing this approach, anyone can verifiably and irreversibly take a quantity of any ASA out of circulation forever.
+
+## 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>.
+
+
+> Comments like this are non-normative.
+
+### Definitions
+
+- **Claimable ASA**: An Algorand Standard Asset (ASA) which has been transferred to a vault following the standard set forth in this proposal such that only the intended receiver account can claim it at their convenience.
+- **Vaultt**: An Algorand application used to hold claimable ASAs for a given account.
+- **Master**: An Algorand application used to keep track of all of the vaults created for Algorand accounts.
+- **dApp**: A decentralized application frontend, interpreted here to mean an off-chain frontend (a webapp, native app, etc.) that interacts with applications on the blockchain.
+- **Explorer**: An off-chain application that allows browsing the blockchain, showing details of transactions.
+- **Wallet**: An off-chain application that stores secret keys for on-chain accounts and can display and sign transactions for these accounts.
+- **Mainnet ID**: The ID for the application that should be called upon claiming an asset on mainnet
+- **Testnet ID**: The ID for the application that should be called upoin claiming an asset on testnet
+- **Minimum Balance Requirement (MBR)**: The minimum amount of Algos which must be held by an account on the ledger, which is currently 0.1A + 0.1A per ASA opted into.
+
+### TEAL Smart Contracts
+
+There are two smart contracts being utilized: The [vault](../assets/arc-0012/vault.teal) and the [master](../assets/arc-0012/master.teal).
+
+#### Vault
+
+##### Storage
+
+| Type   | Key        | Value          | Description                                           |
+| ------ | ---------- | -------------- | ----------------------------------------------------- |
+| Global | “creator”  | Account        | The account that funded the creation of the vault     |
+| Global | “master”   | Application ID | The application ID that created the vault             |
+| Global | “receiver” | Account        | The account that can claim/reject ASAs from the vault |
+| Box    | Asset ID   | Account        | The account that funded the MBR for the given ASA     |
+
+##### Methods
+
+###### Opt-In
+* Opts vault into ASA
+* Creates box: ASA -> “funder”
+  * “funder” being the account that initiates the opt-in
+  * “funder” is the one covering the ASA MBR
+
+###### Claim
+* Transfers ASA from vault to “receiver”
+* Deletes box: ASA -> “funder”
+* Returns ASA and box MBR to “funder”
+
+###### Reject
+* Sends ASA to ASA creator
+* Refunds rejector all fees incurred (thus rejecting is free)
+* Deletes box: ASA -> “funder”
+* Remaining balance sent to fee sink
+
+#### Master
+
+##### Storage
+
+| Type | Key     | Value          | Description                     |
+| ---- | ------- | -------------- | ------------------------------- |
+| Box  | Account | Application ID | The vault for the given account |
+
+##### Methods
+
+###### Create Vault
+* Creates a vault for a given account (“receiver”)
+* Creates box: “receiver” -> vault ID
+* App/box MBR funded by vault creator
+
+###### Delete Vault
+* Deletes vault app
+* Deletes box: “receiver” -> vault ID
+* App.box MBR returned to vault creator
+
+###### Verify Axfer
+* Verifies asset is going to correct vault for “receiver”
+
+###### getVaultID
+* Returns vault ID for “receiver”
+* Fails if “receiver” does not have vault
+
+###### getVaultAddr
+* Returns vault address for “receiver”
+* Fails if “receiver” does not have vault
+
+###### hasVault
+* Determines if “receiver” has a vault
+
+## Rationale
+
+This design was created to offer a standard mechanism by which wallets, explorers, and dapps could enable users to send, receive, and find claimable ASAs without requiring any changes to the core protocol.
+
+## Backwards Compatibility
+
+This ARC makes no changes to the consensus protocol and creates no backwards compatibility issues.
+
+## Reference Implementation
+
+### Source code
+
+* <a href="https://github.com/algorandfoundation/ARCs/tree/main/assets/arc-0012/contracts">Contracts</a>
+* <a href="https://github.com/algorandfoundation/ARCs/tree/main/assets/arc-0012/arc12-sdk">TypeScript SDK</a>
+
+
+## Security Considerations
+
+Both applications (The vault and the master have not been audited)
+
+## 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-0015.md

@@ -0,0 +1,112 @@
+---
+arc: 15
+title: Encrypted Short Messages
+description: Scheme for encryption/decryption that allows for private messages.
+author: Stéphane Barroso (@sudoweezy), Paweł Pierścionek (@urtho)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/*
+status: Deprecated
+type: Standards Track
+category: Interface
+created: 2022-11-21
+requires: 4
+---
+
+# Encrypted Short Messages
+
+## Abstract
+
+The goal of this convention is to have a standard way for block explorers, wallets, exchanges, marketplaces, and more generally, client software to send, read & delete short encrypted messages.
+
+## 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>.
+
+> Comments like this are non-normative.
+
+### Account's message Application
+
+To receive a message, an Account **MUST** create an application that follows this convention:
+
+- A Local State named `public_key` **MUST** contain an *NACL Public Key (Curve 25519)* key
+- A Local State named `arc` **MUST** contain the value `arc15-nacl-curve25519`
+
+
+- A Box `inbox` where:
+  - Keys is an ABI encoded of the tuple `(address,uint64)` containing the address of the sender and the round when the message is sent
+  - Value is an encoded  **text**
+
+> With this design, for each round, the sender can only write one message per round.
+> For the same round, an account can receive multiple messages if distinct sender sends them
+
+### ABI Interface
+
+The associated smart contract **MUST** implement the following ABI interface:
+```json
+{
+  "name": "ARC_0015",
+  "desc": "Interface for an encrypted messages application",
+  "methods": [
+    {
+      "name": "write",
+      "desc": "Write encrypted text to the box inbox",
+      "args": [
+        { "type": "byte[]", "name": "text", "desc": "Encrypted text provided by the sender." }
+      ],
+      "returns": { "type": "void" }
+    },
+    {
+      "name": "authorize",
+      "desc": "Authorize an addresses to send a message",
+      "args": [
+        { "type": "byte[]", "name": "address_to_add", "desc": "Address of a sender" },
+        { "type": "byte[]", "name": "info", "desc": "information about the sender" }
+      ],
+      "returns": { "type": "void" }
+    },
+    {
+      "name": "remove",
+      "desc": "Delete the encrypted text sent by an account on a particular round. Send the MBR used for a box to the Application's owner.",
+      "args": [
+        { "type": "byte[]", "name": "address", "desc": "Address of the sender"},
+        { "type": "uint64", "name": "round", "desc": "Round when the message was sent"}
+      ],
+      "returns": { "type": "void" }
+    },
+    {
+      "name": "set_public_key",
+      "desc": "Register a NACL Public Key (Curve 25519) to the global value public_key",
+      "args": [
+        { "type": "byte[]", "name": "public_key", "desc": "NACL Public Key (Curve 25519)" }
+      ],
+      "returns": { "type": "void" }
+    }
+  ]
+}
+```
+> Warning: The remove method only removes the box used for a message, but it is still possible to access it by looking at the indexer.
+
+## Rationale
+Algorand blockchain unlocks many new use cases - anonymous user login to dApps and classical WEB2.0 solutions being one of them. For many use-cases, anonymous users still require asynchronous event notifications, and email seems to be the only standard option at the time of the creation of this ARC. With wallet adoption of this standard, users will enjoy real-time encrypted A2P (application-to-person) notifications without having to provide their email addresses and without any vendor lock-in.
+
+There is also a possibility to do a similar version of this ARC with one App which will store every message for every Account.
+
+Another approach was to use the note field for messages, but with box storage available, it was a more practical and secure design.
+
+## Reference Implementation
+
+The following codes are not audited and are only here for information purposes.
+It **MUST** not be used in production.
+
+Here is an example of how the code can be run in python :
+[main.py](../assets/arc-0015/main.py).
+> The delete method is only for test purposes, it is not part of the ABI for an `ARC-15` Application.
+
+An example the application created using Beaker can be found here :
+[application.py](../assets/arc-0015/application.py).
+
+
+## Security Considerations
+Even if the message is encrypted, it will stay on the blockchain.
+If the secret key used to decrypt is compromised at one point, every related message IS at risk.
+
+## 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-0016.md

@@ -0,0 +1,97 @@
+---
+arc: 16
+title: Convention for declaring traits of an NFT's
+description: This is a convention for declaring traits in an NFT's metadata.
+author: Keegan Thompson (@keeganthomp)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/62
+status: Final
+type: Standards Track
+category: ARC
+sub-category: Asa
+created: 2022-01-04
+---
+
+# Standard for declaring traits inside non-fungible NFT's metadata
+
+## Abstract
+
+The goal is to establish a standard for how traits are declared inside a non-fungible NFT's metadata, for example as specified in ([ARC-3](./arc-0003.md)), ([ARC-69](./arc-0069.md)) or ([ARC-72](./arc-0072.md)).
+
+## 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>.
+
+> Comments like this are non-normative.
+
+If the property `traits` is provided anywhere in the metadata, it **MUST** adhere to the schema below.
+If the NFT is a part of a larger collection and that collection has traits, all the available traits for the collection **MUST** be listed as a property of the `traits` object.
+If the NFT does not have a particular trait, it's value **MUST** be "none".
+
+The JSON schema for `traits` is as follows:
+
+```json
+{
+  "title": "Traits for Non-Fungible Token",
+  "type": "object",
+  "properties": {
+    "traits": {
+      "type": "object",
+      "description": "Traits (attributes) that can be used to calculate things like rarity. Values may be strings or numbers"
+    }
+  }
+}
+```
+
+#### Examples
+
+##### Example of an NFT that has traits
+
+```json
+{
+  "name": "NFT With Traits",
+  "description": "NFT with traits",
+  "image": "https://s3.amazonaws.com/your-bucket/images/two.png",
+  "image_integrity": "sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=",
+  "properties": {
+    "creator": "Tim Smith",
+    "created_at": "January 2, 2022",
+    "traits": {
+      "background": "red",
+      "shirt_color": "blue",
+      "glasses": "none",
+      "tattoos": 4,
+    }
+  }
+}
+```
+
+##### Example of an NFT that has no traits
+
+```json
+{
+  "name": "NFT Without Traits",
+  "description": "NFT without traits",
+  "image": "https://s3.amazonaws.com/your-bucket/images/one.png",
+  "image_integrity": "sha256-47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=",
+  "properties": {
+    "creator": "John Smith",
+    "created_at": "January 1, 2022",
+  }
+}
+```
+
+## Rationale
+
+A standard for traits is needed so programs know what to expect in order to calculate things like rarity.
+
+## Backwards Compatibility
+
+If the metadata does not have the field `traits`, each value of `properties` should be considered a trait.
+
+## Security Considerations
+
+None.
+
+## Copyright
+
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.