@goplausible/algorand-mcp 3.0.7

package/dist/resources/knowledge/taxonomy/developer:docs:rest-apis:restendpoints.md

@@ -0,0 +1,76 @@
+title: REST Endpoints
+Algorand maintains SDK support in [JavaScript](../../sdks/javascript/#install-sdk-for-runtime), [Python](../../sdks/python/#install-sdk), [Java](../../sdks/java/#install-sdk-for-runtime) and [Go](../../sdks/go/#install-go-sdk). More languages are also available through [Community Provided SDKs](https://developer.algorand.org/ecosystem-projects/?from_query=sdk#net-sdk). The Algorand SDKs offer both standalone and network-connected development functionality.
+
+# Algod, Indexer and KMD REST Endpoints
+
+Integration with the Algorand protocol daemon (`algod`), Algorand key management daemon (`kmd`) or Algorand Indexer daemon (`algorand-indexer`) is performed using a set of REST APIs.
+
+All REST methods and models are fully described within reference documentation.
+
+- [Algod REST APIs](../../rest-apis/algod/)
+
+- [Indexer REST APIs](../../rest-apis/indexer/)
+
+- [KMD REST APIs](../../rest-apis/kmd/)
+
+_**Algod REST Endpoints**_
+
+!!! info
+    Algorand provides endpoints for [Open API Specification version 2 (OAS2)](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/2.0.md) and [OAS3](https://github.com/OAI/OpenAPI-Specification/tree/main/versions).
+
+These APIs are described using the [Open API Specification version 3 (OAS3)](https://github.com/OAI/OpenAPI-Specification/blob/main/versions/3.1.0.md).
+
+[Algod REST Endpoints OAS3 specfile](https://github.com/algorand/go-algorand/blob/master/daemon/algod/api/algod.oas3.yml?raw=true)(.yml)
+
+Run Algod in Postman OAS3.
+
+[![Run in Postman](https://run.pstmn.io/button.svg)](https://app.getpostman.com/run-collection/7417958-60ff1bfc-b5f2-42aa-83b0-6888f0d4c2f4?action=collection%2Ffork&collection-url=entityId%3D7417958-60ff1bfc-b5f2-42aa-83b0-6888f0d4c2f4%26entityType%3Dcollection%26workspaceId%3Dab8846ef-efa3-4872-a5e5-c2992de6b69c)
+
+OAS2 Algod specfile [here](https://github.com/algorand/go-algorand/blob/master/daemon/algod/api/algod.oas2.json?raw=true)
+
+_**Indexer REST Endpoints**_
+
+The `algorand-indexer` daemon provides its API from the _host:port_ defined by the _--server_ flag specified at start up. The default port is 8980.
+
+[Indexer REST Endpoints OAS3 specfile](https://www.github.com/algorand/indexer/blob/develop/api/indexer.oas3.yml?raw=true)(.yml)
+
+Run Indexer in Postman OAS3.
+
+[![Run in Postman](https://run.pstmn.io/button.svg)](https://app.getpostman.com/run-collection/7417958-2e088cf0-8c78-44b0-8b08-9a832b120d1a?action=collection%2Ffork&collection-url=entityId%3D7417958-2e088cf0-8c78-44b0-8b08-9a832b120d1a%26entityType%3Dcollection%26workspaceId%3Dab8846ef-efa3-4872-a5e5-c2992de6b69c)
+
+OAS2 Indexer specfile [here](https://github.com/algorand/indexer/blob/develop/api/indexer.oas2.json?raw=true)
+
+_**KMD REST Endpoints**_
+
+!!! info
+    All examples in this section assume the data directory is ~/node/data
+
+
+This API is described using the [Open API Specification version 2 (OAS 2)](https://github.com/OAI/OpenAPI-Specification/blob/master/versions/2.0.md). The `kmd` daemon serves it's API from the _kmd.net_ files found in the _~/node/data_ and _~/node/data/kmd-{version}_ directories. The `kmd` daemons provide their API specifications in a [swagger json](https://github.com/algorand/go-algorand/blob/master/daemon/kmd/api/swagger.json) format available from this endpoint:
+
+Algorand Key Management Daemon (`kmd`)
+
+```zsh
+curl http://$(cat ~/node/data/kmd-v0.5/kmd.net)/swagger.json
+```
+
+!!! info
+    The `kmd` daemon is only automatically started when using the `goal` command line tool with specific commands requiring key management access. If you require API access to `kmd` you will need to manually start the process with `goal` using the command: `goal kmd start -d <data-dir>`. If the kmd is started with the above command it never times out and stops running unless a timeout flag is specified with the -t flag. The default of 0 is no timeout.
+
+# Security Token
+
+Most REST calls will also require an API token header to authenticate with the API server. For both `algod` and `kmd` the token is automatically generated by the daemon at startup and stored in a file. `algod` places _algod.token_ in the _~/node/data_ directory. `kmd` places _kmd.token_ the _~/node/data/kmd-{version}_ directory. Security tokens can be regenerated for both using the `goal node generatetoken` command.
+
+| Daemon    | Header Identifier   | Header Value Defined Via                    |
+| --------- | ------------------- | ------------------------------------------- |
+| `algod`   | X-Algo-API-Token    | file: ~/node/data/algod.token               |
+| `kmd`     | X-KMD-API-Token     | file: ~/node/data/kmd-\{version\}/kmd.token |
+| `indexer` | X-Indexer-API-Token |                                             |
+
+Each SDK provides a method for setting these headers. Most REST tools provide a method for setting additional headers. To set the header with a `curl` command use the `-H` parameter. For example, to make a call to retrieve a specific block, use the following curl command:
+
+```zsh
+curl http://$(cat ~/node/data/algod.net)/v2/blocks/16486179 -H "X-Algo-API-Token: $(cat ~/node/data/algod.token)"
+```
+
+In the above example, the block information will be displayed if the block exists on the local node. If the node is a non-Archival node, blocks older than 1000 blocks will not be available.

package/dist/resources/knowledge/taxonomy/developer:docs:run-a-node:operations:catchup.md

@@ -0,0 +1,33 @@
+title: Catchup And status
+
+# Catchup
+
+When first starting a node it will process all blocks in the blockchain, even if it does not store all blocks locally. The node does so to verify every block in the blockchain thereby checking the validity of the chain. The process can be time-consuming but is essential when running a trusted node.  
+
+With adequate [hardware and Internet connection](../../setup/install#hardware-requirements), syncing MainNet takes between 2 and 4 weeks in October 2022.
+
+If you cannot wait for catchup, there are multiple options:
+* [AlgoKit](/docs/get-started/algokit) allows quick setup of private network and public networks. For public networks, the node will be non-archival and use fast catchup. Sandbox should only be used for development purposes.
+* [Fast Catchup](../../setup/install#sync-node-network-using-fast-catchup) can be used to quickly sync a **non-archival** node, but requires trust in the entity providing the catchpoint.
+* Third-party snapshots such [AlgoNode.io snapshots](https://algonode.io/extras/) may be used for **archival** nodes, but requires trust in the third party. Algorand denies any responsibility if any such snapshot is used.
+
+!!! info    
+    If a node is stopped it will stop processing blocks. Once the node is restarted, it will start processing blocks where it left off.
+
+!!! info
+    The terms "sync" and "catchup/catch up" are used interchangeably.
+
+# Node Status
+
+It is possible to check the status of the catchup process by checking a node's status.
+
+```
+goal node status [-d <data directory>]
+```
+
+After running this status check, monitor the `Sync Time:` property that is returned. If this value is incrementing, the node is still synching. The `Sync Time:` will display `Sync Time: 0.0s` when the node is fully caught up. The status also reports the last block process by the node in the `Last committed block:` property. Comparing this block number to what is shown using an Algorand [Block Explorer](https://developer.algorand.org/ecosystem-projects/#block-explorers) will indicate how much more time catchup will take.
+
+!!! info
+    Progress of last committed block is not linear. Earlier blocks usually have much fewer transactions than more recent blocks and catchup usually slows down the closer to the current block you are.
+
+

package/dist/resources/knowledge/taxonomy/developer:docs:run-a-node:operations:switch_networks.md

@@ -0,0 +1,89 @@
+title: Switch Networks
+By default, an Algorand installation is configured to run on MainNet. For most users, this is the desired outcome. Developers, however, need access to [TestNet or BetaNet networks](../../../archive/build-apps/setup/#choosing-a-network). This guide describes switching between networks.
+
+
+# Replacing the Genesis file
+Every Algorand node has a data directory that is used to store the ledger and other configuration information. As part of this configuration, a `genesis.json` file is used. The `genesis.json` file specifies the initial state of the blockchain - its ‘genesis block’. This is a JSON formatted file with the schema for the blockchain. It contains the network name and id, the protocol version and list of allocated addresses to start the chain with. Each address contains a list of things like address status and the amount of Algos owned by the address.
+
+As part of the installer, a `genesisfiles` directory is created under the node's installed location for binaries. This directory contains additional directories for each of the Algorand networks: BetaNet, TestNet, and MainNet. These directories contain the `genesis.json` file for each of the Algorand networks (eg `~/node/genesisfiles/mainnet/genesis.json`). 
+
+!!! info
+    The genesis file for *Debian* and *RPM* installs are stored in the `/var/lib/algorand/genesis/` directory.
+
+The network can be switched by either replacing the current genesis file located in the `data` directory with the specific network `genesis.json` or by creating a new `data` directory and copying the specific network `genesis.json` file to the new `data` directory. Replacing the current genesis file will not destroy the current network data, but will prevent running multiple networks on the same node. To run multiple networks at the same time multiple data directories are required.
+
+# Using a new Data Directory
+To construct a new data directory follow the steps described below that depend on the type of install that was used with the current node.
+
+## Mac OS or Other Linux Distros
+Assume the node binaries are currently installed in `~/node` and the data directory is set to `~/node/data`. Create the new data directory for the network that is being switched to. (eg `~/node/testnetdata`). 
+
+```
+cd ~/node
+./goal node stop -d data
+mkdir testnetdata 
+cp ~/node/genesisfiles/testnet/genesis.json ~/node/testnetdata
+```
+Startup the new node using the `-d` option to point at the new network.
+
+```
+./goal node start -d ~/node/testnetdata
+```
+
+The node will restart and begin communicating with the TestNet network. It will need to sync with the network which will take time. Run the following command to check the current sync status.
+
+```
+./goal node status -d ~/node/testnetdata
+```
+
+At this point, the original network can be stared as well using the standard data directory.
+
+## Debian or RPM installs
+For *Debian* and *RPM* installs the data directory is set to `/var/lib/algorand`. With these installs, the genesis files are stored in `/var/lib/algorand/genesis/`. Create the new data directory for the network that is being switched to. (eg `/var/lib/algorand_testnet`). 
+
+```
+ALGORAND_DATA=/var/lib/algorand_testnet
+sudo mkdir -p ${ALGORAND_DATA}
+```
+Copy the specific network genesis file to the new directory and set the ownership to the algorand account.
+
+```
+sudo cp -p /var/lib/algorand/genesis/testnet/genesis.json ${ALGORAND_DATA}/genesis.json
+sudo cp -p /var/lib/algorand/system.json ${ALGORAND_DATA}/system.json
+sudo chown -R algorand ${ALGORAND_DATA}
+```
+
+Use `systemctl` to enable the process and start it.
+
+```
+sudo systemctl enable algorand@$(systemd-escape ${ALGORAND_DATA})
+sudo systemctl start algorand@$(systemd-escape ${ALGORAND_DATA})
+```
+The process can be disabled or stopped using `systemctl` commands.
+
+```
+sudo systemctl stop algorand@$(systemd-escape ${ALGORAND_DATA})
+sudo systemctl disable algorand@$(systemd-escape ${ALGORAND_DATA})
+```
+
+# DNS Configuration for BetaNet
+
+For the BetaNet network, when installing a new node or relay, make the following modification to the `config.json` file located in the node's data directory. 
+
+Edit the `config.json` file and replace the line
+``` 
+"DNSBootstrapID": "<network>.algorand.network",
+```
+with 
+``` 
+"DNSBootstrapID": "<network>.algodev.network",
+```
+If former line is not present, just add the latter line.
+If there is no `config.json` in the Algorand data folder, just create a new one with the following content:
+```json
+{
+    "DNSBootstrapID": "<network>.algodev.network"
+}
+```
+
+This modification to the `DNSBootstrapID` is only for the BetaNet network.

package/dist/resources/knowledge/taxonomy/developer:docs:run-a-node:participate:generate_keys.md

@@ -0,0 +1,76 @@
+title: Generate a participation key
+
+Algorand provides a set of keys for voting and proposing blocks separate from account spending keys. These are called **participation keys** (sometimes referred to as **partkeys**).  At a high-level, participation keys are a specialized set of keys located on a single node. Once this participation key set is associated with an account, the account has the ability to participate in consensus. 
+
+_[Read more about how Participation Keys function in the Algorand Consensus Protocol](../../../get-details/algorand_consensus#participation-keys)._
+
+!!! info "Important"
+	- The account’s private spending key does not need to be on the node to generate a participation key. Technically, anyone can generate a participation key for a particular account, but only the private spending key of the account can authorize the transaction that would register the account to go online with a particular participation key. This distinction allows you to keep private keys in cold storage.
+	- For security, the individual keys for each round are deleted from the key file as each round is completed. It is critical for the safety of the Algorand blockchain to avoid storing backups of participation key files that have been registered for an account.  
+	- The limit to the range you can specify for a partkey validity period is 2^24 - 1 (16,777,215). For security, it is recommended that the range does not exceed 3,000,000 rounds.
+
+# Generate the participation key with `goal`
+
+To generate a participation key, use the [`goal account addpartkey`](../../../clis/goal/account/addpartkey) command on the node where the participation key will reside. This command takes the address of the participating account, a range of rounds, and an optional key dilution parameter.  It then generates a [VRF key pair](../../../get-details/algorand_consensus#verifiable-random-function) and, using optimizations, generates a set of single-round voting keys for each round of the range specified. The VRF private key is what is passed into the VRF to determine if you are selected to propose or vote on a block in any given round. 
+
+=== "goal"
+    ```zsh 
+    $ goal account addpartkey -a <address-of-participating-account> --roundFirstValid=<partkey-first-round> --roundLastValid=<partkey-last-round>
+    Participation key generation successful
+    ```
+
+This creates a participation key on the node. You can use the `-o` flag to specify a different location in the case where you will eventually transfer your key to a different node to construct the keyreg transaction.
+
+!!! tip
+	To optimize storage, the Key Dilution parameter defaults to the square root of the participation period length but this can be overridden with the flag `--keyDilution`. The Key Dilution determines how many ephemeral keys will be stored on an algorand node, as they are generated in batches. For example, if your participation period is set to 3,000,000 rounds, a batch of 1,732 ephemeral keys will be generated upfront, with additional batches getting generated after each set is used.
+
+# Add participation key
+
+If you chose to save the participation key and now want to add it to the server, you can use the following command to add the partkey file to the node.
+
+```bash
+$ goal account installpartkey --partkey ALICE...VWXYZ.0.30000.partkey --delete-input
+```
+
+# Check that the key exists
+
+The [`goal account listpartkeys`](../../../clis/goal/account/listpartkeys) command will check for any participation keys that live on the node and display pertinent information about them. 
+
+=== "goal"
+    ```zsh
+    $ goal account listpartkeys
+    Registered  Account      ParticipationID   Last Used  First round  Last round
+    yes         TUQ4...NLQQ  GOWHR456...              27            0     3000000
+    ```
+
+
+The output above is an example of `goal account listpartkeys` run from a particular node. It displays all partkeys and whether or not each key has been **registered**, the **filename** of the participation key, the **first** and **last** rounds of validity for the partkey, the **parent address** (i.e. the address of the participating account) and the **first key**. The first key refers to the key batch and the index in that batch (`<key-batch>.<index>`) of the latest key that has not been deleted. This is useful in verifying that your node is participating (i.e. the batch should continue to increment as keys are deleted). It can also help ensure that you don't store extra copies of registered participation keys that have past round keys intact. 
+
+
+!!! warning
+	It is okay to have multiple participation keys on a single node. However, if you generate multiple participation keys for the same account with overlapping rounds make sure you are aware of which one is the active one. It is recommended that you only keep one key per account - the active one - _except_ during partkey renewal when you switch from the old key to the new key. Renewing participation keys is discussed in detail in the [Renew Participation Keys](./renew.md) section.
+
+# View participation key info
+
+Use [`goal account partkeyinfo`](../../../clis/goal/account/partkeyinfo) to dump all the information about each participation key that lives on the node. This information is used to generate the online key registration transaction [described in the next section](./online.md).
+
+=== "goal"
+    ```zsh
+    $ goal account partkeyinfo
+    Dumping participation key info from /opt/data...
+
+    Participation ID:          GOWHR456IK3LPU5KIJ66CRDLZM55MYV2OGNW7QTZYF5RNZEVS33A
+    Parent address:            TUQ4HOIR3G5Z3BZUN2W2XTWVJ3AUUME4OKLINJFAGKBO4Y76L4UT5WNLQQ
+    Last vote round:           11
+    Last block proposal round: 12
+    Effective first round:     1
+    Effective last round:      3000000
+    First round:               0
+    Last round:                3000000
+    Key dilution:              10000
+    Selection key:             l6MsaTt7AiCAdG+69LG/wjaprsI1vImZuGN6gQ1jS88=
+    Voting key:                Rleu99r3UqlwuuhaxCTrTQUuq1C9qk5uJd2WQQEG+6U=
+    ```
+
+
+Above is the example output from a particular node. Use these values to create the [key registration transaction](../../../get-details/transactions#register-account-online) that will place the account online.

package/dist/resources/knowledge/taxonomy/developer:docs:run-a-node:participate:index.md

@@ -0,0 +1,56 @@
+title: Overview
+
+This section covers the procedure for registering an account to participate in the Algorand Consensus Protocol. It begins with a description of important concepts and best practices before getting started. 
+
+!!! tldr
+	- Accounts participate in the Algorand consensus protocol by generating a valid participation key and then registering that key online with a special online registration transaction.
+	- Accounts mark themselves online by submitting an [online key registration transaction](../../get-details/transactions#register-account-online) for a valid participation key.
+	- Accounts mark themselves offline by submitting an [offline key registration transaction](../../get-details/transactions#register-account-offline). 
+	- It is important to mark your account offline if it is not participating. Not doing so is bad network behavior and will decrease the honest/dishonest user ratio that underpins the liveness of the agreement protocol.
+	- It is important to ensure that only the latest update of the participation key ever exists at any time.
+	- In the event of node migration, hardware swap, or other similar events, it is preferable to have your participation key offline for a few rounds than to have it present on multiple nodes at the same time.
+
+# Important Concepts
+
+## Online Participation
+In the context of this section, participation means participation in the Algorand consensus protocol. An account that participates in the Algorand consensus protocol is eligible and available to be selected to propose and vote on new blocks in the Algorand blockchain. Note that the likelihood that this account will be selected to propose and vote on blocks is proportional to its amount of stake. Read more about voting and block proposals in the [Algorand Consensus Protocol overview](../../get-details/algorand_consensus#the-algorand-consensus-protocol).
+
+!!! info
+    Participation in consensus currently does not affect the proportion of participation rewards an account receives. Participation rewards are [based on the amount](https://algorand.foundation/rewards-faq) of stake an account has, irrespective of whether the account is marked online or offline. Furthermore, currently there are no participation rewards on MainNet.
+
+## Online/Offline Status
+In order for an account to participate in consensus, it must first mark itself online. Marking an account online requires the account to have a valid participation key, which has been registered with the network by way of an [online key registration transaction](../../get-details/transactions#register-account-online), authorized by the participating account. Marking an account offline requires an [offline key registration transaction](../../get-details/transactions#register-account-offline) also authorized by the private key of the participating account.
+
+# Guidelines for a Healthy Network
+
+## Ensure that Online Accounts are Participating
+If an account registers itself online, it is important that its participation key is online. _A participation key is online if there is a single fully-synchronized node on the Algorand network that has that key in its ledger directory._ You should always mark an account offline if it is not actually available to participate, since the network uses the online/offline status of an account to calculate block vote thresholds. If you are marked online but you are not participating, you would be considered a dishonest user and will negatively impact the voting threshold. Furthermore, if your node experiences issues you are not able to solve promptly, it is recommended that you register the account offline as soon as possible.
+
+!!! tip
+	If you keep your private keys in cold storage, it is recommended that you generate and sign enough offline transactions to be able to take the account offline in case of emergencies. Learn more about generating transactions for future rounds in the [Transactions guide](../../get-details/transactions#). Learn how to create and authorize transactions offline in the [Authorizing Transactions Offline](../../get-details/transactions/offline_transactions) guide.
+
+## Renew participation keys before they expire
+Participation keys are valid for a specific round range. Make sure to renew participation keys or mark the account offline before the current participation key expires. Your account will _not_ automatically be marked offline.
+
+_Visit the [Renew Participation Keys section](./renew.md) for detailed instructions._
+
+## Ensure that Participation Nodes are working properly
+
+Monitor your participation node to ensure high performance and consistent access to your registered participation key. 
+The following should be monitored:
+
+* last committed block (`goal node status` or API) matches a third-party API service
+* CPU / RAM / disk use are within thresholds
+* clock is accurate (blocks are timestamped using the clock time from the block proposer's node, so keep your node clock accurate and on time)
+* the participation node is sending votes and proposing blocks at the expected frequency.
+
+## Securely Store Participation Keys
+
+Registered participation keys that are in operation are regularly updated through the protocol so that they cannot be used to vote on earlier rounds. Essentially, the set of keys corresponding to earlier rounds are deleted after the round passes to ensure that the compromise of a participation key by a bad actor does not give the bad actor the potential to rewrite history. Because of this, it is important that there only exists a single instance of the participation key (files ending in `*.partkey`) at any time in the system. 
+
+!!! warning
+	Because of this, holding backups of participation keys is highly discouraged, unless appropriate procedures are setup to purge those backups on a regular basis.
+
+# Technical Procedure
+
+The rest of this section will describe how to [generate a participation key](./generate_keys.md) for an account, [mark or register the account online](./online.md) (with the generated participation key), [mark or register an account offline](./offline.md), and [renew a participation key](./renew.md) for an account.

package/dist/resources/knowledge/taxonomy/developer:docs:run-a-node:participate:offline.md

@@ -0,0 +1,83 @@
+title: Register offline
+
+To mark an account **offline** send a key registration transaction to the network authorized by the account to be marked offline. The signal to mark the sending account offline is the issuance of a `"type": "keyreg"` transaction that does not contain any participation key-related fields (i.e. they are all set to null values)
+
+!!! info "Important"
+	Just like with online keyreg transactions. The moment a key registration transaction is confirmed by the network it takes 320 rounds for the change to take effect. So, if a key registration is confirmed in round 5000, the account will stop participating at round 5320.
+
+# Create an offline key registration transaction
+
+Create an offline key registration transaction for the address: `EW64GC6F24M7NDSC5R3ES4YUVE3ZXXNMARJHDCCCLIHZU6TBEOC7XRSBG4` by inserting the following code snippet into the construction portion of the example shown in [Authorizing Transactions Offline](../../../get-details/transactions/offline_transactions#unsigned-transaction-file-operations). The file produced and displayed with `goal clerk inspect` should look almost exactly the same as the output shown in the [constructing a register offline transaction example](../../../get-details/transactions#register-account-offline). 
+
+=== "Python"
+    <!-- ===PYSDK_TRANSACTION_KEYREG_OFFLINE_CREATE=== -->
+	```python
+	# get suggested parameters
+	params = algod_client.suggested_params()
+	
+	# create keyreg transaction to take this account offline
+	offline_keyreg = transaction.KeyregTxn(
+	    sender="EW64GC6F24M7NDSC5R3ES4YUVE3ZXXNMARJHDCCCLIHZU6TBEOC7XRSBG4",
+	    sp=params,
+	    votekey=None,
+	    selkey=None,
+	    votefst=None,
+	    votelst=None,
+	    votekd=None,
+	)
+	print(online_keyreg.dictify())
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/participation.py#L29-L43)
+    <!-- ===PYSDK_TRANSACTION_KEYREG_OFFLINE_CREATE=== -->
+
+=== "JavaScript"
+    <!-- ===JSSDK_TRANSACTION_KEYREG_OFFLINE_CREATE=== -->
+	```javascript
+	// get suggested parameters
+	const suggestedParams = await algodClient.getTransactionParams().do();
+	// create keyreg transaction to take this account offline
+	const offlineKeyReg = algosdk.makeKeyRegistrationTxnWithSuggestedParamsFromObject(
+	  {
+	    from: addr,
+	    suggestedParams,
+	  }
+	);
+	console.log(offlineKeyReg.get_obj_for_encoding());
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/participation.ts#L44-L54)
+    <!-- ===JSSDK_TRANSACTION_KEYREG_OFFLINE_CREATE=== -->
+
+=== "Go"
+    <!-- ===GOSDK_TRANSACTION_KEYREG_OFFLINE_CREATE=== -->
+    <!-- ===GOSDK_TRANSACTION_KEYREG_OFFLINE_CREATE=== -->
+
+=== "Java"
+    <!-- ===JAVASDK_TRANSACTION_KEYREG_OFFLINE_CREATE=== -->
+	```java
+	// create keyreg transaction to take this account offline
+	Transaction keyRegOfflineTxn = Transaction.KeyRegistrationTransactionBuilder().suggestedParams(sp)
+	        .sender(address)
+	        .build();
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/Participation.java#L37-L41)
+    <!-- ===JAVASDK_TRANSACTION_KEYREG_OFFLINE_CREATE=== -->
+
+=== "goal"
+    <!-- ===GOAL_TRANSACTION_KEYREG_OFFLINE_CREATE=== -->
+    ```zsh
+    $ goal account changeonlinestatus --address=EW64GC6F24M7NDSC5R3ES4YUVE3ZXXNMARJHDCCCLIHZU6TBEOC7XRSBG4 --fee=1000 --firstvalid=7000000 --lastvalid=7001000 --online=false --txfile=offline.txn
+    ```
+    <!-- ===GOAL_TRANSACTION_KEYREG_OFFLINE_CREATE=== -->
+
+# Authorize and Send the Transaction
+Use the appropriate [authorization method](../../../get-details/transactions/signatures) to sign the transaction. 
+
+!!! tip
+    It is recommended that you authorize the transaction offline to protect the security of your private keys, especially for high-value participating accounts. 
+
+Once the transaction is signed, wait for the network to reach the transaction's first valid round and then [submit](../../../archive/build-apps/hello_world#submit-the-transaction) and the SDK Method "wait for confirmation". 
+
+**See also**
+
+- [Key Registration Transactions](../../../get-details/transactions#key-registration-transaction)
+- [Register account offline](../../../get-details/transactions#register-account-offline)

package/dist/resources/knowledge/taxonomy/developer:docs:run-a-node:participate:online.md

@@ -0,0 +1,170 @@
+title: Register online
+
+This section assumes that you have already [generated a participation key](generate_keys.md) for the account you plan to mark online. 
+
+Registering an account online requires authorizing a [key registration transaction](../../get-details/transactions/index.md#key-registration-transaction) with details of the participation key that will vote on the account's behalf. Once the transaction is processed by the blockchain, the Verifiable Random Function public key (referred to as the VRF public key) is written into the account’s data and the account will start participating in consensus with that key. This VRF public key is how the account is associated with the specific participation keys.
+
+!!! info "Important"
+	The moment a key registration transaction is confirmed by the network it takes 320 rounds for the change to take effect. In other words, if a key registration is confirmed in round 1000, the account will not start participating until round 1320.
+
+# Create an online key registration transaction
+
+Create a key registration transaction for the address: `EW64GC6F24M7NDSC5R3ES4YUVE3ZXXNMARJHDCCCLIHZU6TBEOC7XRSBG4` by inserting the following code snippet into the construction portion of the example shown in [Authorizing Transactions Offline](../../get-details/transactions/offline_transactions.md#unsigned-transaction-file-operations). The file produced and displayed with `goal clerk inspect` should look almost exactly the same as the output shown in the [constructing a register online transaction example](../../get-details/transactions/index.md#register-account-online). 
+
+
+=== "JavaScript"
+    <!-- ===JSSDK_TRANSACTION_KEYREG_ONLINE_CREATE=== -->
+	```javascript
+	// get suggested parameters
+	const params = await algodClient.getTransactionParams().do();
+	
+	// Parent addr
+	const addr = 'MWAPNXBDFFD2V5KWXAHWKBO7FO4JN36VR4CIBDKDDE7WAUAGZIXM3QPJW4';
+	// VRF public key
+	const selectionKey = 'LrpLhvzr+QpN/bivh6IPpOaKGbGzTTB5lJtVfixmmgk=';
+	// Voting pub key
+	const voteKey = 'G/lqTV6MKspW6J8wH2d8ZliZ5XZVZsruqSBJMwLwlmo=';
+	// State proof key
+	const stateProofKey =
+	  'RpUpNWfZMjZ1zOOjv3MF2tjO714jsBt0GKnNsw0ihJ4HSZwci+d9zvUi3i67LwFUJgjQ5Dz4zZgHgGduElnmSA==';
+	
+	// sets up keys for 100000 rounds
+	const numRounds = 1e5;
+	
+	// dilution default is sqrt num rounds
+	const keyDilution = numRounds ** 0.5;
+	
+	// create transaction
+	const onlineKeyreg = algosdk.makeKeyRegistrationTxnWithSuggestedParamsFromObject(
+	  {
+	    from: addr,
+	    voteKey,
+	    selectionKey,
+	    stateProofKey,
+	    voteFirst: params.firstRound,
+	    voteLast: params.firstRound + numRounds,
+	    voteKeyDilution: keyDilution,
+	    suggestedParams: params,
+	  }
+	);
+	
+	console.log(onlineKeyreg.get_obj_for_encoding());
+	```
+	[Snippet Source](https://github.com/algorand/js-algorand-sdk/blob/examples/examples/participation.ts#L7-L41)
+    <!-- ===JSSDK_TRANSACTION_KEYREG_ONLINE_CREATE=== -->
+
+=== "Python"
+    <!-- ===PYSDK_TRANSACTION_KEYREG_ONLINE_CREATE=== -->
+	```python
+	# get suggested parameters
+	params = algod_client.suggested_params()
+	
+	votekey = "eXq34wzh2UIxCZaI1leALKyAvSz/+XOe0wqdHagM+bw="
+	selkey = "X84ReKTmp+yfgmMCbbokVqeFFFrKQeFZKEXG89SXwm4="
+	
+	num_rounds = int(1e5)  # sets up keys for 100000 rounds
+	key_dilution = int(num_rounds**0.5)  # dilution default is sqrt num rounds
+	
+	# create transaction
+	online_keyreg = transaction.KeyregTxn(
+	    sender="EW64GC6F24M7NDSC5R3ES4YUVE3ZXXNMARJHDCCCLIHZU6TBEOC7XRSBG4",
+	    votekey=votekey,
+	    selkey=selkey,
+	    votefst=params.first,
+	    votelst=params.first + num_rounds,
+	    votekd=key_dilution,
+	    sp=params,
+	)
+	print(online_keyreg.dictify())
+	```
+	[Snippet Source](https://github.com/algorand/py-algorand-sdk/blob/examples/examples/participation.py#L6-L26)
+    <!-- ===PYSDK_TRANSACTION_KEYREG_ONLINE_CREATE=== -->
+
+=== "Java"
+    <!-- ===JAVASDK_TRANSACTION_KEYREG_ONLINE_CREATE=== -->
+	```java
+	// get suggested parameters
+	Response<TransactionParametersResponse> rsp = algodClient.TransactionParams().execute();
+	TransactionParametersResponse sp = rsp.body();
+	
+	String address = "EW64GC6F24M7NDSC5R3ES4YUVE3ZXXNMARJHDCCCLIHZU6TBEOC7XRSBG4";
+	
+	String votekey = "eXq34wzh2UIxCZaI1leALKyAvSz/+XOe0wqdHagM+bw=";
+	String skey = "X84ReKTmp+yfgmMCbbokVqeFFFrKQeFZKEXG89SXwm4=";
+	
+	Long numRounds = 100000l; // sets up keys for 100000 rounds
+	Long keyDilution = (long) Math.sqrt(numRounds); // dilution default is sqrt num rounds
+	
+	Transaction keyRegTxn = Transaction.KeyRegistrationTransactionBuilder().suggestedParams(sp)
+	        .sender(address)
+	        .selectionPublicKeyBase64(skey)
+	        .participationPublicKeyBase64(votekey)
+	        .voteFirst(sp.lastRound)
+	        .voteLast(sp.lastRound + numRounds)
+	        .voteKeyDilution(keyDilution)
+	        .build();
+	// ... sign and send to network
+	```
+	[Snippet Source](https://github.com/algorand/java-algorand-sdk/blob/examples/examples/src/main/java/com/algorand/examples/Participation.java#L13-L34)
+    <!-- ===JAVASDK_TRANSACTION_KEYREG_ONLINE_CREATE=== -->
+
+=== "Go"
+    <!-- ===GOSDK_TRANSACTION_KEYREG_ONLINE_CREATE=== -->
+	```go
+	fromAddr := "MWAPNXBDFFD2V5KWXAHWKBO7FO4JN36VR4CIBDKDDE7WAUAGZIXM3QPJW4"
+	voteKey := "87iBW46PP4BpTDz6+IEGvxY6JqEaOtV0g+VWcJqoqtc="
+	selKey := "1V2BE2lbFvS937H7pJebN0zxkqe1Nrv+aVHDTPbYRlw="
+	sProofKey := "f0CYOA4yXovNBFMFX+1I/tYVBaAl7VN6e0Ki5yZA3H6jGqsU/LYHNaBkMQ/rN4M4F3UmNcpaTmbVbq+GgDsrhQ=="
+	voteFirst := uint64(16532750)
+	voteLast := uint64(19532750)
+	keyDilution := uint64(1732)
+	nonpart := false
+	tx, err := transaction.MakeKeyRegTxnWithStateProofKey(
+		fromAddr,
+		[]byte{},
+		sp,
+		voteKey,
+		selKey,
+		sProofKey,
+		voteFirst,
+		voteLast,
+		keyDilution,
+		nonpart,
+	)
+	```
+	[Snippet Source](https://github.com/algorand/go-algorand-sdk/blob/examples/examples/participation/main.go#L27-L47)
+    <!-- ===GOSDK_TRANSACTION_KEYREG_ONLINE_CREATE=== -->
+
+=== "goal"
+    <!-- ===GOAL_TRANSACTION_KEYREG_ONLINE_CREATE=== -->
+    ```zsh 
+    # WARNING: This command must be run on the node where the partkey lives and the node
+    # must only have a single partkey for the account. Otherwise the command will
+    # choose one at random.
+    $ goal account changeonlinestatus --address=EW64GC6F24M7NDSC5R3ES4YUVE3ZXXNMARJHDCCCLIHZU6TBEOC7XRSBG4 --fee=2000 --firstvalid=6002000 --lastvalid=6003000 --online=true --txfile=online.txn
+    ```
+    <!-- ===GOAL_TRANSACTION_KEYREG_ONLINE_CREATE=== -->
+
+# Authorize and Send the Transaction
+Use the appropriate [authorization method](../../../get-details/transactions/signatures) to sign the transaction. 
+
+!!! tip
+    It is recommended that you authorize the transaction offline to protect the security of your private keys, especially for high-value participating accounts. 
+
+[Verify that the participation key is on the node](../generate_keys#check-that-the-key-exists) prior to submitting the signed transaction. Once verified, wait for the network to reach the transaction's first valid round, then [submit](../../../archive/build-apps/hello_world#submit-the-transaction) the transaction and the SDK method "wait for confirmation".
+
+# Check that the node is participating
+
+At any time, you can validate whether your node is participating by `grep`-ing the `node.log` file in your data directory, looking for a `"VoteBroadcast"` messages where the `"Sender"` is your public key participation address.
+
+```
+$ grep 'VoteBroadcast' node.log
+...
+{"Context":"Agreement","Hash":"QJADVNJZDXYEQUPHITB6REFDGBY4AHBPPBIPVXLOPOASZA4T3PIA","ObjectPeriod":0,"ObjectRound":896659,"ObjectStep":2,"Period":0,"Round":0,"Sender":"3IE2GDYYSI56U53AQ6UUWRGAIGG5D4RHWLMCXJOPWQJA2ABF2X2A","Step":0,"Type":"VoteBroadcast","Weight":1,"WeightTotal":1,"file":"pseudonode.go","function":"github.com/algorand/go-algorand/agreement.pseudonodeVotesTask.execute","level":"info","line":344,"msg":"vote created for broadcast (weight 1, total weight 1)","time":"2019-05-10T18:38:54.137592-04:00"}
+...
+```
+
+**See also**
+
+- [Key Registration Transactions](../../../get-details/transactions/#key-registration-transaction)
+- [Register account online](../../../get-details/transactions/#register-account-online)

package/dist/resources/knowledge/taxonomy/developer:docs:run-a-node:participate:renew.md

@@ -0,0 +1,29 @@
+title: Renew participation keys
+
+The process of renewing a participation key is simply creating a new participation key and registering it online before the previous key expires.
+
+You can renew a participation key anytime before it expires, and we recommend to do it at least two weeks (about 268,800 rounds) in advance so as not to risk [having an account marked as online that is not participating](./index.md#ensure-that-online-accounts-are-participating).
+
+The validity ranges of participation keys can overlap. For any account, at any time, at most one participation key is registered, namely the one included in the latest online key registration transaction for this account. 
+
+
+# Step-by-Step
+1. [Create a new participation key](./generate_keys.md) with a first voting round that is less than the last voting round of the current participation key. It should leave enough time to carry out this whole process (e.g. 40,000 rounds).
+2. Once the network reaches the first voting round for the new key, [submit an online key registration transaction for the new participation key](./online.md).
+3. Wait at least 320 rounds to [validate that the node is participating](./online.md#check-that-the-node-is-participating).
+4. Once participation is confirmed, it is safe to [delete the old participation key](#removing-old-keys).
+
+<center> ![Renewal Window](../../imgs/renew-0.png) </center>
+<center>*Example key rotation window* </center>
+
+!!! info
+	`goal` supplies single commands to renew all participation keys on a node ([`goal account renewallpartkeys`](../../../clis/goal/account/renewallpartkeys)) or renew the participation key for a specific account ([`goal account renewpartkey`](../../../clis/goal/account/renewpartkey)). It is recommended that you only use these for testing purposes or for very low-stake accounts, since both of them require your private keys to be online.
+
+# Removing Old Keys
+
+When a participation key is no longer in use, you can remove it by running the following goal command with the participation ID of the key you want to remove.
+
+```bash
+$ goal account deletepartkey --partkeyid IWBP2447JQIT54XWOZ7XKWOBVITS2AEIBOEZXDACX5Q6DZ4Z7VHA
+```
+Make sure to identify the correct key (i.e. make sure it is _not_ the currently registered key) before deleting.