@goplausible/algorand-mcp 3.0.7

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

@@ -0,0 +1,90 @@
+---
+arc: 5
+title: Wallet Transaction Signing API (Functional)
+description: An API for a function used to sign a list of transactions.
+author: DanBurton (@DanBurton)
+discussions-to: https://github.com/algorandfoundation/ARCs/issues/52
+status: Final
+type: Standards Track
+category: Interface
+sub-category: Wallet
+created: 2021-08-09
+---
+
+# Algorand Wallet Transaction Signing API (Functionality Only)
+
+> This ARC is intended to be completely compatible with [ARC-1](./arc-0001.md).
+
+## Abstract
+
+ARC-1 defines a standard for signing transactions with security in mind. This proposal is a strict subset of ARC-1 that outlines only the minimum functionality required in order to be useable.
+
+Wallets that conform to ARC-1 already conform to this API.
+
+Wallets conforming to [ARC-5](./arc-0005.md) but not ARC-1 **MUST** only be used for testing purposes and **MUST NOT** used on MainNet.
+This is because this ARC-5 does not provide the same security guarantees as ARC-1 to protect properly wallet users.
+
+## 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.
+
+### Interface `SignTxnsFunction`
+
+Signatures are requested by calling a function `signTxns(txns)` on a list `txns` of transactions. The dApp may also provide an optional parameter `opts`.
+
+A wallet transaction signing function `signTxns` is defined by the following interface:
+```ts
+export type SignTxnsFunction = (
+   txns: WalletTransaction[],
+   opts?: SignTxnsOpts,
+)
+   => Promise<(SignedTxnStr | null)[]>;
+```
+* `SignTxnsOpts` is as specified by [ARC-1](./arc-0001.md#interface-signtxnsopts).
+* `SignedTxnStr` is as specified by [ARC-1](./arc-0001.md#interface-signedtxnstr).
+
+A `SignTxnsFunction`:
+* expects `txns` to be in the correct format as specified by `WalletTransaction`.
+
+### Interface `WalletTransaction`
+
+```ts
+export interface WalletTransaction {
+   /**
+    * Base64 encoding of the canonical msgpack encoding of a Transaction.
+    */
+   txn: string;
+}
+```
+
+### Semantic requirements
+
+* The call `signTxns(txns, opts)` **MUST** either throw an error or return an array `ret` of the same length as the `txns` array.
+* Each element of `ret` **MUST** be a valid `SignedTxnStr` with the underlying transaction exactly matching `txns[i].txn`.
+
+This ARC uses interchangeably the terms "throw an error" and "reject a promise with an error".
+
+`signTxns` **SHOULD** follow the error standard specified in [ARC-0001](./arc-0001.md#error-standards).
+
+### UI requirements
+
+Wallets satisfying this ARC but not [ARC-0001](./arc-0001.md) **MUST** clearly display a warning to the user that they **MUST** not be used with real funds on MainNet.
+
+## Rationale
+
+This simplified version of ARC-0001 exists for two main reasons:
+
+1. To outline the minimum amount of functionality needed in order to be useful.
+2. To serve as a stepping stone towards full ARC-0001 compatibility.
+
+While this ARC **MUST** not be used by users with real funds on MainNet for security reasons, this simplified API sets a lower bar and acts as a signpost for which wallets can even be used at all.
+
+## 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-0006.md

@@ -0,0 +1,202 @@
+---
+arc: 6
+title: Algorand Wallet Address Discovery API
+description: API function, enable, which allows the discovery of accounts
+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 Address Discovery API
+
+## Abstract
+
+A function, `enable`, which allows the discovery of accounts.
+Optional functions, `enableNetwork` and `enableAccounts`, which handle the multiple capabilities of `enable` separately.
+This document requires nothing else, but further semantic meaning is prescribed to these functions in [ARC-0010](arc-0010.md#semantic-requirements) which builds off of this one and a few others.
+The caller of this function is usually a dApp.
+
+## 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.
+
+### Interface `EnableFunction`
+
+```ts
+export type AlgorandAddress = string;
+export type GenesisHash = string;
+
+export type EnableNetworkFunction = (
+  opts?: EnableNetworkOpts
+) => Promise<EnableNetworkResult>;
+
+export type EnableAccountsFunction = (
+  opts?: EnableAccountsOpts
+) => Promise<EnableAccountsResult>;
+
+export type EnableFunction = (
+  opts?: EnableOpts
+) => Promise<EnableResult>;
+
+export type EnableOpts = (
+  EnableNetworkOpts & EnableAccountsOpts
+);
+
+export interface EnableNetworkOpts {
+  genesisID?: string;
+  genesisHash?: GenesisHash;
+};
+
+export interface EnableAccountsOpts {
+  accounts?: AlgorandAddress[];
+};
+
+
+export type EnableResult = (
+  EnableNetworkResult & EnableAccountsResult
+);
+
+export interface EnableNetworkResult {
+  genesisID: string;
+  genesisHash: GenesisHash;
+}
+
+export interface EnableAccountsResult {
+  accounts: AlgorandAddress[];
+}
+
+export interface EnableError extends Error {
+  code: number;
+  data?: any;
+}
+```
+
+An `EnableFunction` with optional input argument `opts:EnableOpts` **MUST** return a value `ret:EnableResult` or **MUST** throw an exception object of type `EnableError`.
+
+#### String specification: `GenesisID` and `GenesisHash`
+
+A `GenesisID` is an ascii string
+
+A `GenesisHash` is base64 string representing a 32-byte genesis hash.
+
+#### String specification: `AlgorandAddress`
+
+Defined as in [ARC-0001](./arc-0001.md#interface-algorandaddress):
+
+> An Algorand address is represented by a 58-character base32 string. It includes includes the checksum.
+
+#### Error Standards
+
+`EnableError` follows the same rules as `SignTxnsError` from [ARC-0001](./arc-0001.md#error-interface-signtxnserror) and uses the same status error codes.
+
+### Interface `WalletAccountManager`
+```ts
+export interface WalletAccountManager {
+  switchAccount: (addr: AlgorandAddress) => Promise<void>
+  switchNetwork: (genesisID: string) => Promise<void>
+  onAccountSwitch: (hook: (addr: AlgorandAddress) => void)
+  onNetworkSwitch: (hook: (genesisID: string, genesisHash: GenesisHash) => void)
+}
+```
+
+Wallets SHOULD expose `switchAccount` function to allow an app to switch an account to another one managed by the wallet. The `switchAccount` function should return a promise which will be fulfilled when the wallet will effectively switch an account.
+The function must thrown an `Error` exception when the wallet can't execute the switch (for example, the provided address is not managed by the wallet or when the address is not a valid Algorand address).
+
+Similarly, wallets SHOULD expose `switchNetwork` function to instrument a wallet to switch to another network.
+The function must thrown an `Error` exception when the wallet can't execute the switch (for example, when the provided genesis ID is not recognized by the wallet).
+
+Very often, webapp have their own state with information about the user (provided by the account address) and a network. For example, a webapp can list all compatible Smart Contracts for a given network.
+For descent integration with a wallet, we must be able to react in a webapp on the account and network switch from the wallet interface. For that we define 2 functions which MUST be exposed by wallets: `onAccountSwitch` and `onNetworkSwitch`. These function will register a hook and will call it whenever a user switches respectively an account or network from the wallet interface.
+
+### Semantic requirements
+
+This ARC uses interchangeably the terms "throw an error" and "reject a promise with an error".
+
+#### First call to `enable`
+
+Regarding a first call by a caller to `enable(opts)` or `enable()` (where `opts` is `undefined`), with potential promised return value `ret`:
+
+When `genesisID` and/or `genesisHash` is specified in `opts`:
+
+- The call `enable(opts)` **MUST** either throw an error or return an object `ret` where `ret.genesisID` and `ret.genesisHash` match `opts.genesisID` and `opts.genesisHash` (i.e., `ret.genesisID` is identical to `opts.genesisID` if `opts.genesisID` is specified, and `ret.genesisHash` is identical to `opts.genesisHash` if `opts.genesisHash` is specified).
+- The user **SHOULD** be prompted for permission to acknowledge control of accounts on that specific network (defined by `ret.genesisID` and `ret.genesisHash`).
+- In the case only `opts.genesisID` is provided, several networks may match this ID and the user **SHOULD** be prompted to select the network they wish to use.
+
+When neither `genesisID` nor `genesisHash` is specified in `opts`:
+
+- The user **SHOULD** be prompted to select the network they wish to use.
+- The call `enable(opts)` **MUST** either throw an error or return an object `ret` where `ret.genesisID` and `ret.genesisHash` **SHOULD** represent the user's selection of network.
+- The function **MAY** throw an error if it does not support user selection of network.
+
+When `accounts` is specified in `opts`:
+
+- The call `enable(opts)` **MUST** either throw an error or return an object `ret` where `ret.accounts` is an array that starts with all the same elements as `opts.accounts`, in the same order.
+- The user **SHOULD** be prompted for permission to acknowledge their control of the specified accounts. The wallet **MAY** allow the user to provide more accounts than those listed. The wallet **MAY** allow the user to select fewer accounts than those listed, in which the wallet **MUST** return an error which **SHOULD** be a user rejected error and contain the rejected accounts in `data.accounts`.
+
+When `accounts` is not specified in `opts`:
+
+- The user **SHOULD** be prompted to select the accounts they wish to reveal on the selected network.
+- The call `enable(opts)` **MUST** either throw an error or return an object `ret` where `ret.accounts` is a empty or non-empty array.
+- If `ret.accounts` is not empty, the caller **MAY** assume that `ret.accounts[0]` is the user's "currently-selected" or "default" account, for DApps that only require access to one account.
+
+> Empty `ret.accounts` array are used to allow a DApp to get access to an Algorand node but not to signing capabilities.
+
+#### Network
+
+In addition to the above rules, in all cases, if `ret.genesisID` is one of the official network `mainnet-v1.0`, `testnet-v1.0`, or `betanet-v1.0`, `ret.genesisHash` **MUST** match the genesis hash of those networks
+
+| Genesis ID     | Genesis Hash                                   |
+| -------------- | ---------------------------------------------- |
+| `mainnet-v1.0` | `wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=` |
+| `testnet-v1.0` | `SGO1GKSzyE7IEPItTxCByw9x8FmnrCDexi9/cOUJOiI=` |
+| `betanet-v1.0` | `mFgazF+2uRS1tMiL9dsj01hJGySEmPN28B/TjjvpVW0=` |
+
+When using a genesis ID that is not one of the above, the caller **SHOULD** always provide a `genesisHash`.
+This is because a `genesisID` does not uniquely define a network in that case.
+If a caller does not provide a `genesisHash`, multiple calls to `enable` may return a different network with the same `genesisID` but a different `genesisHash`.
+
+#### Identification of the caller
+
+The `enable` function **MAY** remember the choices of the user made by a specific caller and use them everytime the same caller calls the function.
+The function **MUST** ensure that the caller can be securely identified.
+In particular, by default, the function **MUST NOT** allow webapps on the http protocol to call it, as such webapps can easily be modified by a man-in-the-middle attacker.
+In the case of callers that are https websites, the caller **SHOULD** be identified by its fully qualified domain name.
+
+The function **MAY** offer the user some "developer mode" or "advanced" options to allow calls from insecure dApps.
+In that case, the fact that the caller is insecure and/or the fact that the wallet in "developer mode" **MUST** be clearly displayed by the wallet.
+
+#### Multiple calls to `enable`
+
+The same caller **MAY** call multiple time the `enable` function.
+When the caller is a dApp, every time a dApp is refreshed, it actually **SHOULD** call the `enable()` function.
+
+The `enable` function **MAY NOT** return the same value every time it is called, even when called with the exact same argument `opts`.
+The caller **MUST NOT** assume that the `enable` function will always return the same value, and **MUST** properly handle changes of available accounts and/or changes of network.
+
+For example, a user may want to change network or accounts for a dApp.
+That is why, upon refresh, the dApp **SHOULD** automatically switch network and perform all required changes.
+Examples of required changes include but are not limited to change of the list of accounts, change of statuses of the account (e.g., opted in or not), change of the balances of the accounts.
+
+### `enableNetwork` and `enableAccounts`
+
+It may be desirable for a dapp to perform network queries prior to requesting that the user enable an account for use with the dapp. Wallets may provide the functionality of `enable` in two parts: `enableNetwork` for network discovery, and `enableAccounts` for account discovery, which together are the equivalent of calling `enable`.
+
+## Rationale
+
+This API puts power in the user's hands to choose a preferred network and account to use when interacting with a dApp.
+
+It also allows dApp developers to suggest a specific network, or specific accounts, as appropriate.
+The user still maintains the ability to reject the dApp's suggestions, which corresponds to rejecting the promise returned by `enable()`.
+
+## 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-0007.md

@@ -0,0 +1,113 @@
+---
+arc: 7
+title: Algorand Wallet Post Transactions API
+description: API function to Post Signed Transactions to the network.
+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 Post Transactions API
+
+## Abstract
+
+A function, `postTxns`, which accepts an array of `SignedTransaction`s, and posts them to the network.
+
+## 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.
+
+This ARC uses interchangeably the terms "throw an error" and "reject a promise with an error".
+
+### Interface `PostTxnsFunction`
+
+```ts
+export type TxnID = string;
+export type SignedTxnStr = string;
+
+export type PostTxnsFunction = (
+  stxns: SignedTxnStr[],
+) => Promise<PostTxnsResult>;
+
+export interface PostTxnsResult {
+  txnIDs: TxnID[];
+}
+
+export interface PostTxnsError extends Error {
+  code: number;
+  data?: any;
+  successTxnIDs: (TxnID | null)[];
+}
+```
+
+A `PostTxnsFunction` with input argument `stxns:string[]` and promised return value `ret:PostTxnsResult`:
+* expects `stxns` to be in the correct string format as specified by `SignedTxnStr` (defined below).
+* **MUST**, if successful, return an object `ret` such that `ret.txID` is in the correct string format as specified by `TxID`.
+
+> The use of `txID` instead of `txnID` is to follow the standard name for the transaction ID.
+
+### String specification: `SignedTxnStr`
+
+Defined as in [ARC-0001](./arc-0001.md#interface-signedtxnstr):
+
+> [`SignedTxnStr` is] the base64 encoding of the canonical msgpack encoding of the `SignedTxn` corresponding object, as defined in the <a href="https://github.com/algorandfoundation/specs">Algorand specs</a>.
+
+### String specification: `TxnID`
+
+A `TxnID` is a 52-character base32 string (without padding) corresponding to a 32-byte string.
+For example: `H2KKVITXKWL2VBZBWNHSYNU3DBLYBXQAVPFPXBCJ6ZZDVXQPSRTQ`.
+
+### Error standard
+
+`PostTxnsError` follows the same rules as `SignTxnsError` from [ARC-0001](./arc-0001.md#error-interface-signtxnserror) and uses the same status codes as well as the following status codes:
+
+
+| Status Code | Name | Description |
+| ----------- | ---- | ----------- |
+| 4400 | Failure Sending Some Transactions | Some transactions were not sent properly. |
+
+### Semantic requirements
+
+Regarding a call to `postTxns(stxns)` with promised return value `ret`:
+
+* `postTxns` **MAY** assume that `stxns` is an array of valid `SignedTxnStr` strings that represent correctly signed transactions such that:
+  * Either all transaction belong to the same group of transactions and are in the correct order. In other words, either `stxns` is an array of a single transaction with a zero group ID (`txn.Group`), or `stxns` is an array of one or more transactions with the *same* non-zero group ID. The function **MUST** reject if the transactions do not match their group ID. (The caller must provide the transactions in the order defined by the group ID.)
+  >An early draft of this ARC required that the size of a group of transactions must be greater than 1 but, since the Algorand protocol supports groups of size 1, this requirement had been changed so dApps don't have to have special cases for single transactions and can always send a group to the wallet.
+  * Or `stxns` is a concatenation of arrays satisfying the above.
+* `postTxns` **MUST** attempt to post all transactions together.  With the `algod` v2 API, this implies splitting the transactions into groups and making an API call per transaction group. `postTxns` **SHOULD NOT** wait after each transaction group but post all of them without pause in-between.
+* `postTxns` **MAY** ask the user whether they approve posting those transactions.
+  > A dApp can always post transactions itself without the help of `postTxns` when a public network is used.
+  > However, when a private network is used, a dApp may need `postTxns`, and in this case, asking the user's approval can make sense.
+  > Another such use case is when the user uses a specific trusted node that has some legal restrictions.
+* `postTxns` **MUST** wait for confirmation that the transactions are finalized.
+  > TODO: Decide whether to add an optional flag to not wait for that.
+* If successful, `postTxns` **MUST** resolve the returned promise with the list of transaction IDs `txnIDs` of the posted transactions `stxn`.
+* If unsuccessful, `postTxns` **MUST** reject the promise with an error `err` of type `PostTxnsError` such that:
+  * `err.code=4400` if there was a failure sending the transactions or a code as specified in [ARC-0001](./arc-0001.md#error-standards) if the user or function disallowed posting the transactions.
+  * `err.message` **SHOULD** describe what went wrong in as much detail as possible.
+  * `err.successTxnIDs` **MUST** be an array such that `err.successTxnID[i]` is the transaction ID of `stxns[i]` if `stxns[i]` was successfully committed to the blockchain, and `null` otherwise.
+
+### Security considerations
+
+In case the wallet uses an API service that is secret or provided by the user, the wallet **MUST** ensure that the URL of the service and the potential tokens/headers are not leaked to the dApp.
+
+> Leakage may happen by accidentally including too much information in responses or errors returned by the various methods. For example, if the Node.JS superagent library is used without filtering errors and responses, errors and responses may include the request object, which includes the potentially secret API service URL / secret token headers.
+
+## Rationale
+
+This API allows DApps to use a user's preferred connection in order to submit transactions to the network.
+
+The user may wish to use a specific trusted node, or a particular paid service with their own secret token. This API protects the user's secrets by not exposing connection details to the DApp.
+
+## 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-0008.md

@@ -0,0 +1,55 @@
+---
+arc: 8
+title: Algorand Wallet Sign and Post API
+description: A function used to simultaneously sign and post transactions to the network.
+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 Sign and Post API
+
+## Abstract
+
+A function `signAndPostTxns`, which accepts an array of `WalletTransaction`s, and posts them to the network.
+
+Accepts the inputs to [ARC-0001](./arc-0001.md#interface-signtxnsfunction)'s / [ARC-0005](./arc-0005.md#interface-signtxnsfunction)'s `signTxns`, and produces the output of [ARC-0007](./arc-0007.md#interface-posttxnsfunction)'s `postTxns`.
+
+## Specification
+
+### Interface `SignAndPostTxnsFunction`
+
+```ts
+export type SignAndPostTxnsFunction = (
+   txns: WalletTransaction[],
+   opts?: any,
+) => Promise<PostTxnsResult>;
+```
+
+* `WalletTransaction` is as specified by [ARC-0005](./arc-0005.md#interface-wallettransaction).
+* `PostTxnsResult` is as specified by [ARC-0007](./arc-0007.md#interface-posttxnsfunction).
+
+Errors are handled exactly as specified by [ARC-0001](./arc-0001.md#error-standards) and [ARC-0007](./arc-0007.md#error-standard)
+
+## Rationale
+
+Allows the user to be sure that what they are signing is in fact all that is being sent. Doesn't necessarily grant the DApp direct access to the signed txns, though they are posted to the network, so they should not be considered private.
+
+Exposing only this API instead of exposing `postTxns` directly is potentially safer for the wallet user, since it only allows the posting of transactions which the user has explicitly approved.
+
+## Security Considerations
+
+In case the wallet uses an API service that is secret or provided by the user, the wallet **MUST** ensure that the URL of the service and the potential tokens/headers are not leaked to the dApp.
+
+> Leakage may happen by accidentally including too much information in responses or errors returned by the various methods. For example, if the nodeJS superagent library is used without filtering errors and responses, errors and responses may include the request object, which includes the potentially secret API service URL / secret token headers.
+
+For dApps using the `signAndPostTxns` function, it is **RECOMMENDED** to display a Waiting/Loading Screen to wait until the transaction is confirmed to prevent potential issues.
+
+> The reasoning is the following: the pop-up/window in which the wallet is showing the waiting/loading screen may disappear in some cases (e.g., if the user clicks away from it). If it disappears, the user may be tempted to perform again the action, causing significant damages.
+
+## 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-0009.md

@@ -0,0 +1,63 @@
+---
+arc: 9
+title: Algorand Wallet Algodv2 and Indexer API
+description: An API for accessing Algod and Indexer through a user's preferred connection.
+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 Algodv2 and Indexer API
+
+## Abstract
+
+Functions `getAlgodv2Client` and `getIndexerClient` which return a `BaseHTTPClient` that can be used to construct an `Algodv2Client` and an `IndexerClient` respectively (from the <a href="https://github.com/algorand/js-algorand-sdk/blob/develop/src/client/baseHTTPClient.ts">JS SDK</a>);
+
+## Specification
+
+### Interface `GetAlgodv2ClientFunction`
+
+```ts
+type GetAlgodv2ClientFunction = () => Promise<BaseHTTPClient>
+```
+
+Returns a promised `BaseHTTPClient` that can be used to then build an `Algodv2Client`, where `BaseHTTPClient` is an interface matching the interface `algosdk.BaseHTTPClient` from the <a href="https://github.com/algorand/js-algorand-sdk/blob/develop/src/client/baseHTTPClient.ts">JS SDK</a>).
+
+### Interface `GetIndexerClientFunction`
+
+```ts
+type GetIndexerClientFunction = () => Promise<BaseHTTPClient>
+```
+
+Returns a promised `BaseHTTPClient` that can be used to then build an `Indexer`, where `BaseHTTPClient` is an interface matching the interface `algosdk.BaseHTTPClient` from the <a href="https://github.com/algorand/js-algorand-sdk/blob/develop/src/client/baseHTTPClient.ts">JS SDK</a>).
+
+### Security considerations
+
+The returned `BaseHTTPClient` **SHOULD** filter the queries made to prevent potential attacks and reject (i.e., throw an exception) if this is not satisfied.
+A non-exhaustive list of checks is provided below:
+* Check that the relative PATH does not contain `..`.
+* Check that the only provided headers are the ones used by the SDK (when this ARC was written: `accept` and `content-type`) and their values are the ones provided by the SDK.
+
+`BaseHTTPClient` **MAY** impose rate limits.
+
+For higher security, `BaseHTTPClient` **MAY** also check the queries with regards to the OpenAPI specification of the node and the indexer.
+
+In case the wallet uses an API service that is secret or provided by the user, the wallet **MUST** ensure that the URL of the service and the potential tokens/headers are not leaked to the dApp.
+
+> Leakage may happen by accidentally including too much information in responses or errors returned by the various methods. For example, if the nodeJS superagent library is used without filtering errors and responses, errors and responses may include the request object, which includes the potentially secret API service URL / secret token headers.
+
+## Rationale
+
+Nontrivial dApps often require the ability to query the network for activity. Algorand dApps written without regard to wallets are likely written using `Algodv2` and `Indexer` from `algosdk`.
+This document allows dApps to instantiate `Algodv2` and `Indexer` for a wallet API service, making it easy for JavaScript dApp authors to port their code to work with wallets.
+
+## 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-0010.md

@@ -0,0 +1,111 @@
+---
+arc: 10
+title: Algorand Wallet Reach Minimum Requirements
+description: Minimum requirements for Reach to function with a given wallet.
+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 Minimum Requirements
+
+## Abstract
+
+An amalgamation of APIs which comprise the minimum requirements for Reach to be able to function correctly with a given wallet.
+
+## Specification
+
+A group of related functions:
+
+* `enable` (**REQUIRED**)
+* `enableNetwork` (**OPTIONAL**)
+* `enableAccounts` (**OPTIONAL**)
+* `signAndPostTxns` (**REQUIRED**)
+* `getAlgodv2Client` (**REQUIRED**)
+* `getIndexerClient` (**REQUIRED**)
+* `signTxns` (**OPTIONAL**)
+* `postTxns` (**OPTIONAL**)
+
+* `enable`: as specified in [ARC-0006](./arc-0006.md#interface-enablefunction).
+* `signAndPostTxns`: as specified in [ARC-0008](./arc-0008.md#interface-signandposttxnsfunction).
+* `getAlgodv2Client` and `getIndexerClient`: as specified in [ARC-0009](./arc-0009.md#specification).
+* `signTxns`: as specified in [ARC-0005](./arc-0005.md#interface-signtxnsfunction) / [ARC-0001](./arc-0001.md#interface-signtxnsfunction).
+* `postTxns`: as specified in [ARC-0007](./arc-0007.md#interface-posttxnsfunction).
+
+There are additional semantics for using these functions together.
+
+### Semantic Requirements
+
+* `enable` **SHOULD** be called before calling the other functions and upon refresh of the dApp.
+* Calling `enableNetwork` and then `enableAccounts` **MUST** be equivalent to calling `enable`.
+* If used instead of `enable`: `enableNetwork` **SHOULD** be called before `enableAccounts` and `getIndexerClient`. Both `enableNetwork` and `enableAccounts` **SHOULD** be called before the other functions.
+* If `signAndPostTxns`, `getAlgodv2Client`, `getIndexerClient`, `signTxns`, or `postTxns` are called before `enable` (or `enableAccounts`), they **SHOULD** throw an error object with property `code=4202`. (See Error Standards in [ARC-0001](arc-0001.md#error-standards)).
+* `getAlgodv2Client` and `getIndexerClient` **MUST** return connections to the network indicated by the `network` result of `enable`.
+* `signAndPostTxns` **MUST** post transactions to the network indicated by the `network` result of `enable`
+* The result of `getAlgodv2Client` **SHOULD** only be used to query the network. `postTxns` (if available) and `signAndPostTxns` **SHOULD** be used to send transactions to the network. The `Algodv2Client` object **MAY** be modified to throw exceptions if the caller tries to use it to post transactions.
+* `signTxns` and `postTxns` **MAY** or **MAY NOT** be provided. When one is provided, they both **MUST** be provided. In addition, `signTxns` **MAY** display a warning that the transactions are returned to the dApp rather than posted directly to the blockchain.
+
+### Additional requirements regarding LogicSigs
+
+`signAndPostTxns` must also be able to handle logic sigs, and more generally transactions signed by the DApp itself.
+In case of logic sigs, callers are expected to sign the logic sig by themselves, rather than expecting the wallet to do so on their behalf.
+To handle these cases, we adopt and extend the [ARC-0001](./arc-0001.md#interface-wallettransaction) format for `WalletTransaction`s that do not need to be signed:
+
+```json
+{
+  "txn": "...",
+  "signers": [],
+  "stxn": "..."
+}
+```
+
+* `stxn` is a `SignedTxnStr`, as specified in [ARC-0007](./arc-0007.md#string-specification-signedtxnstr).
+* For production wallets, `stxn` **MUST** be checked to match `txn`, as specified in [ARC-0001](./arc-0001.md#semantic-and-security-requirements).
+
+`signAndPostTxns` **MAY** reject when none of the transactions need to be signed by the user.
+
+## Rationale
+
+In order for a wallet to be useable by a DApp, it must support features for account discovery, signing and posting transactions, and querying the network.
+
+To whatever extent possible, the end users of a DApp should be empowered to select their own wallet, accounts, and network to be used with the DApp.
+Furthermore, said users should be able to use their preferred network node connection, without exposing their connection details and secrets (such as endpoint URLs and API tokens) to the DApp.
+
+The APIs presented in this document and related documents are sufficient to cover the needed functionality, while protecting user choice and remaining compatible with best security practices.
+Most DApps indeed always need to post transactions immediately after signing.
+`signAndPostTxns` allows this goal without revealing the signed transactions to the DApp, which prevents surprises to the user: there is no risk the DApp keeps in memory the transactions and post it later without the user knowing it (either to achieve a malicious goal such as forcing double spending, or just because the DApp has a bug).
+However, there are cases where `signTxns` and `postTxns` need to be used: for example when multiple users need to coordinate to sign an atomic transfer.
+
+## Reference Implementation
+
+```js
+async function main(wallet) {
+
+  // Account discovery
+  const enabled = await wallet.enable({genesisID: 'testnet-v1.0'});
+  const from = enabled.accounts[0];
+
+  // Querying
+  const algodv2 = new algosdk.Algodv2(await wallet.getAlgodv2Client());
+  const suggestedParams = await algodv2.getTransactionParams().do();
+  const txns = makeTxns(from, suggestedParams);
+
+  // Sign and post
+  const res = await wallet.signAndPost(txns);
+  console.log(res);
+
+};
+```
+
+Where `makeTxns` is comparable to what is seen in [ARC-0001](./arc-0001.md#reference-implementation)'s sample code.
+
+## Security Considerations
+
+None.
+
+## Copyright
+
+Copyright and related rights waived via <a href="https://creativecommons.org/publicdomain/zero/1.0/">CCO</a>.