GITBOOK-187: Some nits

Trevor Porter · gitbook-bot · commit 057ec10d39fc · 2023-04-12T11:25:46.000Z
diff --git a/.gitbook/assets/Screen Shot 2022-11-02 at 5.52.14 PM (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (2) (1) (1).png b/.gitbook/assets/Screen Shot 2022-11-02 at 5.52.14 PM (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (1) (2) (2) (1) (1).png
diff --git a/deploy/deploy-hyperlane/README.md b/deploy/deploy-hyperlane/README.md
@@ -21,5 +21,5 @@ At a high level, deploying Hyperlane requires the following actions:
 1. Setting up the [keys.md](keys.md "mention") you will use to deploy contracts and run validators and relayers
 2. Deploying Hyperlane contracts to the local chain and to every remote chain with which the local chain will be able to send and receive messages.
 3. Running one or more [validators.md](../../protocol/agents/validators.md "mention") for the new chain, to provide security for outgoing messages
-4. Running [relayer.md](../../protocol/agents/relayer.md "mention") for the local chain and every remote chain which which the local chain will be able to send and receive messages.
+4. Running [relayer.md](../../protocol/agents/relayer.md "mention") for the local chain and every remote chain with which the local chain will be able to send and receive messages.
 5. Testing that messages can be sent from the local chain to each of the remote chains, and vice versa.&#x20;
diff --git a/deploy/deploy-hyperlane/deploy-contracts.md b/deploy/deploy-hyperlane/deploy-contracts.md
@@ -46,7 +46,7 @@ export const chains: ChainMap<ChainMetadata> = {
 };
 ```
 
-Finally, add the `MultisigIsmConfig` entry for your local chaina to `hyperlane-deploy/config/multisig_ism.ts`. An example with a single validator has been populated for you for `anvil`.
+Finally, add the `MultisigIsmConfig` entry for your local chain to `hyperlane-deploy/config/multisig_ism.ts`. An example with a single validator has been populated for you for `anvil`.
 
 ```typescript
 export const multisigIsmConfig: ChainMap<MultisigIsmConfig> = {
diff --git a/operators/agent-configuration.md b/operators/agent-configuration.md
@@ -34,7 +34,7 @@ Mounting an entire directory can be done with the flag `--mount source=$LOCAL_CO
 For example, suppose you have a config file at your local machine's path `/home/workspace/ethereum.json` and want to run the validator with it.
 
 {% code title="Example" overflow="wrap" %}
-```
+```sh
 docker run -it --mount type=bind,source=/home/workspace/ethereum.json,target=/config/ethereum.json,readonly -e CONFIG_FILES=/config/ethereum.json $DOCKER_IMAGE ./validator
 ```
 {% endcode %}
diff --git a/operators/agent-keys/hexadecimal-key-setup.md b/operators/agent-keys/hexadecimal-key-setup.md
@@ -7,7 +7,7 @@ description: Generating a raw hexadecimal key
 Using hexadecimal keys is the easiest and fastest way to configure Hyperlane agents.
 
 {% hint style="warning" %}
-Hexadecimal keys are not recommended for production environments, for which [aws-setup.md](aws-setup.md "mention") are recommended.,&#x20;
+Hexadecimal keys are not recommended for production environments, for which [aws-setup.md](aws-setup.md "mention") are recommended.
 {% endhint %}
 
 ### Generate a hexadecimal key&#x20;
diff --git a/operators/relayers/README.md b/operators/relayers/README.md
@@ -4,12 +4,10 @@ description: Everything you need to start running a relayer
 
 # Relayers
 
-Hyperlane [relayers](../../../protocol/agents/relayer.md) deliver interchain messages to their recipients.
+Hyperlane [relayers](../../protocol/agents/relayer.md) deliver interchain messages to their recipients.
 
-Every Hyperlane message requires two transactions to be delivered, one on the origin chain to [dispatch](../../../apis/messaging-api/send.md) the message, and one on the destination chain to [process](../../../apis/messaging-api/receive.md) the messages. Relayers are responsible for sending the second transaction.
+Every Hyperlane message requires two transactions to be delivered, one on the origin chain to [dispatch](../../apis/messaging-api/send.md) the message, and one on the destination chain to [process](../../apis/messaging-api/receive.md) the messages. Relayers are responsible for sending the second transaction.
 
-<!-- INCLUDE diagrams/interchain-gas.md -->
-<!-- WARNING: copied from the included file path. Do not edit directly. -->
 ```mermaid
 %%{ init: {
   "theme": "neutral",
@@ -46,23 +44,20 @@ flowchart TB
     click IGP https://github.com/hyperlane-xyz/hyperlane-monorepo/blob/main/solidity/contracts/igps/InterchainGasPaymaster.sol
 ```
 
-<!-- WARNING: copied from the included file path. Do not edit directly. -->
-<!-- END -->
-
 Hyperlane relayers are run on a per-origin-chain basis, delivering outbound messages from that chain to one or more remote chains. Relayers have no special permissions in Hyperlane. If relayer keys are compromised, only the tokens held by those keys are at risk.
 
 Running a relayer requires the following:
 
 #### RPC nodes
 
-Relayers use RPC nodes to read the origin chain, and deliver messages to the destination chain(s). Relayers  must be configured with an RPC node for the origin chain, and each destination chain.&#x20;
+Relayers use RPC nodes to read the origin chain, and deliver messages to the destination chain(s). Relayers must be configured with an RPC node for the origin chain, and each destination chain.
 
 #### One or more signing keys
 
 In order to deliver messages, relayers must be configured with a signing key for each destination chain.
 
-The relayer uses this key to sign `Mailbox.process()` transactions. The Hyperlane relayer agent currently supports configuration with raw private keys.
+The relayer uses this key to sign `Mailbox.process()` transactions. The Hyperlane relayer agent currently supports configuration with AWS KMS keys that are accessed via API keys/secrets or raw hexadecimal private keys.
 
 #### A machine to run on
 
-Relayers can compile the rust binary themselves, or run a docker image provided by Abacus Works. The binary can be run using your favorite cloud service.
+Relayers can compile the Rust binary themselves, or run a Docker image provided by Abacus Works. The binary can be run using your favorite cloud service.
diff --git a/operators/relayers/message-filtering.md b/operators/relayers/message-filtering.md
@@ -49,6 +49,6 @@ For example, the following config used as a whitelist will ensure the relayer wi
 ]
 ```
 
-As a string, a valid config may look like `HYP_RELAYER_WHITELIST='[{"senderAddress":"","destinationDomain":["1"],"recipientAddress":""},{"senderAddress":"0xca7f632e91B592178D83A70B404f398c0a51581F","destinationDomain":["42220","43114"],"recipientAddress":""},{"senderAddress":"","destinationDomain":["42161","420"],"recipientAddress":"0xca7f632e91B592178D83A70B404f398c0a51581F"}]'`
+As a string, a valid config may look like `HYP_RELAYER_WHITELIST='[{"senderAddress":"*","destinationDomain":["1"],"recipientAddress":"*"},{"senderAddress":"0xca7f632e91B592178D83A70B404f398c0a51581F","destinationDomain":["42220","43114"],"recipientAddress":"*"},{"senderAddress":"*","destinationDomain":["42161","420"],"recipientAddress":"0xca7f632e91B592178D83A70B404f398c0a51581F"}]'`
 
 The blacklist supersedes the whitelist, i.e. if a message matches both the whitelist _and_ the blacklist, it will not be delivered.
diff --git a/operators/relayers/setup.md b/operators/relayers/setup.md
@@ -4,7 +4,7 @@ description: Required setup instructions
 
 # Setup
 
-The relayer is responsible for delivering messages to their destination chains. This involves being able to submit transactions to many destination chains, and therefore requires access to a key for signing transaction. There are two supported key types: hexadecimal private keys (for in-memory signing), and AWS KMS based keys (best practice for production environments).
+The relayer is responsible for delivering messages to their destination chains. This involves being able to submit transactions to many destination chains, and therefore requires access to a key for signing transactions. There are two supported key types: hexadecimal private keys (for in-memory signing), and AWS KMS based keys (best practice for production environments).
 
 ## Hexadecimal keys
 
diff --git a/operators/validators/README.md b/operators/validators/README.md
@@ -83,8 +83,8 @@ The Hyperlane validator agent currently supports signing with AWS KMS keys that
 
 Validators write their signatures off-chain to publicly accessible, highly available, storage, so that they can be aggregated by [relayers](../../protocol/agents/relayer.md).
 
-The Hyperlane validator agent currently supports storing signatures on AWS S3 using the same AWS API key above.
+The Hyperlane validator agent currently supports storing signatures on AWS S3 using the same AWS API key above, as well as storing signatures in the local filesystem for testing.
 
 #### A machine to run on
 
-Validators can compile the rust binary themselves, or run a docker image provided by Abacus Works. The binary is completely stateless and can be run using your favorite cloud service. You can even run multiple instances of them in different regions for high availability, as Hyperlane has no notion of "double signing".
+Validators can compile the Rust binary themselves, or run a Docker image provided by Abacus Works. The binary is completely stateless and can be run using your favorite cloud service. You can even run multiple instances of them in different regions for high availability, as Hyperlane has no notion of "double signing".
diff --git a/operators/validators/announcing-your-validator.md b/operators/validators/announcing-your-validator.md
@@ -70,7 +70,7 @@ Now you can submit your signed announcement to the `ValidatorAnnounce` smart con
 
 {% tab title="Cast" %}
 1. Announce your validator by running the following command, filling in the following variables:
-   1. Set `$VALIDATOR_ANNOUNCE_ADDRESS` to the address of the `ValidatorAnnounce` contract: [addresses.md](../../resources/addresses.md "mention")
+   1. Set `$VALIDATOR_ANNOUNCE_ADDRESS` to the address of the `ValidatorAnnounce` contract for your origin chain. You can find addresses for existing deployments here: [addresses.md](../../resources/addresses.md "mention")
    2. Set `$VALIDATOR` to `value.validator` from your JSON announcement
    3. Set `$STORAGE_LOCATION` to `value.storage_location` from your JSON announcement
    4. Set `$SIGNATURE` to the `serialized_signature` from your JSON announcement.
diff --git a/operators/validators/environment-variables.md b/operators/validators/environment-variables.md
@@ -4,28 +4,28 @@ description: Configure your validator
 
 # Environment variables
 
-Make sure that you have completed [local-setup.md](setup/local-setup.md "mention") or [aws-setup.md](setup/aws-setup.md "mention")
+Make sure that you have completed [local-setup.md](setup/local-setup.md "mention") or [aws-setup.md](setup/aws-setup.md "mention").
 
 Also take a look at the [agent-configuration.md](../agent-configuration.md "mention") page.
 
 ### Environment variables
 
 Your validator takes environment variables as configuration. See below for these environment variables & those that are specific to the setup instructions you followed.
 
-| Environment variable                                 | Description                                                                                                                                                                                                                                                                                                                                                 |
-| ---------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
-| `CONFIG_FILES`                                       | If you want support your own chain that you [permissionlessly deployed](broken-reference), you specify the path to that agent config file here as well.                                                                                                                                                                                                     |
-| `HYP_VALIDATOR_ORIGINCHAINNAME`                      | The name of the chain being validated (e.g. `ethereum`)                                                                                                                                                                                                                                                                                                     |
-| `HYP_VALIDATOR_REORGPERIOD`                          | <p>The number of block confirmations a validator should wait before signing the <code>Mailbox</code> merkle root. Note that signing a root that is later invalidated (i.e. due to a re-org) is considered fraudulent behavior and will eventually be slashable.</p><p>Suggestions <a href="environment-variables.md#suggested-reorg-periods">below</a>.</p> |
-| `HYP_VALIDATOR_INTERVAL`                             | <p>In seconds, the frequency with which the validator should poll the <code>Mailbox</code> merkle root.</p><p>Suggestions <a href="environment-variables.md#suggested-reorg-periods">below</a>.</p>                                                                                                                                                         |
-| `HYP_BASE_CHAINS_[origin chain name]_CONNECTION_URL` | <p>The RPC URL of the node for the chain you are validating. Note Polygon mainnet requires an RPC URL of an archive node (see <a data-mention href="./#an-rpc-node">#an-rpc-node</a>for details).<br>e.g. <code>HYP_BASE_CHAINS_ETHEREUM_CONNECTION_URL</code> or <code>HYP_BASE_CHAINS_POLYGON_CONNECTION_URL</code></p>                                   |
-| `HYP_BASE_METRICS`                                   | Set to `9090`, or any other port number you wish to expose Prometheus metrics on. Not specifying a value will result in metrics not being exposed.                                                                                                                                                                                                          |
-| `HYP_BASE_TRACING_LEVEL`                             | Specifies the log level, set to `info`                                                                                                                                                                                                                                                                                                                      |
-| `HYP_BASE_TRACING_FMT`                               | Specifies the format of the logs, set it to either `pretty` or `json`                                                                                                                                                                                                                                                                                       |
+| Environment variable                                 | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
+| ---------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `CONFIG_FILES`                                       | <p>If you want support your own chain that you <a href="broken-reference">permissionlessly deployed</a>, you specify the path to that agent config file here as well.<br>Note these files must be accessible within the filesystem your validator has access to. If you're running in Docker, see <a data-mention href="../agent-configuration.md#config-files-with-docker">#config-files-with-docker</a> for tips on mounting your config files into your Docker container.</p> |
+| `HYP_VALIDATOR_ORIGINCHAINNAME`                      | The name of the chain being validated (e.g. `ethereum`)                                                                                                                                                                                                                                                                                                                                                                                                                          |
+| `HYP_VALIDATOR_REORGPERIOD`                          | <p>The number of block confirmations a validator should wait before signing the <code>Mailbox</code> merkle root. Note that signing a root that is later invalidated (i.e. due to a re-org) is considered fraudulent behavior and will eventually be slashable.</p><p>Suggestions <a href="environment-variables.md#suggested-reorg-periods">below</a>.</p>                                                                                                                      |
+| `HYP_VALIDATOR_INTERVAL`                             | <p>In seconds, the frequency with which the validator should poll the <code>Mailbox</code> merkle root.</p><p>Suggestions <a href="environment-variables.md#suggested-reorg-periods">below</a>.</p>                                                                                                                                                                                                                                                                              |
+| `HYP_BASE_CHAINS_[origin chain name]_CONNECTION_URL` | <p>The RPC URL of the node for the chain you are validating. Note Polygon mainnet requires an RPC URL of an archive node (see <a data-mention href="./#an-rpc-node">#an-rpc-node</a>for details).<br>e.g. <code>HYP_BASE_CHAINS_ETHEREUM_CONNECTION_URL</code> or <code>HYP_BASE_CHAINS_POLYGON_CONNECTION_URL</code></p>                                                                                                                                                        |
+| `HYP_BASE_METRICS`                                   | Set to `9090`, or any other port number you wish to expose Prometheus metrics on. Not specifying a value will result in metrics not being exposed.                                                                                                                                                                                                                                                                                                                               |
+| `HYP_BASE_TRACING_LEVEL`                             | Specifies the log level, set to `info`                                                                                                                                                                                                                                                                                                                                                                                                                                           |
+| `HYP_BASE_TRACING_FMT`                               | Specifies the format of the logs, set it to either `pretty` or `json`                                                                                                                                                                                                                                                                                                                                                                                                            |
 
 #### Setup-specific environment variables
 
-These **required** environment variables differ based on which [setup](setup/) instructions you followed.
+These **required** environment variables differ based on which [setup](setup/ "mention") instructions you followed.
 
 {% tabs %}
 {% tab title="AWS setup" %}
@@ -63,7 +63,7 @@ These are required environment variables that are specific to the [local-setup.m
 
 ### Next
 
-Next, in the [Start validating](start-validating.md) section we will get the validator up and running.
+Next, in the [start-validating.md](start-validating.md "mention") section we will get the validator up and running.
 
 {% content-ref url="start-validating.md" %}
 [start-validating.md](start-validating.md)
diff --git a/operators/validators/start-validating.md b/operators/validators/start-validating.md
diff --git a/protocol/messaging.md b/protocol/messaging.md

Original file line number	Diff line number	Diff line change
`@@ -49,6 +49,6 @@ For example, the following config used as a whitelist will ensure the relayer wi`
`49`	`49`	`]`
`50`	`50`	```
`51`	`51`
`52`		-As a string, a valid config may look like `HYP_RELAYER_WHITELIST='[{"senderAddress":"","destinationDomain":["1"],"recipientAddress":""},{"senderAddress":"0xca7f632e91B592178D83A70B404f398c0a51581F","destinationDomain":["42220","43114"],"recipientAddress":""},{"senderAddress":"","destinationDomain":["42161","420"],"recipientAddress":"0xca7f632e91B592178D83A70B404f398c0a51581F"}]'`
	`52`	+As a string, a valid config may look like `HYP_RELAYER_WHITELIST='[{"senderAddress":"","destinationDomain":["1"],"recipientAddress":""},{"senderAddress":"0xca7f632e91B592178D83A70B404f398c0a51581F","destinationDomain":["42220","43114"],"recipientAddress":""},{"senderAddress":"","destinationDomain":["42161","420"],"recipientAddress":"0xca7f632e91B592178D83A70B404f398c0a51581F"}]'`
`53`	`53`
`54`	`54`	`The blacklist supersedes the whitelist, i.e. if a message matches both the whitelist _and_ the blacklist, it will not be delivered.`