@goplausible/algorand-mcp 3.0.7

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

@@ -0,0 +1,98 @@
+---
+arc: 21
+title: Round based datafeed oracles on Algorand
+description: Conventions for building round based datafeed oracles on Algorand
+author: ori-shem-tov (@ori-shem-tov)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/124
+status: Final
+type: Standards Track
+category: Interface
+sub-category: Application
+created: 2022-03-09
+requires: 4
+---
+
+# Round based datafeed oracles on Algorand
+
+## Abstract
+
+The following document introduces conventions for building round based datafeed oracles on Algorand using the ABI defined in [ARC-4](./arc-0004.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.
+
+An [ARC-21](./arc-0021.md) oracle **MUST** have an associated smart-contract implementaing the ABI interface described below.
+
+### ABI Interface
+
+Round based datafeed oracles allow smart-contracts to get data with relevancy to a specific block number, for example the ALGO price at a specific round.
+
+The associated smart contract **MUST** implement the following ABI interface:
+```json
+{
+  "name": "ARC_0021",
+  "desc": "Interface for a round based datafeed oracle",
+  "methods": [
+    {
+      "name": "get",
+      "desc": "Get data from the oracle for a specific round",
+      "args": [
+        { "type": "uint64", "name": "round", "desc": "The desired round" },
+        { "type": "byte[]", "name": "user_data", "desc": "Optional: Extra data provided by the user. Pass an empty slice if not used." }
+      ],
+      "returns": { "type": "byte[]", "desc": "The oracle's response. If the data doesn't exist, the response is an empty slice." }
+    },
+    {
+      "name": "must_get",
+      "desc": "Get data from the oracle for a specific round. Panics if the data doesn't exist.",
+      "args": [
+        { "type": "uint64", "name": "round", "desc": "The desired round" },
+        { "type": "byte[]", "name": "user_data", "desc": "Optional: Extra data provided by the user. Pass an empty slice if not used." }
+      ],
+      "returns": { "type": "byte[]", "desc": "The oracle's response" }
+    },
+    /** Optional */
+    {
+      "name": "get_closest",
+      "desc": "Get data from the oracle closest to a specified round by searching over past rounds.",
+      "args": [
+        { "type": "uint64", "name": "round", "desc": "The desired round" },
+        { "type": "uint64", "name": "search_span", "desc": "Threshold for number of rounds in the past to search on." }
+        { "type": "byte[]", "name": "user_data", "desc": "Optional: Extra data provided by the user. Pass an empty slice if not used." }
+      ],
+      "returns": { "type": "(uint64,byte[])", "desc": "The closest round and the oracle's response for that round. If the data doesn't exist, the round is set to 0 and the response is an empty slice." }
+    },
+    /** Optional */
+    {
+      "name": "must_get_closest",
+      "desc": "Get data from the oracle closest to a specified round by searching over past rounds. Panics if no data is found within the specified range.",
+      "args": [
+        { "type": "uint64", "name": "round", "desc": "The desired round" },
+        { "type": "uint64", "name": "search_span", "desc": "Threshold for number of rounds in the past to search on." }
+        { "type": "byte[]", "name": "user_data", "desc": "Optional: Extra data provided by the user. Pass an empty slice if not used." }
+      ],
+      "returns": { "type": "(uint64,byte[])", "desc": "The closest round and the oracle's response for that round." }
+    }
+  ]
+}
+```
+
+### Method boundaries
+
+- All of `get`, `must_get`, `get_closest` and `must_get_closest` functions **MUST NOT** use local state.
+- Optional arguments of type `byte[]` that are not used are expected to be passed as an empty byte slice.
+
+## Rationale
+
+The goal of these conventions is to make it easier for smart-contracts to interact with off-chain data sources.
+
+## 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-0022.md

@@ -0,0 +1,75 @@
+---
+arc: 22
+title: Add `read-only` annotation to ABI methods
+description: Convention for creating methods which don't mutate state
+author: ori-shem-tov (@ori-shem-tov)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/125
+status: Final
+type: Standards Track
+category: Interface
+sub-category: Application
+created: 2022-03-16
+requires: 4
+---
+
+# Extend [ARC-4](./arc-0004.md) to add `read-only` annotation to methods
+
+The following document introduces a convention for creating methods (as described in [ARC-4](./arc-0004.md)) which don't mutate state.
+
+## Abstract
+
+The goal of this convention is to allow smart contract developers to distinguish between methods which mutate state and methods which don't by introducing a new property to the `Method` descriptor.
+
+## 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.
+
+### Read-only functions
+
+A `read-only` function is a function with no side-effects. In particular, a `read-only` function **SHOULD NOT** include:
+- local/global state modifications
+- calls to non `read-only` functions
+- inner-transactions
+
+It is **RECOMMENDED** for a `read-only` function to not access transactions in a group or metadata of the group.
+
+> The goal is to allow algod to easily execute `read-only` functions without broadcasting a transaction
+
+In order to support this annotation, the following `Method` descriptor is suggested:
+```typescript
+interface Method {
+  /** The name of the method */
+  name: string;
+  /** Optional, user-friendly description for the method */
+  desc?: string;
+  /** Optional, is it a read-only method (according to ARC-22) */
+  readonly?: boolean
+  /** The arguments of the method, in order */
+  args: Array<{
+    /** The type of the argument */
+    type: string;
+    /** Optional, user-friendly name for the argument */
+    name?: string;
+    /** Optional, user-friendly description for the argument */
+    desc?: string;
+  }>;
+  /** Information about the method's return value */
+  returns: {
+    /** The type of the return value, or "void" to indicate no return value. */
+    type: string;
+    /** Optional, user-friendly description for the return value */
+    desc?: string;
+  };
+}
+```
+## Rationale
+
+## 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-0023.md

@@ -0,0 +1,189 @@
+---
+arc: 23
+title: Sharing Application Information
+description: Append application information to compiled TEAL applications
+author: Stéphane Barroso (@sudoweezy), Fabrice Benhamouda (@fabrice102)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/80
+status: Final
+type: Standards Track
+category: Interface
+sub-category: Application
+created: 2023-01-11
+---
+
+## Abstract
+
+The following document introduces a convention for appending information (stored in various files) to the compiled application's bytes.
+The goal of this convention is to standardize the process of verifying and adding this information.
+The encoded information byte string is `arc23` followed by the IPFS CID v1 of a folder containing the files with the information.
+
+The minimum required file is `contract.json` representing the contract metadata (as described in [ARC-4](arc-0004.md)), and as extended by future potential ARCs).
+
+## 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.
+
+### Files containing Application Information
+
+Application information are represented by various files in a folder that:
+
+* **MUST** contain a file  `contract.json` representing the contract metadata (as described in [ARC-4](arc-0004.md)), and as extended by future potential ARCs).
+* **MAY** contain a file with the basename `application` followed by the extension of the high-level language the application is written in (e.g., `application.py` for PyTeal).
+  > To allow the verification of your contract, be sure to write the version used to compile the file after the import eg: `from pyteal import * #pyteal==0.20.1`
+* **MAY** contain the files `approval.teal` and `clear.teal`, that are the compiled versions of approval and clear program in TEAL.
+    * Note that `approval.teal` will not be able to contain the application information as this would create circularity. If `approval.teal` is provided, it is assumed that the *actual* `approval.teal` that is deployed corresponds to `approval.teal` with the proper `bytecblock` (defined below) appended at the end.
+* **MAY** contain other files as defined by other ARCs.
+
+### CID, Pinning, and CAR of the Application Information
+
+The <a href="https://github.com/multiformats/cid">CID</a> allows to access the corresponding application information files using <a href="https://docs.ipfs.tech/">IPFS</a>.
+
+The CID **MUST**:
+
+* Represent a folder of files, even if only `contract.json` is present.
+    > You may need to use the option `--wrap-with-directory` of `ipfs add`
+* 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`
+
+Since the exact CID depends on the options provided when creating it and of the IPFS software version (if default options are used), for any production application, the folder of files **SHOULD** be published and pinned on IPFS.
+
+> All examples in this ARC assume the use of Kubo IPFS version 0.17.0 with default options apart those explicitly stated.
+
+If the IPFS is not pinned, any production application **SHOULD** provide a <a href="https://ipld.io/specs/transport/car/carv1">Content Address Archiver (CAR)</a>( file of the folder, obtained using `ipfs dag export`.
+
+For public networks (e.g., MainNet, TestNet, BetaNet), block explorers and wallets (that support this ARC) **SHOULD** try to recover application information files from IPFS, and if not possible, **SHOULD** allow developers to upload a CAR file.
+If a CAR file is used, these tools **MUST** validate the CAR file matches the CID.
+
+For development purposes, on private networks, the application information files **MAY** be instead provided as a .zip or .tar.gz containing at the root all the required files.
+Block explorers and wallets for *private* networks **MAY** allow uploading the application information as a .zip or .tar.gz.
+They still **SHOULD** validate the files.
+
+> The validation of .zip or .tar.gz files will work if the same version of the IPFS software is used with the same option. Since for development purposes, the same machine is normally used to code the dApp and run the block explorer/wallet, this is most likely not an issue.
+> However, for production purposes, we cannot assume the same IPFS software is used and a CAR file is the best solution to ensure that the application information files will always be available and possible to validate.
+
+> Example: For the example stored in `/asset/arc-0023/application_information`, the CID is `bafybeiavazvdva6uyxqudfsh57jbithx7r7juzvxhrylnhg22aeqau6wte`, which can be obtained with the command:
+>
+> ```
+> ipfs add --cid-version=1 --hash=sha2-256 --recursive --quiet --wrap-with-directory --only-hash application_information
+> ```
+
+
+### Associated Encoded Information Byte String
+
+The (encoded) information byte string is `arc23` concatenated to the 36 bytes of the binary CID.
+
+The information byte string is always 41-byte long and always start, in hexadecimal with `0x6172633233` (corresponding to `arc23`).
+
+> Example: for the above CID `bafybeiavazvdva6uyxqudfsh57jbithx7r7juzvxhrylnhg22aeqau6wte`, the binary CID corresponds to the following hexadecimal value:
+>
+> ```
+> 0x0170122015066a3a83d4c5e1419647efd2144cf7fc7e9a66b73c70b69cdad0090053d699
+> ```
+>
+> and hence the encoded information byte string has the following hexadecimal value:
+>
+> ```
+> 0x61726332330170122015066a3a83d4c5e1419647efd2144cf7fc7e9a66b73c70b69cdad0090053d699
+> ```
+
+### Inclusion of the Encoded Information Byte String in Programs
+
+The encoded information byte string is included in the *approval program* of the application via a <a href="https://developer.algorand.org/docs/get-details/dapps/avm/teal/opcodes/#bytecblock-bytes">`bytecblock`</a> with a unique byte string equal to the encoding information byte string.
+
+> For the example above, the `bytecblock` is:
+>
+> ```
+> bytecblock 0x61726332330170122015066a3a83d4c5e1419647efd2144cf7fc7e9a66b73c70b69cdad0090053d699
+> ```
+>
+> and when compiled this gives the following byte string (at least with TEAL v8 and before):
+>
+> ```
+> 0x26012961726332330170122015066a3a83d4c5e1419647efd2144cf7fc7e9a66b73c70b69cdad0090053d699
+> ```
+
+The size of the compiled application plus the bytecblock **MUST** be, at most, the maximum size of a compiled application according to the latest consensus parameters supported by the compiler.
+
+> At least with TEAL v8 and before, appending the `bytecblock` to the end of the program should add exactly 44 bytes (1 byte for opcode `bytecblock`, 1 byte for 0x01 -the number of byte strings-, 1 byte for 0x29 the length of the encoded information byte string, 41 byte for the encodedin information byte string)
+
+The `bytecblock` **MAY** be placed anywhere in the TEAL source code as long as it does not modify the semantic of the TEAL source code.
+However, if `approval.teal` is provided as an application information file, the `bytecblock` **SHOULD** be the last opcode of the deployed TEAL program.
+
+Developers **MUST** check that, when adding the `bytecblock` to their program, semantic is not changed.
+
+> At least with TEAL v8 and before, adding a `bytecblock` opcode at the end of the approval program does not change the semantics of the program, as long as opcodes are correctly aligned, there is no jump after the last position (that would make the program fail without `bytecblock`), and there is enough space left to add the opcode, at least with TEAL v8 and before.
+> However, though very unlikely, future versions of TEAL may not satisfy this property.
+
+The `bytecblock` **MUST NOT** contain any additional byte string beyond the encoded information byte string.
+
+> For example, the following `bytecblock` is **INVALID**:
+>
+> ```
+> bytecblock 0x61726332330170122015066a3a83d4c5e1419647efd2144cf7fc7e9a66b73c70b69cdad0090053d699 0x42
+> ```
+
+### Retrieval the Encoded Information Byte String and CID from Compiled TEAL Programs
+
+For programs until TEAL v8, a way to find the encoded information byte string is to search for the prefix:
+
+```
+0x2601296172633233
+```
+
+which is then followed by the 36 bytes of the binary CID.
+
+Indeed, this prefix is composed of:
+
+* 0x26, the `bytecblock` opcode
+* 0x01, the number of byte strings provided in the `bytecblock`
+* 0x29, the length of the encoded information byte string
+* 0x6172633233, the hexadecimal of `arc23`
+
+Software retrieving the encoded information byte string **SHOULD** check the TEAL version and only perform retrieval for supported TEAL version.
+They also **SHOULD** gracefully handle false positives, that is when the above prefix is found multiple times.
+One solution is to allow multiple possible CID for a given compiled program.
+
+Note that opcode encoding may change with the TEAL version (though this did not happen up to TEAL v8 at least).
+If the `bytecblock` opcode encoding changes, software that extract the encoded information byte string from compiled TEAL programs **MUST** be updated.
+
+## Rationale
+
+By appending the IPFS CID of the folder containing information about the Application, any user with access to the blockchain could easily verify the Application and the ABI of the Application and interact with it.
+
+Using IPFS has several advantages:
+
+* Allows automatic retrievel of the application information when pinned.
+* Allows easy archival using CAR.
+* Allows support of multiple files.
+
+## Reference Implementation
+
+The following codes are not audited and are only here for information purposes.
+
+Here is an example of a python script that can generate the hash and append it to the compiled application, according this ARC:
+[main.py](../assets/arc-0023/main.py).
+
+A Folder containing:
+- example of the application [application.py](../assets/arc-0023/application_information/application.py).
+- example of the contract metadata that follow [ARC-4](arc-0004.md) [contract.json](../assets/arc-0023/application_information/contract.json).
+
+Files are accessible through followings IPFS command:
+```console
+$ ipfs cat bafybeiavazvdva6uyxqudfsh57jbithx7r7juzvxhrylnhg22aeqau6wte/contract.json
+$ ipfs cat bafybeiavazvdva6uyxqudfsh57jbithx7r7juzvxhrylnhg22aeqau6wte/application.py
+```
+> If they are not accessible be sure to removed [--only-hash | -n] from your command or check you ipfs node.
+
+## Security Considerations
+
+CIDs are unique; however, related files **MUST** be checked to ensure that the application conforms.
+An `arc-23` CID added at the end of an application is here to share information, not proof of anything.
+In particular, nothing ensures that a provided `approval.teal` matches the actual program on chain.
+
+## 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-0025.md

@@ -0,0 +1,241 @@
+---
+arc: 25
+title: Algorand WalletConnect v1 API
+description: API for communication between Dapps and wallets using WalletConnect
+author: JasonPaulos (@jasonpaulos)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/104
+status: Final
+type: Standards Track
+category: Interface
+sub-category: Wallet
+created: 2022-05-12
+---
+
+# Algorand WalletConnect v1 API
+
+This document specifies a standard API for communication between Algorand decentralized applications and wallets using the WalletConnect v1 protocol.
+
+## Abstract
+
+WalletConnect https://walletconnect.com/ is an open protocol to communicate securely between mobile wallets and decentralized applications (dApps) using QR code scanning (desktop) or deep linking (mobile). It’s main use case allows users to sign transactions on web apps using a mobile wallet.
+
+This document aims to establish a standard API for using the WalletConnect v1 protocol on Algorand, leveraging the existing transaction signing APIs defined in [ARC-1](./arc-0001.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.
+
+It is strongly recommended to read and understand the entirety of [ARC-1](./arc-0001.md) before reading this ARC.
+
+### Overview
+
+This overview section is non-normative. It offers a brief overview of the WalletConnect v1 lifecycle. A more in-depth description can be found in the WalletConnect v1 documentation https://docs.walletconnect.com/tech-spec .
+
+In order for a dApp and wallet to communicate using WalletConnect, a WalletConnect session must be established between them. The dApp is responsible for initiating this session and producing a session URI, which it will communicate to the wallet, typically in the form of a QR code or a deep link. This processed is described in the [Session Creation](#session-creation) section.
+
+Once a session is established between a dApp and a wallet, the dApp is able to send requests to the wallet. The wallet is responsible for listening for requests, performing the appropriate actions to fulfill requests, and sending responses back to the dApp with the results of requests. This process is described in the [Message Schema](#message-schema) section.
+
+### Session Creation
+
+The dApp is responsible for initializing a WalletConnect session and producing a WalletConnect URI that communicates the necessary session information to the wallet. This process is as described in the WalletConnect documentation https://docs.walletconnect.com/tech-spec#requesting-connection, with one addition. In order for wallets to be able to easily and immediately recognize an Algorand WalletConnect session, dApps **SHOULD** add an additional URI query parameter to the WalletConnect URI. If present, the name of this parameter **MUST** be `algorand` and its value **MUST** be `true`. This query parameter can appear in any order relative to the other query parameters in the URI.
+
+> For example, here is a standard WalletConnect URI:
+> ```
+> wc:4015f93f-b88d-48fc-8bfe-8b063cc325b6@1?bridge=https%3A%2F%2F9.bridge.walletconnect.org&key=b0576e0880e17f8400bfff92d4caaf2158cccc0f493dcf455ba76d448c9b5655
+> ```
+> And here is that same URI with the Algorand-specific query parameter:
+> ```
+> wc:4015f93f-b88d-48fc-8bfe-8b063cc325b6@1?bridge=https%3A%2F%2F9.bridge.walletconnect.org&key=b0576e0880e17f8400bfff92d4caaf2158cccc0f493dcf455ba76d448c9b5655&algorand=true
+> ```
+
+It is **RECOMMENDED** that dApps include this query parameter, but it is not **REQUIRED**. Wallets **MAY** reject sessions if the session URI does not contain this query parameter.
+
+#### Chain IDs
+
+WalletConnect v1 sessions are associated with a numeric chain ID. Since Algorand chains do not have numeric identifiers (instead, the genesis hash or ID is used for this purpose), this document defines the following chain IDs for the Algorand ecosystem:
+
+* MainNet (genesis hash `wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=`): 416001
+* TestNet (genesis hash `SGO1GKSzyE7IEPItTxCByw9x8FmnrCDexi9/cOUJOiI=`): 416002
+* BetaNet (genesis hash `mFgazF+2uRS1tMiL9dsj01hJGySEmPN28B/TjjvpVW0=`): 416003
+
+At the time of writing, these chain IDs do not conflict with any known chain that also uses WalletConnect. In the unfortunate event that this were to happen, the `algorand` query parameter discussed above would be used to differentiate Algorand chains from others.
+
+Future Algorand chains, if introduced, **MUST** be assigned new chain IDs.
+
+Wallets and dApps **MAY** support all of the above chain IDs or only a subset of them. If a chain ID is presented to a wallet or dApp that does not support that chain ID, they **MUST** terminate the session.
+
+For compatibility with WalletConnect usage prior to this ARC, the following catch-all chain ID is also defined:
+
+* All Algorand Chains (legacy value): 4160
+
+Wallets and dApps **SHOULD** support this chain ID as well for backwards compatibility. Unfortunately this ID alone is not enough to identify which Algorand chain is being used, so extra fields in message requests (i.e. the genesis hash field in a transaction to sign) **SHOULD** be consulted as well to determine this.
+
+### Message Schema
+
+Note: interfaces are defined in TypeScript. These interfaces are designed to be serializable to and from valid JSON objects.
+
+The WalletConnect message schema is a set of JSON-RPC 2.0 https://www.jsonrpc.org/specification requests and responses. Decentralized applications will send requests to the wallets and will receive responses as JSON-RPC messages. All requests **MUST** adhere to the following structure:
+
+```typescript
+interface JsonRpcRequest {
+  /**
+   * An identifier established by the Client. Numbers SHOULD NOT contain fractional parts.
+   */
+  id: number;
+  /**
+   * A String specifying the version of the JSON-RPC protocol. MUST be exactly "2.0".
+   */
+  jsonrpc: "2.0";
+  /**
+   * A String containing the name of the RPC method to be invoked.
+   */
+  method: string;
+  /**
+   * A Structured value that holds the parameter values to be used during the invocation of the method.
+   */
+  params: any[];
+}
+```
+
+The Algorand WalletConnect schema consists of a single RPC method, `algo_signTxn`, as described in the following section.
+
+All responses, whether successful or unsuccessful, **MUST** adhere to the following structure:
+
+```typescript
+interface JsonRpcResponse {
+  /**
+   * This member is REQUIRED.
+   * It MUST be the same as the value of the id member in the Request Object.
+   * If there was an error in detecting the id in the Request object (e.g. Parse error/Invalid Request), it MUST be Null.
+   */
+  id: number;
+  /**
+   * A String specifying the version of the JSON-RPC protocol. MUST be exactly "2.0".
+   */
+  jsonrpc: "2.0";
+  /**
+   * This member is REQUIRED on success.
+   * This member MUST NOT exist if there was an error invoking the method.
+   * The value of this member is determined by the method invoked on the Server.
+   */
+  result?: any;
+  /**
+   * This member is REQUIRED on error.
+   * This member MUST NOT exist if the requested method was invoked successfully.
+   */
+  error?: JsonRpcError;
+}
+
+interface JsonRpcError {
+  /**
+   * A Number that indicates the error type that occurred.
+   * This MUST be an integer.
+   */
+  code: number;
+  /**
+   * A String providing a short description of the error.
+   * The message SHOULD be limited to a concise single sentence.
+   */
+  message: string;
+  /**
+   * A Primitive or Structured value that contains additional information about the error.
+   * This may be omitted.
+   * The value of this member is defined by the Server (e.g. detailed error information, nested errors etc.).
+   */
+  data?: any;
+}
+```
+
+#### `algo_signTxn`
+
+This request is used to ask a wallet to sign one or more transactions in one or more atomic groups.
+
+##### Request
+
+This request **MUST** adhere to the following structure:
+
+```typescript
+interface AlgoSignTxnRequest {
+  /**
+   * As described in JsonRpcRequest.
+   */
+  id: number;
+  /**
+   * As described in JsonRpcRequest.
+   */
+  jsonrpc: "2.0";
+  /**
+   * The method to invoke, MUST be "algo_signTxn".
+   */
+  method: "algo_signTxn";
+  /**
+   * Parameters for the transaction signing request.
+   */
+  params: SignTxnParams;
+}
+
+/**
+ * The first element is an array of `WalletTransaction` objects which contain the transaction(s) to be signed.
+ * If transactions from an atomic transaction group are being signed, then all transactions in the group (even the ones not being signed by the wallet) MUST appear in this array.
+ *
+ * The second element, if present, contains addition options specified with the `SignTxnOpts` structure.
+ */
+type SignTxnParams = [WalletTransaction[], SignTxnOpts?];
+```
+
+> `SignTxnParams` is a tuple with an optional element https://www.typescriptlang.org/docs/handbook/release-notes/typescript-3-0.html#optional-elements-in-tuple-types, meaning its length can be 1 or 2.
+
+The [`WalletTransaction`](./arc-0001.md#interface-wallettransaction) and [`SignTxnOpts`](./arc-0001.md#interface-signtxnsopts) types are defined in [ARC-1](./arc-0001.md).
+
+All specifications, restrictions, and guidelines declared in ARC-1 for these types apply to their usage here as well. Additionally, all security requirements and restrictions for processing transaction signing requests from ARC-1 apply to this request as well.
+
+> For more information, see [ARC-1 - Syntax and Interfaces](./arc-0001.md#syntax-and-interfaces) and [ARC-1 - Semantic and Security Requirements](./arc-0001.md#semantic-and-security-requirements).
+
+##### Response
+
+To respond to a request, the wallet **MUST** send back the following response object:
+
+```typescript
+interface AlgoSignTxnResponse {
+  /**
+   * As described in JsonRpcResponse.
+   */
+  id: number;
+  /**
+   * As described in JsonRpcResponse.
+   */
+  jsonrpc: "2.0";
+  /**
+   * An array containing signed transactions at specific indexes.
+   */
+  result?: Array<SignedTxnStr | null>;
+  /**
+   * As described in JsonRpcResponse.
+   */
+  error?: JsonRpcError;
+}
+```
+
+[`SignedTxnStr`](./arc-0001.md#interface-signedtxnstr) type is defined in [ARC-1](./arc-0001.md).
+
+
+In this response, `result` **MUST** be an array with the same length as the number of `WalletTransaction`s in the request (i.e. `<AlgoSignTxnRequest instance>.params[0].length`). For every integer `i` such that `0 <= i < result.length`:
+
+* If the transaction at index `i` in the group should be signed by the wallet (i.e. `<AlgoSignTxnRequest instance>.params[0][i].signers` is not an empty array): `result[i]` **MUST** be a base64-encoded string containing the msgpack-encoded signed transaction `params[0][i].txn`.
+* Otherwise: `result[i]` **MUST** be `null`, since the wallet was not requested to sign this transaction.
+
+If the wallet does not approve signing every transaction whose signature is being requested, the request **MUST** fail.
+
+All request failures **MUST** use the error codes defined in [ARC-1 - Error Standards](./arc-0001.md#error-standards).
+
+## Rationale
+
+## Security Considerations
+
+None.
+
+## Copyright
+
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.