feat: refactor docs navigation (#1327)

Author: Olanetsoft

CONTRIBUTING.md

@@ -4,12 +4,14 @@ We appreciate your interest in contributing to Axelar! This document `CONTRIBUTI
 
 ## Table of contents
 
-- [Getting Started](#getting-started)
-- [How to contribute](#how-to-contribute)
-  - [Code of Conduct](#code-of-conduct)
-    - [Standards](#our-standards)
-    - [Responsibilities](#our-responsibilities)
-- [Project structure](#project-structure)
+- [Contributing to Axelar](#contributing-to-axelar)
+  - [Table of contents](#table-of-contents)
+  - [Getting started](#getting-started)
+  - [How to contribute](#how-to-contribute)
+  - [Code of conduct](#code-of-conduct)
+    - [Standards](#standards)
+    - [Responsibilities](#responsibilities)
+  - [Project structure](#project-structure)
 
 ## Getting started
 
@@ -22,16 +24,16 @@ If you are new to contributing to open-source projects, we encourage you to read
 ## How to contribute
 
 1. Before you submit your Pull Request (PR), search the project for an open or closed PR related to your submission. You don't want to duplicate effort.
-2. Fork the repository within your user and clone it to your local machine.
-3. Install the dependencies for the project as indicated in the README.
-4. Create a new branch for your contribution with the following command:
+1. Fork the repository within your user and clone it to your local machine.
+1. Install the dependencies for the project as indicated in the README.
+1. Create a new branch for your contribution with the following command:
 
    ```shell
    git checkout -b my-fix-branch
    ```
 
-5. Make your changes in the new git branch.
-6. Commit your changes. Your commit message should follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification.
+1. Make your changes in the new git branch.
+1. Commit your changes. Your commit message should follow the [Conventional Commits](https://www.conventionalcommits.org/en/v1.0.0/) specification.
 
    ```shell
    git commit -a

src/content/docs/dev/amplifier/chain-integration/introduction.mdx

@@ -10,7 +10,7 @@ import { Callout } from "/src/components/callout";
 
 ## Integration Architecture
 
-To connect your chain to the Axelar network via the Interchain Amplifier, you'll need to build or instantiate 4 smart contracts and 1 relayer service.
+To connect your chain to the Axelar network via the Interchain Amplifier, you'll need to build or instantiate 5 smart contracts and 1 relayer service.
 
 - **Source Chain Gateway Contract**
   - Built using the tech stack of your chain, you'll need to deploy a smart contract implementing the [Cross-Chain Gateway Protocol](https://github.com/axelarnetwork/cgp-spec).

src/content/docs/dev/amplifier/introduction.mdx

@@ -1,4 +1,4 @@
-# Introduction to the Interchain Amplifier
+# Getting Started with Chain Integration
 
 import { Callout } from "/src/components/callout";
 
@@ -8,6 +8,8 @@ import { Callout } from "/src/components/callout";
   frequently for updates.
 </Callout>
 
+## What is the Interchain Amplifier?
+
 The Interchain Amplifier enables dynamic application-level connections of new blockchains and services to the Axelar network. dApp developers gain access to more new blockchains faster. Integrators can use Amplifier to connect their own chains to the Axelar Network. This enables generalized connections between blockchains using different technology stacks (Solidity, Rust, etc), consensus mechanisms (Proof of Stake, L2s), and blockchains from many different communities.
 
 The Interchain Amplifier is a set of on-chain contracts and related services that enable integrators to easily connect chains and off-chain capabilities to the Axelar network. It is part of Axelar's [Mobius Development Stack (MDS)](https://docs.axelar.dev/dev/what-is-mobius-development-stack/). Developers can then seamlessly build applications that take advantage of these chains and capabilities.
@@ -20,11 +22,34 @@ The Amplifier consists of the following, all on the Axelar network:
 - Gateways
 - CosmWasm methods for receiving and sending messages
 
-To connect to the Amplifier, integrators should:
+## Integration Architecture
+
+To connect your chain to the Axelar network via the Interchain Amplifier, you'll need to build or instantiate 4 smart contracts and 1 relayer service:
+
+- **Source Chain Gateway Contract**
+  - Built using the tech stack of your chain, you'll need to deploy a smart contract implementing the [Cross-Chain Gateway Protocol](https://github.com/axelarnetwork/cgp-spec).
+  - For EVM chains, you can re-use the existing [EVM Gateway](https://github.com/axelarnetwork/axelar-cgp-solidity).
+  - This contract serves as the primary API for developers sending messages from your chain.
+- **Verifier Contract**
+  - A smart contract on the Axelar network that verifies the validity of transactions on your chain.
+  - Most integrators will begin by using or customizing a [Voting Verifier](https://github.com/axelarnetwork/axelar-amplifier/tree/main/contracts/voting-verifier) or can be customized to your needs for cases such as verification via ZK Proof.
+  - If you deploy a Voting Verifier, verifiers will need to support your chain and vote on the truth of source chain transactions.
+- **Gateway Contract**
+  - A gateway contract that exists on the Axelar network that will know how to use your verifier contract to check the validity of a transaction and then knows how to forward transactions onto the Amplifier router.
+  - Most integrators will begin by using or customizing this [Gateway Contract](https://github.com/axelarnetwork/axelar-amplifier/tree/main/contracts/gateway).
+- **Prover Contract**
+  - A smart contract on the Axelar network that knows how to prove the validity of a transaction on your chain.
+  - Most integrators will begin by using or customizing the [multisig prover](https://github.com/axelarnetwork/axelar-amplifier/tree/main/contracts/multisig-prover)
+- **Message Relayer**
+  - A service built with any tech stack that listens for events on your chain and relays them to the Axelar network.
+  - Get started with our [Message Relayer Example](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/amplifier)
+  - Setup your relayer to send data to the Axelarscan API (TBD) related to transactions with your network
+- **Governance Contract**
+  - A source chain contract that can receive messages from the Axelar Network representing governance decisions, such as updating your gateway.
+- **Gas Table Updater**
+  - A service that updates the gas table, so that gas price estimations involving your chain are accurate.
 
-- Implement and deploy a Gateway to the Axelar Network
-- Work with verifiers to vote, prove, and attest to message validity
-- Provide relaying infrastructure to identify incoming messages and act on outgoing messages
+The [chain integration guide](/dev/amplifier/chain-integration/integrate-a-chain) will walk you through this process within the current Amplifier DevNet. Contract deployment on Testnet or Mainnet will require governance proposal.
 
 ## General Message Passing with Amplifier
 
@@ -33,21 +58,57 @@ The following diagram shows how the Amplifier handles General Message Passing:
 <object
   type="image/svg+xml"
   data="/images/assets/axelar_amplifier-introduction-diagram_dark.svg"
- 
   class="hidden dark:block w-full max-w-[60rem] mx-auto py-6"
 >
   Your browser does not support SVG
 </object>
 <object
   type="image/svg+xml"
   data="/images/assets/axelar_amplifier-introduction-diagram_light.svg"
- 
   class=" dark:hidden w-full max-w-[60rem] mx-auto py-6"
 >
   Your browser does not support SVG
 </object>
 
-
 See the [GMP with Amplifier example](/dev/amplifier/gmp-example) for additional details.
 
 Developers who are looking to send messages between chains connected via Amplifier don't need to worry about working directly with the Amplifier themselves. They can use standard [General Message Passing (GMP)](/dev/general-message-passing/overview) to send messages between chains via a gateway available on the source chain. Amplifier will handle the verification, routing, and proving of messages between chains.
+
+## Integration Process
+
+Most integrators will follow the following process:
+
+1. Learn & Understand Amplifier
+   - Follow the [chain integration guide](/dev/amplifier/chain-integration/integrate-a-chain) to deploy standardize contracts to the DevNet to understand the tools and basics of the process.
+1. Customize and Deploy to DevNet
+   - Build (or instantiate or customize) each of the [required contracts and the relayer](#integration-architecture).
+   - You may choose to change the logic of your verifier contract (for ZK use cases for example) or prover contract.
+1. Whitelist contracts
+   - For the DevNet [use the form](https://docs.google.com/forms/d/e/1FAIpQLSchD7P1WfdSCQfaZAoqX7DyqJOqYKxXle47yrueTbOgkKQDiQ/viewform) to ask to be whitelisted
+1. Become a [verifier](/validator/amplifier/verifier-onboarding) for your chain.
+   - To test your chain, you will need active verifiers to vote on messages from your chain
+1. Test your integration
+   - Make sure you can send and receive messages on your chain.
+1. Begin audit process
+   - You should audit your on-chain contracts.
+1. Propose to Testnet
+   - [Make on-chain proposals](/dev/amplifier/chain-integration/governance-proposals/) on the testnet to create your CosmWasm smart contracts.
+     1. Proposal to store your CosmWasm code.
+     1. Proposal to instantiate your contracts.
+   - Make an on-chain proposal to add your chain to the Amplifier router.
+1. Test in Testnet
+   - Ensure your contracts are working as expected.
+   - Verify with developers that they can send messages to and from your chain.
+1. Productionize your relayer
+   - Ensure your relayer is robust, fault-tolerant, and can handle the load of your chain.
+1. Propose to Mainnet
+    - [Make on-chain proposals](/dev/amplifier/chain-integration/governance-proposals/) on Mainnet to create your CosmWasm smart contracts.
+      1. Proposal to store your CosmWasm code.
+      1. Proposal to instantiate your contracts.
+    - Make an on-chain proposal to add your chain to the Amplifier router.
+1. Fund rewards pools
+    - [Fund the rewards pool](/dev/amplifier/add-rewards/) for your `VotingVerifier` and `MultisigProver`.
+
+## Next Steps
+
+Once you understand the architecture and integration process, you're ready to start implementing. Head to the [Integrate a Chain](/dev/amplifier/chain-integration/integrate-a-chain) guide for step-by-step technical instructions.

src/content/docs/dev/amplifier/its-hub/routing-mechanics.mdx

@@ -14,7 +14,7 @@ ITS Hub routing works in the following way:
 Each token transfer or deployment involves two General Message Passing (GMP) calls:
 
 1. **From Source Chain to ITS Hub**: The ITS Edge Contract on the source chain sends a GMP call to the ITS Hub, wrapping the original payload.
-2. **From ITS Hub to Destination Chain**: The ITS Hub processes the payload, applies security measures, and forwards it to the ITS Edge Contract on the destination chain.
+1. **From ITS Hub to Destination Chain**: The ITS Hub processes the payload, applies security measures, and forwards it to the ITS Edge Contract on the destination chain.
 
 ### Payload Wrapping
 

src/content/docs/dev/axelar-sandbox/how-to-use.mdx

@@ -20,19 +20,19 @@ Let's begin by executing our examples. So, here's how the website looks like:
 
 ![Guide-2](/images/sandbox-guide-2.png)
 
-2. `hello-world` is the default example. It shows how to update destination contract states from the source chain contract. The example can be run against testnet or simulated environment.
+1. `hello-world` is the default example. It shows how to update destination contract states from the source chain contract. The example can be run against testnet or simulated environment.
 
 ![Guide-3](/images/sandbox-guide-3.png)
 
-3. Clicks at the **Execute** button in the upper right corner to run an example.
+1. Clicks at the **Execute** button in the upper right corner to run an example.
 
 ![Guide-4](/images/sandbox-guide-4.png)
 
-4. Next, the solidity contracts will be compiled; if successful, the javascript file will be executed; otherwise, the error message will be displayed. The "Output" panel displays all Javascript log messages that have already been executed.
+1. Next, the solidity contracts will be compiled; if successful, the javascript file will be executed; otherwise, the error message will be displayed. The "Output" panel displays all Javascript log messages that have already been executed.
 
 ![Guide-5](/images/sandbox-guide-5.png)
 
-5. The "**Transactions**" panel displays all transaction info sent from the "**sender**" and the "**relayer**" wallet. The relayer wallet is the wallet that interacts with your destination contract while the sender does that with the source contract. The transaction information includes:
+1. The "**Transactions**" panel displays all transaction info sent from the "**sender**" and the "**relayer**" wallet. The relayer wallet is the wallet that interacts with your destination contract while the sender does that with the source contract. The transaction information includes:
 
 - `Transaction hash`
 - `Transaction status`

src/content/docs/dev/axelarjs-sdk/token-transfer-dep-addr.mdx

@@ -7,7 +7,7 @@ A deposit address is a temporary special address created and monitored by **Axel
 ### Deposit address workflow
 
 1. The user generates a deposit address on a specific source chain.
-2. The user sends tokens to the deposit address on the source chain.
+1. The user sends tokens to the deposit address on the source chain.
 
 - Examples:
 
@@ -25,8 +25,8 @@ A deposit address is a temporary special address created and monitored by **Axel
   [AxelarQueryAPI](/dev/axelarjs-sdk/axelar-query-api/#gettransferfee).
 </Callout>
 
-3. Axelar relayers observe the deposit transaction on the source chain and complete it on the destination chain, assuming the amount exceeds the requisite fee.
-4. Watch your tokens arrive on the destination chain.
+1. Axelar relayers observe the deposit transaction on the source chain and complete it on the destination chain, assuming the amount exceeds the requisite fee.
+1. Watch your tokens arrive on the destination chain.
 
 ### 1. Prerequisite
 

src/content/docs/dev/axelarjs-sdk/tx-status-query-recovery.mdx

@@ -44,7 +44,7 @@ See the status of a transaction by passing its `txHash` into [`queryTransactionS
 
 It takes two parameters
 1. `txHash`: The transaction hash you are querying
-2. `eventIndex`: This is an optional parameter, useful for separating multiple [internal transactions](https://docs.alchemy.com/docs/what-are-internal-transactions) from one another that may have the same transaction hash.
+1. `eventIndex`: This is an optional parameter, useful for separating multiple [internal transactions](https://docs.alchemy.com/docs/what-are-internal-transactions) from one another that may have the same transaction hash.
 
 ```ts
 const txHash: string =

src/content/docs/dev/cosmos-gmp/cosmos-2way-manual-relay.mdx

@@ -9,8 +9,8 @@ Axelar’s off-chain relayer service currently does not support the automatic pr
 To manually process a two-way transaction to Cosmos through the Axelar network, perform the following steps:
 
 1. Confirm the gateway transaction on Axelar after the source chain transaction reaches finality.
-2. Monitor the Axelar network for the `MessageReceived` event.
-3. Manually route the message using the `RouteMessage` transaction on Axelar.
+1. Monitor the Axelar network for the `MessageReceived` event.
+1. Manually route the message using the `RouteMessage` transaction on Axelar.
 
 ## Step-by-Step Guide
 

src/content/docs/dev/gas-service/pricing.mdx

@@ -3,9 +3,9 @@
 Transactions using Axelar often have costs associated on their source chain, the Axelar network, and their destination chain. Whether for token transfers or General Message Passing, every cross-chain transaction is made up of 4 types of costs:
 
 1. Initiating the transaction on the source chain,
-2. Processing the transaction through the Axelar blockchain
-3. Relaying to the gateway contract on the destination chain
-4. Executing the destination smart contract with the payload
+1. Processing the transaction through the Axelar blockchain
+1. Relaying to the gateway contract on the destination chain
+1. Executing the destination smart contract with the payload
 
 To simplify paying for transaction pricing through the pipeline, Axelar has two general solutions to this problem.
 
@@ -30,7 +30,7 @@ For general message passing, Axelar's gas service allows the user/dApp to pay al
    - Validator confirmation voting on the Axelar Network
    - Relaying of approval on the destination chain
    - Costs related to delivering any possible refund on the destination chain
-2. **Execution Fee (i.e. the gas to execute the `_execute` method on the destination chain)** - The execution fee is variable depending on the chains involved, and the complexity of your `_execute` method.
+1. **Execution Fee (i.e. the gas to execute the `_execute` method on the destination chain)** - The execution fee is variable depending on the chains involved, and the complexity of your `_execute` method.
 
 The `estimateGasFee` method in the [AxelarJS SDK](/dev/axelarjs-sdk/axelar-query-api/#estimategasfee) calculates this total cost for you.
 
@@ -46,8 +46,8 @@ Certain EVM chains have really volatile gas prices. To account for this, it is r
 
 The `estimateGasFee` method exposes two additional optional parameters to enhance execution certainty:
 
-1. a `minGasPrice` to be used on the destination chain, and
-2. a `gasMultipler` to be used to multiply the calculated figure by a specified buffer for execution certainty.
+1. A `minGasPrice` to be used on the destination chain, and
+1. A `gasMultipler` to be used to multiply the calculated figure by a specified buffer for execution certainty.
 
 #### REFUNDS
 
@@ -64,9 +64,15 @@ The `estimateGasFee` method can be used (yet again) to determine the amount of g
 
 #### HANDLING ERRORS
 
-Transactions may intermittently stall on their way from a source chain to a destination chain. Common root causes for stalled transactions included: 1 - failure to send a valid transaction from the source chain into the Axelar network for processing; 2 - insufficient gas payments paid by the user; 3 - transaction revert on the destination chain.
+Transactions may intermittently stall on their way from a source chain to a destination chain. Common root causes for stalled transactions included: 
+1. Failure to send a valid transaction from the source chain into the Axelar network for processing. 
+1. Insufficient gas payments paid by the user.
+1. Transaction revert on the destination chain.
 
-Every transaction can be seen on Axelarscan with a detailed view of where transactions get "stuck", so one can start there to debug such circumstances. Axelarscan and the AxelarJS SDK expose two approaches to recover stalled transactions: 1. manual execution of the transaction on the destination chain, or 2. add gas for transactions. More details can be found [here](/dev/general-message-passing/debug/error-debugging/) for debugging and [here](/dev/general-message-passing/debug/transaction-recovery/) and recovery.
+Every transaction can be seen on Axelarscan with a detailed view of where transactions get "stuck", so one can start there to debug such circumstances. Axelarscan and the AxelarJS SDK expose two approaches to recover stalled transactions: 
+
+1. Manual execution of the transaction on the destination chain, or 
+1. Add gas for transactions. More details can be found [here](/dev/general-message-passing/debug/error-debugging/) for debugging and [here](/dev/general-message-passing/debug/transaction-recovery/) and recovery.
 
 ## callContractWithToken (General Message Passing)
 
@@ -76,8 +82,8 @@ Fees for `callContractWithToken` are almost identical to those of `callContract`
 
 Fees for GMP express include all of the same fees as `callContractWithToken`, plus:
 
-- an `Express Fee` that covers relayer/reorg risk
-- gas used to execute the express method
+- An `Express Fee` that covers relayer/reorg risk
+- Gas used to execute the express method
 
 For GMP Express transactions, the total refund will then be: