@goplausible/algorand-mcp 3.0.7

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

@@ -0,0 +1,167 @@
+---
+arc: 34
+title: xGov Pilot - Proposal Process
+description: Criteria for the creation of proposals.
+author: Stéphane Barroso (@SudoWeezy), Adriana Belotti, Michel Treccani
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/151
+status: Deprecated
+type: Meta
+created: 2022-11-22
+---
+
+## Abstract
+
+The Goal of this ARC is to clearly define the steps involved in submitting proposals for the xGov Program, to increase transparency and efficiency, ensuring all proposals are given proper consideration. The goal of this grants scheme is to fund proposals that will help us in our goal of increasing the adoption of the Algorand network, as the most advanced layer 1 blockchain to date. The program aims to fund proposals to develop open source software, including tooling, as well as educational resources to help inform and grow the Algorand community.
+
+## 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>.
+
+### What is a proposal
+
+The xGov program aims to provide funding for individuals or teams to:
+
+- Develop of open source applications and tools (eg. an open source AMM or contributing content to an Algorand software library).
+- Develop Algorand education resources, preferably in languages where the resources are not yet available(eg. a video series teaching developers about Algorand in Portuguese or Indonesian).
+
+The remainder of the xGov program pilot will not fund proposals for:
+
+- Supplying liquidity.
+- Reserving funds to pay for ad-hoc open-source development (devs can apply directly for an xGov grant).
+- Buying ASAs, including NFTs.
+
+Proposals **SHALL NOT** be divided in small chunks.
+> Issues requiring resolution may have been discussed on various online platforms such as forums, discord, and social media networks.
+> Proposals requesting a large amount of funds **MUST BE** split into a milestone-based plan. See [Submit a proposal](./arc-0034.md#submit-a-proposal)
+
+### Duty of a proposer
+
+Having the ability to propose measures for a vote is a significant privilege, which requires:
+
+- A thorough understanding of the needs of the community.
+- Alignment of personal interests with the advancement of the Algorand ecosystem.
+- Promoting good behavior amongst proposers and discouraging "gaming the system".
+- Reporting flaws and discussing possible solutions with the AF team and community using either the Algorand Forum or the xGov Discord channels.
+
+### Life of a proposal
+
+The proposal process will follow the steps below:
+
+- Anyone can submit a proposal at any time.
+- Proposals will be evaluated and refined by the community and xGovs before they are available for voting.
+- Up to one month is allocated for voting on proposals.
+- The community will vote on proposals that have passed the refinement and temperature check stage.
+
+> If too many proposals are received in a short period of time. xGovs can elect to close proposals, in order to be able to handle the volume appropriately.
+
+### Submit a proposal
+
+In order to submit a proposal, a proposer needs to create a pull request on the following repository: <a href="https://github.com/algorandfoundation/xGov">xGov Proposals</a>.
+
+Proposals **MUST**:
+
+- Be posted on the <a href="https://forum.algorand.org/">Algorand Forum</a> (using tags: Governance and xGov Proposals) and discussed with the community during the review phased. Proposals without a discussion thread WILL NOT be included in the voting session.
+- Follow the [template form provided](../assets/arc-0034/TemplateForm.md), filling all the template sections
+- Follow the rules of the xGov Proposals Repository.
+- The minimum requested Amount is 10000 Algo
+- Have the status `Final` before the end of the temperature check.
+- Be either Proactive (the content of the proposal is yet to be created) or Retroactive (the content of the proposal is already created)
+- Milestone-based grants must submit a proposal for one milestone at a time.
+- Milestones need to follow the governance periods cycle. With the current 3-months cycle, a milestone could be 3-months, 6 months, 9 months etc.
+- The proposal must display all milestones with clear deliverables and the amount requested must match the 1st milestone. If a second milestone proposal is submitted, it must display the first completed milestone, linking all deliverables. If a third milestone proposal is submitted, it must display the first and second completed milestone, linking all deliverables. This repeats until all milestones are completed.
+- Funding will only be disbursed upon the completion of deliverables.
+- A proposal must specify how its delivery can be verified,  so that it can be checked prior to payment.
+- Proposals must include clear, non-technical descriptions of deliverables. We encourage the use of multimedia (blog/video) to help explain your proposal’s benefits to the community.
+- Contain the maintenance period, availability, and sustainability plans. This includes information on potential costs and the duration for which services will be offered at no or reduced cost.
+
+Proposals **MUST NOT**:
+
+- Request funds for marketing campaigns or organizing future meetups.
+
+> Each entity, individual, or project can submit at most two proposals (one proactive proposal and one retroactive proposal). Attempts to circumvent this rule may lead to disqualification or denial of funds.
+
+### Disclaimer jurisdictions and exclusions
+
+To be eligible to apply for a grant, projects must abide by the <a href="https://www.algorand.foundation/disclaimers">Disclaimers</a> (in particular the “Excluded Jurisdictions” section) and be willing to enter into <a href="https://drive.google.com/file/d/1dsKwQGhnS3h_PrSkoidhnvqlX7soLpZ-/view">a binding contract with the Algorand Foundation</a>.
+Additionally, applications promoting gambling, adult content, drug use, and violence of any kind are not permitted.
+
+> We are currently accepting grant applications from US-based individual/business. If the grant is approved, Algos will be converted to USDCa upon payment. This exception will be reviewed periodically.
+
+### Voting Power
+
+When an account participates in its first session, the voting power assigned to it will be equivalent to the total governance rewards it would have received. For all following sessions, the account's voting power will adjust based on the rewards lost by members in their pool who did not meet their obligations.
+
+The voting power for an upcoming session is computed as:
+`new_account_voting_power = (initial_pool_voting_power * initial_account_voting_power) / pool_voting_power_used`
+
+Where:
+
+- `new_account_voting_power`: Voting power allocated to an account for the next session.
+- `initial_account_voting_power`: The voting power originally assigned to an account, based on the governance rewards.
+- `initial_pool_voting_power`: The total voting power of the pool during its initial phase. This is the sum of governance rewards for all pool participants.
+- `pool_voting_power_used`: The voting power from the pool that was actually used in the last session.
+
+### Proposal Approval Threshold
+
+In order for a proposal to be approved, it is necessary for the number of votes in favor of the proposal to be proportionate to the amount of funds requested. This ensures that the allocation of funds is in line with the community's consensus and in accordance with democratic principles.
+
+The formula to calculate the voting power needed to pass a proposal is as follows:
+`voting_power_needed = (amount_requested) / (amount_available) * (current_session_voting_power_used)`
+
+Where:
+
+- `voting_power_needed`: Voting power required for a proposal to be accepted.
+- `amount_requested`: The requested amount a proposal is seeking.
+- `amount_available`: The entire grant funds available for the current session.
+- `current_session_voting_power_used`: The voting power used in the current session.
+
+> eg. 2 000 000 Algo are available to be given away as grants, 300 000 000 Algo are committed to the xGov Process, 200 000 000 Algo are used during the vote:
+>
+> - Proposal A request 100 000 Algos (5 % of the Amount available)
+> - Proposal A needs 5 % of the used votes (10 000 000 Votes) to go through
+
+### Voting on proposal
+
+At the start of the voting period xGovs [ARC-33](arc-0033.md) will vote on proposals using the voting tool hosted at <a href="https://xgov.algorand.foundation/">https://xgov.algorand.foundation/</a>.
+
+Vote will refer to the PR number and a cid hash of the proposal itself.
+
+The CID MUST:
+
+- Represent the file.
+
+- Be a version V1 CID
+  - E.g., use the option --cid-version=1 of ipfs add
+
+- Use SHA-256 hash algorithm
+  - E.g., use the option --hash=sha2-256 of ipfs add
+
+### Grants calculation
+
+The allocation of grants will consider the funding request amounts and the available amount of ALGO to be distributed.
+
+### Grants contract & payment
+
+- Once grants are approved, the Algorand Foundation team will handle the applicable contract and payment.
+- **Before submitting your grant proposal**, review the contract template and ensure you're comfortable with its terms: <a href="https://drive.google.com/file/d/1dsKwQGhnS3h_PrSkoidhnvqlX7soLpZ-/view">Contract Template</a>.
+
+> For milestone-based grants, please also refer to the [Submit a proposal section](./arc-0034.md#submit-a-proposal)
+
+## Rationale
+
+The current status of the proposal process includes the following elements:
+
+- Proposals will be submitted off-chain and linked to the on-chain voting through a hash.
+- Projects that require multiple funding rounds will need to submit separate proposals.
+- The allocation of funds will be subject to review and adjustment during each governance period.
+- Voting on proposals will take place on-chain.
+
+We encourage the community to continue to provide input on this topic through the submission of questions and ideas in this ARC document.
+
+## 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-0035.md

@@ -0,0 +1,151 @@
+---
+arc: 35
+title: Algorand Offline Wallet Backup Protocol
+description: Wallet-agnostic backup protocol for multiple accounts
+author: Yigit Guler (@yigitguler)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/156
+status: Final
+type: Standards Track
+category: Interface
+sub-category: Wallet
+created: 2023-01-03
+---
+# Algorand Secure Offline Wallet Backup Protocol
+
+
+## Abstract
+This document outlines the high-level requirements for a wallet-agnostic backup protocol that can be used across all wallets on the Algorand ecosystem.
+
+## 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>.
+
+### Requirements
+At a high-level, offline wallet backup protocol has the following requirements:
+
+ * Wallet applications should allow backing up and storing multiple accounts at the same time.
+Account information should be encrypted with a user-defined secret key, utilizing NaCl SecretBox method (audited and endorsed by Algorand).
+
+ * Encrypted final string should be easily copyable to be stored digitally.
+When importing, wallet applications should be able to detect already imported accounts and gracefully ignore them.
+
+### Format
+
+Before encryption, account information should be converted to the following JSON format:
+
+```
+{
+  "device_id": "UNIQUE IDENTIFIER FOR DEVICE (OPTIONAL)",
+  "provider_name": "PROVIDER NAME (OPTIONAL, i.e. Pera Wallet)",
+  "accounts": [
+    {
+      "address": "ACCOUNT PUBLIC ADDRESS (REQUIRED)",
+      "name": "USER DEFINED ACCOUNT NAME (OPTIONAL)",
+      "account_type": "TYPE OF ACCOUNT: single, multisig, watch, contact, ledger (REQUIRED)",
+    "private_key": "PRIVATE KEY AS BASE64 ENCODING OF 64 BYTE ALGORAND PRIVATE KEY as encoded by algosdk (NOT PASSPHRASE, REQUIRED for user-owned accounts, can be omitted in case of watch, contact, multisig, ledger accounts)",
+      "metadata": "ANY ADDITIONAL CONTENT (OPTIONAL)",
+      "multisig": "Multisig information (only required if the account_type is multisig)",
+      "ledger": {
+        "device_id": "device id",
+        "index": <index of the account on device, integer>,
+        "connection_type": "bluetooth|usb"
+      },
+    },
+    ...
+  ]
+}
+```
+
+*Clients must accept additional fields in the JSON document.*
+
+Here is an example with a single account:
+
+```
+{
+  "device_id": "2498232091970170817",
+  "provider_name": "Pera Wallet",
+  "accounts": [
+    {
+      "address": "ELWRE6HZ7KIUT46EQ6PBISGD3ND6QSCBVWICYR2QR2Y7LOBRZRCAIKLWDE",
+      "name": "My NFT Account",
+      "account_type": "single",
+      "private_key": "w0HG2VH7tAYz9PD4SYX0flC4CKh1OONCB6U5bP7cXGci7RJ4+fqRSfPEh54USMPbR+hIQa2QLEdQjrH1uDHMRA=="
+    }
+  ],
+}
+```
+
+Here is an example with a single multi-sig account:
+
+```
+{
+  "device_id": "2498232091970170817",
+  "provider_name": "Pera Wallet",
+  "accounts": [
+    {
+      "address": "ELWRE6HZ7KIUT46EQ6PBISGD3ND6QSCBVWICYR2QR2Y7LOBRZRCAIKLWDE",
+      "name": "Our Multisig Account",
+      "account_type": "multisig",
+      "multisig": {
+        version: 1,
+        threshold: 2,
+        addrs: [
+            account1.addr,
+            account2.addr,
+            account3.addr,
+            ],
+     },
+    }
+  ],
+}
+```
+
+### Encryption
+
+Once the input JSON is ready, as specified above, it needs to be encrypted. Even if it is assumed that the user is going to store this information in a secure location, copy-pasting it without encryption is not secure since multiple applications can access the clipboard.
+
+The information needs to be encrypted using a very long passphrase. 12 words mnemonic will be used as the key. 12-word mnemonic is secure and it will not create confusion with the 25-word mnemonics that are used to encrypt accounts.
+
+The wallet applications should not allow users to copy the 12-word mnemonic nor allow taking screenshots. The users should note it visually.
+
+The encryption should be made as follows:
+
+1. The wallet generates a random 16-byte string S (using a cryptographically secure random number generator)
+2. The wallet derives a 32-byte key: `key = HMAC-SHA256(key="Algorand export 1.0", input=S)`
+    On libsodium, use https://libsodium.gitbook.io/doc/advanced/hmac-sha2#hmac-sha-256,
+    `crypto_auth_hmacsha256_init` / `crypto_auth_hmacsha256_update` / `crypto_auth_hmacsha256_final`
+3. The wallet encrypts the input JSON using `crypto_secretbox_easy` from libsodium (https://libsodium.gitbook.io/doc/secret-key_cryptography/secretbox)
+4. The wallet outputs the following output JSON:
+
+```
+{
+  "version": "1.0",
+  "suite": "HMAC-SHA256:sodium_secretbox_easy",
+  "ciphertext": <base64 of the ciphertext>
+}
+```
+
+This JSON document (will be referred as ciphertext envelope JSON) needs to be encoded with base64 again in order to make it easier to copy-paste & store.
+
+5. S is encoded as a 12-word mnemonic (according to BIP-39) and displayed to the user.
+
+The user will be responsible for keeping the 12-word mnemonic and the base64 output of the ciphertext envelope JSON in safe locations. Note that step 5 is the default approach, however, the wallets can support other methods other than mnemonics as well, as long as they are secure.
+
+
+### Importing
+When importing, wallet applications should ask the user for the base64 output of the envelope JSON and the 12-word mnemonic. After getting these values, it should attempt to decrypt the encrypted string using the 12-word mnemonic. On successful decryption, accounts that can be imported can be processed.
+
+## Rationale
+There are many benefits to having an openly documented format:
+
+ * Better interoperability across wallets, allowing users to use multiple wallets easily by importing all of their accounts using a single format.
+
+ * Easy and secure backup of all wallet data at a user-defined location, including secure storage in digital environments.
+
+ * Ability to transfer data from device to device securely, such as when moving data from one mobile device to another.
+
+
+## Security Considerations
+Tbd
+
+## 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-0036.md

@@ -0,0 +1,84 @@
+---
+arc: 36
+title: Convention for declaring filters of an NFT
+description: This is a convention for declaring filters in an NFT metadata
+author: Stéphane Barroso (@sudoweezy)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/163
+status: Final
+type: Standards Track
+category: ARC
+sub-category: Asa
+created: 2023-03-10
+---
+
+# Standard for declaring filters inside non-fungible token metadata
+
+## Abstract
+
+The goal is to establish a standard for how filters are declared inside a non-fungible (NFT) metadata.
+
+## 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 `filters` is provided anywhere in the metadata of an nft, it **MUST** adhere to the schema below.
+If the nft is a part of a larger collection and that collection has filters, all the available filters for the collection **MUST** be listed as a property of the `filters` object.
+If the nft does not have a particular filter, it's value **MUST** be "none".
+
+The JSON schema for `filters` is as follows:
+
+```json
+{
+  "title": "Filters for Non-Fungible Token",
+  "type": "object",
+  "properties": {
+    "filters": {
+      "type": "object",
+      "description": "Filters can be used to filter nfts of a collection.  Values must be an array of strings or numbers."
+    }
+  }
+}
+```
+
+#### Examples
+
+##### Example of an NFT that has traits & filters
+
+```json
+{
+  "name": "NFT With Traits & filters",
+  "description": "NFT with traits & filters",
+  "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": "yellow",
+      "head": "curly"
+    },
+    "filters": {
+      "xp": 120,
+      "state": "REM"
+    }
+  }
+}
+```
+
+## Rationale
+
+A standard for filters is needed so programs know what to expect in order to filter things without using rarity.
+
+## Backwards Compatibility
+
+If `filters` wants to be added on top of fields [ARC-16](./arc-0016.md) `traits` and `filters` should be inside the `properties` object. (eg: [Example above](./arc-0036.md#example-of-an-nft-that-has-traits--filters))
+
+## 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-0042.md

@@ -0,0 +1,76 @@
+---
+arc: 42
+title: xGov Pilot - Integration
+description: Integration of xGov Process
+author: Stéphane Barroso (@SudoWeezy)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/204
+status: Deprecated
+type: Informational
+created: 2023-06-01
+---
+
+## Abstract
+
+This ARC aims to explain how the xGov process can be integrated within dApps.
+
+## Motivation
+
+By leveraging the xGov decentralization, it can improve the overall efficiency of this initiative.
+
+## 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://www.ietf.org/rfc/rfc2119.txt">RFC-2119</a>.
+
+### How to register
+
+#### How to find the xGov Escrow address
+
+The xGov Escrow address can be extracted using this endpoint: `https://governance.algorand.foundation/api/periods/active/`.
+
+```json
+{
+  ...
+  "xgov_escrow_address": "string",
+  ...
+}
+```
+
+#### Registration
+Governors should specify the xGov-related fields. Specifically, governors can sign up to be xGovs by designating as beneficiaries the xGov escrow address (that changes from one governance period to the next). They can also designate an xGov-controller address that would participate on their behalf in xGov votes via the optional parameter "xGv":"aaa". Namely, the Notes field has the form.
+
+af/gov1:j{"com":nnn,"mmm1":nnn1,"mmm2":nnn2,"bnf":"XYZ","xGv":"ABC"}
+Where:
+
+"com":nnn is the Algo commitment;
+"mmm":nnn is a commitment for LP-token with asset-ID mmm;
+"bnf":"XYZ" designates the address "XYZ" as the recipient of rewards ("XYZ" must equal the xGov escrow in order to sign up as an xGov);
+The optional "xGv":"ABC" designates address "ABC" as the xGov-controller of this xGov account.
+
+#### Goal example
+
+goal clerk send -a 0 -f ALDJ4R2L2PNDGQFSP4LZY4HATIFKZVOKTBKHDGI2PKAFZJSWC4L3UY5HN4 -t RFKCBRTPO76KTY7KSJ3HVWCH5HLBPNBHQYDC52QH3VRS2KIM7N56AS44M4 -n
+
+‘af/gov1:j{“com”:1000000,“12345":2,“67890”:30,“bnf”:“DRWUX3L5EW7NAYCFL3NWGDXX4YC6Y6NR2XVYIC6UNOZUUU2ERQEAJHOH4M”,“xGv”:“ALDJ4R2L2PNDGQFSP4LZY4HATIFKZVOKTBKHDGI2PKAFZJSWC4L3UY5HN4”}’
+
+
+### How to Interact with the Voting Application
+#### How to get the Application ID
+Every vote will be a different ID, but search for all apps created by the used account and look at the global state to see if is_bootstrapped is 1.
+
+#### ABI
+
+The ABI is available <a href="https://github.com/algorandfoundation/nft_voting_tool/blob/main/src/algorand/smart_contracts/artifacts/VotingRoundApp/contract.json">here </a>.
+A working test example of how to call application's method is here:
+https://github.com/algorandfoundation/nft_voting_tool/blob/main/src/algorand/smart_contracts/tests/voting.spec.ts
+
+## Rationale
+This integration will improve the usage of the process.
+
+## Backwards Compatibility
+None
+
+
+## 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-0047.md

@@ -0,0 +1,171 @@
+---
+arc: 47
+title: Logic Signature Templates
+description: Defining templated logic signatures so wallets can safely sign them.
+author: Joe Polny (@joe-p)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/226
+status: Final
+type: Standards Track
+category: ARC
+sub-category: Wallet
+created: 2023-07-17
+---
+
+## Abstract
+This standard allows wallets to sign known logic signatures and clearly tell the user what they are signing.
+
+## Motivation
+Currently, most Algorand wallets do not enable the signing of logic signature programs for the purpose of delegation. The rationale is to prevent users from signing malicious programs, but this limitation also prevents non-malicious delegated logic signatures from being used in the Algorand ecosystem. As such, there needs to be a way to provide a safe way for wallets to sign logic signatures without putting users at risk.
+
+## Specification
+
+A logic signature **MUST** be described via the following JSON interface(s):
+
+### Interface
+
+```typescript
+interface LogicSignatureDescription {
+    name: string,
+    description: string,
+    program: string,
+    variables: {
+        variable: string,
+        name: string,
+        type: string,
+        description: string
+    }[]
+}
+```
+
+| Key | Description |
+| --- | ----------- |
+| `name` | The name of the logic signature. **SHOULD** be short and descriptive |
+| `description` | A description of what the logic signature does |
+| `program` | base64 encoding of the TEAL program source
+| `variables` | An array of variables in the program |
+| `variables.variable` | The name of the variable in the templated program. |
+| `variables.name` | Human-friendly name for the variable. **SHOULD** be short and descriptive |
+| `variables.type` | **MUST** be a type defined below in the `type` section |
+| `variables.description` | A description of how this variable is used in the program |
+
+### Variables
+
+A variable in the program **MUST** be start with `TMPL_`
+
+#### Types
+
+All non-reference ABI types **MUST** be supported by the client. ABI values **MUST** be encoded in base16 (with the leading `0x`) with the following exceptions:
+
+| Type | Description |
+| ---- | ----------- |
+| `address` | 58-character base32 Algorand public address. Typically to be used as an argument to the `addr` opcode. Front-ends **SHOULD** provide a link to the address on an explorer
+| `application` | Application ID. Alias for `uint64`. Front-ends **SHOULD** provide a link to the app on an explorer |
+| `asset` | Asset ID. Alias for `uint64`. Front-ends **SHOULD** provide a link to the asset on an explorer |
+| `string` | UTF-8 string. Typically used as an argument to `byte`, `method`, or a branching opcode.
+| `hex` | base16 encoding of binary data. Typically used as an argument to `byte`. **MUST** be prefixed with `0x` |
+
+For all other value, front-ends **MUST** decode the ABI value to display the human-readable value to the user.
+
+### Input Validation
+
+All ABI values **MUST** be encoded as base16 and prefixed with `0x`, with the exception of `uint64` which should be provided as an integer.
+
+String values **MUST NOT** include any unescaped `"` to ensure there is no TEAL injection.
+
+All values **MUST** be validated to ensure they are encoded properly. This includes the following checks:
+
+* An `address` value must be a valid Algorand address
+* A `uint64`, `application`, or `asset` value must be a valid unsigned 64-bit integer
+
+### Unique Identification
+
+To enable unique identification of a description, clients **MUST** calculate the SHA256 hash of the JSON description canonicalized in accordance with <a href="https://www.rfc-editor.org/rfc/rfc8785">RFC 8785</a>.
+
+### WalletConnect Method
+
+For wallets to support this ARC, they need to support the a `algo_templatedLsig` method.
+
+The method expects three parameters described by the interface below
+
+```ts
+interface TemplatedLsigParams {
+    /** The canoncalized ARC47 templated lsig JSON as described in this ARC */
+    arc47: string
+    /** The values of the templated variables, if there are any */
+    values?: {[variable: string]: string | number}
+    /** The hash of the expected program. Wallets should compile the lsig with the given values to verify the program hash matches */
+    hash: string
+}
+```
+
+## Rationale
+
+This provides a way for frontends to clearly display to the user what is being signed when signing a logic signature.
+
+Template variables must be immediate arguments. Otherwise a string variable could specify the opcode in the program, which could have unintended and unclear consequences.
+
+`TMPL_` prefix is used to align with existing template variable tooling.
+
+Hashing canonicalized JSON is useful for ensuring clients, such as wallets, can create a allowlist of templated logic signatures.
+
+## Backwards Compatibility
+N/A
+
+## Test Cases
+N/A
+
+## Reference Implementation
+
+A reference implementation can be found in the`../assets/arc-0047` folder.
+
+[lsig.teal](../assets/arc-0047/lsig.teal) contains the templated TEAL code for a logic signature that allows payments of a specific amount every 25,000 blocks.
+
+[dapp.ts](../assets/arc-0047/dapp.ts) contains a TypeScript script showcasing how a dapp would form a wallet connect request for a templated logic signature.
+
+[wallet.ts](../assets/arc-0047/wallet.ts) contains a TypeScript script showcasing how a wallet would handle a request for signing a templated logic signature.
+
+[validate.ts](../assets/arc-0047/validate.ts) contains a TypeScript script showcasing how one could validate templated TEAL and variable values.
+
+### String Variables
+
+
+#### Invalid: Partial Argument
+```
+#pragma version 9
+byte "Hello, TMPL_NAME"
+```
+
+This is not valid because `TMPL_NAME` is not the full immediate argument.
+
+#### Invalid: Not An Argument
+```
+#pragma version 9
+TMPL_PUSH_HELLO_NAME
+```
+
+This is not valid because `TMPL_PUSH_HELLO_NAME` is not an immediate argument to an opcode.
+
+#### Valid
+```
+#pragma version 9
+byte TMPL_HELLO_NAME
+```
+
+This is valid as `TMPL_HELLO_NAME` is the entire immediate argument of the `byte` opcode. A possible value could be `Hello, AlgoDev`
+
+### Hex Variables
+
+#### Valid
+```
+#pragma version 9
+byte TMPL_DEAD_BEEF
+```
+
+This is valid as `TMPL_DEAD_BEEF` is the full immediate argument to the `byte` opcode. A possible value could be `0xdeadbeef`.
+
+
+## Security Considerations
+It should be made clear that this standard alone does not define how frontends, particularly wallets, should deem a logic signature to be safe. This is a decision made solely by the front-ends as to which logic signatures they allow to be signed. It is **RECOMMENDED** to only support the signing of audited or otherwise trusted logic signatures.
+
+## Copyright
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.