@goplausible/algorand-mcp 3.0.7

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

@@ -0,0 +1,335 @@
+---
+arc: 72
+title: Algorand Smart Contract NFT Specification
+description: Base specification for non-fungible tokens implemented as smart contracts.
+author: William G Hatch (@willghatch)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/162
+status: Living
+type: Standards Track
+category: Interface
+sub-category: Application
+created: 2023-01-10
+requires: 3, 4, 16, 22, 28, 73
+---
+
+# Algorand Smart Contract NFT Specification
+
+## Abstract
+This specifies an interface for non-fungible tokens (NFTs) to be implemented on Algorand as smart contracts.
+This interface defines a minimal interface for NFTs to be owned and traded, to be augmented by other standard interfaces and custom methods.
+
+
+## Motivation
+Currently most NFTs in the Algorand ecosystem are implemented as ASAs.
+However, to provide rich extra functionality, it can be desirable to implement NFTs as a smart contract instead.
+To foster an interoperable NFT ecosystem, it is necessary that the core interfaces for NFTs be standardized.
+
+
+## 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>.
+
+
+### Core NFT specification
+
+A smart contract NFT that is compliant with this standard must implement the interface detection standard defined in [ARC-73](./arc-0073.md).
+
+Additionally, the smart contract MUST implement the following interface:
+
+```json
+{
+  "name": "ARC-72",
+  "desc": "Smart Contract NFT Base Interface",
+  "methods": [
+    {
+      "name": "arc72_ownerOf",
+      "desc": "Returns the address of the current owner of the NFT with the given tokenId",
+      "readonly": true,
+      "args": [
+        { "type": "uint256", "name": "tokenId", "desc": "The ID of the NFT" },
+      ],
+      "returns": { "type": "address", "desc": "The current owner of the NFT." }
+    },
+    {
+      "name": "arc72_transferFrom",
+      "desc": "Transfers ownership of an NFT",
+      "readonly": false,
+      "args": [
+        { "type": "address", "name": "from" },
+        { "type": "address", "name": "to" },
+        { "type": "uint256", "name": "tokenId" }
+      ],
+      "returns": { "type": "void" }
+    },
+  ],
+  "events": [
+    {
+      "name": "arc72_Transfer",
+      "desc": "Transfer ownership of an NFT",
+      "args": [
+        {
+          "type": "address",
+          "name": "from",
+          "desc": "The current owner of the NFT"
+        },
+        {
+          "type": "address",
+          "name": "to",
+          "desc": "The new owner of the NFT"
+        },
+        {
+          "type": "uint256",
+          "name": "tokenId",
+          "desc": "The ID of the transferred NFT"
+        }
+      ]
+    }
+  ]
+}
+```
+
+Ownership of a token ID by the zero address indicates that ID is invalid.
+The `arc72_ownerOf` method MUST return the zero address for invalid token IDs.
+The `arc72_transferFrom` method MUST error when `from` is not the owner of `tokenId`.
+The `arc72_transferFrom` method MUST error unless called by the owner of `tokenId` or an approved operator as defined by an extension such as the transfer management extension defined in this ARC.
+The `arc72_transferFrom` method MUST emit a `arc72_Transfer` event a transfer is successful.
+A `arc72_Transfer` event SHOULD be emitted, with `from` being the zero address, when a token is first minted.
+A `arc72_Transfer` event SHOULD be emitted, with `to` being the zero address, when a token is destroyed.
+
+All methods in this and other interfaces defined throughout this standard that are marked as `readonly` MUST be read-only as defined by [ARC-22](./arc-0022.md).
+
+The ARC-73 interface selector for this core interface is `0x53f02a40`.
+
+
+### Metadata Extension
+
+A smart contract NFT that is compliant with this metadata extension MUST implement the interfaces required to comply with the Core NFT Specification, as well as the following interface:
+
+```json
+{
+  "name": "ARC-72 Metadata Extension",
+  "desc": "Smart Contract NFT Metadata Interface",
+  "methods": [
+    {
+      "name": "arc72_tokenURI",
+      "desc": "Returns a URI pointing to the NFT metadata",
+      "readonly": true,
+      "args": [
+        { "type": "uint256", "name": "tokenId", "desc": "The ID of the NFT" },
+      ],
+      "returns": { "type": "byte[256]", "desc": "URI to token metadata." }
+    }
+  ],
+}
+```
+
+URIs shorter than the return length MUST be padded with zero bytes at the end of the URI.
+The token URI returned SHOULD be an `ipfs://...` URI so the metadata can't expire or be changed by a lapse or takeover of a DNS registration.
+The token URI SHOULD NOT be an `http://` URI due to security concerns.
+The URI SHOULD resolve to a JSON file following :
+- the JSON Metadata File Schema defined in [ARC-3](./arc-0003.md).
+- the standard for declaring traits defined in [ARC-16](./arc-0016.md).
+
+Future standards could define new recommended URI or file formats for metadata.
+
+The ARC-73 interface selector for this metadata extension interface is `0xc3c1fc00`.
+
+### Transfer Management Extension
+
+A smart contract NFT that is compliant with this transfer management extension MUST implement the interfaces required to comply with the Core NFT Specification, as well as the following interface:
+
+```json
+{
+  "name": "ARC-72 Transfer Management Extension",
+  "desc": "Smart Contract NFT Transfer Management Interface",
+  "methods": [
+    {
+      "name": "arc72_approve",
+      "desc": "Approve a controller for a single NFT",
+      "readonly": false,
+      "args": [
+        { "type": "address", "name": "approved", "desc": "Approved controller address" },
+        { "type": "uint256", "name": "tokenId", "desc": "The ID of the NFT" },
+      ],
+      "returns": { "type": "void" }
+    },
+    {
+      "name": "arc72_setApprovalForAll",
+      "desc": "Approve an operator for all NFTs for a user",
+      "readonly": false,
+      "args": [
+        { "type": "address", "name": "operator", "desc": "Approved operator address" },
+        { "type": "bool", "name": "approved", "desc": "true to give approval, false to revoke" },
+      ],
+      "returns": { "type": "void" }
+    },
+    {
+      "name": "arc72_getApproved",
+      "desc": "Get the current approved address for a single NFT",
+      "readonly": true,
+      "args": [
+        { "type": "uint256", "name": "tokenId", "desc": "The ID of the NFT" },
+      ],
+      "returns": { "type": "address", "desc": "address of approved user or zero" }
+    },
+    {
+      "name": "arc72_isApprovedForAll",
+      "desc": "Query if an address is an authorized operator for another address",
+      "readonly": true,
+      "args": [
+        { "type": "address", "name": "owner" },
+        { "type": "address", "name": "operator" },
+      ],
+      "returns": { "type": "bool", "desc": "whether operator is authorized for all NFTs of owner" }
+    },
+  ],
+  "events": [
+    {
+      "name": "arc72_Approval",
+      "desc": "An address has been approved to transfer ownership of the NFT",
+      "args": [
+        {
+          "type": "address",
+          "name": "owner",
+          "desc": "The current owner of the NFT"
+        },
+        {
+          "type": "address",
+          "name": "approved",
+          "desc": "The approved user for the NFT"
+        },
+        {
+          "type": "uint256",
+          "name": "tokenId",
+          "desc": "The ID of the NFT"
+        }
+      ]
+    },
+    {
+      "name": "arc72_ApprovalForAll",
+      "desc": "Operator set or unset for all NFTs defined by this contract for an owner",
+      "args": [
+        {
+          "type": "address",
+          "name": "owner",
+          "desc": "The current owner of the NFT"
+        },
+        {
+          "type": "address",
+          "name": "operator",
+          "desc": "The approved user for the NFT"
+        },
+        {
+          "type": "bool",
+          "name": "approved",
+          "desc": "Whether operator is authorized for all NFTs of owner "
+        }
+      ]
+    },
+  ]
+}
+```
+
+The `arc72_Approval` event MUST be emitted when the `arc72_approve` method is called successfully.
+The zero address for the `arc72_approve` method and the `arc72_Approval` event indicate no approval, including revocation of previous single NFT controller.
+When a `arc72_Transfer` event emits, this also indicates that the approved address for that NFT (if any) is reset to none.
+The `arc72_ApprovalForAll` event MUST be emitted when the `arc72_setApprovalForAll` method is called successfully.
+The contract MUST allow multiple operators per owner.
+The `arc72_transferFrom` method, when its `nftId` argument is owned by its `from` argument, MUST succeed for when called by an address that is approved for the given NFT or approved as operator for the owner.
+
+The ARC-73 interface selector for this transfer management extension interface is `0xb9c6f696`.
+
+### Enumeration Extension
+
+A smart contract NFT that is compliant with this enumeration extension MUST implement the interfaces required to comply with the Core NFT Specification, as well as the following interface:
+
+```json
+{
+  "name": "ARC-72 Enumeration Extension",
+  "desc": "Smart Contract NFT Enumeration Interface",
+  "methods": [
+    {
+      "name": "arc72_balanceOf",
+      "desc": "Returns the number of NFTs owned by an address",
+      "readonly": true,
+      "args": [
+        { "type": "address", "name": "owner" },
+      ],
+      "returns": { "type": "uint256" }
+    },
+    {
+      "name": "arc72_totalSupply",
+      "desc": "Returns the number of NFTs currently defined by this contract",
+      "readonly": true,
+      "args": [],
+      "returns": { "type": "uint256" }
+    },
+    {
+      "name": "arc72_tokenByIndex",
+      "desc": "Returns the token ID of the token with the given index among all NFTs defined by the contract",
+      "readonly": true,
+      "args": [
+        { "type": "uint256", "name": "index" },
+      ],
+      "returns": { "type": "uint256" }
+    },
+  ],
+}
+```
+
+The sort order for NFT indices is not specified.
+The `arc72_tokenByIndex` method MUST error when `index` is greater than `arc72_totalSupply`.
+
+The ARC-73 interface selector for this enumeration extension interface is `0xa57d4679`.
+
+
+## Rationale
+
+This specification is based on <a href="https://eips.ethereum.org/EIPS/eip-721">ERC-721</a>, with some differences.
+
+### Core Specification
+
+The core specification differs from ERC-721 by:
+
+* removing `safeTransferFrom`, since there is not a test for whether an address on Algorand corresponds to a smart contract
+* moving management functionality out of the base specification into an extension
+* moving balance query functionality out of the base specification into the enumeration extension
+
+Moving functionality out of the core specification into extensions allows the base specification to be much simpler, and allows extensions for extra capabilities to evolve separately from the core idea of owning and transferring ownership of non-fungible tokens.
+It is recommended that NFT contract authors make use of extensions to enrich the capabilities of their NFTs.
+
+### Metadata Extension
+
+The metadata extension differns from the ERC-721 metadata extension by using a fixed-length URI return and removing the `symbol` and `name` operations.  Metadata such as symbol or name can be included in the metadata pointed to by the URI.
+
+### Transfer Management Extension
+
+The transfer management extension is taken from the set of methods and events from the base ERC-721 specification that deal with approving other addresses to transfer ownership of an NFT.
+This functionality is important for trusted NFT galleries like OpenSea to list and sell NFTs on behalf of users while allowing the owner to maintain on-chain ownership.
+However, this set of functionality is the bulk of the complexity of the ERC-721 standard, and moving it into an extension vastly simplifies the core NFT specification.
+Additionally, other interfaces have been proposed to allow for the sale of NFTs in decentralized manners without needing to give transfer control to a trusted third party.
+
+### Enumeration Extension
+
+The enumeration extension is taken from the ERC-721 enumeration extension.
+However, it also includes the `arc72_balanceOf` function that is included in the base ERC-721 specification.
+This change simplifies the core standard and groups the `arc72_balanceOf` function with related functionality for contracts where supply details are desired.
+
+
+## Backwards Compatibility
+
+This standard introduces a new kind of NFT that is incompatible with NFTs defined as ASAs.
+Applications that want to index, manage, or view NFTs on Algorand will need to handle these new smart NFTs as well as the already popular ASA implementation of NFTs will need to add code to handle both, and existing smart contracts that handle ASA-based NFTs will not work with these new smart contract NFTs.
+
+While this is a severe backwards incompatibility, smart contract NFTs are necessary to provide richer and more diverse functionality for NFTs.
+
+
+## Security Considerations
+
+The fact that anybody can create a new implementation of a smart contract NFT standard opens the door for many of those implementations to contain security bugs.
+Additionally, malicious NFT implementations could contain hidden anti-features unexpected by users.
+As with other smart contract domains, it is difficult for users to verify or understand security properties of smart contract NFTs.
+This is a tradeoff compared with ASA NFTs, which share a smaller set of security properties that are easier to validate, to gain the possibility of adding novel features.
+
+
+## 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-0073.md

