@goplausible/algorand-mcp 3.0.7

package/dist/resources/knowledge/taxonomy/developer:docs:details:accounts:index.md

@@ -0,0 +1,107 @@
+title: Overview
+
+This section is an overview of **Accounts** on Algorand. It reviews core terminology and guides developers on how to interpret these terms in different contexts. 
+
+
+
+
+# Quick start videos
+
+If you prefer videos, take a look at this 6 minute guide to Learn How to Manage Private / Public Algorand Account Keys.
+
+<iframe width="100%" style="aspect-ratio:16/9" src="https://www.youtube-nocookie.com/embed/SewNDCBvk58" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
+
+# Terminology
+## Keys and Addresses
+
+Algorand uses Ed25519 high-speed, high-security elliptic-curve signatures. The keys are produced through standard, open-source cryptographic libraries packaged with each of the SDKs. The key generation algorithm takes a random value as input and outputs two 32-byte arrays, representing a public key and its associated private key. These are also referred to as a public/private key pair. These keys perform important cryptographic functions like signing data and verifying signatures. 
+
+<center> ![Key Generation](../../imgs/accounts-0.png) </center>
+<center>*Public/Private Key Generation* </center>
+
+For reasons that include the need to make the keys human-readable and robust to human error when transferred, both the public and private keys undergo transformations. The output of these transformations is what the majority of developers, and usually all end-users, see. In fact, the Algorand developer tools actively seek to mask the complexity involved in these transformations. So unless you are a protocol-level developer modifying cryptographic-related source code, you may never actually encounter the true public/private key pair. 
+
+
+### Transformation: Public Key to Algorand Address
+
+The **public key** is transformed into an Algorand address, by adding a 4-byte checksum to the end of the public key and then encoding it in base32. The result is what both the developer and end-user recognize as an **Algorand address**. The address is 58 characters long.
+
+<center> ![Algorand Address](../../imgs/accounts-1.png) </center>
+<center>*Public Key to Algorand Address* </center>
+
+!!! info
+	Since users almost never see the true public key, and the Algorand address is a unique mapping back to the public key, the use of the term **public key** is frequently (and inaccurately) used to mean **address**. 
+	
+!!! tip
+	Assuming the [Python SDK is installed](../../sdks/python/#install-sdk), it is possible to convert addresses to (base32-encoded) public keys and vice-versa using the following one-liners (here used on the address `VCMJKWOY5P5P7SKMZFFOCEROPJCZOTIJMNIYNUCKH7LRO45JMJP6UYBIJA`):
+	```bash
+	python3 -c "import base64, sys, algosdk; [print(base64.b32encode(algosdk.encoding.decode_address(line.strip())).decode()) for line in sys.stdin if line.strip()]" <<< VCMJKWOY5P5P7SKMZFFOCEROPJCZOTIJMNIYNUCKH7LRO45JMJP6UYBIJA
+
+	python3 -c "import base64, sys, algosdk; [print(algosdk.encoding.encode_address(base64.b32decode(line.strip()))) for line in sys.stdin if line.strip()]" <<< VCMJKWOY5P5P7SKMZFFOCEROPJCZOTIJMNIYNUCKH7LRO45JMJPQ====
+	```
+
+### Transformation: Private Key to base64 private key
+
+A base64 encoded concatenation of the private and public keys is a representation of the private key most commonly used by developers interfacing with the SDKs. It is likely not a representation familiar to end users.
+
+<center> ![base64 private key](../../imgs/accounts-2.png) </center>
+<center>*Base64 Private Key* </center>
+
+### Transformation: Private Key to 25-word mnemonic
+
+The 25-word mnemonic is the most user-friendly representation of the private key. It is generated by converting the private key bytes into 11-bit integers and then mapping those integers to the [bip-0039 English word list](https://raw.githubusercontent.com/bitcoin/bips/master/bip-0039/english.txt), where integer _n_ maps to the word in the _nth_ position in the list. By itself, this creates a 24-word mnemonic. A checksum is added by taking the first two bytes of the hash of the private key and converting them to 11-bit integers and then to their corresponding word in the word list. This word is added to the end of the 24 words to create a 25-word mnemonic.
+
+This representation is called the private key **mnemonic**. You may also see it referred to as a **passphrase**. 
+
+<center> ![Mnemonic](../../imgs/accounts-3.png) </center>
+<center>*Private Key Mnemonic* </center>
+
+!!! info
+	Both the base64 representation of a private key and the private key mnemonic are considered **private keys**. It is important to disambiguate in contexts where the representation is important. 
+
+## Wallets
+
+Wallets, in the context of Algorand developer tools, refer to wallets generated and managed by the Key Management Daemon (kmd) process. A wallet stores a collection of keys. kmd stores collections of wallets and allows users to perform operations using the keys stored within these wallets. Every wallet is associated with a master key, represented as a 25-word mnemonic, from which all accounts in that wallet are derived. This allows the owner of the wallet to only need to remember a single passphrase for all of their accounts. Wallets are stored encrypted on disk. 
+
+See [Wallet-derived (kmd)](./create.md#wallet-derived-kmd) accounts in the [Creation Methods](./create.md) section for more details.
+
+## Accounts
+Accounts are entities on the Algorand blockchain associated with specific onchain data, like a balance. An Algorand Address is the identifier for an Algorand account. 
+
+After generating a private key and corresponding address, sending Algos to the address on Algorand will initialize its state on the Algorand blockchain. 
+
+<center> ![Account](../../imgs/accounts-4.png) </center>
+<center>*Initializing an Account* </center>
+
+### Attributes
+#### Minimum Balance
+Every account on Algorand must have a minimum balance of 100,000 microAlgos. If ever a transaction is sent that would result in a balance lower than the minimum, the transaction will fail. The minimum balance increases with each asset holding the account has (whether the asset was created or owned by the account) and with each application the account created or opted in. Destroying a created asset, opting out/closing out an owned asset, destroying a created app, or opting out an opted in app decreases accordingly the minimum balance.
+
+Read more about assets, applications, and changes to the minimum balance requirement in the [Algorand Standard Assets](../asa) and [Smart contracts details](../dapps/smart-contracts/apps) sections.
+
+#### Online/Offline
+By default, Algorand accounts are set to **offline**. An **online** account is one that participates in Algorand consensus. For an account to go online, it must generate a participation key and send a special key registration transaction. Read more about how to register an account online in the [Network Participation](../../run-a-node/participate/index.md) section.
+
+### Other Account Types
+Creating an Algorand address from a public key is not the only way. A valid address can also be produced from a compiled TEAL contract and through multisignature accounts. These accounts differ in how they authorize spends, but they look like any other account on Algorand. Read more about contract accounts in the [Algorand Smart Contracts](/docs/get-details/dapps/smart-contracts/apps/#application-account) section. Multisignature accounts are described [below](create#multisignature).
+
+### Special Accounts
+
+Two accounts carry special meaning on the Algorand blockchain. They are the **FeeSink** and the **RewardsPool**. The FeeSink is where all fees from transactions are sent. The FeeSink can only spend to the RewardsPool account. The RewardsPool was first used to distribute rewards to balance holding accounts. Currently this account is not used. 
+
+In addition, the ZeroAddress `AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAY5HFKQ` is an address that represents a blank byte array. It is used when you leave an address field in a transaction blank.
+
+_MainNet [FeeSink](../algorand-networks/mainnet#feesink-address) and [RewardsPool](../algorand-networks/mainnet#rewardspool-address) addresses_
+
+_TestNet [FeeSink](../algorand-networks/testnet#feesink-address) and [RewardsPool](../algorand-networks/testnet#rewardspool-address) addresses_
+
+## A note about term usage in these docs
+Even in these docs, use of these terms may be inconsistent. At times this is a deliberate style choice to ensure clarity around a broader concept. Sometimes it is to emphasize the inherent pairing of the public and private portions of a key. (e.g. In code examples, it is sometimes clearer to name variables as such to emphasize the connection between these two entities). Other times it is to abstract away from complexity related to generating an account on Algorand. For example, code samples may use terms like "generateAccount" to generate a private key and Algorand address. There is an underlying assumption that this pair will be used as an Algorand account even though on generation it is not yet represented on the blockchain and therefore is not yet technically an Algorand account.
+
+
+??? tip "Interpretation Guide"
+	Here are a few examples of the way these terms appear in the wild and suggestions on how to interpret them. It is always best to ask for clarification when the terms are ambiguous.
+
+	1. A developer says they are looking to create a wallet for Algorand and are asking about kmd. - _In this situation, it is probably best to direct them to this page so they understand all the ways to create accounts on Algorand. They may want to support more than one generation method, including kmd._
+	2. A consumer says: "I have 5 accounts in my wallet." - _Consumers are likely referring to mobile or web wallets, and probably not the underlying kmd wallet mechanism._
+	3. A protocol developer wants to explore the signature validation mechanism in the Algorand protocol. - _This developer will most definitely encounter the true public/private key pairs as well as many of the concepts detailed above._

package/dist/resources/knowledge/taxonomy/developer:docs:details:accounts:rekey.md

@@ -0,0 +1,462 @@
+Title: Rekeying
+
+## Overview
+
+Rekeying is a powerful protocol feature which enables an Algorand account holder to maintain a static public address while dynamically rotating the authoritative private spending key(s). This is accomplished by issuing a "rekey-to transaction" which sets the _authorized address_ field within the account object. Future transaction authorization using the account's public address must be provided by the spending key(s) associated with the _authorized address_ which may be a single key address, MultiSig address or LogicSig program address. Key management is an important concept to understand and Algorand provides tools to accomplish relevant tasks securely. 
+
+# Quick start videos
+
+If you prefer videos, take a look at this 4 minute guide to Learn About Algorand Account Rekeying.
+
+<iframe width="100%" style="aspect-ratio:16/9" src="https://www.youtube-nocookie.com/embed/7yffxc4Q_H0" title="YouTube video player" frameborder="0" allow="accelerometer; autoplay; clipboard-write; encrypted-media; gyroscope; picture-in-picture; web-share" allowfullscreen></iframe>
+
+!!! Info
+    The term "spending key(s)" is used throughout this document to signify that generally either a single key or a set of keys from a MultiSig account may authorize from a given public address. The address itself cannot distinguish how many spending keys are specifically required.
+
+!!! warning
+    Using the `--close-to` parameter on any transaction from a _rekeyed account_ will remove the **auth-addr** field, thus reverting signing authority to the original address. The `--close-to` parameter should be used with caution by keyholder(s) of **auth-addr** as the effects remove their authority to access this account thereafter.
+
+!!! warning
+	Rekeying an account affects the **authorizing address** for that account only. Note that an Account is distinct from an address so there are several important points that may not be obvious:
+
+	**1)** If an account is closed (balance to 0) the rekey setting is lost (see previous warning).
+
+  	**2)** Rekeys are not recursively resolved, that is, if A is rekeyed to B and B rekeyed to C, A will have it's transactions authorized by B not C.
+	
+  	**3)** Rekeying members of a Multisig has no effect on the Multisig authorization since it's composed of Addresses not accounts. If necessary the Multisig account would need to be rekeyed itself.
+	
+
+### Account Review
+
+The [account overview](../#keys-and-addresses) page introduces _keys_, _addresses_ and _accounts_. During initial account generation, a public key and corresponding private spending key are created and used to derive the Algorand address. This public address is commonly displayed within wallet software and remains static for each account. When you receive Algos or other assets, they will be sent to your public Algorand address. When you send from your account, the transaction must be authorized using the appropriate private spending key(s).  
+
+### Authorized Addresses
+
+The _balance record_ of every account includes the "auth-addr" field which, when populated, defines the required _authorized address_ to be evaluated during transaction validation. Initially, the "auth-addr" field is implicitly set to the account's "address" field and the only valid _private spending key_ is the one created during account generation. To conserve resources, the "auth-addr" field is only stored and displayed after an authorized _rekey-to transaction_ is confirmed by the network. 
+
+Conceptually illustrated in the image below, a "standard" account uses its _private spending key_ to authorize from its _public address_. A "rekeyed" account defines the _authorized address_ which references a distinct "foreign" address and thus requires the _private spending key(s)_ thereof to authorize future transactions.
+
+![Accounts](../../imgs/accounts.png)
+
+#### Standard Account
+
+Use the following code sample to view a _standard_ account on BetaNet:
+
+=== "goal"
+  ```bash
+  goal account dump --address NFFMZJC6H52JLEAITTJ7OIML3XCJFKIRXYRJLO4WLWIJZB7N6CTWESRAZU
+  ```
+
+Response:
+
+```json hl_lines="2"
+{
+  "addr": "NFFMZJC6H52JLEAITTJ7OIML3XCJFKIRXYRJLO4WLWIJZB7N6CTWESRAZU",
+  "algo": 100000,
+  [...]
+}
+```
+Notice the response includes the "addr" field which is the public address. Implicitly, only the spending key associated with this address may authorize transactions for this account.
+
+#### Rekeyed Account
+
+Next, modify your command slightly to display results for this _rekeyed_ account: `L42DW7MSHP4PMIAZSDAXYTZVHTE756KGXCJYGFKCET5XHIAWLBYYNSMZQU`.
+
+Response:
+
+```json hl_lines="2 4"
+{
+  "addr": "L42DW7MSHP4PMIAZSDAXYTZVHTE756KGXCJYGFKCET5XHIAWLBYYNSMZQU",
+  "algo": 100000,
+  "spend": "NFFMZJC6H52JLEAITTJ7OIML3XCJFKIRXYRJLO4WLWIJZB7N6CTWESRAZU",
+  [...]
+}
+```
+
+This response includes the addition of the "spend" field. This is the "auth-addr" within the _account object_ and signifies any transactions from `L42DW7MSHP4PMIAZSDAXYTZVHTE756KGXCJYGFKCET5XHIAWLBYYNSMZQU` must now be authorized by `NFFMZJC6H52JLEAITTJ7OIML3XCJFKIRXYRJLO4WLWIJZB7N6CTWESRAZU` to be confirmed by the network. 
+
+### Rekey-to Transaction
+
+A _rekey-to transaction_ is a transaction which includes the `rekey-to` parameter set to a well-formed Algorand address. Authorization for this transaction must be provided by the existing _authorized address_. As shown in the first example account above, the _authorized address_ is implicitly the "addr" field of this account even though the "auth-addr" field is not explicitly defined. Only the private spending key of this "addr" address may be used to authorize a _rekey-to transaction_.
+
+The _rekey-to transaction_ workflow is as follows: 
+
+- Construct a transaction which specifies an _address_ for the `rekey-to` parameter
+- Add required signature(s) from the **current** _authorized address_
+- Send and confirm the transaction on the network
+
+#### Construct Transaction
+
+The following commands will construct an unsigned transaction file `rekey.txn` and inspect the contents:
+
+=== "goal"
+  ```bash
+  goal clerk send --from L42DW7MSHP4PMIAZSDAXYTZVHTE756KGXCJYGFKCET5XHIAWLBYYNSMZQU \
+                    --to L42DW7MSHP4PMIAZSDAXYTZVHTE756KGXCJYGFKCET5XHIAWLBYYNSMZQU \
+                    --amount 0 \
+                    --rekey-to NFFMZJC6H52JLEAITTJ7OIML3XCJFKIRXYRJLO4WLWIJZB7N6CTWESRAZU \
+                    --out rekey.txn
+  goal clerk inspect rekey.txn
+  ```
+
+Response:
+
+```json hl_lines="11"
+rekey.txn[0]
+{
+  "txn": {
+    "fee": 1000,
+    "fv": 4921687,
+    "gen": "betanet-v1.0",
+    "gh": "mFgazF+2uRS1tMiL9dsj01hJGySEmPN28B/TjjvpVW0=",
+    "lv": 4922687,
+    "note": "bbD6hjNZNdg=",
+    "rcv": "L42DW7MSHP4PMIAZSDAXYTZVHTE756KGXCJYGFKCET5XHIAWLBYYNSMZQU",
+    "rekey": "NFFMZJC6H52JLEAITTJ7OIML3XCJFKIRXYRJLO4WLWIJZB7N6CTWESRAZU",
+    "snd": "L42DW7MSHP4PMIAZSDAXYTZVHTE756KGXCJYGFKCET5XHIAWLBYYNSMZQU",
+    "type": "pay"
+  }
+}
+```
+
+Construction of the _rekey-to transaction_ includes the `rekey-to` parameter and the value `"NFFMZJC6H52JLEAITTJ7OIML3XCJFKIRXYRJLO4WLWIJZB7N6CTWESRAZU"`. Notice the resulting unsigned transaction output includes the "rekey" field and this value.
+
+#### Add Authorized Signature(s) 
+
+Adding the **current** authorized signature(s) to a _rekey-to transaction_ is required prior to sending to the network for confirmation. The "snd" field provides the address to the _account object_ where the "auth-addr" field is defined. 
+
+!!! Info
+    Examples provided below demonstrate the commands in detail and allow you to _rekey_ accounts in various scenarios. 
+
+#### Send and Confirm
+
+Once all of the required signatures are gathered into a single signed transaction, it may be sent to the network for confirmation. The result for the sample account is:
+
+```json hl_lines="4"
+{
+  "addr": "L42DW7MSHP4PMIAZSDAXYTZVHTE756KGXCJYGFKCET5XHIAWLBYYNSMZQU",
+  "algo": 100000,
+  "spend": "NFFMZJC6H52JLEAITTJ7OIML3XCJFKIRXYRJLO4WLWIJZB7N6CTWESRAZU",
+  [...]
+}
+```
+
+### Conclusion
+
+The result of a confirmed _rekey-to transaction_ will be the "auth-addr" field of the _account object_ is defined, modified or removed. Defining or modifying means only the _private spending key(s)_ of the corresponding _authorized address_ may authorize future transactions for this _public address_. Removing the "auth-addr" field is really an explicit assignment of the _authorized address_ back to the "addr" field of the _account object_ (observed implicitly because the field is not displayed). 
+
+The "auth-addr" may be specified within a _rekey-to transaction_ as a distinct foreign address representing a single key address, MultiSig address or LogicSig program address to provide maximum flexibility in key management options. 
+
+!!! Warning
+    The protocol does not validate control of the required spending key(s) associated with the _authorized address_ defined by `--rekey-to` parameter when the _rekey-to transaction_ is sent. This is by design and affords additional privacy features to the new _authorized address_. It is incumbent upon the user to ensure proper key management practices and `--rekey-to` assignments.
+
+
+## Use Case Scenarios
+
+!!! Info
+    Below are a series of potential use cases for rekeying various accounts. 
+
+## 1 - Rekey to Single Address
+
+The first scenario rekeys a single key account with address "A" to a distinct single key account with address "B". This requires two single key accounts at time _t0_. The result from time _t1_ is transactions for address "A" must be authorized by address "B". 
+
+![Rekey-to Single Key Address](../../imgs/rekey-single-single.png)
+
+### Generate and Fund Accounts
+
+Refer to the Getting Started guide to learn how to generate two accounts and fund their respective address from the Faucet. This example uses the following public addresses:
+
+```bash
+  ADDR_A="UGAGADYHIUGFGRBEPHXRFI6Z73HUFZ25QP32P5FV4H6B3H3DS2JII5ZF3Q"
+  ADDR_B="LOWE5DE25WOXZB643JSNWPE6MGIJNBLRPU2RBAVUNI4ZU22E3N7PHYYHSY"
+```
+
+View the initial _authorized address_ for Account A using `goal`:
+
+```bash
+goal account dump --address $ADDR_A
+```
+
+Response:
+
+```json hl_lines="2"
+{
+  "addr": "UGAGADYHIUGFGRBEPHXRFI6Z73HUFZ25QP32P5FV4H6B3H3DS2JII5ZF3Q",
+  "algo": 100000,
+  [...]
+}
+```
+
+Implicitly, the _authorized address_ is the defined as the "addr" field displayed here.
+
+### Rekey to Single Address
+
+Account A intends to _rekey_ its _authorized address_ to `$ADDR_B` which is the public address of Account "B". This can be accomplished in a single `goal` command:
+
+=== "goal"
+  ```bash
+  goal clerk send --from $ADDR_A --to $ADDR_A --amount 0 --rekey-to $ADDR_B
+  ```
+
+Results of `goal account dump --address $ADDR_A` will now display:
+
+```json hl_lines="5"
+{
+  "addr": "UGAGADYHIUGFGRBEPHXRFI6Z73HUFZ25QP32P5FV4H6B3H3DS2JII5ZF3Q",
+  "algo": 199000,
+  [...]
+  "spend": "LOWE5DE25WOXZB643JSNWPE6MGIJNBLRPU2RBAVUNI4ZU22E3N7PHYYHSY"
+}
+```
+
+The populated "spend" field instructs the validation protocol to only approve transactions for this _account object_ when authorized by the _spending key(s)_ of that address. Validators will ignore all other attempted authorizations, including those from the _public address_ defined in the "addr" field. 
+
+#### TEST: Send with Auth A
+
+The following transaction will **fail** because, by default, `goal` attempts to add the authorization using the `--from` parameter. However, the protocol will reject this because it is expecting the authorization from `$ADDR_B` due to the confirmed _rekeying transaction_ above.
+
+=== "goal"
+  ```bash
+  goal clerk send --from $ADDR_A --to $ADDR_B --amount 100000
+  ```
+
+### Send from Authorized Address
+
+Sending from the _authorized address_ of Account "A" requires:
+
+- Construct an unsigned transaction from `$ADDR_A`
+- Sign using _authorized address_ `$ADDR_B`
+- Send authorized transaction 
+
+#### Construct Unsigned Transaction
+
+First, construct an unsigned transaction using `goal` with the `--outfile` flag to write the unsigned transction to a file:
+
+=== "goal"
+  ```bash
+  goal clerk send --from $ADDR_A --to $ADDR_B --amount 100000 --out send-single.txn
+  ```
+
+#### Sign Using Authorized Address
+
+Next, locate the wallet containing the _private spending key_ for Account "B". The `goal clerk sign` command provides the flag `--signer` which allows specifying the proper required _authorized address_ `$ADDR_B`. Notice the `infile` flag reads in the unsigned transaction file from above and the `--outfile` flag writes the signed transaction to a separate file.
+
+=== "goal"
+  ```bash
+  goal clerk sign --signer $ADDR_B --infile send-single.txn --outfile send-single.stxn
+  ```
+
+#### TEST: Send with Auth B
+
+Finally, send the the signed transaction file using `goal`:
+
+=== "goal"
+  ```bash
+  goal clerk rawsend --filename send-single.stxn
+  ```
+
+This will succeed, sending the 100000 microAlgos from `$ADDR_A` to `$ADDR_B` using the _private spending key_ of Account "B".
+
+## 2 - Rekey to MultiSig Address
+
+The second scenario _rekeys_ a single key account with _public address_ "A" to a MultiSig address "BC_T1". This scenario reuses both Accounts "A" and "B", adds a third Account "C" and creates a MultiSig Account "BC_T1" comprised of addresses "B" and "C" with a threshold of 1. The result will be the _private spending key_ for `$ADDR_B` or `$ADDR_C` may authorize transaction from `$ADDR_A`.
+
+![Rekey-to MultiSig Address](../../imgs/rekey-single-multisig.png)
+
+### Generate Additional Account
+
+Follow the same procedure as above to generate a third account for use as "C".
+
+### Generate New MultiSig Account
+
+Reference the documentation to generate MultiSig account. Ensure it uses both `$ADDR_B` and the new `$ADDR_C` with a threshold of 1  (so either "B" or "C" may authorize). Set the resulting account address to the `$ADDR_BC_T1` environment variable for use below.
+
+### Rekey to MultiSig Address
+
+Recall from scenario 1 that Account "A" has already _rekeyed_ to `$ADDR_B`. 
+
+### Construct Unsigned Transaction
+
+The _rekey transaction_ constructed for this scenario requires authorize from `$ADDR_B`.
+
+=== "goal"
+  ```bash
+  goal clerk send --from $ADDR_A --to $ADDR_A --amount 0 --rekey-to $ADDR_BC_T1 --out rekey-multisig.txn
+  ```
+
+### Sign Rekey Transaction
+
+=== "goal"
+  ```bash
+  goal clerk sign --signer $ADDR_B --infile rekey-multisig.txn --outfile rekey-multisig.stxn
+  ```
+
+### Send and Confirm Rekey to MultiSig
+
+=== "goal"
+  ```bash
+  goal clerk rawsend --filename rekey-multisig.stxn
+  goal account dump --address $ADDR_A
+  ```
+
+The _rekey transaction_ will confirm, resulting in the "spend" field update within the _account object_:
+
+```json hl_lines="5"
+{
+  "addr": "UGAGADYHIUGFGRBEPHXRFI6Z73HUFZ25QP32P5FV4H6B3H3DS2JII5ZF3Q",
+  "algo": 199000,
+  [...]
+  "spend": "NEWMULTISIGADDRESSBCT1..."
+}
+```
+
+#### TEST: Send with Auth BC_T1
+
+Use the established pattern:
+
+- Construct unsigned transaction
+- Sign transaction
+- Confirm transaction
+
+=== "goal"
+  ```bash
+  goal clerk send --from $ADDR_A --to $ADDR_B --amount 100000 --msig-params="1 $ADDR_B $ADDR_C" --out send-multisig-bct1.txn
+  goal clerk multisig sign --tx send-multisig-bct1.txn --address $ADDR_C
+  goal clerk rawsend --filename send-multisig-bct1.txn
+  ```
+
+This transaction will succeed as _private spending key_ for `$ADDR_C` provided the authorization and meets the threshold requirement for the MultiSig account.
+
+## SDK Example:
+In the following example Account 1 is rekeyed to Account 2. The code then illustrates that signing a transaction from Account 1 will fail if signed with Account 1's private key and succeed if signed with Account 2's private key.
+
+=== "Python"
+	<!-- ===PYSDK_ACCOUNT_REKEY=== -->
+	```python
+	# Any kind of transaction can contain a rekey
+	rekey_txn = transaction.PaymentTxn(
+	    account_1.address, sp, account_1.address, 0, rekey_to=account_2.address
+	)
+	signed_rekey = rekey_txn.sign(account_1.private_key)
+	txid = algod_client.send_transaction(signed_rekey)
+	result = transaction.wait_for_confirmation(algod_client, txid, 4)
+	print(f"rekey transaction confirmed in round {result['confirmed-round']}")
+	
+	# Now we should get an error if we try to submit a transaction
+	# signed with account_1s private key
+	expect_err_txn = transaction.PaymentTxn(
+	    account_1.address, sp, account_1.address, 0
+	)
+	signed_expect_err_txn = expect_err_txn.sign(account_1.private_key)
+	try:
+	    txid = algod_client.send_transaction(signed_expect_err_txn)
+	except Exception as e:
+	    print("Expected error: ", e)
+	
+	# But its fine if we sign it with the account we rekeyed to
+	signed_expect_err_txn = expect_err_txn.sign(account_2.private_key)
+	txid = algod_client.send_transaction(signed_expect_err_txn)
+	result = transaction.wait_for_confirmation(algod_client, txid, 4)
+	print(f"transaction confirmed in round {result['confirmed-round']}")
+	
+	# rekey account1 back to itself so we can actually use it later
+	rekey_txn = transaction.PaymentTxn(
+	    account_1.address, sp, account_1.address, 0, rekey_to=account_1.address
+	)
+	signed_rekey = rekey_txn.sign(account_2.private_key)
+	txid = algod_client.send_transaction(signed_rekey)
+	result = transaction.wait_for_confirmation(algod_client, txid, 4)
+	print(f"rekey transaction confirmed in round {result['confirmed-round']}")
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/account.py#L65-L99)
+	<!-- ===PYSDK_ACCOUNT_REKEY=== -->
+
+=== "JavaScript"
+	<!-- ===JSSDK_ACCOUNT_REKEY=== -->
+	```javascript
+	// rekey the original account to the new signer via a payment transaction
+	// Note any transaction type can be used to rekey an account
+	const rekeyTxn = algosdk.makePaymentTxnWithSuggestedParamsFromObject({
+	  from: acct1.addr,
+	  to: acct1.addr,
+	  amount: 0,
+	  suggestedParams,
+	  rekeyTo: acct2.addr, // set the rekeyTo field to the new signer
+	});
+	
+	await client.sendRawTransaction(rekeyTxn.signTxn(acct1.privateKey)).do();
+	await algosdk.waitForConfirmation(client, rekeyTxn.txID().toString(), 3);
+	
+	const acctInfo = await client.accountInformation(acct1.addr).do();
+	
+	console.log(`Account Info: ${acctInfo} Auth Addr: ${acctInfo['auth-addr']}`);
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/accounts.ts#L87-L103)
+	<!-- ===JSSDK_ACCOUNT_REKEY=== -->
+
+
+=== "Java"
+	<!-- ===JAVASDK_ACCOUNT_REKEY=== -->
+	```java
+	
+	// Any kind of transaction can contain a rekey, here we use a Payment
+	// transaction
+	Transaction rekeyTxn = Transaction.PaymentTransactionBuilder().sender(acct1.getAddress())
+	                .receiver(acct1.getAddress()).suggestedParams(sp).rekey(acct2.getAddress()).build();
+	SignedTransaction signedRekeyTxn = acct1.signTransaction(rekeyTxn);
+	Response<PostTransactionsResponse> resp = algodClient.RawTransaction()
+	                .rawtxn(Encoder.encodeToMsgPack(signedRekeyTxn)).execute();
+	ExampleUtils.printTxnResults(algodClient, resp.body(), "rekey");
+	
+	// Create a transaction to rekey it back
+	Transaction rekeyBack = Transaction.PaymentTransactionBuilder().sender(acct1.getAddress())
+	                .receiver(acct1.getAddress()).suggestedParams(sp).rekey(acct1.getAddress()).build();
+	
+	// note we sign with acct2's key
+	SignedTransaction signedRekeyBack = acct2.signTransaction(rekeyBack);
+	Response<PostTransactionsResponse> rekeyBackResponse = algodClient.RawTransaction()
+	                .rawtxn(Encoder.encodeToMsgPack(signedRekeyBack)).execute();
+	ExampleUtils.printTxnResults(algodClient, rekeyBackResponse.body(), "rekey back");
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/AccountExamples.java#L96-L115)
+	<!-- ===JAVASDK_ACCOUNT_REKEY=== -->
+
+=== "Go"
+	<!-- ===GOSDK_ACCOUNT_REKEY=== -->
+	```go
+	sp, err := algodClient.SuggestedParams().Do(context.Background())
+	if err != nil {
+		log.Fatalf("failed to get suggested params: %s", err)
+	}
+	
+	addr := acct.Address.String()
+	// here we create a payment transaction but rekey is valid
+	// on any transaction type
+	rktxn, err := transaction.MakePaymentTxn(addr, addr, 0, nil, "", sp)
+	if err != nil {
+		log.Fatalf("failed to creating transaction: %s\n", err)
+	}
+	// Set the rekey parameter
+	rktxn.RekeyTo = rekeyTarget.Address
+	
+	_, stxn, err := crypto.SignTransaction(acct.PrivateKey, rktxn)
+	if err != nil {
+		fmt.Printf("Failed to sign transaction: %s\n", err)
+	}
+	
+	txID, err := algodClient.SendRawTransaction(stxn).Do(context.Background())
+	if err != nil {
+		fmt.Printf("failed to send transaction: %s\n", err)
+		return
+	}
+	
+	result, err := transaction.WaitForConfirmation(algodClient, txID, 4, context.Background())
+	if err != nil {
+		fmt.Printf("Error waiting for confirmation on txID: %s\n", txID)
+		return
+	}
+	
+	fmt.Printf("Confirmed Transaction: %s in Round %d\n", txID, result.ConfirmedRound)
+	```
+	[Snippet Source](https://github.com/algorand/go-algorand-sdk/blob/examples/examples/account/main.go#L49-L82)
+	<!-- ===GOSDK_ACCOUNT_REKEY=== -->

package/dist/resources/knowledge/taxonomy/developer:docs:details:algorand-networks:betanet.md

@@ -0,0 +1,31 @@
+title: BetaNet 🔷
+# What's New
+
+🔷 = BetaNet availability only
+
+# Version
+`v4.0.0-beta`
+
+# Release Version
+https://github.com/algorand/go-algorand/releases/tag/v4.0.0-beta
+
+# Genesis ID
+`betanet-v1.0`
+
+# Genesis Hash
+`mFgazF+2uRS1tMiL9dsj01hJGySEmPN28B/TjjvpVW0=`
+
+# FeeSink Address
+`A7NMWS3NT3IUDMLVO26ULGXGIIOUQ3ND2TXSER6EBGRZNOBOUIQXHIBGDE`
+
+# RewardsPool Address
+`7777777777777777777777777777777777777777777777777774MSJUVU`
+
+# Faucet
+
+You can dispense algos to your TestNet account by visiting [Algorand BetaNet Dispenser](https://bank.betanet.algodev.network/).
+
+Click the Google sign-in link at the top of the Dispenser page and sign-in with your Google account. Complete the reCAPTCHA. Then copy and paste the address you would like to send money to into the empty text box. Click "Dispense". A `200` status code and a transaction ID means success. Run `goal account balance -a <algorand-address>` to view the new balance.
+
+
+

package/dist/resources/knowledge/taxonomy/developer:docs:details:algorand-networks:index.md

@@ -0,0 +1,23 @@
+title: Overview
+
+Algorand has three public networks: [**MainNet**](mainnet), [**TestNet**](testnet), and [**BetaNet**](betanet). This section provides details about each of these networks that will help you validate the integrity of your connection to them. 
+
+<center>
+**Diagram of the relationship between the three public networks.**
+
+![Algorand Public Networks](../../imgs/network.png)
+
+</center>
+
+Each network page, contains the following information:
+
+- **What's New** ([M](mainnet#whats-new), [T](testnet#whats-new), [B](betanet#whats-new))- An optional section where new features are highlighted with links to accompanying documentation.
+- **Version** ([M](mainnet#version), [T](testnet#version), [B](betanet#version)) - The latest protocol software version.  Should match `goal -v` or `GET /versions` [build version](/docs/rest-apis/algod#buildversion).
+- **Release Version** ([M](mainnet#release-version), [T](testnet#release-version), [B](betanet#release-version)) - A link to the official release notes where you can view all the latest changes.
+- **Genesis ID** ([M](mainnet#genesis-id), [T](testnet#genesis-id), [B](betanet#genesis-id)) - A human-readable identifier for the network. This should not be used as a unique identifier.
+- **Genesis Hash** ([M](mainnet#genesis-hash), [T](testnet#genesis-hash), [B](betanet#genesis-hash)) - The unique identifier for the network, present in every transaction. Validate that your transactions match the network you plan to submit them to.
+- **FeeSink Address** ([M](mainnet#feesink-address), [T](testnet#feesink-address), [B](betanet#feesink-address)) - Read more about special accounts [here](/docs/get-details/accounts#special-accounts).
+- **RewardsPool Address** ([M](mainnet#rewardspool-address), [T](testnet#rewardspool-address), [B](betanet#rewardspool-address)) - Read more about special accounts [here](../accounts#special-accounts).
+- **Faucet** ([T](testnet#faucet), [B](betanet#faucet)) - Link to a faucet (TestNet and BetaNet only).
+
+

package/dist/resources/knowledge/taxonomy/developer:docs:details:algorand-networks:mainnet.md

@@ -0,0 +1,19 @@
+title: MainNet
+
+# Version
+`v3.27.0-stable`
+
+# Release Version
+https://github.com/algorand/go-algorand/releases/tag/v3.27.0-stable
+
+# Genesis ID
+`mainnet-v1.0`
+
+# Genesis Hash
+`wGHE2Pwdvd7S12BL5FaOP20EGYesN73ktiC1qzkkit8=`
+
+# FeeSink Address
+`Y76M3MSY6DKBRHBL7C3NNDXGS5IIMQVQVUAB6MP4XEMMGVF2QWNPL226CA`
+
+# RewardsPool Address
+`737777777777777777777777777777777777777777777777777UFEJ2CI`