@@ -0,0 +1,93 @@
+---
+arc: 73
+title: Algorand Interface Detection Spec
+description: A specification for smart contracts and indexers to detect interfaces of smart contracts.
+author: William G Hatch (@willghatch)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/165
+status: Final
+type: Standards Track
+category: Interface
+sub-category: Application
+created: 2023-01-10
+requires: 4, 22, 28
+---
+
+# Algorand Interface Detection Spec
+
+## Abstract
+
+This ARC specifies an interface detection interface based on <a href="https://eips.ethereum.org/EIPS/eip-165">ERC-165</a>.
+This interface allows smart contracts and indexers to detect whether a smart contract implements a particular interface based on an interface selector.
+
+
+## Motivation
+
+[ARC-4](arc-0004.md) applications have associated Contract or Interface description JSON objects that allow users to call their methods.
+However, these JSON objects are communicated outside of the consensus network.
+Therefore indexers can not reliably identify contract instances of a particular interface, and smart contracts have no way to detect whether another contract supports a particular interface.
+An on-chain method to detect interfaces allows greater composability for smart contracts, and allows indexers to automatically detect implementations of interfaces of interest.
+
+
+## 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>.
+
+
+### How Interfaces are Identified
+
+The specification for interfaces is defined by [ARC-4](./arc-0004.md).
+This specification extends ARC-4 to define the concept of an interface selector.
+We define the interface selector as the XOR of all selectors in the interface.
+Selectors in the interface include selectors for methods, selectors for events as defined by [ARC-28](./arc-0028.md), and selectors for potential future kinds of interface components.
+
+As an example, consider an interface that has two methods and one event, `add(uint64,uint64)uint128`, `add3(uint64,uint64,uint64)uint128`, and `alert(uint64)`.
+The method selector for the `add` method is the first 4 bytes of the method signature's SHA-512/256 hash.
+The SHA-512/256 hash of `add(uint64,uint64)uint128` is `0x8aa3b61f0f1965c3a1cbfa91d46b24e54c67270184ff89dc114e877b1753254a`, so its method selector is `0x8aa3b61f`.
+The SHA-512/256 hash of `add3(uint64,uint64,uint64)uint128` is `0xa6fd1477731701dd2126f24facf3492d470cf526e7d4d849fea33d102b45f03d`, so its method selector is `0xa6fd1477`
+The SHA-512/256 hash of `alert(uint64)` is `0xc809efe9fd45417226d52b605658b83fff27850a01efeea30f694d1e112d5463`, so its method selector is `0xc809efe9`
+The interface selector is defined as the bitwise exclusive or of all method and event selectors, so the interface selector is `0x8aa3b61f XOR 0xa6fd1477 XOR 0xc809efe9`, which is `0xe4574d81`.
+
+### How a Contract will Publish the Interfaces it Implements for Detection
+
+In addition to out-of-band JSON contract or interface description data, a contract that is compliant with this specification shall implement the following interface:
+
+```json
+{
+  "name": "ARC-73",
+  "desc": "Interface for interface detection",
+  "methods": [
+    {
+      "name": "supportsInterface",
+      "desc": "Detects support for an interface specified by selector.",
+      "readonly": true,
+      "args": [
+        { "type": "byte[4]", "name": "interfaceID", "desc": "The selector of the interface to detect." },
+      ],
+      "returns": { "type": "bool", "desc": "Whether the contract supports the interface." }
+    }
+  ]
+}
+```
+
+The `supportsInterface` method must be `readonly` as specified by [ARC-22](./arc-0022.md).
+
+The implementing contract must have a `supportsInterface` method that returns:
+
+* `true` when `interfaceID` is `0x4e22a3ba` (the selector for [ARC-73](./arc-0073.md), this interface)
+* `false` when `interfaceID` is `0xffffffff`
+* `true` for any other `interfaceID` the contract implements
+* `false` for any other `interfaceID`
+
+
+## Rationale
+
+This specification is nearly identical to the related specification for Ethereum, <a href="https://eips.ethereum.org/EIPS/eip-165">ERC-165</a>, merely adapted to Algorand.
+
+
+## Security Considerations
+
+It is possible that a malicious contract may lie about interface support.
+This interface makes it easier for all kinds of actors, inclulding malicious ones, to interact with smart contracts that implement it.
+
+
+## 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-0074.md

@@ -0,0 +1,128 @@
+---
+arc: 74
+title: NFT Indexer API
+description: REST API for reading data about Application's NFTs.
+author: William G Hatch (@willghatch)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/170
+status: Final
+type: Standards Track
+category: Interface
+sub-category: Application
+created: 2023-02-17
+requires: 72
+---
+
+
+## Abstract
+This specifies a REST interface that can be implemented by indexing services to provide data about NFTs conforming to the [ARC-72](arc-0072.md) standard.
+
+## Motivation
+While most data is available on-chain, reading and analyzing on-chain logs to get a complete and current picture about NFT ownership and history is slow and impractical for many uses.
+This REST interface standard allows analysis of NFT contracts to be done in a centralized manner to provide fast, up-to-date responses to queries, while allowing users to pick from any indexing provider.
+
+
+## Specification
+
+This specification defines two REST endpoints: `/nft-index/v1/tokens` and `/nft-index/v1/transfers`.
+Both endpoints respond only to `GET` requests, take no path parameters, and consume no input.
+But both accept a variety of query parameters.
+
+### `GET /nft-indexer/v1/tokens`
+
+Produces `application/json`.
+
+Optional Query Parameters:
+
+| Name | Schema | Description |
+| --- | --- | --- |
+| round | integer | Include results for the specified round.  For performance reasons, this parameter may be disabled on some configurations. |
+| next | string | Token for the next page of results.  Use the `next-token` provided by the previous page of results. |
+| limit | integer | Maximum number of results to return.  There could be additional pages even if the limit is not reached. |
+| contractId | integer | Limit results to NFTs implemented by the given contract ID. |
+| tokenId | integer | Limit results to NFTs with the given token ID. |
+| owner | address | Limit results to NFTs owned by the given owner. |
+| mint-min-round | integer | Limit results to NFTs minted on or after the given round. |
+| mint-max-round | integer | Limit results to NFTs minted on or before the given round. |
+
+When successful, returns a response with code 200 and an object with the schema:
+
+| Name | Required? | Schema | Description |
+| --- | --- | --- | --- |
+| tokens | required | <Token> array | Array of Token objects that fit the query parameters, as defined below. |
+| current-round | required | integer | Round at which the results were computed. |
+| next-token | optional | string | Used for pagination, when making another request provide this token as the `next` parameter. |
+
+The `Token` object has the following schema:
+
+| Name | Required? | Schema | Description |
+| --- | --- | --- | --- |
+| owner | required | address | The current owner of the NFT. |
+| contractId | required | integer | The ID of the ARC-72 contract that defines the NFT. |
+| tokenId | required | integer | The tokenID of the NFT, which along with the contractId addresses a unique ARC-72 token. |
+| mint-round | optional | integer | The round at which the NFT was minted (IE the round at which it was transferred from the zero address to the first owner). |
+| metadataURI | optional | string | The URI given for the token by the `metadataURI` API of the contract, if applicable. |
+| metadata | optional | object | The result of resolving the `metadataURI`, if applicable and available. |
+
+When unsuccessful, returns a response with code 400 or 500 and an object with the schema:
+
+| Name | Required? | Schema |
+| --- | --- | --- |
+| data | optional | object |
+| message | required | string |
+
+### `GET /nft-indexer/v1/transfers`
+
+Produces `application/json`.
+
+Optional Query Parameters:
+
+| Name | Schema | Description |
+| --- | --- | --- |
+| round | integer | Include results for the specified round.  For performance reasons, this parameter may be disabled on some configurations. |
+| next | string | Token for the next page of results.  Use the `next-token` provided by the previous page of results. |
+| limit | integer | Maximum number of results to return.  There could be additional pages even if the limit is not reached. |
+| contractId | integer | Limit results to NFTs implemented by the given contract ID. |
+| tokenId | integer | Limit results to NFTs with the given token ID. |
+| user | address | Limit results to transfers where the user is either the sender or receiver. |
+| from | address | Limit results to transfers with the given address as the sender. |
+| to | address | Limit results to transfers with the given address as the receiver. |
+| min-round | integer | Limit results to transfers that were executed on or after the given round. |
+| max-round | integer | Limit results to transfers that were executed on or before the given round. |
+
+When successful, returns a response with code 200 and an object with the schema:
+
+| Name | Required? | Schema | Description |
+| --- | --- | --- | --- |
+| transfers | required | <Transfer> array | Array of Transfer objects that fit the query parameters, as defined below. |
+| current-round | required | integer | Round at which the results were computed. |
+| next-token | optional | string | Used for pagination, when making another request provide this token as the `next` parameter. |
+
+The `Transfer` object has the following schema:
+
+| Name | Required? | Schema | Description |
+| --- | --- | --- | --- |
+| contractId | required | integer | The ID of the ARC-72 contract that defines the NFT. |
+| tokenId | required | integer | The tokenID of the NFT, which along with the contractId addresses a unique ARC-72 token. |
+| from | required | address | The sender of the transaction. |
+| to | required | address | The receiver of the transaction. |
+| round | required | integer | The round of the transfer. |
+
+When unsuccessful, returns a response with code 400 or 500 and an object with the schema:
+
+| Name | Required? | Schema |
+| --- | --- | --- |
+| data | optional | object |
+| message | required | string |
+
+## Rationale
+This standard was designed to feel similar to the Algorand indexer API, and uses the same query parameters and results where applicable.
+
+## Backwards Compatibility
+This standard presents a versioned REST interface, allowing future extensions to change the interface in incompatible ways while allowing for the old service to run in tandem.
+
+
+## Security Considerations
+All data available through this indexer API is publicly available.
+
+## 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-0076.md

@@ -0,0 +1,99 @@
+---
+arc: 76
+title: Password Account
+description: Password account using PBKDF2
+author: Ludovit Scholtz (@scholtz)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/208
+status: Deprecated
+type: Standards Track
+category: Core
+created: 2023-06-12
+---
+
+## Abstract
+This standard specifies a computation for seed bytes for Password Account. For general adoption it is better for people to remember passphrase than mnemonic. With this standard person can hash the passphrase and receive the seed bytes for X25529 algorand account.
+
+## Motivation
+By providing a clear and precise computation process, Password Account empowers individuals to effortlessly obtain their seed bytes for algorand account. In the realm of practicality and widespread adoption, the standard highlights the immense advantages of utilizing a passphrase rather than a mnemonic. Remembering a passphrase becomes the key to unlocking a world of possibilities. With this groundbreaking standard, individuals can take control of their X25529 Algorand account by simply hashing their passphrase and effortlessly receiving the corresponding seed bytes. It's time to embrace this new era of accessibility and security, empowering yourself to reach new heights in the world of Password Accounts. Let this standard serve as your guiding light, motivating community to embark on a journey of limitless possibilities and unparalleled success.
+
+This standard seek the synchronization between wallets which may provide password protected accounts.
+
+## Specification
+
+Seed bytes generation is calculated with algorithm:
+
+```
+      const init = `ARC-0076-${password}-{slotId}-PBKDF2-999999`;
+      const salt = `ARC-0076-{slotId}-PBKDF2-999999`;
+      const iterations = 999999;
+      const cryptoKey = await window.crypto.subtle.importKey(
+        "raw",
+        Buffer.from(init, "utf-8"),
+        "PBKDF2",
+        false,
+        ["deriveBits", "deriveKey"]
+      );
+      const masterBits = await window.crypto.subtle.deriveBits(
+        {
+          name: "PBKDF2",
+          hash: "SHA-256",
+          salt: Buffer.from(salt, "utf-8"),
+          iterations: iterations,
+        },
+        cryptoKey,
+        256
+      );
+
+      const uint8 = new Uint8Array(masterBits);
+      const mnemonic = algosdk.mnemonicFromSeed(uint8);
+      const genAccount = algosdk.mnemonicToSecretKey(mnemonic);
+```
+
+Length of the data section SHOULD be at least 16 bytes long.
+
+Slot ID is account iteration. Default is "0".
+
+### Email Password account
+
+Email Password account is account generated from the original data
+
+```
+      const init = `ARC-0076-${email}-${password}-{slotId}-PBKDF2-999999`;
+      const salt = `ARC-0076-${email}-{slotId}-PBKDF2-999999`;
+```
+
+The email part can be published to the service provider backend and verified by the service provider. Password MUST NOT be transferred over the network.
+
+Length of the password SHOULD be at least 16 bytes long.
+
+### Sample data
+This sample data may be used for verification of the ```ARC-0076``` implementation.
+
+```
+const email = "email@example.com";
+const password = "12345678901234567890123456789012345678901234567890";
+const slotId = "0";
+const init = `ARC-0076-${email}-${password}-{slotId}-PBKDF2-999999`;
+const salt = `ARC-0076-${email}-{slotId}-PBKDF2-999999`;
+```
+
+Results in:
+
+```
+masterBits = [225,7,139,154,245,210,181,138,188,129,145,53,246,184,243,88,163,163,109,208,77,71,7,235,81,244,129,215,102,168,105,21]
+account.addr = "5AHWQJ5D52K4GRW4JWQ5GMR53F7PDSJEGT4PXVFSBQYE7VXDVG3WSPWSBM"
+```
+
+## Rationale
+This standard was designed to allow the wallets to provide password protected accounts which does not require general population to store the mnemonic. Email extension allows service providers to bind specific account with the email address, and user experience to feel the basic authentication form with email and password they are already used to from web2 usecases.
+
+## Backwards Compatibility
+We expect future extensions to be compatible with Password account. The hash mechanism for the future algorighms should be suffixed such as ```-PBKDF2-999999```.
+
+## Security Considerations
+This standard moves the security of strength of the account to how user generates the password.
+
+This standard relies on randomness  and collision resistance of PBKDF2 and 'SHA-256'. User MUST be informed about the risks associated with this type of account.
+
+## Copyright
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.