### EVM Chains
diff --git a/src/content/docs/dev/send-tokens/deprecated/deposit-address.mdx b/src/content/docs/dev/send-tokens/deprecated/deposit-address.mdx
new file mode 100644
index 000000000..4a544debe
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/deprecated/deposit-address.mdx
@@ -0,0 +1,17 @@
+import { Callout } from "/src/components/callout";
+
+
+# Transfer assets using a deposit address (Deprecated)
+
+
+ Note: Transfering assets via `deposit addresses` are deprecated. For gateway tokens it is recommended to use `callContractWithToken()` and for other tokens it is recommended to use the `Interchain Token Service`.
+
+
+A [deposit address](/dev/axelarjs-sdk/token-transfer-dep-addr/) is a temporary one-time address created and monitored by Axelar’s Relayer Services. Deposit addresses generally function for up to 24 hours.
+
+Use a deposit address if:
+
+- You need functionality not offered by the `sendToken()` method, such as Cosmos-to-X.
+- You want to allow token transfers from wallets that do not interact with Axelar, such as when withdrawing funds from a centralized exchange.
+
+To transfer assets using a deposit address, install the AxelarJS SDK and initiate an `AxelarAssetTransfer`.
\ No newline at end of file
diff --git a/src/content/docs/dev/send-tokens/deprecated/send-tokens.mdx b/src/content/docs/dev/send-tokens/deprecated/send-tokens.mdx
new file mode 100644
index 000000000..8eda75d87
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/deprecated/send-tokens.mdx
@@ -0,0 +1,158 @@
+import { Callout } from "/src/components/callout";
+
+
+# Send Tokens Cross-Chain (Deprecated)
+
+
+ Note: Transfering assets via `sendToken()` is deprecated. For gateway tokens it is recommended to use `callContractWithToken()` and for other tokens it is recommended to use the `Interchain Token Service`**.**
+
+
+
+## Call `sendToken()` on an EVM source chain
+
+To send a token from an EVM source chain:
+
+### 1. Find the source chain’s Gateway contract address
+
+Locate the source chain’s Gateway contract address on either the [mainnet](/dev/reference/mainnet-contract-addresses/) or the [testnet](/dev/reference/testnet-contract-addresses/).
+
+EVM chains use Axelar Gateway smart contracts to send tokens. These are application-layer smart contracts that send and receive payloads as well as monitor transaction state.
+
+All Gateway contracts implement the [`IAxelarGateway`](https://github.com/axelarnetwork/axelar-cgp-solidity/blob/main/contracts/interfaces/IAxelarGateway.sol/) interface, which has a public method called `sendToken()` that transfers tokens between chains:
+
+```solidity
+function sendToken(
+ string memory destinationChain,
+ string memory destinationAddress,
+ string memory symbol,
+ uint256 amount
+) external;
+```
+
+### 2. Call the source chain’s `approve()` method
+
+Transferring tokens through a Gateway is similar to doing a typical ERC-20 token transfer. You’ll need to call the source chain’s `approve()` method (inherited from the [ERC-20 interface](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/) to allow the Gateway to transfer a specific token in a specific amount.
+
+```solidity
+function approve(address spender, uint256 amount) external returns (bool);
+```
+
+`spender` is the source chain’s Gateway contract address on either the mainnet or the testnet.
+
+### 3. Call `sendToken()` on the source chain’s Gateway contract
+
+Call `sendToken()` on the source chain’s Gateway contract to transfer the tokens. For example:
+
+```solidity
+sendToken(
+ "avalanche", // destination chain name
+ "0xF16DfB26e1FEc993E085092563ECFAEaDa7eD7fD", // some destination wallet address (should be your own)
+ "axlUSDC", // asset symbol, can be differ by chain, see above
+ 100000000 // amount (in atomic units)
+)
+```
+
+Once you call `sendToken()`, watch for the tokens to appear at the address on the destination chain.
+
+## Call `sendToken()` on a Cosmos-based source chain
+
+For Cosmos-based source chains, `sendToken()` is a simple IBC transfer of any asset supported on the Axelar network. The message is sent to the address `axelar1dv4u5k73pzqrxlzujxg3qp8kvc3pje7jtdvu72npnt5zhq05ejcsn5qme5`, which is the designated address on the Axelar network for receiving [GMP](/dev/general-message-passing/overview/) messages, and includes a `memo` field with the following payload:
+
+```typescript
+ {
+ destination_chain,
+ destination_address,
+ payload: null,
+ type: 3, // corresponds to the `sendToken` command on Axelar
+ }
+```
+
+## Use the AxelarJS SDK to call `sendToken()`
+
+The AxelarJS SDK allows any frontend application to call `sendToken()` with one line of JS code.
+
+### EVM chain example
+
+```typescript
+import {
+ AxelarAssetTransfer,
+ CHAINS,
+ Environment,
+ SendTokenParams,
+} from "@axelar-network/axelarjs-sdk";
+import { ethers, Wallet } from "ethers";
+
+const api = new AxelarAssetTransfer({ environment: Environment.TESTNET });
+
+const getSigner = () => {
+ const privateKey = PRIVATE_KEY;
+ return new Wallet(privateKey);
+};
+
+async function test() {
+ const provider = new ethers.providers.JsonRpcProvider(
+ "https://api.avax-test.network/ext/bc/C/rpc",
+ );
+ const signer = getSigner().connect(provider);
+ const requestOptions: SendTokenParams = {
+ fromChain: CHAINS.TESTNET.AVALANCHE,
+ toChain: CHAINS.TESTNET.OSMOSIS,
+ destinationAddress: "osmo1x3z2vepjd7fhe30epncxjrk0lehq7xdqe8ltsn",
+ asset: { symbol: "aUSDC" },
+ amountInAtomicUnits: "5000000",
+ options: {
+ evmOptions: {
+ signer,
+ provider,
+ txOptions: null as any,
+ approveSendForMe: true,
+ },
+ },
+ };
+ return api.sendToken(requestOptions);
+}
+```
+
+### Cosmos-based chain example
+
+```typescript
+import {
+ AxelarAssetTransfer,
+ CHAINS,
+ Environment,
+ SendTokenParams,
+} from "@axelar-network/axelarjs-sdk";
+import { DirectSecp256k1HdWallet } from "@cosmjs/proto-signing";
+
+const api = new AxelarAssetTransfer({ environment: Environment.TESTNET });
+
+const getSigner = async () => {
+ const mnemonic = MNEMONIC;
+ return DirectSecp256k1HdWallet.fromMnemonic(mnemonic, { prefix: "osmo" });
+};
+
+async function test() {
+ const offlineSigner = await getSigner();
+ const requestOptions: SendTokenParams = {
+ fromChain: CHAINS.TESTNET.OSMOSIS,
+ toChain: CHAINS.TESTNET.AVALANCHE,
+ destinationAddress: "0xB8Cd93C83A974649D76B1c19f311f639e62272BC",
+ asset: {
+ denom:
+ "ibc/6F34E1BD664C36CE49ACC28E60D62559A5F96C4F9A6CCE4FC5A67B2852E24CFE",
+ }, //aUSDC
+ amountInAtomicUnits: "1000000",
+ options: {
+ cosmosOptions: {
+ cosmosDirectSigner: offlineSigner,
+ rpcUrl: "https://rpc.osmotest5.osmosis.zone/",
+ fee: {
+ gas: "250000",
+ amount: [{ denom: "uosmo", amount: "30000" }],
+ },
+ },
+ },
+ };
+ return api.sendToken(requestOptions);
+}
+```
\ No newline at end of file
diff --git a/src/content/docs/dev/send-tokens/glossary.mdx b/src/content/docs/dev/send-tokens/glossary.mdx
new file mode 100644
index 000000000..c834523d9
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/glossary.mdx
@@ -0,0 +1,52 @@
+# Interchain Token Glossary
+
+## Interchain Token
+
+An Interchain Token is an ERC-20 token that can be transferred between blockchains, preserving native token qualities. At the core, an Interchain Token is an ERC-20 contract on a public blockchain secured by a dynamic validator set. If this contract implements the [`IInterchainToken`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interfaces/IInterchainToken.sol) interface, it will have knowledge of its own [Token Manager](/dev/send-tokens/glossary#token-manager) and will contain all of the Token Manager’s transfer methods. If it does not implement this interface, token transfers must be done through explicit function calls on the Token Manager.
+
+## Interchain Token Service
+
+The Interchain Token Service is a [smart contract](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol) deployed by Axelar that manages the creation and management of Interchain Tokens and Token Managers. Its address on both mainnet and testnet is [`0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C`](https://etherscan.io/address/0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C) ([testnet deployment](https://sepolia.etherscan.io/address/0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C)).
+
+## Canonical Interchain Token
+
+A canonical Interchain Token is a token originally deployed on one chain that now has interchain capabilities through ITS. The Interchain Token Service wraps the token on the original chain to give it these capabilities, then duplicates the wrapped original on all other chains. This standardization ensures consistent behavior and enables interoperability between blockchains, allowing cross-chain transactions and interactions within blockchain networks that support various chains.
+
+Every ERC-20 token can only have one canonical chain. It will be deployed to all other chains as a [standardized token](/dev/send-tokens/glossary#standardized-token).
+
+## Custom Token
+
+A custom token is an ERC-20 token that is designed to serve specific use cases within the blockchain ecosystem. Unlike [standardized tokens](/dev/send-tokens/glossary#standardized-token), custom tokens are highly customizable, allowing their creators to define unique features, functionalities, and rules. For example, a standardized token will have the same name and symbol on all chains, but a custom token can have a different name and symbol on each chain. Custom tokens can optionally implement the [`IInterchainToken`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interfaces/IInterchainToken.sol) interface for transfer methods directly on the ERC-20 contract.
+
+## Standardized Token
+
+In the context of Axelar’s Interchain Token Service, a standardized token is a ERC-20 contract that implements the [`IInterchainToken`](https://github.com/axelarnetwork/interchain-token-service/blob/8d66c0b4d42fa7c3918ee9e2ccb9d80b7a4e3b1b/contracts/interfaces/IInterchainToken.sol) and [`IStandardizedToken`](https://github.com/axelarnetwork/interchain-token-service/blob/8d66c0b4d42fa7c3918ee9e2ccb9d80b7a4e3b1b/contracts/interfaces/IStandardizedToken.sol) interfaces and can be deployed by the Interchain Token Service.
+
+## Token ID
+
+A token ID is a token’s unique identifier within a blockchain network. It remains the same across all the chains that the token is deployed to.
+
+## Token Manager
+
+A [`TokenManager`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/token-manager/TokenManager.sol) is a contract that is responsible for managing interchain tokens. There are two types of token managers:
+
+- [Lock/Unlock](/dev/send-tokens/glossary#lockunlock) — can lock and release token supply
+- [Mint/Burn](/dev/send-tokens/glossary#mintburn) — can mint or burn tokens
+
+Token Managers must be designated either Lock/Unlock or Mint/Burn.
+
+## Lock/Unlock
+
+To lock or unlock a smart contract means to temporarily restrict or restore the transfer of tokens or assets within the contract. Locking can be used in smart contracts to enforce specific conditions or trigger events only when certain criteria are met.
+
+## Mint/Burn
+
+Minting refers to the creation of new tokens, typically increasing the total supply. Burning involves permanently removing tokens from circulation, reducing the total supply. In the Interchain Token Service, the contract’s Token Manager will mint new tokens on its chain when there are incoming token transfers, and burn the received tokens when there are outgoing token transfers.
+
+## Distributor Role
+
+The distributor is a permission role for custom tokens within the Axelar ecosystem. Tokens with distributor permissions can mint and burn tokens. This role is essential for managing the token supply and ensuring its proper functioning.
+
+## Operator
+
+In Interchain Token Service, the Operator is a role for a Token Manager that can set the `flowLimit` to control the influx and outflux of tokens on an ERC-20 contract.
diff --git a/src/content/docs/dev/send-tokens/interchain-tokens/create-new-interchain-token.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/create-new-interchain-token.mdx
new file mode 100644
index 000000000..e16044a84
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/create-new-interchain-token.mdx
@@ -0,0 +1,55 @@
+import { Callout } from "/src/components/callout";
+
+# Create New Token
+
+Interchain Tokens are tokens deployed via the [Interchain Token Service (ITS)](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol). These tokens are relatively simple ERC-20 contracts with built-in ITS integration, making them bridgeable to other blockchains as soon as they are deployed.
+
+If you are starting fresh and want to deploy a brand new token that will have bridging capabilities from day one, ITS offers the ability to deploy a token directly through the [Interchain Token Factory](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenFactory.sol).
+
+## Deploy an Interchain Token
+
+Use the `deployInterchainToken` function to deploy a new interchain token on your preferred chain.
+
+```solidity
+function deployInterchainToken(
+ bytes32 salt, // unique salt for token deployment
+ string calldata name, // token name
+ string calldata symbol, // token symbol
+ uint8 decimals, // token decimals
+ uint256 initialSupply, // initial token supply
+ address minter // address receiving the initially minted tokens
+) external payable returns (bytes32 tokenId) {};
+```
+
+This function [deploys an interchain token](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenFactory.sol#L133), connects it to ITS upon deployment, and returns the unique token ID.
+
+## Deploy a Remote Interchain Token
+
+Use the [`deployRemoteInterchainToken`](https://github.com/axelarnetwork/interchain-token-service/blob/94677f1072da127a0ee7ff5ab6784dcfe11789e8/contracts/InterchainTokenFactory.sol#L249) function to deploy the token on a remote chain as a cross-chain transaction.
+Using this function, there is no minter role assigned if you need to deploy a token on a remote chain with a minter, use the [`deployRemoteInterchainTokenWithMinter`](https://github.com/axelarnetwork/interchain-token-service/blob/94677f1072da127a0ee7ff5ab6784dcfe11789e8/contracts/InterchainTokenFactory.sol#L269) function.
+
+```solidity
+function deployRemoteInterchainToken(
+ bytes32 salt, // your unique salt value
+ string calldata destinationChain, // destination chain name
+ uint256 gasValue // gas sent for token deployment
+) external payable returns (bytes32 tokenId) {};
+```
+
+This function deploys a remote interchain token on a specified destination chain and returns a token ID.
+
+
+ **NOTE:** The security of your token is only as strong as the security of the
+ chains with which it integrates. When deploying an interchain token, ensure
+ that all target chains are trustworthy.
+
+
+## What's Next
+
+You can initiate an interchain transfer from your source chain to a destination chain by using the [`interchainTransfer`](/dev/send-tokens/interchain-tokens/interchain-transfer/) method on the [ITS contract](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol).
+
+For further examples utilizing the Interchain Token Service, check out the [`axelar-examples`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm) repository on GitHub. There you will find an example implementation titled [`its-interchain-token`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-interchain-token), which demonstrates how to deploy Interchain Tokens across EVM chains and how to transfer tokens between them.
+
+## Tutorial
+
+For a step-by-step guide on deploying an Interchain Token, check out the [Programmatically Create a New Token Using the Interchain Token Service](/dev/send-tokens/interchain-tokens/developer-guides/programmatically-create-a-token/) tutorial.
diff --git a/src/content/docs/dev/send-tokens/interchain-tokens/developer-guides/link-custom-tokens-deployed-across-multiple-chains-into-interchain-tokens.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/developer-guides/link-custom-tokens-deployed-across-multiple-chains-into-interchain-tokens.mdx
new file mode 100644
index 000000000..ba757bbcd
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/developer-guides/link-custom-tokens-deployed-across-multiple-chains-into-interchain-tokens.mdx
@@ -0,0 +1,818 @@
+# Link Custom Tokens Deployed Across Multiple Chains
+
+import { Callout } from "/src/components/callout";
+
+Custom ERC-20 tokens deployed on multiple chains with specific minting policies, ownership structures, rate limits, and other bespoke functionalities can be turned into Interchain Tokens through the [Interchain Token Service](/dev/send-tokens/interchain-tokens/intro/).
+
+In this tutorial, you will:
+
+- Link custom tokens deployed across multiple chains into Interchain Tokens
+- Deploy a simple ERC-20 token on the BSC chain
+- Deploy a simple ERC-20 token on the Avalanche Fuji chain
+- Register token metadata with the ITS Contract on both BSC and Avalanche Fuji chain
+- Register the custom token with the [Interchain Token Factory](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenFactory.sol) on BSC and Avalanche Fuji chain
+- Link custom token with the [Interchain Token Factory](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenFactory.sol) from BSC to Avalanche Fuji chain
+- Assign the minter role to your token's Token Manager on BSC and Avalanche Fuji chain
+
+## Prerequisites
+
+You will need:
+
+- A basic understanding of [Solidity](https://www.tutorialspoint.com/solidity/index.htm) and [JavaScript](https://www.w3schools.com/js/)
+- A [MetaMask wallet](https://metamask.io/) with tBNB and Avax funds for testing. If you don't have these funds, you can get tBNB from the [BSC faucet](https://www.bnbchain.org/en/testnet-faucet) and Avax from the Avalanche Fuji faucets ([1](https://faucets.chain.link/fuji), [2](https://core.app/tools/testnet-faucet/)).
+
+## Deploy an ERC-20 token on the BSC and Avalanche Fuji testnets
+
+Deploy the following `SimpleCustomToken` on the BSC and Avalanche Fuji testnets.
+
+This code utilizes OpenZeppelin's libraries to create a custom ERC-20 token with functionalities for minting, burning, and access control. The token includes a minter role, which enables designated addresses to mint or burn tokens. Additionally, it incorporates ERC20Permit for gasless transactions. The contract starts with a predefined supply of tokens minted to the deployer's address and establishes roles for a default administrator and minter:
+
+```solidity
+
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.18;
+
+// Import OpenZeppelin contracts for ERC-20 standard token implementations,
+// burnable tokens, access control mechanisms, and permit functionality
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";
+import "@openzeppelin/contracts/access/AccessControl.sol";
+import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Permit.sol";
+
+contract SimpleCustomToken is ERC20, ERC20Burnable, AccessControl, ERC20Permit {
+
+// Define a constant for the minter role using keccak256 to generate a unique hash
+ bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");
+
+ constructor(address defaultAdmin, address minter)
+ ERC20("SimpleCustomToken", "SCT") // Set token name and symbol
+ ERC20Permit("SimpleCustomToken") // Initialize ERC20Permit with the token name
+ {
+ // Mint an initial supply of tokens to the message sender
+ _mint(msg.sender, 10000 * 10 ** decimals());
+
+
+ // Grant the DEFAULT_ADMIN_ROLE to the specified defaultAdmin address
+ _grantRole(DEFAULT_ADMIN_ROLE, defaultAdmin);
+
+
+ // Grant the MINTER_ROLE to the specified minter address
+ // Addresses with the minter role are allowed to mint new tokens
+ _grantRole(MINTER_ROLE, minter);
+ }
+
+ // Mint new tokens. Only addresses with the MINTER_ROLE can call this function
+ function mint(address to, uint256 amount) public onlyRole(MINTER_ROLE) {
+ _mint(to, amount);
+ }
+
+ // Burn tokens from a specified account
+ function burn(address account, uint256 amount) public onlyRole(MINTER_ROLE) {
+ _burn(account, amount);
+ }
+}
+```
+
+Check out this [Hardhat guide](https://hardhat.org/tutorial) to learn how to deploy your ERC-20 token using Hardhat step by step.
+
+## Set up your development environment
+
+### Create and initialize a project
+
+Open up your terminal and navigate to any directory of your choice. Run the following commands to create and initiate a project:
+
+```bash
+mkdir custom-interchain-token-project && cd custom-interchain-token-project
+npm init -y
+```
+
+# Install Hardhat and the AxelarJS SDK
+
+Install Hardhat and the AxelarJS SDK with the following commands:
+
+```bash
+npm install --save-dev hardhat@2.18.1 dotenv@16.3.1
+npm install @axelar-network/axelarjs-sdk@0.13.9 crypto@1.0.1 @nomicfoundation/hardhat-toolbox@2.0.2
+```
+
+### Set up project ABIs
+
+Next, set up the ABIs for the [Interchain Token Service](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol) and the contract from the token you deployed.
+
+Create a folder named `utils`. Inside the folder, create the following new files and add the respective ABIs:
+
+- Add the [Interchain Token Service ABI](https://gist.github.com/Olanetsoft/2a632784e6753d34ca7ffc4f73bf58ed) to `interchainTokenServiceABI.json`.
+- Add the [Interchain Token Factory ABI](https://gist.github.com/Olanetsoft/7d24e936f4cf6bd3d10d7b4f9a18d838) to `interchainTokenFactoryABI.json`.
+- Add your custom token ABI to `customTokenABI.json`. You can get this from [BSC Scan](https://testnet.bscscan.com/) or [Avalanche Fuji Scan](https://testnet.snowtrace.io/) with the address of your deployed token if your contract is verified. Otherwise, you can get it from the same service on which you deployed the `SimpleCustomToken`.
+
+## Set up an RPC for the local chain
+
+Set up an RPC for the BSC and Avalanche Fuji testnet in the root directory.
+
+### Create an `.env` file
+
+To make sure you're not accidentally publishing your private key, create an [.env file](https://blog.bitsrc.io/a-gentle-introduction-to-env-files-9ad424cc5ff4) to store it in:
+
+```bash
+touch .env
+```
+
+### Add your private key to `.env` and `hardhat.config.js.`
+
+[Export your private key](https://support.metamask.io/managing-my-wallet/secret-recovery-phrase-and-private-keys/how-to-export-an-accounts-private-key/) and add it to the `.env` file you just created:
+
+```bash
+PRIVATE_KEY= // Add your account private key here
+```
+
+
+ If you will push this project on GitHub, create a `.gitignore` file and
+ include `.env`.
+
+
+Then, create a file with the name `hardhat.config.js` and add the following code snippet:
+
+```javascript
+require("@nomicfoundation/hardhat-toolbox");
+require("dotenv").config({ path: ".env" });
+
+const PRIVATE_KEY = process.env.PRIVATE_KEY;
+
+/** @type import('hardhat/config').HardhatUserConfig */
+module.exports = {
+ solidity: "0.8.18",
+ networks: {
+ bsc: {
+ url: "https://bsc-testnet.drpc.org/",
+ chainId: 97,
+ accounts: [PRIVATE_KEY],
+ },
+ avalanche: {
+ url: "https://avalanche-fuji-c-chain-rpc.publicnode.com/",
+ chainId: 43113,
+ accounts: [PRIVATE_KEY],
+ },
+ },
+};
+```
+
+## Register token metadata with the ITS Contract on both BSC and Avalanche Fuji chain
+
+Now that you have set up an RPC for the BSC and Avalanche Fuji testnet, you can register token metadata with the ITS Contract on both chains.
+The token metadata registers the metadata for a token on the ITS Hub. This metadata is used to scale linked tokens.
+
+### Create a `customInterchainToken.js` script
+
+Create a new file named `customInterchainToken.js` and import the required dependencies:
+
+- `Ethers.js`
+- The [AxelarJS SDK](https://github.com/axelarnetwork/axelarjs-sdk)
+- The custom token contract ABI
+- The address of the [`InterchainTokenService`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol) contract
+- The address of your token deployed on BSC and Avalanche Fuji testnet
+
+```javascript
+const hre = require("hardhat");
+const crypto = require("crypto");
+const ethers = hre.ethers;
+
+const interchainTokenServiceContractABI = require("./utils/interchainTokenServiceABI");
+const interchainTokenFactoryContractABI = require("./utils/interchainTokenFactoryABI");
+const customTokenABI = require("./utils/customTokenABI");
+
+const MINT_BURN = 4;
+
+const interchainTokenServiceContractAddress =
+ "0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C";
+const interchainTokenFactoryContractAddress =
+ "0x83a93500d23Fbc3e82B410aD07A6a9F7A0670D66";
+
+const bscCustomTokenAddress = "0x0b769061149B1267e1979C4EA0b57b178dB9a53D"; // Replace with your token address on BSC
+const avalancheCustomTokenAddress =
+ "0xA41E40930CBCDB9fcC63A6307199b0EABC33b4A5"; // Replace with your token address on Avalanche Fuji
+```
+
+### Get the signer
+
+Next, create a `getSigner()` function in `customInterchainToken.js`. This will obtain a signer for a secure transaction:
+
+```javascript
+//...
+
+async function getSigner() {
+ const [signer] = await ethers.getSigners();
+ return signer;
+}
+```
+
+### Get the contract instance
+
+Then, create a `getContractInstance()` function in `customInterchainToken.js`. This will get the contract instance based on the contract's address, ABI, and signer:
+
+```javascript
+//...
+
+async function getContractInstance(contractAddress, contractABI, signer) {
+ return new ethers.Contract(contractAddress, contractABI, signer);
+}
+```
+
+### Register token metadata with the ITS Contract on BSC
+
+Create a `registerTokenMetadataOnBSC` function for the BSC testnet. This will register the token metadata on BSC.
+
+```javascript
+//...
+
+// register token metadata : bsc
+async function registerTokenMetadataOnBSC() {
+ // Get a signer to sign the transaction
+ const signer = await getSigner();
+
+ // Get the InterchainTokenService contract instance
+ const interchainTokenServiceContract = await getContractInstance(
+ interchainTokenServiceContractAddress,
+ interchainTokenServiceContractABI,
+ signer,
+ );
+
+ // Register token metadata
+ const deployTxData =
+ await interchainTokenServiceContract.registerTokenMetadata(
+ bscCustomTokenAddress,
+ ethers.utils.parseEther("0.0001"), // gas value
+ { value: ethers.utils.parseEther("0.001") },
+ );
+
+ console.log(`Transaction Hash: ${deployTxData.hash},`);
+}
+
+//...
+```
+
+### Register token metadata with the ITS Contract on Avalanche Fuji
+
+Create a `registerTokenMetadataOnAvalanche` function for the Avalanche Fuji testnet. This will register the token metadata on Avalanche Fuji.
+
+```javascript
+// register token metadata : avalanche
+async function registerTokenMetadataOnAvalanche() {
+ // Get a signer to sign the transaction
+ const signer = await getSigner();
+
+ // Get the InterchainTokenService contract instance
+ const interchainTokenServiceContract = await getContractInstance(
+ interchainTokenServiceContractAddress,
+ interchainTokenServiceContractABI,
+ signer,
+ );
+
+ // Register token metadata
+ const deployTxData =
+ await interchainTokenServiceContract.registerTokenMetadata(
+ avalancheCustomTokenAddress,
+ ethers.utils.parseEther("0.0001"), // gas value
+ { value: ethers.utils.parseEther("0.001") },
+ );
+
+ console.log(`Transaction Hash: ${deployTxData.hash},`);
+}
+```
+
+### Add a `main()` function
+
+Add a `main()` function to execute the `customInterchainToken.js` script and handle any errors that may arise:
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ case "registerTokenMetadataOnBSC":
+ await registerTokenMetadataOnBSC();
+ break;
+ case "registerTokenMetadataOnAvalanche":
+ await registerTokenMetadataOnAvalanche();
+ break;
+ default:
+ console.error(`Unknown function: ${functionName}`);
+ process.exitCode = 1;
+ return;
+ }
+}
+
+main().catch((error) => {
+ console.error(error);
+ process.exitCode = 1;
+});
+```
+
+### Run the `customInterchainToken.js` script to deploy to BSC
+
+Run the script in your terminal to register and deploy the token, specifying the `bsc` testnet:
+
+```bash
+FUNCTION_NAME=registerTokenMetadataOnBSC npx hardhat run customInterchainToken.js --network bsc
+```
+
+If you see something similar to the following on your console, you have successfully registered your token metadata on BSC
+
+```bash
+Transaction Hash: 0xf860bd8802d046fb0c752c355bc73c87e69f701348420c6cbdf82534b87c4822,
+
+```
+
+### Run the `customInterchainToken.js` script to deploy to Avalanch Fuji
+
+Run the script in your terminal to register and deploy the token, specifying the `avalanche` testnet:
+
+```bash
+FUNCTION_NAME=registerTokenMetadataOnAvalanche npx hardhat run customInterchainToken.js --network avalanche
+```
+
+If you see something similar to the following on your console, you have successfully registered your token metadata on Avalanche Fuji.
+
+```bash
+Transaction Hash: 0x026ee7992de2108ecb83f37119ec84ebed371ff724d38e8fd055cbecde5b77e6,
+
+```
+
+### Check the transaction on the BSC testnet scanner
+
+Check the [BSC testnet scanner](https://testnet.bscscan.com/) to see if you have successfully [registered your token metadata](https://testnet.bscscan.com/tx/0xf860bd8802d046fb0c752c355bc73c87e69f701348420c6cbdf82534b87c4822).
+
+### Check the transaction on the Avalanche Fuji testnet scanner
+
+Check the [Avalanche Fuji testnet scanner](https://testnet.snowtrace.io/) to see if you have successfully [registered your token metadata](https://testnet.snowtrace.io/tx/0xe3bb64c76637fcd4d9ce9a5bab013fcda95e7040292531230be70daa4f5bd9a1).
+
+## Register the custom token with the Interchain Token Factory
+
+You've registered your token metadata on BSC and Avalanche Fuji. Now, register the custom token with the Interchain Token Factory on the BSC.
+
+To do that, use the following code snippet: create a function with the name `registerCustomTokenOnBSC`. This function registers an existing ERC20 token under a `tokenId` computed from the provided `salt`.
+
+```javascript
+async function registerCustomTokenOnBSC() {
+ // Generate random salt
+ const salt = "0x" + crypto.randomBytes(32).toString("hex");
+
+ // Get a signer to sign the transaction
+ const signer = await getSigner();
+
+ // Get the interchainTokenFactory contract instance
+ const interchainTokenFactoryContract = await getContractInstance(
+ interchainTokenFactoryContractAddress,
+ interchainTokenFactoryContractABI,
+ signer,
+ );
+
+ // Register token metadata
+ const deployTxData = await interchainTokenFactoryContract.registerCustomToken(
+ salt, // salt
+ bscCustomTokenAddress, // token address
+ MINT_BURN, // token management type
+ "0x510e5EA32386B7C48C4DEEAC80e86859b5e2416C", // the address of the operator
+ { value: ethers.utils.parseEther("0.001") },
+ );
+
+ console.log(`
+ Transaction Hash: ${deployTxData.hash},
+ salt: ${salt}`);
+}
+
+//...
+```
+
+### Update `main()` to register custom token
+
+Update `main()` to execute `registerCustomTokenOnBSC()` :
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ //...
+ case "registerCustomTokenOnBSC":
+ await registerCustomTokenOnBSC();
+ break;
+ default:
+ //...
+ }
+}
+
+//...
+```
+
+### Run the `customInterchainToken.js` script to deploy to BSC
+
+Run the script in your terminal to register the custom token, once again specifying the `BSC` testnet (the source chain where all transactions are taking place):
+
+```javascript
+FUNCTION_NAME=registerCustomTokenOnBSC npx hardhat run customInterchainToken.js --network bsc
+```
+
+You should see something similar to the following on your console:
+
+```bash
+Transaction Hash: 0xf0c3fbbece17cc12d9de76182540afb4f5c6c47aeca65c40f9d58f71e362dffe,
+salt: 0xd58c9142d863dde9f0b9ea68b10cce9470626040187a00c16b7b3d4edae70cf9
+
+```
+
+## Link custom token with the Interchain Token Factory from BSC to Avalanche Fuji chain
+
+In this section, you must link the custom token using the Interchain Token Factory between the chains where your token exists.
+
+The key difference between `registerCustomToken` and `linkToken` lies in their purpose and scope. `registerCustomToken` is used exclusively by the Interchain Token Factory to register custom tokens on the current chain, enabling them to be linked later. It deploys a token manager for the token but does not facilitate cross-chain linking. On the other hand, `linkToken` is a more general function that links a token to a destination chain by deploying a token manager on the target chain. It allows users to connect tokens across chains, enabling interchain transfers. While `registerCustomToken` is limited to local registration, `linkToken` extends functionality to cross-chain interoperability.
+
+To do that, create a function named `linkCustomToken` with the following code snippet.
+
+```javascript
+async function linkCustomToken() {
+ // Get a signer to sign the transaction
+ const signer = await getSigner();
+
+ // Get the interchainTokenFactory contract instance
+ const interchainTokenFactoryContract = await getContractInstance(
+ interchainTokenFactoryContractAddress,
+ interchainTokenFactoryContractABI,
+ signer,
+ );
+
+ // Register token metadata
+ const deployTxData = await interchainTokenFactoryContract.linkToken(
+ "0xd58c9142d863dde9f0b9ea68b10cce9470626040187a00c16b7b3d4edae70cf9", // salt, same as previously used
+ "Avalanche", // destination chain
+ avalancheCustomTokenAddress, // destination token address
+ MINT_BURN, // token manager type
+ "0x510e5EA32386B7C48C4DEEAC80e86859b5e2416C", // the address of the operator - linkParams
+ ethers.utils.parseEther("0.001"), // gas value
+ { value: ethers.utils.parseEther("0.001") },
+ );
+
+ console.log(`Transaction Hash: ${deployTxData.hash}`);
+}
+
+//...
+```
+
+### Update `main()` to link custom token
+
+Update `main()` to execute `linkCustomToken()` :
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ //...
+ case "linkCustomToken":
+ await linkCustomToken();
+ break;
+ default:
+ //...
+ }
+}
+
+//...
+```
+
+### Run the `customInterchainToken.js` script to deploy to BSC
+
+Run the script in your terminal to register the custom token, once again specifying the `BSC` testnet (the source chain where all transactions are taking place):
+
+```javascript
+FUNCTION_NAME=linkCustomToken npx hardhat run customInterchainToken.js --network bsc
+```
+
+You should see something similar to the following on your console:
+
+```bash
+Transaction Hash: 0x11c2a212180d7ea2babe7aceb66c32c1e235cc159bceeb4dd6d04411f4a9669f
+
+```
+
+### Check the transaction on the Axelar testnet scanner
+
+Check the [Axelarscan testnet scanner](https://testnet.axelarscan.io/) to see if you have successfully registered the custom token on the Avalanche Fuji testnet. It should look something like [this](https://testnet.axelarscan.io/gmp/0x11c2a212180d7ea2babe7aceb66c32c1e235cc159bceeb4dd6d04411f4a9669f).
+
+Add gas if needed. Ensure that Axelar shows a successful transaction before continuing to the next step.
+
+## Assign the minter role to your token's Token Manager on BSC and Avalanche Fuji chain
+
+You must transfer mint access to the Token Manager address on both chains before you can mint and burn tokens while moving assets between chains.
+
+### Transfer mint access to the Token Manager address on the BSC testnet
+
+Create a `transferMintAccessToTokenManagerOnBSC()` function that will perform the mint access transfer on the BSC testnet. The token manager is a contract needed for moving your asset from one chain to the other. You need to first retrieve the token manager address using the token ID. So, let's start with that. To do that, use the following code snippet.
+
+```javascript
+async function getTokenManagerAddress() {
+ // Get a signer to sign the transaction
+ const signer = await getSigner();
+
+ // Get the InterchainTokenService contract instance
+ const interchainTokenServiceContract = await getContractInstance(
+ interchainTokenServiceContractAddress,
+ interchainTokenServiceContractABI,
+ signer,
+ );
+
+ // Get the interchainTokenFactory contract instance
+ const interchainTokenFactoryContract = await getContractInstance(
+ interchainTokenFactoryContractAddress,
+ interchainTokenFactoryContractABI,
+ signer,
+ );
+
+ // Retrieve linked token id
+ const tokenId = await interchainTokenFactoryContract.linkedTokenId(
+ "0x510e5EA32386B7C48C4DEEAC80e86859b5e2416C", // sender
+ "0xd58c9142d863dde9f0b9ea68b10cce9470626040187a00c16b7b3d4edae70cf9", // salt, same as previously used
+ );
+
+ const tokenManagerAddress =
+ await interchainTokenServiceContract.tokenManagerAddress(tokenId);
+
+ console.log(`
+ Token Manager Address: ${tokenManagerAddress},
+ Token ID: ${tokenId}`);
+}
+```
+
+### Update `main()` to retrieve the token manager address
+
+Update `main()` to execute `getTokenManagerAddress()` :
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ //...
+ case "getTokenManagerAddress":
+ await getTokenManagerAddress();
+ break;
+ default:
+ //...
+ }
+}
+
+//...
+```
+
+### Run the `customInterchainToken.js` script to retrieve the token manager address
+
+Run the script in your terminal to retrieve the token manager address.
+
+```javascript
+FUNCTION_NAME=getTokenManagerAddress npx hardhat run customInterchainToken.js --network bsc
+```
+
+You should see something similar to the following on your console:
+
+```bash
+Token Manager Address: 0x1Ca3eAcB1e8C72869d8962f425631A24e19e8a80,
+Token ID: 0xe0898500c75902b24ca99e2bcb77317acfdf01e66b1cacfd1daf75c66ecd8dfb
+
+```
+
+Next, save your token ID details(you will need them later in this tutorial) and use the token manager address as a parameter to transfer Mint access on both chains. Start with BSC using the folllowing code snippet:
+
+```javascript
+//...
+
+// Transfer mint access on all chains to the Expected Token Manager : BSC
+async function transferMintAccessToTokenManagerOnBSC() {
+ // Get a signer to sign the transaction
+ const signer = await getSigner();
+
+ const tokenContract = await getContractInstance(
+ bscCustomTokenAddress,
+ customTokenABI,
+ signer,
+ );
+
+ // Get the minter role
+ const getMinterRole = await tokenContract.MINTER_ROLE();
+
+ const grantRoleTxn = await tokenContract.grantRole(
+ getMinterRole,
+ "0x1Ca3eAcB1e8C72869d8962f425631A24e19e8a80", // your token manager address
+ );
+
+ console.log("grantRoleTxn: ", grantRoleTxn.hash);
+}
+```
+
+### Update `main()` to transfer mint access on the BSC testnet
+
+Update `main()` to execute `transferMintAccessToTokenManagerOnBSC()` :
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ //...
+ case "transferMintAccessToTokenManagerOnBSC":
+ await transferMintAccessToTokenManagerOnBSC();
+ break;
+ default:
+ //...
+ }
+}
+
+//...
+```
+
+### Run the `customInterchainToken.js` script to deploy to the BSC testnet
+
+Run the script in your terminal to transfer mint access to the Token Manager specifying the `BSC` testnet:
+
+```bash
+FUNCTION_NAME=transferMintAccessToTokenManagerOnBSC npx hardhat run customInterchainToken.js --network bsc
+```
+
+You should see something similar to the following on your console:
+
+```bash
+grantRoleTxn: 0x82f2fdc151e865d08f776485076cb1e5ba8ffb865f5c4f7e6fedbbe046d5e4e3
+
+```
+
+Next, grant mint access to the Avalanche Fuji testnet using the following code snippet:
+
+```javascript
+//...
+
+// Transfer mint access on all chains to the Expected Token Manager : Avalanche
+async function transferMintAccessToTokenManagerOnAvalanche() {
+ // Get a signer to sign the transaction
+ const signer = await getSigner();
+
+ const tokenContract = await getContractInstance(
+ bscCustomTokenAddress,
+ customTokenABI,
+ signer,
+ );
+
+ // Get the minter role
+ const getMinterRole = await tokenContract.MINTER_ROLE();
+
+ const grantRoleTxn = await tokenContract.grantRole(
+ getMinterRole,
+ "0x1Ca3eAcB1e8C72869d8962f425631A24e19e8a80", // your token manager address
+ );
+
+ console.log("grantRoleTxn: ", grantRoleTxn.hash);
+}
+```
+
+### Update `main()` to transfer mint access on the Avalanche Fuji testnet
+
+Update `main()` to execute `transferMintAccessToTokenManagerOnAvalanche()` :
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ //...
+ case "transferMintAccessToTokenManagerOnAvalanche":
+ await transferMintAccessToTokenManagerOnAvalanche();
+ break;
+ default:
+ //...
+ }
+}
+
+//...
+```
+
+### Run the `customInterchainToken.js` script to deploy to Avalanche Fuji testnet
+
+Run the script in your terminal to transfer mint access to the Token Manager specifying the `Avalanche Fuji` testnet:
+
+```bash
+FUNCTION_NAME=transferMintAccessToTokenManagerOnAvalanche npx hardhat run customInterchainToken.js --network avalanche
+```
+
+You should see something similar to the following on your console:
+
+```bash
+grantRoleTxn: 0xdff5ef006caf387b2f86db5ad09837b72107ba9f95561ee47560a05ce55f2cad
+
+```
+
+## Transfer your token between chains
+
+Now that you have deployed a granted mint access to the token manager on both BSC and Avalanche testnet, you can transfer your token between those two chains using the [interchainTransfer()](/dev/send-tokens/interchain-tokens/interchain-transfer/) method.
+
+### Initiate a remote token transfer
+
+In `customInterchainToken.js`, create a `transferTokens()` function to facilitate remote token transfers between chains. Change the token ID to the `tokenId` that you saved from an earlier step, and change the receiver address to your wallet address:
+
+```javascript
+//...
+
+// Transfer tokens : BSC -> Avalanche Fuji
+async function transferTokens() {
+ // Get a signer to sign the transaction
+ const signer = await getSigner();
+
+ const interchainTokenServiceContract = await getContractInstance(
+ interchainTokenServiceContractAddress,
+ interchainTokenServiceContractABI,
+ signer,
+ );
+
+ const transfer = await interchainTokenServiceContract.interchainTransfer(
+ "0xe0898500c75902b24ca99e2bcb77317acfdf01e66b1cacfd1daf75c66ecd8dfb", // tokenId, the one you store in the earlier step
+ "Avalanche", // destination chain
+ "0x510e5EA32386B7C48C4DEEAC80e86859b5e2416C", // receiver address
+ ethers.utils.parseEther("5"), // amount of token to transfer
+ "0x",
+ ethers.utils.parseEther("0.001"), // gasValue
+ {
+ // Transaction options should be passed here as an object
+ value: ethers.utils.parseEther("0.001"),
+ },
+ );
+
+ console.log("Transfer Transaction Hash:", transfer.hash);
+}
+```
+
+### Update `main()` to execute token transfer
+
+Update the `main()` to execute `transferTokens()`:
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ //...
+ case "transferTokens":
+ await transferTokens();
+ break;
+ default:
+ //...
+ }
+}
+
+//...
+```
+
+### Run the `customInterchainToken.js` script to transfer tokens
+
+Run the script in your terminal, specifying the `BSC` testnet:
+
+```bash
+FUNCTION_NAME=transferTokens npx hardhat run customInterchainToken.js --network bsc
+```
+
+You should see something similar to the following on your console:
+
+```bash
+Transfer Transaction Hash: 0xbb7d242ead9fda8ce8d20654fb1c404c611c04bbb198fe15668a17272862e95b
+
+```
+
+If you see this, your interchain transfer has been successful! 🎉
+
+### Check the transaction on the Axelar testnet scanner
+
+Check the [Axelarscan testnet scanner](https://testnet.axelarscan.io/) to see if you have successfully transferred SCT from the [BSC testnet](https://testnet.ftmscan.com/token/0x8D4a6B2A784749BBc412A41C1440C5A67EAB57EE) to the Avalanche Fuji testnet. It should look something like [this](https://testnet.axelarscan.io/gmp/0xbb7d242ead9fda8ce8d20654fb1c404c611c04bbb198fe15668a17272862e95b).
+
+## Congratulations!
+
+You have now programmatically linked custom tokens deployed on multiple chains as Interchain Tokens, using Axelar's Interchain Token Service to transfer them between chains.
+
+Great job making it this far! To show your support for the author of this tutorial, please post about your experience and tag [@axelarnetwork](https://x.com/axelar) on Twitter (X).
+
+## What's next
+
+For further examples utilizing the Interchain Token Service, check out the following in the [`axelar-examples`](https://github.com/axelarnetwork/axelar-examples/tree/main) repo on GitHub:
+
+- [`its-custom-token`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-custom-token) — Demonstrates how to use the ITS with a custom token implementation.
+- [`its-interchain-token`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-interchain-token) — Demonstrates how to deploy Interchain Tokens that are connected across EVM chains and how to send some tokens across.
+- [`its-canonical-token`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-canonical-token) - Demonstrates how to deploy canonical Interchain Token and send cross-chain transfer for these tokens.
+- [`its-lock-unlock-fee`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-lock-unlock-fee) Demonstrates how to deploy deploy interchain token with lock/unlock_fee token manager type.
+- [`its-executable`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-executable) Demonstrates how to deploy interchain token and send a cross-chain transfer along with a message.
+- [`its-mint-burn-from`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-mint-burn-from) Demonstrates how to deploy interchain token with uses `burnFrom()` on token being bridged rather than `burn()`.
+
+## References
+
+- [Interchain Token Service Documentation](/dev/send-tokens/interchain-tokens/intro/)
+- [Interchain Tokens GitHub Repository](https://github.com/axelarnetwork/interchain-token-service/tree/main)
+- [AxelarJS SDK](https://github.com/axelarnetwork/axelarjs-sdk)
diff --git a/src/content/docs/dev/send-tokens/interchain-tokens/developer-guides/programmatically-create-a-canonical-token.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/developer-guides/programmatically-create-a-canonical-token.mdx
new file mode 100644
index 000000000..6021f069e
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/developer-guides/programmatically-create-a-canonical-token.mdx
@@ -0,0 +1,497 @@
+import { Callout } from "/src/components/callout";
+
+# Programmatically Create a Canonical Interchain Token Using the Interchain Token Service
+
+If you have an [ERC-20](https://docs.openzeppelin.com/contracts/4.x/erc20) token on one or more blockchains and you want to make the token interoperable across chains, the [Interchain Token Service](/dev/send-tokens/interchain-tokens/intro/) provides a solution. You can transform an ERC-20 token into an Interchain Token by deploying a [token manager](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/token-manager/TokenManager.sol).
+
+If you would like to create a wrapped, bridgeable version of your ERC-20 token on other chains, you can register it as a [Canonical Interchain Token](/dev/send-tokens/interchain-tokens/register-existing-token/) using the [`InterchainTokenFactory`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenFactory.sol) [contract](https://etherscan.io/address/0x83a93500d23Fbc3e82B410aD07A6a9F7A0670D66).
+
+**Each token can only be registered once as a Canonical Interchain Token.** This ensures unique and streamlined token management across different blockchains. Though you can register your Canonical Interchain Token directly through the [Interchain Token Portal](https://testnet.interchain.axelar.dev/), there are times where you may want to do so programmatically, such as when you have already deployed a token on one chain and wish to deploy a wrapped version of that token on another chain.
+
+In this tutorial, you will learn how to:
+
+- Programmatically create a Canonical Interchain Token from scratch using Axelar's Interchain Token Service
+- Register a Canonical Interchain Token on the BSC chain
+- Deploy remote Canonical Interchain Token on the Avalanche Fuji chain
+- Transfer your token between BSC and Avalanche Fuji
+
+## Prerequisites
+
+You will need:
+
+- A basic understanding of [Solidity](https://www.tutorialspoint.com/solidity/index.htm) and [JavaScript](https://www.w3schools.com/js/)
+- - A [MetaMask wallet](https://metamask.io/) with tBNB and Avax funds for testing. If you don’t have these funds, you can get tBNB from the [BSC faucet](https://www.bnbchain.org/en/testnet-faucet) and Avax from the Avalanche Fuji faucets ([1](https://faucets.chain.link/fuji), [2](https://core.app/tools/testnet-faucet/)).
+
+## Deploy an ERC-20 token on the BSC testnet
+
+[Create a Simple ERC-20 token](https://bakemytoken.com/binance) and give it a name and symbol. You can skip this step if you already have an ERC-20 token deployed on the BSC testnet.
+
+## **Set up your development environment**
+
+### Create and initialize a project
+
+Open up your terminal and navigate to any directory of your choice. Run the following commands to create and initiate a project:
+
+```bash
+mkdir canonical-interchain-token-project && cd canonical-interchain-token-project
+npm init -y
+```
+
+### Install Hardhat and the AxelarJS SDK
+
+Install Hardhat and the AxelarJS SDK with the following commands:
+
+```bash
+npm install --save-dev hardhat@2.18.1 dotenv@16.3.1
+npm install @axelar-network/axelarjs-sdk@0.13.9 crypto@1.0.1 @nomicfoundation/hardhat-toolbox@2.0.2
+```
+
+### Set up project ABIs
+
+Next, set up the ABIs for the [Interchain Token Service](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol), [Interchain Token Factory](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenFactory.sol), and the contract from the token you deployed.
+
+Create a folder named `utils`. Inside the folder, create the following new files and add the respective ABIs:
+
+- Add the [Interchain Token Service ABI](https://gist.github.com/Olanetsoft/2a632784e6753d34ca7ffc4f73bf58ed) to `interchainTokenServiceABI.json`.
+- Add the [Interchain Token Factory ABI](https://gist.github.com/Olanetsoft/7d24e936f4cf6bd3d10d7b4f9a18d838) to `interchainTokenFactoryABI.json`.
+- Add your custom token ABI to `customTokenABI.json`. You can get this from [BSC Scan](https://testnet.bscscan.com/) with the address of your deployed token.
+
+## **Set up an RPC for the local chain**
+
+Back in the root directory, set up an RPC for the BSC testnet. You will use this as your local (source) chain.
+
+### Create an `.env` file
+
+To make sure you’re not accidentally publishing your private key, create an [**`.env`** file](https://blog.bitsrc.io/a-gentle-introduction-to-env-files-9ad424cc5ff4) to store it in:
+
+```bash
+touch .env
+```
+
+### Add your private key to `.env` and `hardhat.config.js`
+
+[Export your private key](https://support.metamask.io/managing-my-wallet/secret-recovery-phrase-and-private-keys/how-to-export-an-accounts-private-key/) and add it to the **`.env`** file you just created:
+
+```bash
+PRIVATE_KEY= // Add your account private key here
+```
+
+
+
+If you will push this project on GitHub, create a `.gitignore` file and include `.env`.
+
+
+
+Then, create a file with the name `hardhat.config.js` and add the following code snippet:
+
+```javascript
+require("@nomicfoundation/hardhat-toolbox");
+require("dotenv").config({ path: ".env" });
+
+const PRIVATE_KEY = process.env.PRIVATE_KEY;
+
+/** @type import('hardhat/config').HardhatUserConfig */
+module.exports = {
+ solidity: "0.8.18",
+ networks: {
+ bsc: {
+ url: "https://bsc-testnet.drpc.org/",
+ chainId: 97,
+ accounts: [PRIVATE_KEY],
+ },
+ },
+};
+```
+
+## Register a Canonical Interchain Token on a local chain
+
+Now that you have set up an RPC for the BSC testnet, you can register a Canonical Interchain Token.
+
+### Create a `canonicalInterchainToken.js` script
+
+Create a new file named `canonicalInterchainToken.js` and import the required dependencies:
+
+- `Ethers.js`
+- The [AxelarJS SDK](https://github.com/axelarnetwork/axelarjs-sdk)
+- The custom token contract ABI
+- The address of the [`InterchainTokenService`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol) contract
+- The address of the [`InterchainTokenFactory`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenFactory.sol) contract
+
+```javascript
+const hre = require("hardhat");
+const crypto = require("crypto");
+const {
+ AxelarQueryAPI,
+ Environment,
+ EvmChain,
+ GasToken,
+} = require("@axelar-network/axelarjs-sdk");
+
+const interchainTokenServiceContractABI = require("./utils/interchainTokenServiceABI");
+const interchainTokenFactoryContractABI = require("./utils/interchainTokenFactoryABI");
+const customTokenContractABI = require("./utils/customTokenABI");
+
+const MINT_BURN = 0;
+const LOCK_UNLOCK = 2;
+
+// Addresses on mainnet/testnet
+const interchainTokenServiceContractAddress =
+ "0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C";
+const interchainTokenFactoryContractAddress =
+ "0x83a93500d23Fbc3e82B410aD07A6a9F7A0670D66";
+const customTokenAddress = "0x0EF6280417A1BF22c8fF05b54D7A7928a173E605"; // your token address
+```
+
+### Get the signer
+
+Next, create a `getSigner()` function in `canonicalInterchainToken.js`. This will obtain a signer for a secure transaction:
+
+```javascript
+//...
+
+async function getSigner() {
+ const [signer] = await ethers.getSigners();
+ return signer;
+}
+```
+
+### Get the contract instance
+
+Then, create a `getContractInstance()` function in `canonicalInterchainToken.js` . This will get the contract instance based on the contract’s address, ABI, and signer:
+
+```javascript
+//...
+
+async function getContractInstance(contractAddress, contractABI, signer) {
+ return new ethers.Contract(contractAddress, contractABI, signer);
+}
+```
+
+## Register Canonical Interchain Token
+
+Now you’re ready to register your token as a Canonical Interchain Token! Create a `registerCanonicalInterchainToken()` function for the BSC testnet. This will register a Canonical Interchain Token with your custom token address:
+
+```javascript
+// Register Canonical Interchain Token to the BSC chain.
+async function registerCanonicalInterchainToken() {
+ // Get a signer to sign the transaction
+ const signer = await getSigner();
+
+ // Create contract instances
+ const interchainTokenFactoryContract = await getContractInstance(
+ interchainTokenFactoryContractAddress,
+ interchainTokenFactoryContractABI,
+ signer,
+ );
+ const interchainTokenServiceContract = await getContractInstance(
+ interchainTokenServiceContractAddress,
+ interchainTokenServiceContractABI,
+ signer,
+ );
+
+ // Register a new Canonical Interchain Token
+ const deployTxData =
+ await interchainTokenFactoryContract.registerCanonicalInterchainToken(
+ customTokenAddress, // Your token address
+ );
+
+ // Retrieve the token ID of the newly registered token
+ const tokenId =
+ await interchainTokenFactoryContract.canonicalInterchainTokenId(
+ customTokenAddress,
+ );
+
+ const expectedTokenManagerAddress =
+ await interchainTokenServiceContract.tokenManagerAddress(tokenId);
+
+ console.log(
+ `
+ Transaction Hash: ${deployTxData.hash},
+ Token ID: ${tokenId},
+ Expected Token Manager Address: ${expectedTokenManagerAddress},
+ `,
+ );
+}
+```
+
+### Add a `main()` function
+
+Add a `main()` function to execute the `canonicalInterchainToken.js` script. It will handle any errors that may arise:
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ case "registerCanonicalInterchainToken":
+ await registerCanonicalInterchainToken();
+ break;
+ default:
+ console.error(`Unknown function: ${functionName}`);
+ process.exitCode = 1;
+ return;
+ }
+}
+
+main().catch((error) => {
+ console.error(error);
+ process.exitCode = 1;
+});
+```
+
+### Run the `canonicalInterchainToken.js` script to deploy to BSC
+
+Run the script in your terminal to register and deploy the token, specifying the `BSC` testnet:
+
+```bash
+FUNCTION_NAME=registerCanonicalInterchainToken npx hardhat run canonicalInterchainToken.js --network bsc
+```
+
+If you see something similar to the following on your console, you have successfully registered your token as a Canonical Interchain Token.
+
+```bash
+Transaction Hash: 0x4ba22486dda650578ed782b8fd4e9a394664e9b4dcb8c2cbd99403543a749325,
+Token ID: 0x90d04b71cd22ebcf0821ff59dd15d10865bf927ed36f0ad6b8c4a8686f0ffe58,
+Expected Token Manager Address: 0xEb910958C32fEB6D85cd1f7c04216BD354834D86,
+```
+
+### Store the token ID
+
+Copy the token ID and store it somewhere safe. You will need it to initiate a remote token transfer in a later step.
+
+### Check the transaction on the BSC testnet scanner
+
+Check the [BSC testnet scanner](https://testnet.bscscan.com/) to see if you have successfully registered your [token as a Canonical Interchain Token](https://testnet.bscscan.com/tx/0x4ba22486dda650578ed782b8fd4e9a394664e9b4dcb8c2cbd99403543a749325).
+
+## Deploy Remote Canonical Interchain Token
+
+You’ve just successfully a Canonical Interchain Token to BSC, which you are using as your local chain. Now, deploy the token remotely to Avalanche Fuji, which will be the remote chain in this tutorial. Remember that you can specify any two chains to be your local and remote chains.
+
+### Estimate gas fees
+
+In `canonicalInterchainToken.js`, call `estimateGasFee()` from the [AxelarJS SDK](https://www.notion.so/bd238d757a144a069501f0b481488ef3?pvs=21) to estimate the actual cost of deploying your remote Canonical Interchain Token on a remote chain:
+
+```javascript
+//...
+
+const api = new AxelarQueryAPI({ environment: Environment.TESTNET });
+
+// Estimate gas costs.
+async function gasEstimator() {
+ const gas = await api.estimateGasFee(
+ EvmChain.BINANCE,
+ EvmChain.AVALANCHE,
+ GasToken.ETH,
+ 700000,
+ 1.1,
+ );
+
+ return gas;
+}
+
+//...
+```
+
+### Perform remote token deployment
+
+Create a `deployRemoteCanonicalInterchainToken()` function that will perform token remote canonical deployment on the Avalanche Fuji testnet.
+
+```javascript
+//...
+
+// deployRemoteCanonicalInterchainToken: On Avalanche Fuji
+async function deployRemoteCanonicalInterchainToken() {
+ // Get a signer for authorizing transactions
+ const signer = await getSigner();
+
+ // Get contract for remote deployment
+ const interchainTokenFactoryContract = await getContractInstance(
+ interchainTokenFactoryContractAddress,
+ interchainTokenFactoryContractABI,
+ signer,
+ );
+
+ // Estimate gas fees
+ const gasAmount = await gasEstimator();
+
+ // Initiate transaction
+ const txn = await interchainTokenFactoryContract[
+ "deployRemoteCanonicalInterchainToken(address,string,uint256)"
+ ](customTokenAddress, "Avalanche", gasAmount, { value: gasAmount });
+
+ console.log(`Transaction Hash: ${txn.hash}`);
+}
+
+//...
+```
+
+### Update `main()` to deploy to remote chains
+
+Update `main()` to execute `deployRemoteCanonicalInterchainToken()` :
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ //...
+ case "deployRemoteCanonicalInterchainToken":
+ await deployRemoteCanonicalInterchainToken();
+ break;
+ default:
+ //...
+ }
+}
+
+//...
+```
+
+### Run the `canonicalInterchainToken.js` script to deploy to Avalanche Fuji testnet
+
+Run the script in your terminal to to deploy remote Canonical Interchain Token, once again specifying the `BSC` testnet (the source chain where all transactions are taking place):
+
+```bash
+FUNCTION_NAME=deployRemoteCanonicalInterchainToken npx hardhat run canonicalInterchainToken.js --network bsc
+```
+
+You should see something similar to the following on your console:
+
+```bash
+Transaction Hash: 0x3c36b04418aca90393435dbe9c2b65d26acc6e9f86aba1f34db27b41d82fda13
+```
+
+### Check the transaction on the Axelar testnet scanner
+
+Check the [Axelarscan testnet scanner](https://testnet.axelarscan.io/) to see if you have successfully deployed the remote Canonical Interchain Token “HM” on the Avalanche Fuji testnet. It should look something like [this](https://testnet.axelarscan.io/gmp/0x3c36b04418aca90393435dbe9c2b65d26acc6e9f86aba1f34db27b41d82fda13). Make sure that Axelar shows a successful transaction before continuing on to the next step.
+
+## Transfer your token between chains
+
+Now that you have registered and deployed a Canonical Interchain Token, both locally to BSC and remotely to Avalanche Fuji, you can transfer between those two chains via the [`interchainTransfer()`](/dev/send-tokens/interchain-tokens/interchain-transfer/) method.
+
+### Initiate a remote token transfer
+
+In `canonicalInterchainToken.js`, create a `transferTokens()` function that will facilitate remote token transfers between chains. Change the token ID to the `tokenId` that you [saved from an earlier step](#store-the-token-id), and change the address in `transfer` to your own wallet address:
+
+```javascript
+//...
+
+// Transfer token between chains.
+async function transferTokens() {
+ const signer = await getSigner();
+
+ const interchainTokenServiceContract = await getContractInstance(
+ interchainTokenServiceContractAddress,
+ interchainTokenServiceContractABI,
+ signer,
+ );
+
+ const customTokenContract = await getContractInstance(
+ customTokenAddress,
+ customTokenContractABI,
+ signer,
+ ); // Approve ITS to spend tokens
+
+ await customTokenContract.approve(
+ interchainTokenServiceContractAddress,
+ ethers.utils.parseEther("50"),
+ );
+
+ const gasAmount = await gasEstimator();
+
+ // Send via token
+ const transfer = await interchainTokenServiceContract.interchainTransfer(
+ "0x90d04b71cd22ebcf0821ff59dd15d10865bf927ed36f0ad6b8c4a8686f0ffe58", // token ID from registerCanonicalInterchainToken
+ "Avalanche", // Destination chain
+ "0x510e5EA32386B7C48C4DEEAC80e86859b5e2416C", // Destination address. Update with your own wallet address
+ ethers.utils.parseEther("50"), // Amount to transfer
+ "0x00",
+ gasAmount, // gasValue
+ { value: gasAmount },
+ );
+
+ console.log("Transfer Transaction Hash:", transfer.hash);
+}
+```
+
+### Update `main()` to execute token transfer
+
+Update the `main()` to execute `transferTokens()`:
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ //...
+ case "transferTokens":
+ await transferTokens();
+ break;
+ default:
+ //...
+ }
+}
+
+//...
+```
+
+### Run the `canonicalInterchainToken.js` script to transfer tokens
+
+Run the script in your terminal, specifying the `BSC` testnet:
+
+```bash
+FUNCTION_NAME=transferTokens npx hardhat run canonicalInterchainToken.js --network bsc
+```
+
+You should see something similar to the following on your console:
+
+```bash
+Transfer Transaction Hash: 0xd46a1941e04d06084eb7df3b1933617eccfb21a77dbcfb3b0399e1ac1c0ee6c9
+```
+
+If you see this, it means that your interchain transfer has been successful! 🎉
+
+
+ **Note:** If you get the following `nonce too low` error, wait a few minutes
+ and run `canonicalInterchainToken.js` again. Some chains have a longer
+ transaction time than others.
+
+
+```bash
+reason: 'nonce has already been used',
+code: 'NONCE_EXPIRED',
+error: ProviderError: nonce too low
+```
+
+### Check the transaction on the Axelar testnet scanner
+
+Check the [Axelarscan testnet scanner](https://testnet.axelarscan.io/) to see if you have successfully transferred HM from the BSC testnet to the Avalanche Fuji testnet. It should look something like [this](https://testnet.axelarscan.io/gmp/0xd46a1941e04d06084eb7df3b1933617eccfb21a77dbcfb3b0399e1ac1c0ee6c9).
+
+### Import the new token into your wallet
+
+You can also import the new token into your own wallet with its contract address that you saved from BSC Scan.
+
+## Congratulations!
+
+You have now programmatically created a Canonical Interchain Token using Axelar’s Interchain Token Service and transferred it between two chains. You should now be able to confidently create and manage your own Interchain Tokens, opening up a wide range of possibilities for token transfers and asset bridges.
+
+Great job making it this far! To show your support to the author of this tutorial, please post about your experience and tag [@axelarnetwork](https://x.com/axelar) on Twitter (X).
+
+## What’s next
+
+For further examples utilizing the Interchain Token Service, check out the following in the [`axelar-examples`](https://github.com/axelarnetwork/axelar-examples/tree/main) repo on GitHub:
+
+- [`its-custom-token`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-custom-token) — Demonstrates how to use the ITS with a custom token implementation.
+- [`its-interchain-token`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-interchain-token) — Demonstrates how to deploy Interchain Tokens that are connected across EVM chains and how to send some tokens across.
+- [`its-canonical-token`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-canonical-token) - Demonstrates how to deploy canonical Interchain Token and send cross-chain transfer for these tokens.
+- [`its-lock-unlock-fee`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-lock-unlock-fee) Demonstrates how to deploy deploy interchain token with lock/unlock_fee token manager type.
+- [`its-executable`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-executable) Demonstrates how to deploy interchain token and send a cross-chain transfer along with a message.
+- [`its-mint-burn-from`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-mint-burn-from) Demonstrates how to deploy interchain token with uses `burnFrom()` on token being bridged rather than `burn()`.
+
+## References
+
+- [Interchain Token Service Documentation](/dev/send-tokens/interchain-tokens/intro/)
+- [Interchain Tokens GitHub Repository](https://github.com/axelarnetwork/interchain-token-service/tree/main)
+- [AxelarJS SDK](https://github.com/axelarnetwork/axelarjs-sdk)
diff --git a/src/content/docs/dev/send-tokens/interchain-tokens/developer-guides/programmatically-create-a-token.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/developer-guides/programmatically-create-a-token.mdx
new file mode 100644
index 000000000..afc5353fa
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/developer-guides/programmatically-create-a-token.mdx
@@ -0,0 +1,495 @@
+# Create a new Interchain Token
+
+[Interchain Tokens](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interchain-token/InterchainToken.sol) are created and managed by Axelar’s [Interchain Token Service](https://github.com/axelarnetwork/interchain-token-service/tree/main), which uses [GMP messages](https://docs.axelar.dev/dev/general-message-passing/overview) to send tokens cross-chain. With it, you can build your own asset bridges, build asset transfers into your interchain dApp, and [take on many other use cases](https://community.axelar.network/t/expanding-the-axelar-ecosystem-ideas-for-infrastructure-projects/2583/2).
+
+The workflow can be summarized in three steps:
+
+1. The user obtains a token `x` from chain A.
+2. A message is sent to chain B specifying where the token should be transferred.
+3. Finally, Chain B receives the message is received and transfers token `x` to the appropriate destination address.
+
+In this tutorial, you will learn how to:
+
+- Programmatically create a new Interchain Token from scratch using Axelar's Interchain Token Service
+- Register and deploy the token locally on the Binance Smart chain (BSC)
+- Register and deploy the token remotely on the Avalanche Fuji chain
+- Transfer your token between those chains
+
+## **Prerequisites**
+
+You will need:
+
+- A basic understanding of [Solidity](https://www.tutorialspoint.com/solidity/index.htm) and [JavaScript](https://www.w3schools.com/js/)
+- A [MetaMask wallet](https://metamask.io/) with tBNB and Avax funds for testing. If you don’t have these funds, you can get tBNB from the [BSC faucet](https://www.bnbchain.org/en/testnet-faucet) and Avax from the Avalanche Fuji faucets ([1](https://faucets.chain.link/fuji), [2](https://core.app/tools/testnet-faucet/)).
+
+## **Set up your development environment**
+
+### Create and initialize a project
+
+Open up your terminal and navigate to any directory of your choice. Run the following commands to create and initiate a project:
+
+```bash
+mkdir interchain-token-project && cd interchain-token-project
+npm init -y
+```
+
+### Install Hardhat and the AxelarJS SDK
+
+Install [Hardhat](https://hardhat.org/) and the [AxelarJS SDK](https://github.com/axelarnetwork/axelarjs-sdk) with the following commands:
+
+```bash
+npm install --save-dev hardhat@2.18.1 dotenv@16.3.1
+npm install @axelar-network/axelarjs-sdk@0.13.9 crypto@1.0.1 @nomicfoundation/hardhat-toolbox@2.0.2
+```
+
+### Set up project ABIs
+
+Next, set up the ABIs for the Interchain Token Service, Interchain Token Factory, and Interchain Token Contract, as they will be needed during deployment.
+
+Create a folder named `utils`. Inside the folder, create the following new files and add the respective ABIs:
+
+- Add the [Interchain Token Service ABI](https://gist.github.com/Olanetsoft/2a632784e6753d34ca7ffc4f73bf58ed) to `interchainTokenServiceABI.json`.
+- Add the [Interchain Token Factory ABI](https://gist.github.com/Olanetsoft/7d24e936f4cf6bd3d10d7b4f9a18d838) to `interchainTokenFactoryABI.json`.
+- Add the [Interchain Token ABI](https://gist.github.com/Olanetsoft/39051a113dfa080d7c58e6cfc8d878cc) to `interchainTokenABI.json`.
+
+## **Set up an RPC for the local chain**
+
+Next, set up an RPC for the BSC testnet, which you will be using as your local (source) chain.
+
+### Create an `.env` file
+
+To make sure you’re not accidentally publishing your private key, create an [**`.env`** file](https://blog.bitsrc.io/a-gentle-introduction-to-env-files-9ad424cc5ff4) to store it in:
+
+```bash
+touch .env
+```
+
+### Add your private key to `.env` and `hardhat.config.js`
+
+[Export your private key](https://support.metamask.io/managing-my-wallet/secret-recovery-phrase-and-private-keys/how-to-export-an-accounts-private-key/) and add it to the `.env` file you just created:
+
+```bash
+PRIVATE_KEY= // Add your account private key here
+```
+
+
+
+Then, create a file with the name `hardhat.config.js` and add the following code snippet:
+
+```javascript
+require("@nomicfoundation/hardhat-toolbox");
+require("dotenv").config({ path: ".env" });
+
+const PRIVATE_KEY = process.env.PRIVATE_KEY;
+
+/** @type import('hardhat/config').HardhatUserConfig */
+module.exports = {
+ solidity: "0.8.18",
+ networks: {
+ bsc: {
+ url: "https://bsc-testnet.drpc.org/",
+ chainId: 97,
+ accounts: [PRIVATE_KEY],
+ },
+ },
+};
+```
+
+## Register and deploy a new Interchain Token to the local chain
+
+Now that you’ve set up a BSC testnet RPC, you can register and deploy a new Interchain Token. For the purposes of this tutorial, the token you’ll create will be called “New Interchain Token” and have the symbol “NIT”:
+
+### Create a `newInterchainToken.js` script
+
+Create a new file named `newInterchainToken.js` and import the required dependencies:
+
+- Ethers.js
+- The AxelarJS SDK
+- The contract ABIs
+- The address of the Interchain Token Service contract
+- The address of the Interchain Token Factory contract
+
+```javascript
+const hre = require("hardhat");
+const crypto = require("crypto");
+const ethers = hre.ethers;
+const {
+ AxelarQueryAPI,
+ Environment,
+ EvmChain,
+ GasToken,
+} = require("@axelar-network/axelarjs-sdk");
+
+const interchainTokenServiceContractABI = require("./utils/interchainTokenServiceABI");
+const interchainTokenFactoryContractABI = require("./utils/interchainTokenFactoryABI");
+const interchainTokenContractABI = require("./utils/interchainTokenABI");
+
+const interchainTokenServiceContractAddress =
+ "0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C";
+const interchainTokenFactoryContractAddress =
+ "0x83a93500d23Fbc3e82B410aD07A6a9F7A0670D66";
+```
+
+### Get the signer
+
+Next, create a `getSigner()` function in `newInterchainToken.js`. This will obtain a signer for a secure transaction:
+
+```javascript
+//...
+
+async function getSigner() {
+ const [signer] = await ethers.getSigners();
+ return signer;
+}
+```
+
+### Get the contract instance
+
+Then, create a `getContractInstance()` function in `newInterchainToken.js` . This will get the contract instance based on the contract’s address, ABI, and signer:
+
+```javascript
+//...
+
+async function getContractInstance(contractAddress, contractABI, signer) {
+ return new ethers.Contract(contractAddress, contractABI, signer);
+}
+```
+
+### Add a deployment function
+
+Now you’re ready to register and deploy your token! Create a `registerAndDeploy()` function for the BSC testnet. This will create a new token called “New Interchain Token” with the symbol “NIT”:
+
+```javascript
+// Register and deploy a new interchain token to the BSC testnet
+async function registerAndDeploy() {
+ // Generate random salt
+ const salt = "0x" + crypto.randomBytes(32).toString("hex");
+
+ // Create a new token
+ const name = "New Interchain Token";
+ const symbol = "NIT";
+ const decimals = 18;
+
+ // Initial token supply
+ const initialSupply = ethers.utils.parseEther("1000");
+
+ // Get a signer to sign the transaction
+ const signer = await getSigner();
+
+ // Create contract instances
+ const interchainTokenFactoryContract = await getContractInstance(
+ interchainTokenFactoryContractAddress,
+ interchainTokenFactoryContractABI,
+ signer,
+ );
+ const interchainTokenServiceContract = await getContractInstance(
+ interchainTokenServiceContractAddress,
+ interchainTokenServiceContractABI,
+ signer,
+ );
+
+ // Generate a unique token ID using the signer's address and salt
+ const tokenId = await interchainTokenFactoryContract.interchainTokenId(
+ signer.address,
+ salt,
+ );
+
+ // Retrieve new token address
+ const tokenAddress =
+ await interchainTokenServiceContract.interchainTokenAddress(tokenId);
+
+ // Retrieve token manager address
+ const expectedTokenManagerAddress =
+ await interchainTokenServiceContract.tokenManagerAddress(tokenId);
+
+ // Deploy new Interchain Token
+ const deployTxData =
+ await interchainTokenFactoryContract.deployInterchainToken(
+ salt,
+ name,
+ symbol,
+ decimals,
+ initialSupply,
+ signer.address,
+ );
+
+ console.log(
+ `
+ Deployed Token ID: ${tokenId},
+ Token Address: ${tokenAddress},
+ Transaction Hash: ${deployTxData.hash},
+ salt: ${salt},
+ Expected Token Manager Address: ${expectedTokenManagerAddress},
+ `,
+ );
+}
+```
+
+### Add a `main()` function
+
+Add a `main()` function for executing the `newInterchainToken.js` script. It will handle any errors that may arise:
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ case "registerAndDeploy":
+ await registerAndDeploy();
+ break;
+ default:
+ console.error(`Unknown function: ${functionName}`);
+ process.exitCode = 1;
+ return;
+ }
+}
+
+main().catch((error) => {
+ console.error(error);
+ process.exitCode = 1;
+});
+```
+
+### Run the `newInterchainToken.js` script to deploy to BSC
+
+Run the script in your terminal to register and deploy the token, specifying the BSC testnet:
+
+```bash
+FUNCTION_NAME=registerAndDeploy npx hardhat run newInterchainToken.js --network bsc
+```
+
+You should see something similar to the following on your console:
+
+```javascript
+Deployed Token ID: 0x46883a49f2798ae966b1bb98f1c2d577d6b4edbcd1fca9d0a28cc2a254852f1e,
+Token Address: 0x5dcDf836212CAc43dacb81af07fF84D805422f6c,
+Transaction Hash: 0xa9a7054dbb348eecbe4f1486d58cda758442489f4a9f0a20d70d1fce63a179dd,
+salt: 0x2ed5cdfe34cf85a1e46aa19679ad29d17d07e8a6197433a2738fabc5e7365d2d,
+Expected Token Manager Address: 0xA7a00f1c3028c81d69F22232822DE82fC8f08403,
+```
+
+This shows that you have created a new interchain token called New Interchain Token (NIT) and deployed it on the BSC testnet.
+
+### Check the transaction on the BSC testnet scanner
+
+Check the [BSC testnet scanner](https://testnet.bscscan.com/) to see if you have successfully [created](https://testnet.bscscan.com/tx/0xa9a7054dbb348eecbe4f1486d58cda758442489f4a9f0a20d70d1fce63a179dd) and [locally deployed](https://testnet.bscscan.com/tx/0xa9a7054dbb348eecbe4f1486d58cda758442489f4a9f0a20d70d1fce63a179dd) a new Interchain Token on the BSC testnet.
+
+### Get new token address
+
+On BSC Scan, navigate to the **ERC-20 Tokens Transferred** section and click **New Interchain Token (NIT)**. This should take you to a page for your new token. Copy the token contract address from the **Other Info** section and store it somewhere safe. You will need it to initiate a remote transfer from the token in a later step.
+
+## Deploy an Interchain Token to a remote chain
+
+You’ve just successfully deployed an Interchain Token to BSC, which you are using as your local chain. Now, deploy it to Avalanceh Fuji, which will be the remote chain in this tutorial. Remember that you can specify any two chains to be your local and remote chains.
+
+### Estimate gas fees
+
+In `newInterchainToken.js`, call `estimateGasFee()` from the [AxelarJS SDK](https://www.npmjs.com/package/@axelar-network/axelarjs-sdk) to estimate the actual cost of deploying your token on a remote chain:
+
+```javascript
+//...
+
+const api = new AxelarQueryAPI({ environment: Environment.TESTNET });
+
+// Estimate gas costs.
+async function gasEstimator() {
+ const gas = await api.estimateGasFee(
+ EvmChain.BINANCE,
+ EvmChain.AVALANCHE,
+ GasToken.ETH,
+ 700000,
+ 1.1,
+ );
+
+ return gas;
+}
+
+//...
+```
+
+### Perform remote token deployment
+
+Create a `deployToRemoteChain()` function that will perform token remote deployment on the Avlanche Fuji testnet. Make sure to replace the `salt` value with the salt returned to your terminal from when you ran `registerAndDeploy()`:
+
+```javascript
+//...
+
+// Deploy to remote chain: Avalanche Fuji
+async function deployToRemoteChain() {
+ // Get a signer for authorizing transactions
+ const signer = await getSigner();
+ // Get contract for remote deployment
+ const interchainTokenFactoryContract = await getContractInstance(
+ interchainTokenFactoryContractAddress,
+ interchainTokenFactoryContractABI,
+ signer,
+ );
+
+ // Estimate gas fees
+ const gasAmount = await gasEstimator();
+
+ // Salt value from registerAndDeploy(). Replace with your own
+ const salt =
+ "0x2ed5cdfe34cf85a1e46aa19679ad29d17d07e8a6197433a2738fabc5e7365d2d";
+
+ // Initiate transaction
+ const txn = await interchainTokenFactoryContract[
+ "deployRemoteInterchainToken(bytes32,string,uint256)"
+ ](salt, "Avalanche", gasAmount, { value: gasAmount });
+
+ console.log(`Transaction Hash: ${txn.hash}`);
+}
+
+//...
+```
+
+### Update `main()` to deploy to remote chains
+
+Update `main()` to execute `deployToRemoteChain()` :
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ //...
+ case "deployToRemoteChain":
+ await deployToRemoteChain();
+ break;
+ default:
+ //...
+ }
+}
+
+//...
+```
+
+### Run the `newInterchainToken.js` script to deploy to Avalanche Fuji
+
+Run the script in your terminal to register and deploy the token, once again specifying the `bsc` testnet (the source chain where all transactions are taking place):
+
+```javascript
+FUNCTION_NAME=deployToRemoteChain npx hardhat run newInterchainToken.js --network bsc
+```
+
+You should see something similar to the following on your console:
+
+```bash
+Transaction Hash: 0x7ad7cbbb7b8a76b26eccd97f6c41d6f38066d829f7e0554ab60223b18665f98a
+```
+
+### Check the transaction on the Axelar testnet scanner
+
+Check the [Axelarscan testnet scanner](https://testnet.axelarscan.io/) to see if you have successfully created and remotely deployed NIT on the Avalanche Fuji testnet. It should look something like [this](https://testnet.axelarscan.io/gmp/0x7ad7cbbb7b8a76b26eccd97f6c41d6f38066d829f7e0554ab60223b18665f98a). Make sure that Axelar shows a successful transaction before continuing on to the next step.
+
+## Transfer your token between chains
+
+Now that you have deployed your token both locally to BSC and remotely to Avalanche Fuji, you can transfer between those two chains using the NIT you just deployed via the [`interchainTransfer()`](https://github.com/axelarnetwork/interchain-token-service/blob/9edc4318ac1c17231e65886eea72c0f55469d7e5/contracts/interfaces/IInterchainTokenStandard.sol#L19) method.
+
+### Initiate a remote token transfer directly from the token
+
+In `newInterchainToken.js`, create a `transferTokens()` function that will facilitate remote token transfers between chains. Change the address in `interchainToken` to the new token address from the FTM scan that you saved from an earlier step, and change the address in `transfer` to your own wallet address:
+
+```javascript
+//...
+
+async function transferTokens() {
+ // Get signer
+ const signer = await getSigner();
+
+ const interchainToken = await getContractInstance(
+ "0x5dcDf836212CAc43dacb81af07fF84D805422f6c", // Update with new token address
+ interchainTokenContractABI, // Interchain Token contract ABI
+ signer,
+ );
+
+ // Calculate gas amount
+ const gasAmount = await gasEstimator();
+
+ // Initiate transfer via token
+ const transfer = await interchainToken.interchainTransfer(
+ "Avalanche", // Destination chain
+ "0x510e5EA32386B7C48C4DEEAC80e86859b5e2416C", // Update with your own wallet address
+ ethers.utils.parseEther("25"), // Transfer 25 tokens
+ "0x", // Empty data payload
+ { value: gasAmount }, // Transaction options
+ );
+ console.log("Transfer Transaction Hash:", transfer.hash);
+}
+
+//...
+```
+
+### Update `main()` to execute token transfer
+
+Update the `main()` to execute `transferTokens()`:
+
+```javascript
+//...
+
+async function main() {
+ const functionName = process.env.FUNCTION_NAME;
+ switch (functionName) {
+ //...
+ case "transferTokens":
+ await transferTokens();
+ break;
+ default:
+ //...
+ }
+}
+
+//...
+```
+
+### Run the `newInterchainToken.js` script to transfer tokens
+
+Run the script in your terminal, specifying the `BSC` testnet:
+
+```javascript
+FUNCTION_NAME=transferTokens npx hardhat run newInterchainToken.js --network bsc
+```
+
+You should see something similar to the following on your console:
+
+```bash
+Transfer Transaction Hash: 0x495f530e603e3bfe425998dcced66e849353a4ba0196cbc0a041ac2f28eb8f96
+```
+
+If you see this, it means that your interchain transfer has been successful! 🎉
+
+### Check the transaction on the Axelar testnet scanner
+
+Check the [Axelarscan testnet scanner](https://testnet.axelarscan.io/) to see if you have successfully transferred NIT from the BSC testnet to the Avalanche Fuji testnet. It should look something like [this](https://testnet.axelarscan.io/gmp/0x495f530e603e3bfe425998dcced66e849353a4ba0196cbc0a041ac2f28eb8f96).
+
+### Import the new token into your wallet
+
+You can also import the new token into your own wallet with its contract address that you saved from BSC Scan. You should have 975 NIT on BSC and 25 NIT on Avalanche Fuji.
+
+## Congratulations!
+
+You have now programmatically created a new interchain token called NIT using Axelar’s Interchain Token Service and transferred it between two chains. You should now be able to confidently create and manage your own Interchain Tokens, opening up a wide range of possibilities for token transfers and asset bridges.
+
+Great job making it this far! To show your support to the author of this tutorial, please post about your experience and tag [@axelarnetwork](https://x.com/axelar) on Twitter (X).
+
+## What’s next
+
+For further examples utilizing the Interchain Token Service, check out the following in the [`axelar-examples`](https://github.com/axelarnetwork/axelar-examples/tree/main) repo on GitHub:
+
+- [`its-custom-token`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-custom-token) — Demonstrates how to use the ITS with a custom token implementation.
+- [`its-interchain-token`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-interchain-token) — Demonstrates how to deploy Interchain Tokens that are connected across EVM chains and how to send some tokens across.
+- [`its-canonical-token`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-canonical-token) - Demonstrates how to deploy canonical Interchain Token and send cross-chain transfer for these tokens.
+- [`its-lock-unlock-fee`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-lock-unlock-fee) Demonstrates how to deploy deploy interchain token with lock/unlock_fee token manager type.
+- [`its-executable`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-executable) Demonstrates how to deploy interchain token and send a cross-chain transfer along with a message.
+- [`its-mint-burn-from`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-mint-burn-from) Demonstrates how to deploy interchain token with uses `burnFrom()` on token being bridged rather than `burn()`.
+
+## References
+
+- [Interchain Token Service Documentation](/dev/send-tokens/interchain-tokens/intro/)
+- [Interchain Tokens GitHub Repository](https://github.com/axelarnetwork/interchain-token-service/tree/main)
+- [AxelarJS SDK](https://github.com/axelarnetwork/axelarjs-sdk)
diff --git a/src/pages/dev/reference/interchain-token-service-rate-limit.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/flow-limit.mdx
similarity index 80%
rename from src/pages/dev/reference/interchain-token-service-rate-limit.mdx
rename to src/content/docs/dev/send-tokens/interchain-tokens/flow-limit.mdx
index 739b170ac..854401ed5 100644
--- a/src/pages/dev/reference/interchain-token-service-rate-limit.mdx
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/flow-limit.mdx
@@ -1,12 +1,12 @@
-# Rate Limit in Interchain Token Service
+# Flow Limit in Interchain Token Service
## Overview
-`FlowLimit` ensures the stability and security of interchain operations by setting constraints on the volume of tokens that can be transferred within a specified time frame. This prevents system abuse and overload, which is crucial in Interchain transfers. `FlowLimit` is managed by the [`FlowLimit` contract](https://github.com/axelarnetwork/interchain-token-service/blob/v1.0.0/contracts/utils/FlowLimit.sol), a core component of the [Interchain Token Service (ITS)](https://github.com/axelarnetwork/interchain-token-service/blob/v1.0.0/contracts/InterchainTokenService.sol) designed to regulate the flow of tokens across different blockchains.
+A `FlowLimit` ensures the stability and security of interchain operations by setting constraints on the volume of tokens that can be transferred within a specified time frame. This prevents system abuse and overload, which is crucial in Interchain transfers, and can be used to prevent transfers of a token on a chain that is undergoing an emergency situation. Flow limits are managed by the [`FlowLimit` contract](https://github.com/axelarnetwork/interchain-token-service/blob/v1.0.0/contracts/utils/FlowLimit.sol).
-The `FlowLimit` contract is [integrated](https://github.com/axelarnetwork/interchain-token-service/blob/0a00533f19197a285d6bddc8ec0c2e908094ebfe/contracts/InterchainTokenService.sol#L520) into the token manager contracts within the Interchain Token Service. These token managers, responsible for handling tokens before and after interchain transfers, utilize the `FlowLimit` functionalities to regulate token transfers and maintain system integrity.
+The `FlowLimit` contract is [used by](https://github.com/axelarnetwork/interchain-token-service/blob/v1.0.0/contracts/token-manager/TokenManager.sol#L15) the [token manager contract](https://github.com/axelarnetwork/interchain-token-service/blob/v1.0.0/contracts/token-manager/TokenManager.sol#L21). These token managers, use the `FlowLimit` functionalities to set cross-chain transfer volume going in and out of a given blockchain.
-This guide provides a comprehensive understanding of how the `FlowLimit` contract operates within the context of [Interchain](https://github.com/axelarnetwork/interchain-token-service/blob/v1.0.0/contracts/InterchainTokenService.sol) token transfers.
+This guide provides a comprehensive understanding of how the `FlowLimit` contract operates within the context of [Interchain token transfers](https://github.com/axelarnetwork/interchain-token-service/blob/v1.0.0/contracts/InterchainTokenService.sol#L455).
## Core Aspects
@@ -31,7 +31,7 @@ The `FlowLimit` contract contains the following public functions.
### `flowLimit()`
Returns the current flow limit value.
-
+
```solidity
/**
* @notice Returns the current flow limit.
@@ -43,11 +43,11 @@ function flowLimit() public view returns (uint256 flowLimit_) {
}
}
```
-
+
### `flowOutAmount()`
Returns the current total amount of tokens that have flowed out in the current epoch.
-
+
```solidity
/**
* @notice Returns the current flow out amount.
@@ -62,11 +62,11 @@ function flowOutAmount() external view returns (uint256 flowOutAmount_) {
}
}
```
-
+
### `flowInAmount()`
Returns the current total amount of tokens that have flowed in the current epoch.
-
+
```solidity
/**
* @notice Returns the current flow in amount.
@@ -81,7 +81,7 @@ function flowInAmount() external view returns (uint256 flowInAmount_) {
}
}
```
-
+
## Internal Management Functions
The `FlowLimit` contract contains the following internal functions.
@@ -89,7 +89,7 @@ The `FlowLimit` contract contains the following internal functions.
### `_setFlowLimit(uint256, bytes32)`
Sets the flow limit for a specific token.
-
+
```solidity
/**
* @notice Internal function to set the flow limit.
@@ -104,11 +104,11 @@ function _setFlowLimit(uint256 flowLimit_, bytes32 tokenId) internal {
emit FlowLimitSet(tokenId, msg.sender, flowLimit_);
}
```
-
+
### `_addFlowOut(uint256)`
Adds to the flow out amount, ensuring it does not exceed the flow limit.
-
+
```solidity
/**
* @notice Adds a flow out amount.
@@ -125,11 +125,11 @@ function _addFlowOut(uint256 flowOutAmount_) internal {
_addFlow(flowLimit_, slotToAdd, slotToCompare, flowOutAmount_);
}
```
-
+
### `_addFlowIn(uint256)`
Adds to the flow in amount, also ensuring adherence to the flow limit.
-
+
```solidity
/**
* @notice Adds a flow in amount.
@@ -154,25 +154,28 @@ There are several options for setting and overriding flow limits in the Intercha
### Fully managed flow limits
If you want Axelar to manage the flow limits for the token and not deal with it yourself:
+
- Deploy the token with the `minter` address set to `address(0)`
### Partially managed flow limits
If you want to manage the flow limits together with Axelar:
+
- Deploy the token with the `minter` address set to your Deployer account or a multi-sig wallet
-If you want to manage the flow limits alone:
+ If you want to manage the flow limits alone:
- Deploy the token with the `minter` address set to your Deployer account
- Call `tokenManager.removeFlowLimiter(itsAddress)` to remove flow limit management by Axelar
### Unmanaged flow limits
If you don't want anyone to manage flow limits:
+
- Deploy the token with the `minter` address set to your Deployer account
- Call `tokenManager.removeFlowLimiter(itsAddress)` to remove flow limit management by Axelar
- Call `tokenManager.removeFlowLimiter(minter)` to remove flow limit management by the minter
- Call `tokenManager.transferOperatorship(address(0))` to remove operatorship
-The following is an example of how to set a flow limit using the `setFlowLimits` method. You might want to increase the limit to the max before removing access granted to yourself.
+The following is an example of how to set a flow limit using the `setFlowLimits` method. You might want to increase the limit to the max before removing access granted to yourself.
```solidity
/**
diff --git a/src/content/docs/dev/send-tokens/interchain-tokens/integrate-custom-token.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/integrate-custom-token.mdx
new file mode 100644
index 000000000..7b5e07f51
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/integrate-custom-token.mdx
@@ -0,0 +1,154 @@
+# Integrate Custom Token
+
+import { Callout } from "/src/components/callout";
+
+Custom tokens are independently deployed tokens, as opposed to [InterchainTokens](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interchain-token/InterchainToken.sol) deployed via the [Interchain Token Service (ITS)](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol). These tokens are integrated with ITS across different chains by deploying a Token Manager for each.
+
+Once a custom token has a Token Manager deployed on a given chain, it becomes bridgeable between blockchains that also have a token connected to a Token Manager sharing the same [`interchainTokenId`](/dev/send-tokens/interchain-tokens/intro/#interchain-token-id).
+
+## Install the Axelar ITS Dependency
+
+Install the Axelar [Interchain Token Service (ITS) package](https://www.npmjs.com/package/@axelar-network/interchain-token-service) using npm or any other node package manager:
+
+```bash
+npm i @axelar-network/interchain-token-service
+```
+
+## Build and Deploy Your ERC-20 Token on Multiple Chains
+
+Build your ERC-20 token and deploy it on multiple chains. You can use a tool like the [Create3 Deployer](/dev/solidity-utilities/#create3-deployer) to ensure your token has the same address across chains.
+
+Example token contract:
+
+```solidity
+import "@openzeppelin/contracts/token/ERC20/ERC20.sol";
+import "@openzeppelin/contracts/token/ERC20/extensions/ERC20Burnable.sol";
+
+contract MyCustomToken is ERC20, ERC20Burnable {
+ constructor(address initialOwner)
+ ERC20("My Custom Token", "MCT")
+ {
+ // Initialization code here
+ }
+
+ function mint(address to, uint256 amount) public onlyMinter {
+ _mint(to, amount);
+ }
+
+ function burn(address from, uint256 amount) public onlyMinter {
+ _burn(from, amount);
+ }
+}
+```
+
+This token is a simple implementation of an ERC-20 token that includes the critical functions needed to integrate with ITS: the ability to `mint()` and `burn()` tokens. ITS calls these functions when bridging tokens between chains.
+
+You can also inherit from the [InterchainTokenStandard](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interchain-token/InterchainTokenStandard.sol#L12) so your token has built-in cross-chain functionality, such as the [interchainTransfer()](/dev/send-tokens/interchain-tokens/interchain-transfer/) function.
+
+## Integrate Custom Token with ITS
+
+After deploying your custom tokens on your preferred chains, the next step is to integrate your token with ITS by following these steps:
+
+1. [Register token metadata with the ITS Contract](#register-token-metadata-with-the-its-contract)
+2. [Register custom token with the Interchain Token Factory](#register-custom-token-with-the-interchain-token-factory)
+3. [Link custom token with the Interchain Token Factory](#link-custom-token-with-the-interchain-token-factory)
+4. [Assign the minter role to your token's Token Manager](#assign-the-minter-role-to-your-tokens-token-manager)
+
+### Register Token Metadata with the ITS Contract
+
+Register your token metadata using the [`registerTokenMetadata`](https://github.com/axelarnetwork/interchain-token-service/blob/94677f1072da127a0ee7ff5ab6784dcfe11789e8/contracts/InterchainTokenService.sol#L274) function on the ITS contract. This function registers metadata for a token on the ITS Hub. This metadata is used for scaling linked tokens.
+For example, if you are integrating your custom token on chains A, B, and C, you should register token metadata on each chain separately. The `registerTokenMetadata()` function must be called on each chain the token will be linked on. When triggered, a cross-chain message will be sent from your source chain to ITS Hub on Axelar.
+
+```solidity
+function registerTokenMetadata(
+ address tokenAddress, // your token address
+ uint256 gasValue // gas value
+) external payable {};
+```
+
+This function registers metadata for a token on the [ITS Hub](/dev/amplifier/its-hub/introduction/). This metadata is used for scaling linked tokens.
+
+> **Note:** Token metadata must be registered before [`linkToken`](https://github.com/axelarnetwork/interchain-token-service/blob/94677f1072da127a0ee7ff5ab6784dcfe11789e8/contracts/InterchainTokenService.sol#L329) can be called for the corresponding token. This function links a remote token on `destinationChain` to a local token corresponding to the `tokenId` computed from the provided `salt`.
+
+You can see a real example of this function being used in [this transaction on Axelarscan](https://testnet.axelarscan.io/gmp/0xf860bd8802d046fb0c752c355bc73c87e69f701348420c6cbdf82534b87c4822-2), which demonstrates registering a token metadata on BNB.
+
+
+### Register Custom Token with the Interchain Token Factory
+
+The [registerCustomToken()](https://github.com/axelarnetwork/interchain-token-service/blob/cc6ef7282e18c6b2842cbf1098b06161e38ea32e/contracts/InterchainTokenService.sol#L298) function registers an existing ERC-20 token (your custom token) under an `interchainTokenId` computed from the provided `salt`. Once executed, your token's [token manager](/dev/send-tokens/interchain-tokens/token-manager/) will be deployed for that blockchain. This function only needs to be called once on a single "home" chain that your token is being integrated with, as opposed to the `registerTokenMetadata()` function that must be triggered on each chain the token will be linked on.
+
+```solidity
+function registerCustomToken(
+ bytes32 salt, // your unique salt value
+ address tokenAddress, // your custom token address
+ TokenManagerType tokenManagerType, // token manager type
+ address operator // operator address
+) external payable returns (bytes32 tokenId) {};
+```
+
+This function is called from the [Interchain Token Factory](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenFactory.sol) rather than directly from ITS because the Factory provides additional utility functions and standardized `interchainTokenId` computation logic.
+
+
+ **Security Note:** The key used to register custom tokens is critical for
+ security. If that key is compromised, the token can be compromised across
+ multiple chains. - Interchain native tokens can only be deployed to additional
+ chains via the same deployer key, so that key must be securely retained. -
+ Tokens registered on ITS should be cautious about granting mint/burn
+ permissions to other contracts. For example, sharing mint permission with the
+ Polygon native bridge is not supported (the Polygon native bridge only looks
+ for burns, which ITS uses—potentially allowing duplicate sends).
+
+
+
+#### Parameters
+
+1. `salt:` The salt is used to compute the `interchainTokenId`. It must be unique for your token integration to ensure the `interchainTokenId` does not intersect with another `interchainTokenId`. If the combination of the `salt` and `sender` is not unique, the transaction will revert.
+1. `tokenAddress`: The token address being linked.
+1. `tokenManagerType`: The [type](/dev/send-tokens/interchain-tokens/token-manager/#token-manager-types) of manager being integrated. The value passed in must correspond to the `enum` value of the manager. (ie 2 for [lockUnlock](/dev/send-tokens/interchain-tokens/token-manager/#lockunlock), 4 for [mintBurn](/dev/send-tokens/interchain-tokens/token-manager/#mintburn)).
+1. `operator`: The address that will hold the [operator](/dev/send-tokens/interchain-tokens/minter-operator-roles/#operator-role) role for this token's token manager.
+
+
+You can see a real example of this function being used in [this transaction on BSC Scan](https://testnet.bscscan.com/tx/0xf0c3fbbece17cc12d9de76182540afb4f5c6c47aeca65c40f9d58f71e362dffe), which demonstrates registering a custom token on BNB.
+
+
+### Link Custom Token with the Interchain Token Factory
+
+To connect your custom tokens between different chains, you can use the [`linkToken`](https://github.com/axelarnetwork/interchain-token-service/blob/94677f1072da127a0ee7ff5ab6784dcfe11789e8/contracts/InterchainTokenFactory.sol#L541) function. This can only be called once your token metadata has been [registered](/dev/send-tokens/interchain-tokens/integrate-custom-token/#register-token-metadata-with-the-its-contract) on both chains and at least one of your tokens has been registered on a given "home" chain via the [registerCustomToken()](/dev/send-tokens/interchain-tokens/integrate-custom-token/#register-custom-token-with-the-interchain-token-factory) function.
+
+```solidity
+function linkToken(
+ bytes32 salt, // your unique salt value previously used
+ string calldata destinationChain, // destination chain
+ bytes calldata destinationTokenAddress, // destination custom token address
+ TokenManagerType tokenManagerType, // token manager type
+ bytes calldata linkParams, // operator address
+ uint256 gasValue // gas value
+) external payable returns (bytes32 tokenId) {}
+```
+
+This function does the following:
+
+1. It computes a `interchainTokenId` using the same salt you used during token registration.
+2. Creates a cross-chain message that instructs the destination chain to deploy a [Token Manager](/dev/send-tokens/interchain-tokens/token-manager/) for your token.
+3. Establishes the connection between your tokens across chains by associating them with the same `interchainTokenId`.
+4. Sets up the appropriate [Token Manager](/dev/send-tokens/interchain-tokens/token-manager/#token-manager-types) type that defines how tokens will be bridged (lock/unlock, mint/burn, etc.).
+
+You can see a real example of this function being used in [this transaction on Axelarscan](https://testnet.axelarscan.io/gmp/0x11c2a212180d7ea2babe7aceb66c32c1e235cc159bceeb4dd6d04411f4a9669f), which demonstrates linking a token between BNB chain and Avalanche.
+
+
+### Assign the `minter` Role to Your Token's Token Manager
+
+Transfer the minter / burn role to the [Token Manager](/dev/send-tokens/interchain-tokens/token-manager/) using the [transferMintership()](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/utils/Minter.sol#L31) function on your token (or any AccessControls contract that may be handling role management for your token). To retrieve your token manager address, use the `tokenManagerAddress` function on the ITS contract by specifying your `tokenId`. This is role transfer is necessary because when your token is bridged to a destination chain, the `msg.sender` of the `mint()` call will be the Token Manager.
+
+
+## What's Next
+
+For further examples utilizing the Interchain Token Service, check out the [`axelar-examples`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm) repository on GitHub. There, you can find implementations such as:
+
+- [`its-custom-token`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-custom-token) — Demonstrates how to use ITS with a custom token implementation.
+- [`its-executable`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-executable) — Demonstrates how to deploy an interchain token and send a cross-chain transfer along with a message.
+- [`its-mint-burn-from`](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-mint-burn-from) — Demonstrates how to deploy an interchain token that uses `burnFrom()` instead of `burn()` when bridging tokens.
+
+## Tutorial
+
+For a step-by-step guide on integrating a custom token, check out the [Link Custom Tokens Deployed Across Multiple Chains into Interchain Tokens](/dev/send-tokens/interchain-tokens/developer-guides/link-custom-tokens-deployed-across-multiple-chains-into-interchain-tokens/) tutorial.
diff --git a/src/content/docs/dev/send-tokens/interchain-tokens/interchain-token-executable.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/interchain-token-executable.mdx
new file mode 100644
index 000000000..de97f4619
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/interchain-token-executable.mdx
@@ -0,0 +1,127 @@
+# Interchain Token Service Executable
+
+import { Callout } from "/src/components/callout";
+
+You can use the [Axelar Interchain Token Service (ITS)](https://github.com/axelarnetwork/interchain-token-service/tree/main) to create a new Interchain Token or integrate an existing ERC-20 token to ITS to give your token bridging functionality. ITS also allows you to send custom messages when making a cross-chain transfer for an ITS token, enabling you to execute specific logic on the destination chain.
+
+## Setting Up an Executable Token
+
+If you want your token transfers to trigger custom logic on the destination chain, the destination contract must implement the [InterchainTokenExecutable](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/executable/InterchainTokenExecutable.sol) interface.
+
+Once your token has been integrated with ITS, you can use the executable functionality to send messages along with your cross-chain token transfer.
+
+## Send Token + Message from Source Chain
+
+To send a token transfer with a custom message, use the `callContractWithInterchainToken()` function from the Interchain Token Service contract.
+You should provide the `tokenId`, `destinationChain`, `destinationAddress`, `amount`, and `data` as parameters.
+
+```solidity
+/**
+ * @notice Initiates an interchain transfer of tokens through the token service.
+ * @param tokenId The token ID.
+ * @param destinationChain The destination chain.
+ * @param destinationAddress The destination address (bytes format).
+ * @param amount The amount of tokens to transfer.
+ * @param data Metadata for the cross-chain transfer. To execute a contract on the destination,
+ * format as bytes.concat(bytes4(0), yourCustomPayload).
+ */
+function callContractWithInterchainToken(
+ bytes32 tokenId,
+ string calldata destinationChain,
+ bytes calldata destinationAddress,
+ uint256 amount,
+ bytes calldata data
+) external payable
+```
+
+
+ - The `destinationAddress` should be an address encoded as bytes. Use the
+ [toBytes()](https://github.com/axelarnetwork/axelar-gmp-sdk-solidity/blob/main/contracts/libs/AddressBytes.sol#L30)
+ method to accomplish this on-chain.
+ - To execute code on the destination
+ chain, the `metadata` parameter should be formatted as:
+ `bytes.concat(bytes4(0), yourCustomPayload)`. The leading `bytes4(0)` signals
+ this is an executable transfer.
+
+
+## Execute on Destination Chain
+
+When the tokens arrive on the destination chain, if the destination address implements the `InterchainTokenExecutable` interface, the system will:
+
+1. Transfer the tokens to your contract.
+1. Call the `_executeWithInterchainToken()` function on your contract.
+
+Your contract needs to implement the `_executeWithInterchainToken()` function that contains your custom logic:
+
+```solidity
+/**
+ * @notice Internal function containing the logic to be executed with interchain token transfer.
+ * derived contracts must implement @dev Logic.
+ * @param commandId The unique message id.
+ * @param sourceChain The source chain of the token transfer.
+ * @param sourceAddress The source address of the token transfer.
+ * @param data The custom data payload you included in the metadata.
+ * @param tokenId The token ID.
+ * @param token The token address.
+ * @param amount The amount of tokens being transferred.
+ */
+function _executeWithInterchainToken(
+ bytes32 commandId,
+ string calldata sourceChain,
+ bytes calldata sourceAddress,
+ bytes calldata data,
+ bytes32 tokenId,
+ address token,
+ uint256 amount
+) internal virtual;
+```
+
+The transferred amount is accessible in the `amount` parameter, and any additional data you included is available in the `data` parameter.
+
+## Implementation Example
+
+Here's a simple example of a contract that implements the InterchainTokenExecutable interface:
+
+```solidity
+// SPDX-License-Identifier: MIT
+pragma solidity ^0.8.0;
+
+import "@axelar-network/interchain-token-service/contracts/executable/InterchainTokenExecutable.sol";
+
+contract MyDestinationContract is InterchainTokenExecutable {
+ // Event to log received transfers
+ event TokensReceived(
+ string sourceChain,
+ bytes sourceAddress,
+ uint256 amount,
+ bytes data
+ );
+
+ /**
+ * @notice Handle incoming token transfers with custom logic
+ */
+ function _executeWithInterchainToken(
+ bytes32 commandId,
+ string calldata sourceChain,
+ bytes calldata sourceAddress,
+ bytes calldata data,
+ bytes32 tokenId,
+ address token,
+ uint256 amount
+ ) internal override {
+ // Access the transferred amount directly from the amount parameter
+
+ // Decode any custom data you sent
+ // Example: (uint256 value) = abi.decode(data, (uint256));
+
+ // Your custom logic here
+
+ // Emit an event for logging
+ emit TokensReceived(sourceChain, sourceAddress, amount, data);
+ }
+}
+```
+
+## What’s next
+
+To find more examples of how to utilize the Interchain Token Service and test the Interchain Token Service Executable, please refer to the [its executable example](https://github.com/axelarnetwork/axelar-examples/blob/main/examples/evm/its-executable/README.md) on GitHub.
diff --git a/src/content/docs/dev/send-tokens/interchain-tokens/interchain-transfer.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/interchain-transfer.mdx
new file mode 100644
index 000000000..3401c754f
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/interchain-transfer.mdx
@@ -0,0 +1,92 @@
+import { Callout } from "/src/components/callout";
+
+# Interchain Transfer
+
+Tokens connected to the Interchain Token Service (ITS) can be transferred between chains by using the `interchainTransfer()` function. The `interchainTransfer()` function is [defined](https://github.com/axelarnetwork/interchain-token-service/blob/releases/2.1.x/contracts/InterchainTokenService.sol#L559) on the ITS edge contract. In addition to existing on the ITS contract itself, tokens inheriting from the [Interchain Token Standard](https://github.com/axelarnetwork/interchain-token-service/blob/releases/2.1.x/contracts/interchain-token/InterchainTokenStandard.sol) will also have access to the `interchainTransfer()` function, so you can send an interchain transfer directly from the token contract itself.
+
+The `interchainTransfer()` function takes the following parameters
+
+1. `tokenId`: The [interchainTokenId](/dev/send-tokens/interchain-tokens/intro/#interchain-token-id) of the token being sent.
+1. `destinationChain`: The name of the chain the token is being sent to.
+1. `destinationAddress`: The receiving address of the cross-chain transfer.
+1. `amount`: The amount of tokens being sent.
+
+It is defined as follows:
+
+```solidity
+function interchainTransfer(
+ bytes32 tokenId,
+ string calldata destinationChain,
+ bytes calldata destinationAddress,
+ uint256 amount
+) external payable{}
+```
+
+## What It Does
+
+When triggered, ITS via the [Token Handler](/dev/send-tokens/interchain-tokens/intro/#token-handler) Pulls the tokens from `msg.sender` using [takeToken()](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/TokenHandler.sol#L67) function. For mint/burn managers, this will involve burning the token on the source whereas for lock/unlock managers, this will involve escrows/locks on the source via the `safeTransferFrom()` function. The `takeToken()` function will also decrement the [flow limit](/dev/send-tokens/interchain-tokens/token-manager/#flow-limits) for the token being moved out of that blockchain.
+
+With the token now either burnt or held by the Token Manager ITS will then send a cross-chain [GMP message](/dev/general-message-passing/overview/) with a payload containing the following:
+
+```solidity
+bytes memory payload = abi.encode(
+ MESSAGE_TYPE_INTERCHAIN_TRANSFER, //message type identifier
+ tokenId,
+ sourceAddress.toBytes(),
+ destinationAddress,
+ amount,
+ data
+);
+```
+
+Once the GMP message arrives to the destination chain, ITS will then call the [giveToken()](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/TokenHandler.sol#L33) function to either `mint` or `unlock` tokens to for the end receiver (depending on which Token Manager Type is used). The `giveToken()` function will also increment the [flow limit](/dev/send-tokens/interchain-tokens/token-manager/#flow-limits) for the token being moved into that blockchain.
+
+You can see a live example of an interchain transfer being called [here on the Axelarscan Explorer](https://testnet.axelarscan.io/gmp/0xbb7d242ead9fda8ce8d20654fb1c404c611c04bbb198fe15668a17272862e95b-3).
+
+## Diagram
+
+Refer to the diagram below to see how the `interchainTransfer()` function works.
+
+
+
+
+
+
+
+## Error Handling
+
+Common errors and their meanings:
+
+| Error | Description | Resolution |
+|-------|-------------|------------|
+| `NotToken` | Caller is not the expected token | Only the token contract can call certain functions |
+| `ZeroAmount` | Transfer amount is 0 | Provide a non-zero amount |
+| `EmptyDestinationAddress` | No destination address provided | Include valid destination address |
+| `FlowLimitExceeded` | Transfer exceeds flow limit | Wait for next epoch or reduce amount |
+| `UntrustedChain` | Destination chain not trusted | Contact operators to add chain |
+| `Paused` | Service is paused | Wait for service to be unpaused |
+| `TakeTokenFailed` | Failed to take tokens from sender | Ensure sufficient balance and approval |
+| `GiveTokenFailed` | Failed to give tokens to recipient | Check token manager configuration |
+
+## Best Practices
+
+1. **Always verify destination chain names** - Use exact chain names as registered in ITS
+2. **Encode addresses correctly** - Follow chain-specific encoding requirements
+3. **Provide sufficient gas** - Calculate gas needs based on destination chain costs
+4. **Monitor flow limits** - Check current flow before large transfers
+5. **Handle failures gracefully** - Implement retry logic for failed transfers
+6. **Test on testnet first** - Verify complete flow before mainnet deployment
+7. **Use event monitoring** - Track `InterchainTransfer` events for confirmation
+8. **Implement receive handlers** - For contract calls, ensure proper token handling
diff --git a/src/content/docs/dev/send-tokens/interchain-tokens/intro.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/intro.mdx
new file mode 100644
index 000000000..9a5376d97
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/intro.mdx
@@ -0,0 +1,73 @@
+import { Callout } from "../../../../../components/callout";
+
+import InterchainTokenIntro from "../../../../../components/interchain-token-intro.astro";
+
+
+
+The [Token Whitelisting for Squid Router form](https://github.com/axelarnetwork/axelar-configs/blob/main/cli/wizard/commands/list-squid-token/README.md) is now live! Download the [axelar-configs](https://github.com/axelarnetwork/axelar-configs) repo, install dependencies, and `npm run wizard` on the command line to access
+the interactive form through the wizard.
+
+
+
+
+
+# Interchain Token Service
+
+Web3 has gone cross-chain, with assets bridging between blockchains and
+developers deploying applications on multiple chains. However, connecting tokens
+that are deployed on multiple chains has always been a cumbersome process.
+
+Interchain Tokens go beyond legacy bridges. The [Interchain Token Service (ITS)](https://axelar.network/its) allows ERC-20 tokens to be available on multiple blockchains. It preserves native
+token qualities while allowing you to easily manage token features and token supply.
+Interchain Tokens run on [open-source code](https://github.com/axelarnetwork/interchain-token-service/tree/main) via smart contracts on a public blockchain secured by a dynamic validator set.
+With ITS, you can have multiple blockchains with canonical versions of your token
+that all share a single EVM address.
+
+You can either create new [Interchain Tokens](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interchain-token/InterchainToken.sol#L19) from scratch or update tokens that already exist on a [supported blockchain](/resources/contract-addresses/mainnet/).
+
+### Key ITS Contract addresses
+
+**Interchain Token Service:** [0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C](https://etherscan.io/address/0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C)
+**Interchain Token Factory:** [0x83a93500d23Fbc3e82B410aD07A6a9F7A0670D66](https://etherscan.io/address/0x83a93500d23Fbc3e82B410aD07A6a9F7A0670D66)
+
+## Key Concepts
+
+### Interchain Token Service
+
+The edge contract deployed on external blockchains. This contract is responsible for facilitating interchain token transfers. It (mostly) does not handle tokens, but is responsible for the messaging that needs to occur for interchain transfers to happen. There are different variations depending on which blockchain is deployed on.
+
+- [Solidity Implementation](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol)
+- [Move Implementation for Sui](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/interchain_token_service.move)
+- [Rust Implementation for Stellar](https://github.com/axelarnetwork/axelar-amplifier-stellar/blob/main/contracts/stellar-interchain-token/src/contract.rs)
+
+### Interchain Token Service Factory
+
+An additional [contract](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenFactory.sol) deployed on each chain connected to ITS. This contract interact with the main Interchain Token Service contract. It is responsible for deploying new interchain tokens and managing their token managers.
+
+### Interchain Token Service Hub
+
+ITS hub is a central routing contract on the Axelar network itself that coordinates token operations across chains. The hub allows for a simpler centralized state for interlinked tokens compared to purely pairwise connections between ITS edged contracts. Further reading can be done [here](https://docs.axelar.dev/dev/amplifier/its-hub/introduction/)
+
+### Interchain Token Service Portal
+
+A [no-code portal](https://interchain.axelar.dev/) to be able to quick deploy new tokens and register existing tokens to ITS
+
+### Token Handler
+
+A separate [contract](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/TokenHandler.sol) used by ITS to interact with tokens it is moving between chains. This will be the contract that is actually existing your token's `mint`, `burn` functions.
+
+### Token Manager
+
+A contract that facilitates integration between your token and ITS. Each token integration on a given chain will have its own unique token manager. It is responsible for managing tokens, such as setting locking token balances, or setting flow limits, for interchain transfers. Further reading can be done [here](https://docs.axelar.dev/dev/send-tokens/interchain-tokens/token-manager/)
+
+### Interchain Token ID
+
+An `interchainTokenId` is how ITS uniquely registers a given token integration between chains. The id must match across all chains so that when a token is moved out of one chain it is moved into the token with corresponding `interchainTokenId` on the destination chain. This id is calculated by running `keccak256(abi.encode(PREFIX_INTERCHAIN_TOKEN_ID, sender, salt))`. The unique sender address combined with salt ensures that the id is deterministic and collision resistant.
+
+### Interchain Token
+
+A token deployed by ITS itself. Whereas a custom token deployed by an individual developer that gets integrated to ITS, an interchain token is pre-written [contract](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interchain-token/InterchainToken.sol) that ITS deploys. This is the token that is deployed by the ITS portal.
+
+## Guides
+
+
diff --git a/src/content/docs/dev/send-tokens/interchain-tokens/minter-operator-roles.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/minter-operator-roles.mdx
new file mode 100644
index 000000000..ed9302c3f
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/minter-operator-roles.mdx
@@ -0,0 +1,129 @@
+# Minter and Operator Roles in Interchain Token Service
+
+The [Interchain Token Service (ITS)](https://github.com/axelarnetwork/interchain-token-service/tree/main) uses two key roles to manage permissions and control: **Minter** and **Operator**. These roles implement access control mechanisms that determine who can perform specific actions on tokens and token managers.
+
+## Minter Role
+
+The Minter role controls who can create (mint) and destroy (burn) tokens. This role is critical for managing the token supply across different chains.
+
+Based on the [`IMinter`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interfaces/IMinter.sol) interface and the contract implementations, a Minter can:
+
+1. **Mint new tokens**: Create new tokens and assign them to any address.
+2. **Burn tokens**: Destroy tokens from circulation.
+3. **Transfer mintership**: Transfer the minter role to another address.
+4. **Propose mintership change**: Propose a new minter (two-step transfer process).
+
+### Implementation Details
+
+When a new Interchain Token is deployed:
+
+- ITS is initially set as the minter for Native Interchain Tokens.
+- The token manager needs to have the minter role in order to mint tokens when receiving them from another chain and burn tokens when sending them to another chain.
+
+There are two primary ways mintership is transferred to the token manager:
+
+1. Automatic Migration: The [`TokenHandler.sol`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/TokenHandler.sol) contract contains an automatic migration mechanism that transfers mintership from ITS to the token manager when tokens are processed:
+
+```solidity
+function _migrateToken(address tokenManager, address tokenAddress, uint256 tokenManagerType) internal {
+ if (tokenManagerType == uint256(TokenManagerType.NATIVE_INTERCHAIN_TOKEN) && IMinter(tokenAddress).isMinter(address(this))) {
+ IMinter(tokenAddress).transferMintership(tokenManager);
+ }
+}
+```
+
+2. Manual Migration: Developers can also explicitly migrate mintership by calling the migrateInterchainToken function on the InterchainTokenService contract:
+
+```solidityC
+function migrateInterchainToken(bytes32 tokenId) external onlyOwner {
+ ITokenManager tokenManager_ = deployedTokenManager(tokenId);
+ address tokenAddress = tokenManager_.tokenAddress();
+ IMinter(tokenAddress).transferMintership(address(tokenManager_));
+}
+```
+
+#### Why Token Managers Need Minter Rights:
+
+For the interchain token system to work properly, token managers need minting and burning capabilities because:
+
+- When tokens are sent from Chain A to Chain B, tokens are burned (or locked) on Chain A and must be minted on Chain B.
+- Without minter rights, the token manager cannot mint the corresponding tokens on the destination chain.
+- Having the token manager as the minter creates a trustless system where ITS doesn't need to maintain privileged access to tokens.
+- It allows the token manager to directly control token supply according to cross-chain message validation.
+
+### Token Manager Integration
+
+For [`NATIVE_INTERCHAIN_TOKEN`](https://github.com/axelarnetwork/interchain-token-service/blob/4ba40851ee13cf98077e38b49f2c106d09a2f67c/contracts/interfaces/ITokenManagerType.sol#L11) and [`MINT_BURN`](https://github.com/axelarnetwork/interchain-token-service/blob/4ba40851ee13cf98077e38b49f2c106d09a2f67c/contracts/interfaces/ITokenManagerType.sol#L15) token manager types, the minter role allows the token manager to mint tokens upon receiving them from another chain and burn tokens when sending them to another chain.
+Its important to note that token manager is required to be whitelisted for these manager types to be used otherwise the manager will not be able to mint/burn.
+
+## Operator Role
+
+The Operator role controls who can manage the token manager's configuration and operations. This role has administrative powers over how tokens are handled during cross-chain transfers.
+
+Based on the [`IOperator`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interfaces/IOperator.sol) interface and contract implementations, an Operator can:
+
+1. **Set flow limits**: Control the rate at which tokens can flow into or out of a chain.
+2. **Approve service**: Grant permission to the ITS to operate on behalf of the token manager.
+3. **Transfer operatorship**: Transfer the operator role to another address.
+4. **Propose operatorship change**: Propose a new operator (two-step transfer process).
+
+### Implementation Details
+
+ITS operators are set during token manager deployment:
+
+```solidity
+// From InterchainTokenFactory.sol
+
+bytes memory linkParams = '';
+if (operator != address(0)) {
+ linkParams = operator.toBytes();
+}
+```
+
+The `linkParams` is used to specify the operator address for the token manager.
+
+## Role Transitions and Ownership
+
+Both roles feature a secure two-step transfer process:
+
+1. The current role holder (operator or minter) proposes a new address (`proposeOperatorship` or `proposeMintership`).
+2. The proposed address must accept the role (`acceptOperatorship` or `acceptMintership`).
+
+This prevents accidental transfers to invalid addresses.
+
+## Practical Applications
+
+### Minter Role Usage
+
+1. **Token Supply Management**: The minter can control the total supply by minting or burning tokens.
+2. **Cross-Chain Transfers**: For mint/burn token managers, the minter mints tokens on the destination chain equivalent to what was burned on the source chain.
+3. **Token Migration**: The [`migrateInterchainToken`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol) function in ITS shows how mintership is transferred to optimize token operations.
+
+### Operator Role Usage
+
+1. **Flow Control**: Operators can set _flow limits_ for how many tokens can flow in or out of a chain in a given period.
+3. **Service Authorization**: Operators can authorize ITS to interact with token managers.
+
+## Role Interaction in ITS
+
+- The ITS contract initially holds the minter role for native interchain tokens.
+- The token manager typically becomes the minter to handle cross-chain transfers.
+- Custom operators can be specified for token managers.
+- When deploying tokens, the factory allows specifying both minter and operator roles:
+
+```solidity
+// From InterchainTokenFactory.sol
+
+token.transferMintership(minter);
+tokenManager.removeFlowLimiter(address(this));
+tokenManager.addFlowLimiter(minter);
+tokenManager.transferOperatorship(minter);
+```
+
+## Security Considerations
+
+1. **Role Separation**: Minter and Operator roles can be held by different entities for better security.
+2. **Flow Limits**: Operators can set flow limits to prevent large-scale attacks.
+3. **Careful Role Transfer**: The two-step transfer process mitigates the risk of losing control.
+
+The Minter and Operator roles form the foundation of ITS's permission system. Developers can build secure and efficient cross-chain token solutions by understanding how these roles function and interact.
\ No newline at end of file
diff --git a/src/content/docs/dev/send-tokens/interchain-tokens/no-code.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/no-code.mdx
new file mode 100644
index 000000000..00ccdd078
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/no-code.mdx
@@ -0,0 +1,41 @@
+
+ The [Token Whitelisting for Squid Router
+ form](https://github.com/axelarnetwork/axelar-configs/blob/main/cli/wizard/commands/list-squid-token/README.md)
+ is now live! Download the
+ [`axelar-configs`](https://github.com/axelarnetwork/axelar-configs) repo,
+ install dependencies, and `npm run wizard` on the command line to access the
+ interactive form through the wizard.
+
+
+# No Code Setup
+
+import { Callout } from "/src/components/callout";
+
+The quickest way to begin exploring and deploying [interchain tokens](/dev/send-tokens/glossary/#interchain-token) is with Axelar's no code [frontend portal](https://interchain.axelar.dev/). (Click [here](https://testnet.interchain.axelar.dev/) for testnet).
+
+The portal offers two main paths. You can either deploy a fresh new token on multiple chains at once or you can connect a pre-existing token to ITS. Once integrated, you can then deploy additional interchain tokens on other blockchains to be bridgeable with your token that you had previously integrated.
+
+## Deploy New Token
+
+To deploy a new token:
+
+1. Connect your wallet.
+1. Select a source network where you have funds available.
+1. Click **Deploy a new Interchain Token**.
+1. Add your new token’s name, symbol, decimals, and amount to mint. You can also mark the token as `mintable`, which will allow the token minter to mint new tokens.
+1. Select additional chains for your token to be available on. You can optionally add the token amount to mint on each selected chain.
+
+If your connected wallet has enough funds, your new token will become available on each chain you selected. It will follow the [Interchain Token Standard](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interfaces/IInterchainTokenStandard.sol), so users can call the [`interchainTransfer()`](/dev/send-tokens/interchain-tokens/interchain-transfer/) method on the token itself to transfer between blockchains.
+
+## Connect Existing Token
+
+1. Connect your wallet.
+1. Select a source network where you have funds available.
+1. Paste in the address of your token that you want to connect to ITS
+1. Click the **Register interchain token** button.
+1. Select additional chains for your token's to be available on.
+1. This will register a [lock/unlock](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interfaces/ITokenManagerType.sol#L13) Token Manager for your custom token on the home chain and a [native interchain token](https://github.com/axelarnetwork/interchain-token-service/blob/7df851d8a4ec4df819961d704bf3067ee8d37521/contracts/interfaces/ITokenManagerType.sol#L11) on any of the remote chains you register your token on.
+
+## Tutorial
+
+For detailed steps on using the portal to create a new token, check out the [How to Create an Interchain Token with Axelar in 4 Steps](https://axelar.network/blog/how-to-create-an-interchain-token-with-axelar-in-4-steps) tutorial.
diff --git a/src/content/docs/dev/send-tokens/interchain-tokens/register-existing-token.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/register-existing-token.mdx
new file mode 100644
index 000000000..a8ddb2bb9
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/register-existing-token.mdx
@@ -0,0 +1,67 @@
+import { Callout } from "/src/components/callout";
+
+# Register Existing Token
+
+If you own an ERC-20 token on a single chain and want a wrapped, bridgeable version on other chains, you can register it as a [Canonical Interchain Token](/dev/send-tokens/glossary/#canonical-interchain-token) using the [Interchain Token Factory contract](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenFactory.sol). Each token can only be registered once as a canonical token on its "home" chain.
+
+You can register your existing token directly via the contract or use the [ITS Portal](/dev/send-tokens/interchain-tokens/no-code/) no-code solution. Take a look at the diagram below to understand the process of registering an existing token as a Canonical Interchain Token.
+
+
+
+
+## Register Your Token as a Canonical Token Using the Interchain Token Factory
+
+Use the [registerCanonicalInterchainToken](https://github.com/axelarnetwork/interchain-token-service/blob/94677f1072da127a0ee7ff5ab6784dcfe11789e8/contracts/InterchainTokenFactory.sol#L402) function to register your token.
+
+```solidity
+function registerCanonicalInterchainToken(
+ address tokenAddress // address of your token
+) external payable returns (bytes32 tokenId) {}
+```
+
+This function deploys a [Lock/Unlock Token Manager](/dev/send-tokens/glossary/#lockunlock) on the source chain, connects it to ITS upon deployment, and returns a unique token ID. Triggering the `registerCanonicalInterchainToken()` function initiates the process of registering your custom token with a Lock/Unlock token manager type on your token's _home chain_.
+
+Once your token is registered on the home chain, you can call the `deployRemoteCanonicalInterchainToken()` function. This will deploy an Interchain Token on a different blockchain that connects to your canonical token on the home chain.
+
+## Deploy a Remote Canonical Interchain Token
+
+Use the [deployRemoteCanonicalInterchainToken](https://github.com/axelarnetwork/interchain-token-service/blob/94677f1072da127a0ee7ff5ab6784dcfe11789e8/contracts/InterchainTokenFactory.sol#L450) function to deploy the token on a remote chain as a cross-chain transaction:
+
+```solidity
+function deployRemoteCanonicalInterchainToken(
+ address originalTokenAddress, // original token address
+ string calldata destinationChain, // destination chain name
+ uint256 gasValue // gas value
+) public payable returns (bytes32 tokenId) {};
+```
+
+This function deploys a token connected to your registered token on the home chain, making it bridgeable to the destination chain, and returns a token ID.
+
+
+ **NOTE:** The security of your token is only as strong as the security of the
+ chains with which it integrates. When deploying an interchain token, ensure
+ that all target chains are trustworthy.
+
+
+
+## What's Next
+
+You can initiate an interchain transfer from your source chain to a destination chain by using the [interchainTransfer()](/dev/send-tokens/interchain-tokens/interchain-transfer/) method on the [ITS contract](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol).
+
+For further examples utilizing the Interchain Token Service, check out the [Axelar Examples](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm) repository on GitHub. There, you will find an example implementation titled [its-canonical-token](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-canonical-token), which demonstrates how to deploy canonical Interchain Tokens and perform cross-chain transfers.
+
+## Tutorial
+
+For a step-by-step guide on registering an existing token, check out the [Programmatically Create a Canonical Interchain Token Using the Interchain Token Service](/dev/send-tokens/interchain-tokens/developer-guides/programmatically-create-a-canonical-token/) tutorial.
diff --git a/src/content/docs/dev/send-tokens/interchain-tokens/token-manager.mdx b/src/content/docs/dev/send-tokens/interchain-tokens/token-manager.mdx
new file mode 100644
index 000000000..6822067f3
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/interchain-tokens/token-manager.mdx
@@ -0,0 +1,58 @@
+# Token Managers
+
+[Token Managers](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/token-manager/TokenManager.sol#L22) are contracts that facilitate connection between your interchain token to the [Interchain Token Service (ITS)](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol). For certain manager types, such as `mint/burn` Token Manager, the manager is the `msg.sender` of the transaction being executed on the destination chain for the token when it is bridged in.
+
+## Token Manager Types
+
+There are different [types](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interfaces/ITokenManagerType.sol#L10) of token managers available for developers to offer different types of integrations to ITS. These are; `nativeInterchain`, `mintBurnFrom`, `lockUnlock`, `lockUnlockFee`, and `mintBurn`.
+
+Each of these types correspond to an `enum` value. When integrating with ITS, developers must pass in the [corresponding value](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/interfaces/ITokenManagerType.sol) for their desired token manager type.
+
+- `NativeInterchainToken`: `0`
+- `Mint/BurnFrom`: `1`
+- `Lock/Unlock`: `2`
+- `Lock/UnlockFee`: `3`
+- `Mint/Burn`: `4`
+
+### Native Interchain Token
+
+For tokens that are deployed [directly from ITS itself](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenFactory.sol#L133) they use a native interchain token manager. Tokens that are deployed via the [frontend portal](/dev/send-tokens/interchain-tokens/no-code/) also use this type of manager.
+
+For more details checkout this [native interchain token example](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-interchain-token).
+
+### Mint/Burn From
+
+The `mint/burnFrom` token manager type, allows tokens to be burnt on the source chain when they are transferred out of that chain and minted when they are transferred back into the source chain. As the name suggests when the token is burnt on the source chain the manager is looking to trigger the `burnFrom()` function on the token rather than the `burn()` function.
+
+The main implication is that ITS must be approved to call `burnFrom()` by the token. The manager must be granted the role to be able to `mint()` the token on the destination chain.
+
+For more details checkout this [Mint/BurnFrom example](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-mint-burn-from).
+
+### Lock/Unlock
+
+Token integrations using the `lock/unlock` token manager will have their token locked with their token's manager. Only a single `lock/unlock` manager can exist for a token as having multiple `lock/unlock` managers would make it substantially more difficult to manage liquidity across many different blockchains. These token managers are best used in the case where a token has a "home chain" where a token can be locked. On the remote chains users can then use a wrapped version of that token which derives it's value from a locked token back on the home chain.
+
+Canonical tokens for example [deployed via ITS](https://github.com/axelarnetwork/interchain-token-service/blob/0dad750abe866ec8e77ea43a2d1563335d14bd32/contracts/InterchainTokenFactory.sol#L402) are examples where a `lock/unlock` token manager type is useful. When bridging tokens out of the destination chain (locking them at the manager) ITS [will call](https://github.com/axelarnetwork/interchain-token-service/blob/0dad750abe866ec8e77ea43a2d1563335d14bd32/contracts/TokenHandler.sol#L102) the `transferTokenFrom()` function, which in turn will call the `safeTranferFrom()` function. For this transaction to be successful, ITS must be `approved()` to call the `safeTransferFrom()` function, otherwise the call will revert.
+
+For more details checkout this [Canonical token example](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-canonical-token). Canonical tokens [use](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenFactory.sol#L387) `lock/unlock` token managers on their "home" chain.
+
+### Lock/Unlock Fee
+
+This manager type is similar to the `lock/unlock` token manager, where the manager locks the token on it's "home chain" when it is bridged out and unlocks it when it is bridged back. The key feature with this token manager is that you have the option to set a fee that will be [deducted](https://github.com/axelarnetwork/interchain-token-service/blob/0dad750abe866ec8e77ea43a2d1563335d14bd32/contracts/TokenHandler.sol#L148) when executing an `interchainTransfer()`.
+
+For more details checkout this [Lock/UnlockFee example](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-lock-unlock-fee).
+
+### Mint/Burn
+
+The `mint/burn` token manager type is used when your token is native (all chains are considered a "home" chain) and allows you to `burn()` tokens from the source chain and `mint()` tokens on the destination chain. The manager will need to be granted the role to be able to execute the `mint()` and `burn()` function on the token.
+
+For more details checkout this [Mint/Burn example](https://github.com/axelarnetwork/axelar-examples/tree/main/examples/evm/its-custom-token).
+
+## Flow Limits
+
+Token Managers handle the flow limits for a token's ITS integration. A `flowLimit` is a set amount that controls the amount in which a token can be sent in/out of a given blockchain. This can have a variety of different usecases including for security emergencies on a given chain where you want to restrict the flow of your token for that particular blockchain.
+
+For each cross-chain transaction that goes through ITS the `flowIn` & `flowAmount` amount are increased to track the [inflow](https://github.com/axelarnetwork/interchain-token-service/blob/0dad750abe866ec8e77ea43a2d1563335d14bd32/contracts/TokenHandler.sol#L33) and [outflow](https://github.com/axelarnetwork/interchain-token-service/blob/0dad750abe866ec8e77ea43a2d1563335d14bd32/contracts/TokenHandler.sol#L67) of tokens. To [set](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/token-manager/TokenManager.sol#L167) the `flowLimit` of a given token the caller must be a registered [flowLimiter](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/utils/RolesConstants.sol#L13).
+
+For more information on `flowLimit`, see [Flow Limit in Interchain Token Service
+](/dev/send-tokens/interchain-tokens/flow-limit/).
diff --git a/src/content/docs/dev/send-tokens/introduction.mdx b/src/content/docs/dev/send-tokens/introduction.mdx
new file mode 100644
index 000000000..ab2356aa3
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/introduction.mdx
@@ -0,0 +1,10 @@
+# Overview
+Axelar offers cross-chain ERC20 token transfer in two main forms. Gateway tokens and Interchain Token Service based tokens. For general users looking to integrate their own tokens it is recommmended to use ITS. For Dapps looking to make use of more widely recognized assets such as `axlUSDC` or `axlETH`, Gateway tokens serve as a simple solution.
+
+## Gateway Tokens
+Gateway tokens are a collection of well known ERC20 tokens that have been wrapped by the Interop Labs team to provide easy cross-chain liquidity between blockchains. The full list of available Gateway tokens can be found [here](/resources/contract-addresses/mainnet/#assets).
+More on how to use/send Gateway tokens can be found [here](/dev/general-message-passing/gmp-tokens-with-messages/)
+
+## Interchain Token Service Tokens (ITS)
+Axelar also offers the ability to make use of ITS. This is a permisionless service where any user (both technical and non technical!) can integrate existing tokens to provide cross-chain functionality for those tokens. Users can also create fresh new ERC20s with cross-chain functionality out of the box.
+More details on ITS can be found [here](/dev/send-tokens/interchain-tokens/intro/)
diff --git a/src/content/docs/dev/send-tokens/roadmap.mdx b/src/content/docs/dev/send-tokens/roadmap.mdx
new file mode 100644
index 000000000..5fb08b767
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/roadmap.mdx
@@ -0,0 +1,25 @@
+# Interchain Token Service Roadmap
+
+## Background
+
+The [Interchain Token Service (ITS)](/dev/send-tokens/introduction) was released to make custom ERC-20 token transfers easier across different blockchains. Unlike bridged tokens, Interchain Tokens are sent between chains via [General Message Passing (GMP)](/dev/general-message-passing/overview) rather than minted on the Axelar chain itself.
+
+The [`InterchainTokenService`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/InterchainTokenService.sol) contract deploys a [`TokenManager`](https://github.com/axelarnetwork/interchain-token-service/blob/main/contracts/token-manager/TokenManager.sol) to handle multichain token operations such as minting, burning, and locking for every chain that a token is registered to. Tokens are tracked through a unique `interchainTokenId` that persists across these chains.
+
+### Types of Interchain Tokens
+
+There are three types of Interchain Token integrations:
+
+- [Standardized Interchain Tokens](/dev/send-tokens/glossary#standardized-token) — ERC-20 tokens that are deployed through the Interchain Token Service from a contract that implements the `IInterchainToken` and `IStandardizedToken` interfaces. They have the same address on all chains, with native bridging and no lock/unlock functionality.
+- [Canonical Interchain Tokens](/dev/send-tokens/glossary#canonical-interchain-token) — Tokens originally deployed on one chain that now have interchain capabilities through ITS. ITS wraps the token on the original chain to give it these capabilities, then duplicates the wrapped original on all other chains.
+- [Custom tokens](/dev/send-tokens/glossary#custom-token) — Interchain Tokens that are designed to serve specific use cases within the blockchain ecosystem. They are deployed with custom functionality along with the required minting and burning `TokenManager` functions.
+
+## The future of ITS
+
+### Migration to governance
+
+The `InterchainTokenService` contract will soon be managed through [EVM contract governance](/learn/evm-governance).
+
+### ITS Hub
+
+The new [Interchain Amplifier](/dev/amplifier/introduction) provide a major overhaul opportunity for the Interchain Token Service. Interop Labs is developing a new **ITS Hub** that will serve as the homebase for the Interchain Token Service on the Axelar blockchain. All token transfers between ITS-enabled chains will be routed through this hub. The ITS hub extends ITS capabilities such as tracking balances and flow limits to all chains integrating with the Interchain Amplifier, including ones not built with smart contracts.
diff --git a/src/content/docs/dev/send-tokens/stellar/deploy-new-token.mdx b/src/content/docs/dev/send-tokens/stellar/deploy-new-token.mdx
new file mode 100644
index 000000000..7341746bf
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/stellar/deploy-new-token.mdx
@@ -0,0 +1,666 @@
+import { Callout } from "../../../../../components/callout";
+
+# Deploy and Transfer a New Token from Stellar to EVM
+
+This guide demonstrates, step by step, how to use Axelar's Interchain Token Service (ITS) to create and transfer tokens between Stellar and other blockchains.
+
+By the end, you will be able to:
+
+1. Deploy a new token on Stellar using Axelar ITS.
+1. Deploy that token representation on an EVM chain (Avalanche Fuji testnet).
+1. Transfer tokens seamlessly between Stellar and the EVM chain.
+
+## Prerequisites
+
+Before starting, make sure you have the following ready:
+
+- [Rust](https://www.rust-lang.org/tools/install) with wasm32 target.
+- [Stellar CLI](https://github.com/stellar/stellar-cli).
+- A Stellar testnet account with funds.
+- A browser wallet like [MetaMask](https://metamask.io/) configured to connect to the Avalanche Fuji testnet, or a similar wallet like [Rabby](https://rabby.io/)
+- Some Avalanche Fuji testnet AVAX (from the [Avalanche faucet](https://faucet.avax.network/)).
+
+## Part 1: Understanding the Interchain Token Service
+
+The [Interchain Token Service (ITS)](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-interchain-token-service) is a protocol that allows tokens to move freely between different blockchains. It provides functionality to:
+
+1. Create tokens that exist on multiple blockchains simultaneously.
+2. Connect existing tokens on one blockchain to other blockchains.
+3. Transfer tokens securely between blockchains.
+
+Unlike the single message-passing pattern of GMP, the ITS involves several components:
+
+- [**Interchain Token Service**](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-interchain-token-service): The main contract that coordinates token operations.
+- [**Token Manager**](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-token-manager): Handles token operations (minting, burning, locking) on a specific chain.
+- [**Interchain Token**](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-interchain-token): The actual token contract that implements the Stellar token interface.
+- [**Gateway**](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-axelar-gateway): Routes messages between blockchains.
+- [**Gas Service**](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-axelar-gas-service): Handles payments for cross-chain execution.
+
+
+ A token created through ITS will have the same token ID across all blockchains
+
+
+## Part 2: Set up your Stellar ITS project
+
+Let's build a Stellar smart contract project that integrates with ITS to create and transfer new tokens.
+
+### Step 1. Initialize a new project
+
+Start by creating a new Stellar contract project and the directory:
+
+```bash
+stellar contract init axelar-its-app
+cd axelar-its-app
+```
+
+This command scaffolds a basic Stellar contract project for you.
+
+> Tip: We'll simplify the default structure as we progress, focusing on the files needed for the ITS integration.
+
+### Step 2: Simplify your project structure
+
+To keep things neat, remove unnecessary folders and consolidate your source files.
+
+Move the `src` folder to the root of your project directory if it isn't there already
+Delete any example or template contract folders, such as `contracts/hello-world`
+
+After cleanup, your folder should look like this:
+
+```bash
+axelar-its-app
+├── src
+│ ├── lib.rs
+├── .gitignore
+├── Cargo.toml
+├── README.md
+```
+
+### Step 3. Configure your dependencies in Cargo.toml
+
+Open `Cargo.toml` in your project root and update it to include dependencies needed for Axelar ITS and Stellar development.
+
+Here's a sample you can copy:
+
+```toml
+[package]
+name = "axelar-its-app"
+version = "0.0.0"
+edition = "2021"
+publish = false
+
+[lib]
+crate-type = ["cdylib"]
+doctest = false
+
+[dependencies]
+soroban-sdk = "22.0.0"
+soroban-token-sdk = "22.0.0"
+stellar-axelar-gateway = { git = "https://github.com/axelarnetwork/axelar-amplifier-stellar", branch = "main", features = ["library"] }
+stellar-axelar-gas-service = { git = "https://github.com/axelarnetwork/axelar-amplifier-stellar", branch = "main", features = ["library"] }
+stellar-interchain-token-service = { git = "https://github.com/axelarnetwork/axelar-amplifier-stellar", branch = "main", features = ["library"] }
+stellar-interchain-token = { git = "https://github.com/axelarnetwork/axelar-amplifier-stellar", branch = "main", features = ["library"] }
+stellar-token-manager = { git = "https://github.com/axelarnetwork/axelar-amplifier-stellar", branch = "main", features = ["library"] }
+stellar-axelar-std = { git = "https://github.com/axelarnetwork/axelar-amplifier-stellar", branch = "main" }
+
+[dev-dependencies]
+soroban-sdk = { version = "22.0.0", features = ["testutils"] }
+
+[profile.release]
+opt-level = "z"
+overflow-checks = true
+debug = 0
+strip = "symbols"
+debug-assertions = false
+panic = "abort"
+codegen-units = 1
+lto = true
+
+[profile.release-with-logs]
+inherits = "release"
+debug-assertions = true
+```
+
+This configuration pulls in Axelar's Stellar libraries from GitHub and sets up your Rust build profiles for optimal WASM compilation.
+
+## Part 3: Implementing the Interchain Token Service (ITS)
+
+Now that the project structure and dependencies are ready, it's time to implement the contract. This contract will interact with the Interchain Token Service (ITS) to create new tokens and enable cross-chain transfers.
+
+We'll build this step by step by creating the core source files inside the `src` folder.
+
+### Step 1: Define the contract entry point (`lib.rs`)
+
+The `lib.rs` file is your contract's main entry point. Here, you declare the modules your contract uses.
+
+Update `src/lib.rs` with:
+
+```rust
+#![no_std]
+
+pub mod contract;
+pub mod error;
+mod storage_types;
+```
+
+- `contract` will contain the main contract implementation
+- `error` defines error types your contract can return
+- `storage_types` holds data structures used for contract storage
+
+### Step 2: Define contract errors (`error.rs`)
+
+A clear list of error codes helps you handle edge cases and report issues properly.
+
+Create `src/error.rs` with the following content:
+
+```rust
+use stellar_axelar_std::{contracterror, soroban_sdk};
+
+#[contracterror]
+#[derive(Copy, Clone, Debug, PartialEq, Eq)]
+#[repr(u32)]
+pub enum ContractError {
+ TrustedChainAlreadySet = 1,
+ TrustedChainNotSet = 2,
+ InvalidMessageType = 3,
+ UntrustedChain = 4,
+ InvalidAmount = 5,
+ InvalidDestinationAddress = 6,
+ NotHubChain = 7,
+ NotHubAddress = 8,
+ InvalidTokenId = 9,
+ TokenAlreadyRegistered = 10,
+ FlowLimitExceeded = 11,
+ InvalidDestinationChain = 12,
+ InvalidData = 13,
+ InvalidTokenName = 14,
+ InvalidTokenSymbol = 15,
+ InvalidTokenDecimals = 16,
+ InvalidInitialSupply = 17,
+ InvalidTokenConfig = 18,
+}
+```
+
+Each error has a unique numeric code and a named variant. This helps both you and users understand why a transaction might fail.
+
+### Step 3: Define storage keys (`storage_types.rs`)
+
+The contract needs to store some key data onchain. Let's define storage keys in `src/storage_types.rs`:
+
+```rust
+use soroban_sdk::{contracttype, String};
+
+#[contracttype]
+#[derive(Clone, Debug)]
+pub enum DataKey {
+ InterchainTokenService,
+ TokenId,
+ Salt,
+ TrustedChain(String),
+}
+```
+
+This storage structure includes:
+
+- `InterchainTokenService`: Stores the address of the deployed ITS contract.
+- `TokenId`: Stores the ID of the token we deploy.
+- `Salt`: Stores the salt used for token deployment (needed for remote deployment).
+- `TrustedChain`: Tracks which chains we've marked as trusted.
+
+### Step 4: Implement the contract logic (`contract.rs`)
+
+#### 1. Setup and Initialization
+
+First, let's create the `contract.rs` file inside the `src` folder with a basic setup and initialization functions:
+
+```rust
+use soroban_sdk::{contract, contractimpl, Address, Bytes, BytesN, Env, String};
+use soroban_token_sdk::metadata::TokenMetadata;
+use stellar_axelar_std::types::Token;
+use stellar_interchain_token_service::InterchainTokenServiceClient;
+
+use crate::storage_types::DataKey;
+
+#[contract]
+pub struct ItsApp;
+
+#[contractimpl]
+impl ItsApp {
+ /// Initialize the contract with the ITS service address
+ pub fn initialize(env: &Env, its_address: Address) {
+ env.storage()
+ .instance()
+ .set(&DataKey::InterchainTokenService, &its_address);
+ }
+
+ /// Get the ITS client
+ fn its_client(env: &Env) -> InterchainTokenServiceClient {
+ let its_address = env
+ .storage()
+ .instance()
+ .get(&DataKey::InterchainTokenService)
+ .unwrap();
+ InterchainTokenServiceClient::new(env, &its_address)
+ }
+
+ /// Check if a chain is trusted
+ pub fn is_trusted_chain(env: &Env, chain: String) -> bool {
+ let its = Self::its_client(env);
+ its.is_trusted_chain(&chain)
+ }
+}
+```
+
+These functions:
+
+- `initialize`: Sets up the contract with the address of the ITS service
+- `its_client`: Creates an instance of the InterchainTokenServiceClient
+- `is_trusted_chain`: Checks if a chain is trusted by the ITS
+
+#### 2. Token Creation Functions
+
+Next, let's add functions to deploy a new token and retrieve token information:
+
+```rust
+ //...
+
+ /// Deploy a new interchain token on Stellar
+ pub fn deploy_token(
+ env: &Env,
+ caller: Address,
+ salt: BytesN<32>,
+ name: String,
+ symbol: String,
+ decimals: u32,
+ initial_supply: i128,
+ ) -> BytesN<32> {
+ caller.require_auth();
+
+ let its = Self::its_client(env);
+
+ // Create token metadata
+ let token_metadata = TokenMetadata {
+ name,
+ symbol,
+ decimal: decimals,
+ };
+
+ // Deploy the token - direct call
+ let token_id = its.deploy_interchain_token(
+ &caller,
+ &salt,
+ &token_metadata,
+ &initial_supply,
+ &None, // No additional minter
+ );
+
+ // Store the token ID and salt for reference
+ env.storage().instance().set(&DataKey::TokenId, &token_id);
+ env.storage().instance().set(&DataKey::Salt, &salt);
+
+ token_id
+ }
+
+ /// Get the currently stored token ID
+ pub fn get_token_id(env: &Env) -> BytesN<32> {
+ env.storage().instance().get(&DataKey::TokenId).unwrap()
+ }
+```
+
+The `deploy_token` function:
+
+- Authenticates the caller to ensure they have permission
+- Creates token metadata with the provided name, symbol, and decimals
+- Deploys a new interchain token with the specified initial supply
+- Stores both the generated `token_id` and salt for future operations
+- Returns the `token_id` for reference
+
+The getter function allows us to retrieve the stored token information:
+
+- `get_token_id`: Returns the ITS `token_id`
+
+#### 3. Implement the Cross-Chain Functions
+
+Finally, let's add functions for cross-chain token deployment and transfers:
+
+```rust
+ //...
+
+ /// Deploy the token to another blockchain
+ pub fn deploy_remote_token(
+ env: &Env,
+ caller: Address,
+ destination_chain: String,
+ gas_token_address: Address,
+ gas_amount: i128,
+ ) -> BytesN<32> {
+ caller.require_auth();
+
+ let its = Self::its_client(env);
+
+ // Get stored salt
+ let salt = env.storage().instance().get(&DataKey::Salt).unwrap_or_else(|| {
+ BytesN::from_array(env, &[0; 32])
+ });
+
+ // Prepare gas token
+ let gas_token = Some(Token {
+ address: gas_token_address,
+ amount: gas_amount,
+ });
+
+ // Deploy to remote chain - direct call
+ let token_id = its.deploy_remote_interchain_token(
+ &caller,
+ &salt,
+ &destination_chain,
+ &gas_token,
+ );
+
+ token_id
+ }
+
+ /// Transfer interchain tokens to another blockchain
+ pub fn transfer_tokens(
+ env: &Env,
+ caller: Address,
+ token_id: BytesN<32>,
+ destination_chain: String,
+ destination_address: Bytes,
+ amount: i128,
+ gas_token_address: Address,
+ gas_amount: i128,
+ ) {
+ caller.require_auth();
+
+ let its = Self::its_client(env);
+
+ // Basic validation
+ if amount <= 0 {
+ panic!("Invalid amount");
+ }
+
+ if destination_address.len() == 0 {
+ panic!("Invalid destination address");
+ }
+
+ // Prepare gas token
+ let gas_token = Some(Token {
+ address: gas_token_address,
+ amount: gas_amount,
+ });
+
+ // Send the tokens cross-chain - direct call
+ its.interchain_transfer(
+ &caller,
+ &token_id,
+ &destination_chain,
+ &destination_address,
+ &amount,
+ &None, // No additional data
+ &gas_token,
+ );
+ }
+```
+
+The `deploy_remote_token` function:
+
+- Deploys the token to another blockchain using the stored salt
+- Configures gas payment for cross-chain operations
+- Returns the `token_id`, which remains consistent across chains
+
+The `transfer_tokens` function:
+
+- Validates the transfer amount and destination address
+- Initiates the cross-chain transfer with appropriate gas payment
+
+With these functions implemented, our contract provides a complete interface for creating new tokens and enabling cross-chain transfers.
+
+## Part 4: Build and Deploy the Contract
+
+Once your contract code is complete, follow these steps to compile and deploy it on the Stellar testnet.
+
+### Step 1: Build your contract
+
+```bash
+stellar contract build
+```
+
+You should see output confirming the build succeeded and showing the location of the `.wasm` file:
+
+```
+ℹ️ CARGO_BUILD_RUSTFLAGS=--remap-path-prefix=/path/to/registry/src= cargo rustc --manifest-path=Cargo.toml --crate-type=cdylib --target=wasm32-unknown-unknown --release
+ Compiling axelar-its-app v0.0.0 (/path/to/axelar-its-example)
+ Finished `release` profile [optimized] target(s) in 1.04s
+ℹ️ Build Summary:
+ Wasm File: target/wasm32-unknown-unknown/release/axelar_its_app.wasm
+ Wasm Hash: 6ec10215f2b47323e143289842bdf274b00929b5632f60e56ef39fd2caa066eb
+ Exported Functions: 8 found
+ •••
+✅ Build Complete
+```
+
+### Step 2. Optimize the WASM file:
+
+```bash
+stellar contract optimize --wasm target/wasm32-unknown-unknown/release/axelar_its_app.wasm
+```
+
+This creates an optimized `.wasm` file you will deploy.
+
+### Step 3. Deploy the contract to the Stellar testnet:
+
+```bash
+stellar contract deploy \
+ --wasm target/wasm32-unknown-unknown/release/axelar_its_app.optimized.wasm \
+ --source YOUR_ACCOUNT_NAME \
+ --network testnet
+```
+
+When the deployment succeeds, you'll receive the address of your new contract. Save this address for future interactions.
+
+You should see something similar to what is shown below on your terminal.
+
+```
+ℹ️ Simulating install transaction…
+ℹ️ Signing transaction: ee3941979c516e4953b65d14704d1c9b9ec0c1646be5295f877f0ea6ae042504
+🌎 Submitting install transaction…
+ℹ️ Using wasm hash 8a09dd41239d938d23546dfd56e935d3e19f0784bd96757990858a78453e913e
+ℹ️ Simulating deploy transaction…
+ℹ️ Transaction hash is c98523481cfecfdb96ae19d19cdb766b18394b711b614ef79a2e924cc15a8461
+🔗 https://stellar.expert/explorer/testnet/tx/c98523481cfecfdb96ae19d19cdb766b18394b711b614ef79a2e924cc15a8461
+ℹ️ Signing transaction: c98523481cfecfdb96ae19d19cdb766b18394b711b614ef79a2e924cc15a8461
+🌎 Submitting deploy transaction…
+🔗 https://stellar.expert/explorer/testnet/contract/CCQBX3AFKB2A43RA6GVY53MFBGK3KSXROUAXZSRV3CG63FXFG7QXNKLT
+✅ Deployed!
+CCQBX3AFKB2A43RA6GVY53MFBGK3KSXROUAXZSRV3CG63FXFG7QXNKLT
+```
+
+## Part 5: Interacting with your contract on the Stellar testnet
+
+Now that our contract is deployed, let's interact with it to create and transfer tokens across the cross-chain.
+
+Now that your contract is deployed on the Stellar testnet, you'll use the Stellar CLI to:
+
+- Initialize your contract by connecting it to the Axelar Interchain Token Service (ITS)
+- Create a new token on Stellar using the ITS
+- Deploy your new token on the Avalanche Fuji testnet
+- Transfer tokens from Stellar to Avalanche Fuji
+
+### Step 1: Initialize your contract with the ITS address
+
+Before creating tokens or transferring, your contract must know where the ITS service lives on Stellar.
+Run this command, replacing `YOUR_CONTRACT_ADDRESS` and `YOUR_ACCOUNT_NAME` accordingly:
+
+```bash
+stellar contract invoke \
+ --network testnet \
+ --id YOUR_CONTRACT_ADDRESS \
+ --source-account YOUR_ACCOUNT_NAME \
+ -- \
+ initialize \
+ --its_address CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK
+```
+
+> Note: `CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK` is the address of the Axelar Interchain Token Service contract on the Stellar testnet. You should confirm this address from the official Axelar documentation for testnet [here](https://github.com/axelarnetwork/axelar-contract-deployments/blob/main/axelar-chains-config/info/testnet.json).
+
+You should see something like:
+
+```
+ℹ️ Signing transaction: f90f7d67180f00e77b0de0b96b6cc801a68093c41ed6544cc82d327b2c1c4837
+```
+
+### Step 2: Check if Avalanche is a trusted chain
+
+It's a good practice to verify that ITS trusts the destination chain (Avalanche) before sending tokens.
+
+A trusted chain is one that the ITS recognizes and allows transfers to and from. To check if Avalanche is trusted, you can use the `is_trusted_chain` function in your contract.
+Replace `YOUR_CONTRACT_ADDRESS` and `YOUR_ACCOUNT_NAME` with your contract address and Stellar account name.
+
+Run the command below:
+
+```bash
+stellar contract invoke \
+ --network testnet \
+ --id YOUR_CONTRACT_ADDRESS \
+ --source-account YOUR_ACCOUNT_NAME \
+ -- \
+ is_trusted_chain \
+ --chain '"Avalanche"'
+```
+
+> Note: The quotes around the chain name are required due to how the Stellar CLI handles string parameters.
+
+You will get this:
+
+```
+ℹ️ Simulation identified as read-only. Send by rerunning with `--send=yes`.
+true
+```
+
+If it returns false, the chain is not yet trusted, and transfers to it won't work until it's added.
+
+### Step 3: Deploy a new Interchain Token on Stellar
+
+Create your own token that can exist across multiple blockchains:
+
+```bash
+stellar contract invoke \
+ --network testnet \
+ --id YOUR_CONTRACT_ADDRESS \
+ --source-account YOUR_ACCOUNT_NAME \
+ -- \
+ deploy_token \
+ --caller YOUR_ACCOUNT_NAME \
+ --salt 0123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef \
+ --name '"Axelar Test Token"' \
+ --symbol '"ATT"' \
+ --decimals 7 \
+ --initial_supply 1000000000
+```
+
+> Make sure to replace the salt with a proper 32-byte hexadecimal string. For convenience, you can use the example value shown above. After executing this command, you should receive a `token_id`. The contract will also internally store both the `token_id` and the salt for future operations.
+
+You will see something like this:
+
+```
+ℹ️ Signing transaction: d6a4cb711a78b681324b9ef8d0ad57ab99bb465261d294daee7f5fbbae242a47
+📅 CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK - Event: [{"symbol":"interchain_token_deployed"},{"bytes":"76e302e75743a189b908c691e481cbc86f7635ae7d56667ebaf44555d8803e0b"},{"address":"CCNZ2XJUC3IHIJIB77NOWKHEHQHNYCNQHMZLNLQSAH5YQS7VWVBYBCKX"},{"string":"Axelar Test Token"},{"string":"ATT"},{"u32":7},"void"] = {"vec":[]}
+📅 CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK - Event: [{"symbol":"token_manager_deployed"},{"bytes":"76e302e75743a189b908c691e481cbc86f7635ae7d56667ebaf44555d8803e0b"},{"address":"CCNZ2XJUC3IHIJIB77NOWKHEHQHNYCNQHMZLNLQSAH5YQS7VWVBYBCKX"},{"address":"CAFKSZAAUJ6KVPC43ZOKXSYSEE6FMTLIPWUUZDHBYFZPVRR6THVOBDBG"},{"u32":0}] = {"vec":[]}
+📅 CCNZ2XJUC3IHIJIB77NOWKHEHQHNYCNQHMZLNLQSAH5YQS7VWVBYBCKX - Event: [{"symbol":"minter_added"},{"address":"CAFKSZAAUJ6KVPC43ZOKXSYSEE6FMTLIPWUUZDHBYFZPVRR6THVOBDBG"}] = {"vec":[]}
+📅 CCNZ2XJUC3IHIJIB77NOWKHEHQHNYCNQHMZLNLQSAH5YQS7VWVBYBCKX - Event: [{"symbol":"mint"},{"address":"CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK"},{"address":"GAGZ5NZJMXKCORPFQMXYZJZTYDSZ5OPTYEPD2HSVNWU3MCV5JIL6IQDP"}] = {"i128":{"hi":0,"lo":1000000000}}
+"76e302e75743a189b908c691e481cbc86f7635ae7d56667ebaf44555d8803e0b"
+```
+
+This deployment returns your token ID, which is `76e302e75743a189b908c691e481cbc86f7635ae7d56667ebaf44555d8803e0b` in this example. Save it somewhere, as you will need it to do interchain token transfers.
+
+### Step 4: Deploy your token to the Avalanche Fuji testnet
+
+With your token created, deploy its representation on the Avalanche Fuji testnet.
+Run the command below, replacing values as needed:
+
+```bash
+stellar contract invoke \
+ --network testnet \
+ --id YOUR_CONTRACT_ADDRESS \
+ --source-account YOUR_ACCOUNT_NAME \
+ -- \
+ deploy_remote_token \
+ --caller YOUR_ACCOUNT_NAME \
+ --destination_chain '"Avalanche"' \
+ --gas_token_address CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC \
+ --gas_amount 10000000
+```
+
+> Notes:
+>
+> - `CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC` is the address of the native XLM token on Stellar testnet.
+> - The gas amount is 10 XLM (10,000,000,000 stroops).
+> - We don't need to specify the token_id as our contract stores this from the token deployment.
+
+You should see:
+
+```
+ℹ️ Signing transaction: 41a6d7c068fb82c777008f8da95c1d285d3b99ca07594b7e2c71eb4ed569018f
+📅 CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK - Event: [{"symbol":"token_deployment_started"},{"bytes":"76e302e75743a189b908c691e481cbc86f7635ae7d56667ebaf44555d8803e0b"},{"address":"CCNZ2XJUC3IHIJIB77NOWKHEHQHNYCNQHMZLNLQSAH5YQS7VWVBYBCKX"},{"string":"Avalanche"},{"string":"Axelar Test Token"},{"string":"ATT"},{"u32":7},"void"] = {"vec":[]}
+📅 CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC - Event: [{"symbol":"transfer"},{"address":"GAGZ5NZJMXKCORPFQMXYZJZTYDSZ5OPTYEPD2HSVNWU3MCV5JIL6IQDP"},{"address":"CAZUKAFB5XHZKFZR7B5HIKB6BBMYSZIV3V2VWFTQWKYEMONWK2ZLTZCT"},{"string":"native"}] = {"i128":{"hi":0,"lo":10000000000}}
+📅 CAZUKAFB5XHZKFZR7B5HIKB6BBMYSZIV3V2VWFTQWKYEMONWK2ZLTZCT - Event: [{"symbol":"gas_paid"},{"address":"CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK"},{"string":"axelar"},{"string":"axelar1aqcj54lzz0rk22gvqgcn8fr5tx4rzwdv5wv5j9dmnacgefvd7wzsy2j2mr"},{"bytes":"acd9ec020c801c7d6e5e9c15a5fa5b7e7944a0d5cdb027e2bdf4e70892d7ab54"},{"address":"GAGZ5NZJMXKCORPFQMXYZJZTYDSZ5OPTYEPD2HSVNWU3MCV5JIL6IQDP"},{"map":[{"key":{"symbol":"address"},"val":{"address":"CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC"}},{"key":{"symbol":"amount"},"val":{"i128":{"hi":0,"lo":10000000000}}}]}] = {...}
+"76e302e75743a189b908c691e481cbc86f7635ae7d56667ebaf44555d8803e0b"
+```
+
+This is a cross-chain transaction. You can check its status on Axelarscan testnet explorer by pasting this transaction hash: `41a6d7c068fb82c777008f8da95c1d285d3b99ca07594b7e2c71eb4ed569018f`. You can check [here](https://testnet.axelarscan.io/gmp/41a6d7c068fb82c777008f8da95c1d285d3b99ca07594b7e2c71eb4ed569018f).
+
+### Step 5: Transfer tokens cross-chain from Stellar to Avalanche
+
+Finally, send some tokens to your Avalanche wallet.
+
+Prepare your Avalanche address (without the `0x` prefix), and run:
+
+```bash
+stellar contract invoke \
+ --network testnet \
+ --id YOUR_CONTRACT_ADDRESS \
+ --source-account YOUR_ACCOUNT_NAME \
+ -- \
+ transfer_tokens \
+ --caller YOUR_ACCOUNT_NAME \
+ --token_id YOUR_TOKEN_ID \
+ --destination_chain '"Avalanche"' \
+ --destination_address '"YOUR_AVALANCHE_ADDRESS"' \
+ --amount 100000000 \
+ --gas_token_address CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC \
+ --gas_amount 10000000
+```
+
+> Notes:
+>
+> - Replace `YOUR_TOKEN_ID` with the token ID you received from the deployment (e.g., 76e302e75743a189b908c691e481cbc86f7635ae7d56667ebaf44555d8803e0b).
+> - Replace `YOUR_AVALANCHE_ADDRESS` with the InterchainToken Service on Avalanche Fuji tesnet (e.g., B5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C - without 0x prefix). The address is the same for all EVM chains.
+> - The amount is 10 tokens with seven decimal places (100,000,000 base units).
+
+You will get something like this:
+
+```
+ℹ️ Signing transaction: 6b8cf06327115b803aa465ebc9a12b9682753d89c391cca396bf767c31642fb2
+📅 CCNZ2XJUC3IHIJIB77NOWKHEHQHNYCNQHMZLNLQSAH5YQS7VWVBYBCKX - Event: [{"symbol":"burn"},{"address":"GAGZ5NZJMXKCORPFQMXYZJZTYDSZ5OPTYEPD2HSVNWU3MCV5JIL6IQDP"}] = {"i128":{"hi":0,"lo":100000000}}
+📅 CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK - Event: [{"symbol":"interchain_transfer_sent"},{"bytes":"76e302e75743a189b908c691e481cbc86f7635ae7d56667ebaf44555d8803e0b"},{"address":"GAGZ5NZJMXKCORPFQMXYZJZTYDSZ5OPTYEPD2HSVNWU3MCV5JIL6IQDP"},{"string":"Avalanche"},{"bytes":"b5fb4be02232b1bba4dc8f81dc24c26980de9e3c"},{"i128":{"hi":0,"lo":100000000}}] = {"vec":["void"]}
+📅 CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC - Event: [{"symbol":"transfer"},{"address":"GAGZ5NZJMXKCORPFQMXYZJZTYDSZ5OPTYEPD2HSVNWU3MCV5JIL6IQDP"},{"address":"CAZUKAFB5XHZKFZR7B5HIKB6BBMYSZIV3V2VWFTQWKYEMONWK2ZLTZCT"},{"string":"native"}] = {"i128":{"hi":0,"lo":10000000000}}
+📅 CAZUKAFB5XHZKFZR7B5HIKB6BBMYSZIV3V2VWFTQWKYEMONWK2ZLTZCT - Event: [{"symbol":"gas_paid"},{"address":"CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK"},{"string":"axelar"},{"string":"axelar1aqcj54lzz0rk22gvqgcn8fr5tx4rzwdv5wv5j9dmnacgefvd7wzsy2j2mr"},{"bytes":"4924e9eeae33b5800cb9418f98a473d14899b034034a9462cd72524697814b69"},{"address":"GAGZ5NZJMXKCORPFQMXYZJZTYDSZ5OPTYEPD2HSVNWU3MCV5JIL6IQDP"},{"map":[{"key":{"symbol":"address"},"val":{"address":"CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC"}},{"key":{"symbol":"amount"},"val":{"i128":{"hi":0,"lo":10000000000}}}]}] = {...}
+```
+
+Looking at axelarsscan with the hash: `6b8cf06327115b803aa465ebc9a12b9682753d89c391cca396bf767c31642fb2`, you will have https://testnet.axelarscan.io/gmp/6b8cf06327115b803aa465ebc9a12b9682753d89c391cca396bf767c31642fb2.
+
+You can register an existing token to make it an interchain token; however, we will cover that in a different guide.
+
+## Part 6: Receiving Tokens on Avalanche Fuji Testnet
+
+After the cross-chain transfer is completed, you can find the address of your token on Avalanche by checking the Axelarscan explorer for your cross-chain transaction or your address on Avalanche Fuji testnet. Now you should be able to see your token balance in your wallet.
+
+You can find the complete code example [here](https://github.com/axelarnetwork/stellar-its-example).
+
+## Conclusion
+
+You've now learned how to:
+
+1. Deploy a new token on Stellar.
+2. Make it available on an EVM chain.
+3. Transfer tokens between blockchains.
diff --git a/src/content/docs/dev/send-tokens/stellar/intro.mdx b/src/content/docs/dev/send-tokens/stellar/intro.mdx
new file mode 100644
index 000000000..8d12d0385
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/stellar/intro.mdx
@@ -0,0 +1,223 @@
+# Stellar Interchain Token Service (ITS)
+
+## What is the Interchain Token Service?
+
+The [Interchain Token Service (ITS)](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-interchain-token-service) is a protocol that allows tokens to move freely between different blockchains. Think of it as a universal bridge for tokens - it provides a standardized way to:
+
+1. Deploy a token onto multiple blockchains that are interlinked.
+1. Connect existing tokens from one blockchain to other blockchains.
+1. Transfer tokens securely between blockchains.
+
+For [Stellar developers](https://developers.stellar.org/), ITS opens up new possibilities to interact with tokens from Ethereum, Polygon, Avalanche, and many other blockchains without understanding the intricacies of each chain's token standards.
+
+## How ITS Works on Stellar
+
+Unlike on EVM chains (like Ethereum), where tokens follow the [ERC-20 standard](https://ethereum.org/en/developers/docs/standards/tokens/erc-20/), Stellar [assets](https://developers.stellar.org/docs/learn/fundamentals/stellar-data-structures/assets) work a bit differently.
+
+Stellar has its classic assets (issued with `G...` address) as well as [contract tokens](https://developers.stellar.org/docs/tokens/token-interface). The classic assets are native assets that have been part of the Stellar network since its inception, including tokens like XLM, USDC, and EURC, they are issued by Stellar Account and have a built-in [asset contract](https://developers.stellar.org/docs/tokens/stellar-asset-contract). Contract tokens were Introduced with Soroban, CAP-41, they allow for custom logic in token implementation through smart contracts. These are similar to ERC-20 tokens on other chains.
+ ITS integration adapts to Stellar's unique characteristics:
+
+1. **Hub Mode Operation**: Stellar ITS works exclusively in "Hub mode" - all cross-chain messages go through the [ITS Hub](/dev/amplifier/its-hub/introduction/) on the Axelar network rather than directly between chains.
+
+1. **Token Representation**: When an external token (like an Ethereum ERC-20) comes to Stellar, it's represented by a Stellar token that's controlled by a special contract called the [TokenManager](https://github.com/axelarnetwork/axelar-amplifier-stellar/blob/main/contracts/stellar-interchain-token-service/src/token_manager.rs).
+
+1. **Trust System**: Instead of trusting specific addresses (as in EVM implementations), Stellar ITS uses a system of trusted chains.
+
+With the integration of Stellar into Axelar, Stellar smart contracts can now leverage ITS to interact with tokens from other [blockchains](https://axelarscan.io/resources/chains) connected to Axelar.
+
+## Key Components of ITS
+
+Before diving into implementation, let's understand the key components:
+
+1. **`InterchainTokenService`**: The main [contract](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-interchain-token-service) that coordinates token-related operations. It's the primary interface for cross-chain token functionality.
+
+1. **`TokenManager`**: A [contract](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-token-manager) that handles tokens' minting, burning, and locking on a specific blockchain. Each token has its own `TokenManager`.
+
+1. **`InterchainToken`**: The token [contract](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-interchain-token) implementing Stellar's token interface.
+
+1. **`Gateway`**: A [contract](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-axelar-gateway) that facilitates the cross-chain message passing between Stellar and other blockchains.
+
+1. **`GasService`**: A [contract](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-axelar-gas-service) that handles payments for cross-chain transactions. Without this, messages couldn't be relayed between chains.
+
+## What You Can Do With ITS
+
+ITS enables several robust use cases on Stellar:
+
+### Deploy a new Interchain Token on Stellar:
+
+```rust
+fn deploy_interchain_token(
+ env: &Env,
+ caller: Address,
+ salt: BytesN<32>,
+ token_metadata: TokenMetadata,
+ initial_supply: i128,
+ minter: Option
,
+) -> Result, ContractError> {
+ // Returns a token_id that uniquely identifies your token across all chains
+}
+```
+
+### Deploy an Interchain Token Remotely to Other Chains:
+
+```rust
+fn deploy_remote_token(
+ env: &Env,
+ caller: Address,
+ salt: BytesN<32>,
+ destination_chain: String,
+ gas_token: Option,
+) -> Result, ContractError> {
+ // Deploys your token to another blockchain like Ethereum, Avalanche, etc.
+}
+```
+
+### Register an Existing Stellar As an Interchain Token to Make It Available on Other Chains
+
+These functions let you link existing tokens to the ITS network, making them available across chains.
+
+```rust
+// Register an existing Stellar token
+fn register_canonical_token(
+ env: &Env,
+ token_address: Address,
+) -> Result, ContractError> {
+ // Registers an existing token with the ITS
+}
+
+// Deploy that token to other chains (Ethereum, Avalanche, etc.)
+fn deploy_remote_canonical_token(
+ env: &Env,
+ token_address: Address,
+ destination_chain: String,
+ spender: Address,
+ gas_token: Option,
+) -> Result, ContractError> {
+ // Makes your existing token available on other blockchains
+}
+```
+
+### Transfer Tokens Cross-Chain
+
+Send tokens between Stellar and any supported blockchain:
+
+```rust
+fn interchain_transfer(
+ env: &Env,
+ caller: Address,
+ token_id: BytesN<32>,
+ destination_chain: String,
+ destination_address: Bytes,
+ amount: i128,
+ data: Option,
+ gas_token: Option,
+) -> Result<(), ContractError> {
+ // Transfers tokens from Stellar to another blockchain
+}
+```
+
+### Trusted Chain Management
+
+Before sending tokens cross-chain, you can check if the destination chain is valid or trusted:
+
+```rust
+fn is_trusted_chain(env: &Env, chain: String) -> bool {
+ storage::is_trusted_chain(env, chain)
+}
+```
+
+### Receive Tokens from Other Chains
+
+To receive tokens from other blockchains, the contract must implement message handling:
+
+```rust
+fn execute(
+ env: &Env,
+ source_chain: String,
+ message_id: String,
+ source_address: String,
+ payload: Bytes,
+) -> Result<(), ContractError> {
+ // This function:
+ // 1. Validates that the message is coming from the ITS Hub
+ // 2. Decodes the message to determine its type
+ // 3. Processes it appropriately - either as a token transfer or a token deployment
+}
+```
+
+### Flow Limits
+
+The ITS implementation includes a [flow-limiting system](/dev/send-tokens/interchain-tokens/flow-limit/) to control how many tokens can move in a given period:
+
+```rust
+#[only_operator]
+fn set_flow_limit(
+ env: &Env,
+ token_id: BytesN<32>,
+ flow_limit: Option,
+) -> Result<(), ContractError> {}
+```
+
+This function allows the [operator](/dev/send-tokens/interchain-tokens/minter-operator-roles/#operator-role) to limit how many tokens can flow in or out over time.
+
+#### Setting Flow Limits
+
+Flow limits are configured per token and can only be set by authorized operators:
+
+```rust
+// Set a flow limit for a token
+client.set_flow_limit(&token_id, &Some(1000_000));
+
+// Remove flow limit (disable flow limiting)
+client.set_flow_limit(&token_id, &None);
+
+// Freeze token transfers (set limit to 0)
+client.set_flow_limit(&token_id, &Some(0));
+```
+
+#### Authorization
+
+- **Only Operators**: Flow limits can only be set by addresses with operator privileges
+- **Per-Token Configuration**: Each token can have its own independent flow limit
+- **Optional Feature**: Tokens without configured flow limits have no transfer restrictions
+
+
+
+#### Query Functions
+
+The ITS contract provides several functions to query flow limit status:
+
+```rust
+// Get the configured flow limit for a token
+fn flow_limit(token_id: BytesN<32>) -> Option
+
+// Get current epoch's outflow amount
+fn flow_out_amount(token_id: BytesN<32>) -> i128
+
+// Get current epoch's inflow amount
+fn flow_in_amount(token_id: BytesN<32>) -> i128
+```
+
+#### Error Handling
+
+The system returns specific errors for different flow limit violations:
+
+- **`InvalidFlowLimit`**: Attempted to set a negative flow limit
+- **`FlowAmountExceededLimit`**: Single transfer exceeds the flow limit
+- **`FlowAmountOverflow`**: Cumulative flow would cause integer overflow
+- **`FlowLimitExceeded`**: Net flow would exceed the configured limit
+
+#### Events
+
+Flow limit changes emit events for monitoring and auditing:
+
+```rust
+FlowLimitSetEvent {
+ token_id: BytesN<32>,
+ flow_limit: Option,
+}
+```
+
+## Next Steps
+
+Learn More: Explore our tutorial on [building a rust project from scratch with interchain token service implementation to deploy and transfer tokens from Steller to EVM](). This tutorial will guide you through distributing tokens across multiple chains.
diff --git a/src/content/docs/dev/send-tokens/stellar/link-custom-token.mdx b/src/content/docs/dev/send-tokens/stellar/link-custom-token.mdx
new file mode 100644
index 000000000..e69de29bb
diff --git a/src/content/docs/dev/send-tokens/stellar/register-existing-stellar-token.mdx b/src/content/docs/dev/send-tokens/stellar/register-existing-stellar-token.mdx
new file mode 100644
index 000000000..e52ab823f
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/stellar/register-existing-stellar-token.mdx
@@ -0,0 +1,653 @@
+import { Callout } from "../../../../../components/callout";
+
+# Register and transfer existing tokens from Stellar to EVM chains using ITS
+
+This guide demonstrates, step-by-step, how to use [Axelar's Interchain Token Service (ITS)](/dev/send-tokens/interchain-tokens/intro/#interchain-token-service) to register an existing token on Stellar and make it available for cross-chain transfers to EVM chains.
+
+By the end, you will be able to:
+
+1. Register an existing token on Stellar with Axelar ITS.
+1. Deploy that token representation on an EVM chain (Avalanche Fuji testnet).
+1. Transfer tokens seamlessly between Stellar and the EVM chain.
+
+## Prerequisites
+
+Before starting, make sure you have the following ready:
+
+- Rust installed with the wasm32 target enabled ([installation instructions](https://www.rust-lang.org/tools/install))
+- Stellar CLI installed ([stellar-cli repo](https://github.com/stellar/stellar-cli))
+- A Stellar testnet account funded with test XLM
+- A browser wallet like MetaMask configured to connect to the Avalanche Fuji testnet, or a similar wallet like Rabby
+- An existing token on Stellar that you control or have permission to register
+
+If you don’t yet have a Stellar token, you can create one using tools like [Token Tool](https://tokentool.bitbond.com/) or programmatically. This guide assumes you already have the token address ready.
+
+## Part 1: Understanding the Interchain Token Service
+
+The [Interchain Token Service (ITS)](https://github.com/axelarnetwork/axelar-amplifier-stellar/tree/main/contracts/stellar-interchain-token-service) is a protocol that allows tokens to move freely between different blockchains.
+
+Instead of deploying a brand-new token, ITS let's you register existing tokens you own on Stellar and seamlessly transfer their value across chains. It achieves this through a canonical token integration, meaning:
+
+- When you transfer your Stellar token to another chain, the ITS _locks_ the token on Stellar
+- It _mints_ a corresponding wrapped token on the destination chain
+- When tokens move back to Stellar, the wrapped tokens are _burned_ and the original tokens are _unlocked_
+
+
+ There can only be a single lock/unlock token manager for the token
+
+
+## Part 2: Set up your Stellar ITS project
+
+Now, let’s build a Stellar smart contract project that integrates with ITS to register and transfer existing tokens.
+
+### Step 1. Initialize a new project
+
+Start by creating a new Stellar contract project and the directory:
+
+```bash
+stellar contract init axelar-its-existing-token
+cd axelar-its-existing-token
+```
+
+This command scaffolds a basic Stellar contract project for you.
+
+> Tip: We'll simplify the default structure as we progress, focusing on the files needed for the ITS integration.
+
+### Step 2: Simplify your project structure
+
+To keep things neat, remove unnecessary folders and consolidate your source files.
+
+- Move the `src` folder to the root of your project directory if it isn’t there already
+- Delete any example or template contract folders, such as `contract/hello-world`
+
+After cleanup later in this section, your folder should look like this:
+
+```bash
+axelar-its-existing-token
+├── src
+│ ├── lib.rs
+├── .gitignore
+├── Cargo.toml
+├── README.md
+```
+
+### Step 3. Configure your dependencies in Cargo.toml
+
+Open `Cargo.toml` in your project root and update it to include dependencies needed for Axelar ITS and Stellar development.
+
+Here’s a sample you can copy:
+
+```toml
+[package]
+name = "axelar-its-existing-token"
+
+version = "0.0.0"
+edition = "2021"
+publish = false
+
+[lib]
+crate-type = ["cdylib"]
+doctest = false
+
+[dependencies]
+soroban-sdk = "22.0.0"
+soroban-token-sdk = "22.0.0"
+stellar-axelar-gateway = { git = "https://github.com/axelarnetwork/axelar-amplifier-stellar", branch = "main", features = ["library"] }
+stellar-axelar-gas-service = { git = "https://github.com/axelarnetwork/axelar-amplifier-stellar", branch = "main", features = ["library"] }
+stellar-interchain-token-service = { git = "https://github.com/axelarnetwork/axelar-amplifier-stellar", branch = "main", features = ["library"] }
+stellar-interchain-token = { git = "https://github.com/axelarnetwork/axelar-amplifier-stellar", branch = "main", features = ["library"] }
+stellar-token-manager = { git = "https://github.com/axelarnetwork/axelar-amplifier-stellar", branch = "main", features = ["library"] }
+stellar-axelar-std = { git = "https://github.com/axelarnetwork/axelar-amplifier-stellar", branch = "main" }
+
+[dev-dependencies]
+soroban-sdk = { version = "22.0.0", features = ["testutils"] }
+
+[profile.release]
+opt-level = "z"
+overflow-checks = true
+debug = 0
+strip = "symbols"
+debug-assertions = false
+panic = "abort"
+codegen-units = 1
+lto = true
+
+[profile.release-with-logs]
+inherits = "release"
+debug-assertions = true
+```
+
+This configuration pulls in Axelar’s Stellar libraries from GitHub and sets up your Rust build profiles for optimal WASM compilation.
+
+## Part 3: Implement the contract logic
+
+Now that the project structure and dependencies are ready, it's time to implement the contract. This contract will interact with the Interchain Token Service (ITS) to register your existing Stellar token and enable cross-chain transfers.
+
+We'll build this step by step by creating the core source files inside the `src` folder.
+
+### Step 1: Define the contract entry point (`lib.rs`)
+
+The `lib.rs` file acts as the main entry point for your contract. Here, you declare the modules your contract uses.
+
+Update `src/lib.rs` with:
+
+```rust
+#![no_std]
+
+pub mod contract;
+pub mod error;
+mod storage_types;
+```
+
+- `contract` will contain the main contract implementation
+- `error` defines error types your contract can return
+- `storage_types` holds data structures used for contract storage
+
+### Step 2: Define contract errors (`error.rs`)
+
+A clear list of error codes helps you handle edge cases and report issues properly.
+
+Create `src/error.rs` with the following content:
+
+```rust
+use stellar_axelar_std::{contracterror, soroban_sdk};
+
+#[contracterror]
+#[derive(Copy, Clone, Debug, PartialEq, Eq)]
+#[repr(u32)]
+pub enum ContractError {
+ TrustedChainAlreadySet = 1,
+ TrustedChainNotSet = 2,
+ InvalidMessageType = 3,
+ UntrustedChain = 4,
+ InvalidAmount = 5,
+ InvalidDestinationAddress = 6,
+ NotHubChain = 7,
+ NotHubAddress = 8,
+ InvalidTokenId = 9,
+ TokenAlreadyRegistered = 10,
+ FlowLimitExceeded = 11,
+ InvalidDestinationChain = 12,
+ InvalidData = 13,
+ InvalidTokenConfig = 14,
+}
+```
+
+Each error has a unique numeric code and a named variant. This helps both you and users understand why a transaction might fail.
+
+### Step 3: Define storage keys (storage_types.rs)
+
+The contract needs to store some key data on-chain. Let's define storage keys in `src/storage_types.rs`:
+
+```rust
+use soroban_sdk::{contracttype, String};
+
+#[contracttype]
+#[derive(Clone, Debug)]
+pub enum DataKey {
+ InterchainTokenService,
+ TokenId,
+ OriginalToken,
+ TrustedChain(String),
+}
+```
+
+This storage structure includes:
+
+- `InterchainTokenService`: Stores the address of the deployed ITS contract
+- `TokenId`: Stores the ID of the registered token
+- `OriginalToken`: Stores the address of the original token we registered
+- `TrustedChain`: Tracks which chains we've marked as trusted
+
+### Step 4: Implement the contract logic (contract.rs)
+
+#### 1. Setup and Initialization
+
+First, let's create the `contract.rs` file inside the `src` folder with a basic setup and initialization functions:
+
+```rust
+use soroban_sdk::{contract, contractimpl, Address, Bytes, BytesN, Env, String};
+use stellar_axelar_std::types::Token;
+use stellar_interchain_token_service::InterchainTokenServiceClient;
+
+use crate::storage_types::DataKey;
+
+#[contract]
+pub struct ExistingTokenApp;
+
+#[contractimpl]
+impl ExistingTokenApp {
+ /// Initialize the contract with the ITS service address
+ pub fn initialize(env: &Env, its_address: Address) {
+ env.storage()
+ .instance()
+ .set(&DataKey::InterchainTokenService, &its_address);
+ }
+
+ /// Get the ITS client
+ fn its_client(env: &Env) -> InterchainTokenServiceClient {
+ let its_address = env
+ .storage()
+ .instance()
+ .get(&DataKey::InterchainTokenService)
+ .unwrap();
+ InterchainTokenServiceClient::new(env, &its_address)
+ }
+
+ /// Check if a chain is trusted
+ pub fn is_trusted_chain(env: &Env, chain: String) -> bool {
+ let its = Self::its_client(env);
+ its.is_trusted_chain(&chain)
+ }
+}
+```
+
+These functions:
+
+- `initialize`: Sets up the contract with the address of the ITS service.
+- `its_client`: Creates an instance of the `InterchainTokenServiceClient`.
+- `is_trusted_chain`: Checks if a chain is trusted by the ITS.
+
+#### 2. Token Registration Functions
+
+Next, let's add functions to register an existing token and retrieve token information:
+
+```rust
+ //...
+
+ /// Register an existing Stellar token for cross-chain use
+ pub fn register_existing_token(
+ env: &Env,
+ caller: Address,
+ token_address: Address,
+ ) -> BytesN<32> {
+ caller.require_auth();
+
+ let its = Self::its_client(env);
+
+ // Register the token - direct call
+ let token_id = its.register_canonical_token(&token_address);
+
+ // Store the token ID and original token address for reference
+ env.storage().instance().set(&DataKey::TokenId, &token_id);
+ env.storage()
+ .instance()
+ .set(&DataKey::OriginalToken, &token_address);
+
+ token_id
+ }
+
+ /// Get the currently stored token ID
+ pub fn get_token_id(env: &Env) -> BytesN<32> {
+ env.storage().instance().get(&DataKey::TokenId).unwrap()
+ }
+
+ /// Get the original token address
+ pub fn get_original_token(env: &Env) -> Address {
+ env.storage()
+ .instance()
+ .get(&DataKey::OriginalToken)
+ .unwrap()
+ }
+```
+
+The `register_existing_token` function:
+
+- Authenticates the caller to ensure they have permission.
+- Registers the existing token with the ITS using `register_canonical_token`.
+- Stores both the generated `token_id` and the original token address.
+- Returns the `token_id` for reference.
+
+The getter functions allow us to retrieve stored token information:
+
+- `get_token_id`: Returns the ITS `token_id`.
+- `get_original_token`: Returns the address of the original token.
+
+#### 3. Cross-Chain Functions
+
+Finally, let's add functions for cross-chain token deployment and transfers:
+
+```rust
+ //...
+
+ /// Deploy the existing registered token to another blockchain
+ pub fn deploy_remote_canonical_token(
+ env: &Env,
+ caller: Address,
+ destination_chain: String,
+ gas_token_address: Address,
+ gas_amount: i128,
+ ) -> BytesN<32> {
+ caller.require_auth();
+
+ let its = Self::its_client(env);
+
+ // Get the original token address
+ let token_address = env
+ .storage()
+ .instance()
+ .get(&DataKey::OriginalToken)
+ .unwrap();
+
+ // Prepare gas token
+ let gas_token = Some(Token {
+ address: gas_token_address,
+ amount: gas_amount,
+ });
+
+ // Deploy to remote chain - direct call
+ let token_id = its.deploy_remote_canonical_token(
+ &token_address,
+ &destination_chain,
+ &caller, // spender
+ &gas_token,
+ );
+
+ token_id
+ }
+
+ /// Transfer interchain tokens to another blockchain
+ pub fn transfer_tokens(
+ env: &Env,
+ caller: Address,
+ token_id: BytesN<32>,
+ destination_chain: String,
+ destination_address: Bytes,
+ amount: i128,
+ gas_token_address: Address,
+ gas_amount: i128,
+ ) {
+ caller.require_auth();
+
+ let its = Self::its_client(env);
+
+ // Basic validation
+ if amount <= 0 {
+ panic!("Invalid amount");
+ }
+
+ if destination_address.len() == 0 {
+ panic!("Invalid destination address");
+ }
+
+ // Prepare gas token
+ let gas_token = Some(Token {
+ address: gas_token_address,
+ amount: gas_amount,
+ });
+
+ // Send the tokens cross-chain - direct call
+ its.interchain_transfer(
+ &caller,
+ &token_id,
+ &destination_chain,
+ &destination_address,
+ &amount,
+ &None, // No additional data
+ &gas_token,
+ );
+ }
+```
+
+The `deploy_remote_canonical_token` function:
+
+- Deploys the registered token to another blockchain.
+- Uses the original token's address (retrieved from storage).
+- Configures gas payment for cross-chain operations.
+- Returns the `token_id`, which remains consistent across chains.
+
+The `transfer_tokens` function:
+
+- Validates the transfer amount and destination address
+- Initiates the cross-chain transfer with appropriate gas payment
+
+With these functions implemented, our contract now provides a complete interface for registering existing tokens and enabling cross-chain transfers.
+
+## Part 4: Build and Deploy the Contract
+
+Once your contract code is complete, follow these steps to compile and deploy it on the Stellar testnet.
+
+### Step 1: Build your contract
+
+```bash
+stellar contract build
+```
+
+You should see output confirming the build succeeded and showing the location of the `.wasm` file:
+
+```
+ℹ️ Build Summary:
+ Wasm File: target/wasm32-unknown-unknown/release/axelar_its_existing_token.wasm
+ Wasm Hash: ...
+ Exported Functions: 8 found
+ ...
+✅ Build Complete
+```
+
+### Step 2: Optimize the WASM file
+
+```bash
+stellar contract optimize --wasm target/wasm32-unknown-unknown/release/axelar_its_existing_token.wasm
+```
+
+This creates an optimized `.wasm` file you will deploy.
+
+### Step 3: Deploy the contract to the Stellar testnet
+
+Use the Stellar CLI to deploy your contract, replacing `YOUR_ACCOUNT_NAME` with your funded Stellar testnet account:
+
+```bash
+stellar contract deploy \
+ --wasm target/wasm32-unknown-unknown/release/axelar_its_existing_token.optimized.wasm \
+ --source YOUR_ACCOUNT_NAME \
+ --network testnet
+```
+
+On success, you’ll receive a contract address. Save this address, you’ll need it to interact with your contract.
+
+Example output:
+
+```bash
+✅ Deployed!
+CCEJZPYGNDQFFNPZBHD474OJILN32J6PELILJX3ZQ5L4OSXU24LBNXMY
+```
+
+Your contract address is `CCEJZPYGNDQFFNPZBHD474OJILN32J6PELILJX3ZQ5L4OSXU24LBNXMY`.
+
+## Part 5: Interacting with your contract on the Stellar testnet
+
+Now that your contract is deployed on the Stellar testnet, you’ll use the Stellar CLI to:
+
+- Initialize your contract by connecting it to the Axelar Interchain Token Service (ITS)
+- Register your existing Stellar token with the ITS through your contract
+- Deploy your registered token representation on the Avalanche Fuji testnet
+- Transfer tokens from Stellar to Avalanche Fuji
+
+### Step 1: Initialize your contract with the ITS address
+
+Before registering tokens or transferring, your contract needs to know where the ITS service lives on Stellar.
+
+Run this command, replacing `YOUR_CONTRACT_ADDRESS` and `YOUR_ACCOUNT_NAME` accordingly:
+
+```bash
+stellar contract invoke \
+ --network testnet \
+ --id YOUR_CONTRACT_ADDRESS \
+ --source-account YOUR_ACCOUNT_NAME \
+ -- \
+ initialize \
+ --its_address CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK
+```
+
+> Note: `CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK` is the address of the Axelar Interchain Token Service contract on the Stellar testnet. You should confirm this address from the [official Axelar documentation for testnet](https://github.com/axelarnetwork/axelar-contract-deployments/blob/main/axelar-chains-config/info/testnet.json). You only need to run this once after deployment.
+
+### Step 2: Check if Avalanche is a trusted chain
+
+It’s a good practice to verify that ITS trusts the destination chain (Avalanche in this case) before sending tokens.
+
+A trusted chain is one that the ITS recognizes and allows transfers to and from. To check if Avalanche is trusted, you can use the `is_trusted_chain` function in your contract.
+Replace `YOUR_CONTRACT_ADDRESS` and `YOUR_ACCOUNT_NAME` with your contract address and Stellar account name.
+
+Run the command below:
+
+```bash
+stellar contract invoke \
+ --network testnet \
+ --id YOUR_CONTRACT_ADDRESS \
+ --source-account YOUR_ACCOUNT_NAME \
+ -- \
+ is_trusted_chain \
+ --chain '"Avalanche"'
+```
+
+> Note: The quotes around the chain name are required due to how the Stellar CLI handles string parameters. You should get a response confirming that Avalanche is trusted:
+
+```
+ℹ️ Simulation identified as read-only. Send by rerunning with `--send=yes`.
+true
+```
+
+If it returns false, the chain is not yet trusted, and transfers to it won’t work until it’s added.
+
+### Step 3: Register your existing Stellar token
+
+Next, register the Stellar token you want to enable for cross-chain transfers.
+
+Replace `EXISTING_TOKEN_ADDRESS` with your token’s Stellar address and run:
+
+```bash
+stellar contract invoke \
+ --network testnet \
+ --id YOUR_CONTRACT_ADDRESS \
+ --source-account YOUR_ACCOUNT_NAME \
+ -- \
+ register_existing_token \
+ --caller YOUR_ACCOUNT_NAME \
+ --token_address EXISTING_TOKEN_ADDRESS
+```
+
+You should see output similar to:
+
+```
+ℹ️ Signing transaction:
+📅 CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK - Event: [{"symbol":"canonical_token_registered"},{"bytes":""},{"address":""}] = {"vec":[]}
+📅 CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK - Event: [{"symbol":"token_manager_deployed"},{"bytes":""},{"address":""},{"address":""},{"u32":1}] = {"vec":[]}
+""
+```
+
+Example response:
+
+```bash
+ℹ️ Signing transaction: ef633fe0cb694729d0c8edc82ef362245797a86a84121eb75e5fc78d534e0205
+📅 CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK - Event: [{"symbol":"token_manager_deployed"},{"bytes":"29aa926bf713f85c3044d3643abb5f591a3aac4494c18e065d22228ac8dfebe8"},{"address":"CCRMJF6QOPL77F2OTX4EPFZGSADCQL76ESSREBIGSZIX57HKFZAS6B4M"},{"address":"CCZ7G5BIFBBYWSWEUUNFYCLEVZYBDEKPUZKUOJZRI23ZAB3DFYEWC5ED"},{"u32":2}] = {"vec":[]}
+"29aa926bf713f85c3044d3643abb5f591a3aac4494c18e065d22228ac8dfebe8"
+```
+
+The response includes your `token_id` - note it as you'll need it later in this tutorial.
+
+### Step 4: Deploy your registered token to the Avalanche Fuji testnet
+
+With your token registered, deploy its representation on the Avalanche Fuji testnet.
+
+Run the command below, replacing values as needed:
+
+```bash
+stellar contract invoke \
+ --network testnet \
+ --id YOUR_CONTRACT_ADDRESS \
+ --source-account YOUR_ACCOUNT_NAME \
+ -- \
+ deploy_remote_canonical_token \
+ --caller YOUR_ACCOUNT_NAME \
+ --destination_chain '"Avalanche"' \
+ --gas_token_address CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC \
+ --gas_amount 10000000
+```
+
+> Notes:
+>
+> - `CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC` is the address of the native XLM token on Stellar testnet.
+> - The gas amount is 1 XLM (100,000,00 stroops).
+
+You’ll see transaction logs and events confirming the deployment started, and a `token_id` string returned.
+
+```
+ℹ️ Signing transaction:
+📅 CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK - Event: [{"symbol":"token_deployment_started"},{"bytes":""},{"address":""},{"string":"Avalanche"},{"string":""},{"string":""},{"u32":},"void"] = {"vec":[]}
+📅 CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC - Event: [{"symbol":"transfer"}, ... ]
+... more events ...
+""
+```
+
+For example:
+
+````bash
+ℹ️ Signing transaction: bbc44b3f76363d295f62800292b38c690735532b469b3018c59bf84860a31ddc
+...
+{"bytes":"8bb9d9cffca6787421eb6e56752bb87ec0f00900ddd901466475ce4e23a44db2"}] = {...}
+"29aa926bf713f85c3044d3643abb5f591a3aac4494c18e065d22228ac8dfebe8"
+
+This is a cross-chain transaction. You can check its status on Axelarscan testnet explorer by pasting the transaction hash as shown [here](https://testnet.axelarscan.io/gmp/bbc44b3f76363d295f62800292b38c690735532b469b3018c59bf84860a31ddc).
+
+### Step 5: Transfer tokens cross-chain from Stellar to Avalanche
+
+Finally, send some tokens to your Avalanche wallet.
+
+Prepare your Avalanche address (without the `0x` prefix), and run:
+
+```bash
+stellar contract invoke \
+ --network testnet \
+ --id YOUR_CONTRACT_ADDRESS \
+ --source-account YOUR_ACCOUNT_NAME \
+ -- \
+ transfer_tokens \
+ --caller YOUR_ACCOUNT_NAME \
+ --destination_chain '"Avalanche"' \
+ --destination_address '"YOUR_AVALANCHE_ADDRESS"' \
+ --amount 100000000 \
+ --token_id TOKEN_ID \
+ --gas_token_address CDLZFC3SYJYDZT7K67VZ75HPJVIEUVNIXF47ZG2FB2RMQQVU2HHGCYSC \
+ --gas_amount 10000000
+````
+
+> Notes:
+>
+> - The amount is 10 tokens with whatever decimal places your token uses (adjust accordingly).
+> - The gas is still 1 XLM as in the previous example.
+
+You should see output similar to:
+
+```
+ℹ️ Signing transaction:
+📅 - Event: [{"symbol":"transfer"}, ... ] = {"i128": ... }
+📅 CCXT3EAQ7GPQTJWENU62SIFBQ3D4JMNQSB77KRPTGBJ7ZWBYESZQBZRK - Event: [{"symbol":"interchain_transfer_sent"},{"bytes":""},{"address":""},{"string":"Avalanche"},{"bytes":""},{"i128":...}] = {"vec":["void"]}
+... more events ...
+```
+
+For example:
+
+```bash
+ℹ️ Signing transaction: 4386580b551692c0b9c1c25c5c7158cbd2270f98fcbfcbdf46f5dd867c5ca645
+{...}
+```
+
+This is a cross-chain transaction. You can check its status on Axelarscan testnet explorer by pasting the transaction hash as shown [here](https://testnet.axelarscan.io/gmp/4386580b551692c0b9c1c25c5c7158cbd2270f98fcbfcbdf46f5dd867c5ca645).
+
+## Part 6: Receiving Tokens on Avalanche Fuji Testnet
+
+After the cross-chain transfer is completed, you can find the address of your token on Avalanche by checking the Axelarscan explorer for your cross-chain transaction or your address on Avalanche Fuji testnet. For example [here](https://testnet.snowtrace.io/address/0x510e5EA32386B7C48C4DEEAC80e86859b5e2416C/tokentxns?tokenaddresses=0xc3Aa19e24aD9dB60A262C753Aaa33F2F9A1b7B16&chainid=43113#erc20)
+
+Now you should be able to see your token balance in your wallet.
+
+You can find the full code example [here](https://github.com/axelarnetwork/stellar-its-example).
+
+## Conclusion
+
+You've now learned how to:
+
+1. Register an existing token on Stellar with the Interchain Token Service
+2. Make it available on an EVM chain
+3. Transfer tokens between blockchains
+
+This approach allows you to make any existing Stellar token cross-chain compatible, opening up new possibilities for your assets.
diff --git a/src/content/docs/dev/send-tokens/sui/intro.mdx b/src/content/docs/dev/send-tokens/sui/intro.mdx
new file mode 100644
index 000000000..531e62e81
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/sui/intro.mdx
@@ -0,0 +1,690 @@
+import { Callout } from "../../../../../components/callout";
+
+# Sui Interchain Token Service (ITS)
+
+Axelar's [Interchain Token Service (ITS)](https://www.axelar.network/its) is live on the Sui blockchain to allow for the integration of coins on Sui to be sent to/from [other ecosystems](https://axelarscan.io/resources/chains) connected to the Axelar Network. ITS allows teams to deploy fresh new fungible [Interchain Tokens](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token/sources/interchain_token.move) as well as integrate custom tokens that want to go cross-chain. ITS is already live on many different EVM and non-evm chains, so that you can send your Sui coins to and from those chains.
+
+The official Sui integration codebase can be found [here](https://github.com/axelarnetwork/axelar-cgp-sui/tree/main/move/interchain_token_service)
+
+
+ The simplest way to use ITS is through Axelar's [ITS
+ Portal](https://interchain.axelar.dev/), which also supports Sui. The [ITS Testnet
+ Portal](https://testnet.interchain.axelar.dev/).
+
+
+
+
+## Register Coin
+
+To integrate a coin with Sui you must first register the coin with ITS. There are different ways to register the coin, depending on how the coin is being integrated. For canonical integrations where the coin on Sui will be connected to a wrapped interchain token on a remote chain you will register the coin on Sui via either [register_coin_from_info()](#register-coin-from-info) or [register_coin_from_metadata()](#register-coin-from-metadata). If you are connecting your Sui coin to a customized token on a different blockchain you will need to call [register_custom_coin()](#register-custom-coin), followed by [link_coin()](#link-coin).
+
+### Register Coin From Info
+
+If you want to register your coin by explicitly passing in its information you will need to register your coin via the `register_coin_from_info()` function. The function returns a new [TokenId](#token-id) and takes five parameters:
+
+1. `its`: The ITS object that will be updated once the new coin is registered.
+1. `name`: The name of the coin being registered.
+1. `symbol`: The symbol of the coin being registered.
+1. `decimals`: The amount of decimals the coin being registered has.
+1. `coin_management`: The type of [management](#coin-management) the coin is registered with.
+
+The function is defined as follows:
+
+```rust
+public(package) fun register_coin_from_info(
+ self: &mut InterchainTokenService,
+ name: std::string::String,
+ symbol: ascii::String,
+ decimals: u8,
+ coin_management: CoinManagement,
+): TokenId {}
+```
+
+This will be a commonly used registration flow as Sui coins often times [freeze](https://docs.sui.io/concepts/object-ownership/immutable#create-immutable-object) its metadata so that no one can alter critical configuration about the coin such as its name, symbol, and decimals.
+
+### Register Coin from Metadata
+
+If you do not want to explicitly pass in your coin's info, then you can register the coin via `register_coin_from_metadata()` function. Whereas the previous `register_coin_from_info()` may be simpler to use, this coin registration prevents against human error, for example, a typo in the symbol or name since the coin paramaters are not validated in any way. The function returns a new [TokenId](#token-id) and takes three parameters:
+
+1. `its`: The ITS object that will be updated once the new coin is registered.
+1. `metadata`: A generic reference to the coin's metadata that contains the coins name, symbol, and decimals.
+1. `coin_management`: The type of [management](#coin-management) the coin is registered with.
+
+```rust
+public(package) fun register_coin_from_metadata(
+ self: &mut InterchainTokenService,
+ metadata: &CoinMetadata,
+ coin_management: CoinManagement,
+): TokenId {}
+```
+
+The coin management must be constructed beforehand, ITS will not construct this automatically for you.
+
+### Register Custom Coin
+To integrate a coin into ITS, the `register_coin()` function must be called. This function takes in the following parameters:
+
+1. `its`: The ITS object that will be updated once the new coin is registered
+1. `coin_info`: The [coin info](#coin-info) represents the name, symbol and decimals of the coin
+1. `coin_management`: The type of [management](#coin-management) the coin is registered with.
+
+However, before you can register your coin, you must first create a [coin-manager](#coin-management) and a [coin-info](#coin-info) for it.
+
+```rust
+public fun register_coin(
+ self: &mut ITS,
+ coin_info: CoinInfo,
+ coin_management: CoinManagement,
+): TokenId {
+ let value = self.value_mut!(b"register_coin");
+
+ value.register_coin(coin_info, coin_management)
+}
+```
+
+Once triggered, ITS will generate a unique [token id](#token-id) from the coin's metadata and management details. Then it will [add](https://docs.sui.io/references/framework/sui/bag#sui_bag_add) the tokenId to the `registered_coins` bag. The full implementation of the `register_coin()` function can be found [here](https://github.com/axelarnetwork/axelar-cgp-sui/blob/v1.1.3/move/interchain_token_service/sources/versioned/interchain_token_service_v0.move#L166)
+
+See [here](https://github.com/axelarnetwork/axelar-contract-deployments/blob/main/sui/its-example.js#L195) for an example of registering a new coin.
+
+## Register Coin Metadata
+
+The `register_coin_metadata()` function is used to register the [TokenMetadata](https://github.com/axelarnetwork/axelar-amplifier/blob/main/packages/interchain-token-service-std/src/primitives.rs#L82) msg type with [ITS Hub](/dev/amplifier/its-hub/introduction/) in order to register token data in ITS hub. This function is required to be called on each chain where you token is being integrated to ITS on if you are planning on linking a custom token.
+
+Note: This function is separate from [register_coin_from_metadata](#register-coin-from-metadata), which is used for registering canonical tokens for Sui.
+
+The `register_coin_metadata()` returns a [MessageTicket](/dev/general-message-passing/sui/gmp-contracts/#message-ticket) and takes the following two parameters:
+
+1. `its`: The ITS object that will be updated once the token's metadata is registered.
+1. `coin_metadata`: The metadata of the coin to be registered.
+
+It is written as follows:
+
+```rust
+public fun register_coin_metadata(self: &InterchainTokenService, coin_metadata: &CoinMetadata): MessageTicket {}
+```
+
+
+
+## Link Coin
+
+If you are looking to connect your custom coin on Sui to a custom coin on another blockchain, such as Ethereum, you will need to *link* the coin between the two chains. The linking process can only take place after the [register_custom_coin](#register-custom-coin) function has been called. The `link_coin()` function is defined as follows:
+
+The function takes seven parameters and returns a [MessageTicket](/dev/general-message-passing/sui/gmp-contracts/#message-ticket).
+
+1. `its`: The ITS object that will be updated once the new token is linked.
+1. `deployer` The deployer’s [channel](/dev/general-message-passing/sui/gmp-contracts/#channel) capability. Used to derive the custom [tokenId](#token-id) with the `salt` and `chain_name`, so only that channel’s holder can link that custom token.
+1. `destination_chain`: The name of the chain where the token is being linked to.
+1. `destination_token_address`: The address of the token the sui coin is being linked to.
+1. `token_manager_type`: The [type of manager](#coin-management) to be deployed on the destination chain.
+1. `link_params`: An array of bytes representing an address to be used as the operator on the destination chain
+
+```rust
+public fun link_coin(
+ self: &InterchainTokenService,
+ deployer: &Channel,
+ salt: Bytes32,
+ destination_chain: String,
+ destination_token_address: vector,
+ token_manager_type: TokenManagerType,
+ link_params: vector,
+): MessageTicket {}
+```
+
+The complete linking token flow is as follows:
+
+1. Deploy your custom token on each chain
+1. [Register coin metadata](#register-coin-metadata)
+1. [Register custom coin on home chain](#register-custom-coin)
+1. [Link coin from home chain](#link-coin)
+
+## Deploy Remote Interchain Token
+
+If you are starting from scratch and want to deploy a fresh new token with cross-chain functionality built into it, you can trigger the `deploy_remote_interchain_token()` function. This function will deploy a new _Interchain Token_ on a different blockchain via a cross-chain [GMP call](https://docs.axelar.dev/dev/general-message-passing/overview/#general-message-passing).
+
+The function takes three parameters:
+
+1. `its`: The ITS object that will be updated once the new token is registered.
+1. `token`: The [token_id](#token-id) representing the token to be deployed on the destination chain.
+1. `destination_chain`: The name of the destination chain to deploy the token on.
+
+```rust
+public fun deploy_remote_interchain_token(
+ self: &InterchainTokenService,
+ token_id: TokenId,
+ destination_chain: String,
+): MessageTicket {
+ let value = self.value!(b"deploy_remote_interchain_token");
+
+ value.deploy_remote_interchain_token(token_id, destination_chain)
+}
+```
+
+Since this function makes a cross-chain call, it will return a [MessageTicket](/dev/general-message-passing/sui/gmp-contracts/#message-ticket) for the cross-chain transaction. The full implementation of the `deploy_remote_interchain_token()` can be found [here](https://github.com/axelarnetwork/axelar-cgp-sui/blob/v1.1.3/move/interchain_token_service/sources/versioned/interchain_token_service_v0.move#L178).
+
+See here for an [example](https://github.com/axelarnetwork/axelar-contract-deployments/blob/main/sui/its-example.js#L107) of how to run a cross-chain deployment for a new coin.
+
+## Interchain Transfer
+
+Once your coin has been integrated with ITS, you can use the `send_interchain_transfer()` function to send it cross-chain to another chain where it has been integrated. Sending an interchain transfer is a two-step process.
+
+The first step is to prepare the [Interchain Transfer Ticket](#interchain-ransfer-ticket) via the [prepare_interchain_transfer](#prepare-interchain-transfer) function. Once the ticket is created, you can trigger the [send_interchain_transfer](#send-interchain-transfer) function. Breaking up the transfer into a two-step process allows the package to be more flexible in the case of an upgrade.
+
+
+
+
+Other functions that return `MessageTickets` in ITS include:
+
+- `link_coin()`
+- `register_coin_metadata()`
+- `deploy_remote_interchain_token()`
+- `send_interchain_transfer()`
+
+
+
+### Prepare Interchain Transfer
+
+This will create the `InterchainTransferTicket` to be passed into the `send_interchain_transfer()`
+
+The function takes six parameters:
+
+1. `token_id`: The id of the coin being sent.
+1. `coin`: The actual [coin](https://docs.sui.io/standards/coin) being sent.
+1. `destination_chain`: The name of the chain the coin is being sent to.
+1. `destination_address`: The address on the destination chain the coin is being sent to.
+1. `metadata`: Executable data being sent along with the coin for a contract on the destination chain to handle.
+1. `source_channel`: The [channel](/dev/general-message-passing/sui/gmp-contracts/#channel) where the message is being sent to. This channel will serve as the source address for the transaction on the destination chain.
+
+```rust
+public fun prepare_interchain_transfer(
+ token_id: TokenId,
+ coin: Coin,
+ destination_chain: String,
+ destination_address: vector,
+ metadata: vector,
+ source_channel: &Channel,
+): InterchainTransferTicket {
+ interchain_transfer_ticket::new(
+ token_id,
+ coin.into_balance(),
+ source_channel.to_address(),
+ destination_chain,
+ destination_address,
+ metadata,
+ VERSION,
+ )
+}
+```
+
+
+### Why Prepare Interchain Transfer is Necessary?
+
+In EVM upgradability on the other hand, smart contracts are replaced atomically. This means that when you upgrade a contract, the proxy automatically knows that it should make a `delegatecall` to a new implementation (as the upgrade comes from swapping in a new implementation at the proxy's storage slot, making the old implementation unreachable). This means that when a package is upgraded, the shared objects created by the old package continue to exist and retain their original data structures, even as new package versions are deployed. Unlike EVM where a proxy immediately redirects all calls to the new implementation, Sui objects must explicitly manage which version of the package logic should handle their operations.
+
+If ITS were to get updated to a new version, the ITS object itself upgrades to the new version, but tickets created before the upgrade still exist with their old version stamps. To ensure backwards compatibility and prevent version mismatches, the `prepare_interchain_transfer()` function creates a `ticket` with a version stamp indicating which version of ITS was active when the ticket was created. When `send_interchain_transfer()` processes the ticket, it can check the version compatibility and either:
+
+1. Process the ticket with v0-compatible logic if it's an old ticket
+1. Process it with v1 logic if it's a new ticket
+1. Reject it if the ticket is from a newer version than the current ITS
+
+### Send Interchain Transfer
+
+With the ticket now created, you can use it with the `send_interchain_transfer()` function. Once called, `send_interchain_transfer()` will trigger the cross-chain call to send the coin from the source chain to the destination chain.
+
+The function takes three parameters:
+
+1. `its`: The ITS object that will be updated once the new coin is registered.
+1. `ticket`: The [ticket](#interchain-transfer-ticket) representing the coin transfer.
+1. `clock`: A [clock](https://docs.sui.io/references/framework/sui/clock) module that provides the time of the transfer.
+
+```rust
+public fun send_interchain_transfer(
+ self: &mut InterchainTokenService,
+ ticket: InterchainTransferTicket,
+ clock: &Clock,
+): MessageTicket {
+ let value = self.value_mut!(b"send_interchain_transfer");
+
+ value.send_interchain_transfer(
+ ticket,
+ VERSION,
+ clock,
+ )
+}
+```
+
+See here for an [example](https://github.com/axelarnetwork/axelar-contract-deployments/blob/main/sui/its-example.js#L65) of how to use the `send_interchain_transfer()`
+
+The full `send_interchain_transfer()` implementation can be found [here](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/versioned/interchain_token_service_v0.move#L212)
+
+## Receive Interchain Transfer
+
+When tokens are sent to Sui, the [Relayer Discovery](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/discovery.move) module triggers the `receive_interchain_transfer()` function on the Sui ITS module. An application must register with the `relayer_discovery` and use a `channel` they control as the destination address to receive tokens with data.
+
+The function takes four parameters:
+
+1. `its`: The ITS object that will be updated once the new coin is registered.
+1. `approved_message`: The cross-chain [message](/dev/general-message-passing/sui/sui-programs/#approvedmessage) sent with the receiving instructions for the coin.
+1. `clock`: A [clock](https://docs.sui.io/references/framework/sui/clock) module that provides the time of the transfer.
+1. `ctx`: The [transaction context](https://docs.sui.io/references/framework/sui/tx_context#sui_tx_context_TxContext) provides the necessary runtime environment for creating or modifying objects and state.
+
+```rust
+public fun receive_interchain_transfer(
+ self: &mut InterchainTokenService,
+ approved_message: ApprovedMessage,
+ clock: &Clock,
+ ctx: &mut TxContext,
+) {
+ let value = self.value_mut!(b"receive_interchain_transfer");
+
+ value.receive_interchain_transfer(approved_message, clock, ctx);
+}
+```
+
+Once the relayer triggers this function, it, in turn, triggers the [give_coin](#give-coin) function on the Coin Management program. Once `give_coin()` has run, the function will transfer the coin to the destination address.
+
+The full `receive_interchain_transfer()` can be found [here](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/versioned/interchain_token_service_v0.move#L247)
+
+### Receive Interchain Transfer With Data
+
+If the source chain sends executable metadata along with the transaction, the `receive_interchain_transfer_with_data()` function will handle that data.
+
+It takes the same parameters as the previous `receive_interchain_transfer()` function, except it also includes a `channel` parameter. The channel checks if the payload's destination address matches the channel's address, ensuring that messages with extra data are correctly routed.
+
+For the channel to be available, the package must be registered with `relayer_discovery` and use a `channel` they control as the destination address.
+
+The key difference with `receive_interchain_transfer_with_data()` is that the function `asserts` that the `data` being sent is not empty and does not simply transfer the coin to the destination address. This function is designed for transfers that carry extra information and require additional routing and validation steps, while the standard version is for simple transfers that don't include extra data and perform the transfer immediately. It is up to the caller to decide how to transfer the coin once the function returns.
+
+```rust
+public fun receive_interchain_transfer_with_data(
+ self: &mut InterchainTokenService,
+ approved_message: ApprovedMessage,
+ channel: &Channel,
+ clock: &Clock,
+ ctx: &mut TxContext,
+): (String, vector, vector, Coin) {
+ let value = self.value_mut!(b"receive_interchain_transfer_with_data");
+
+ value.receive_interchain_transfer_with_data(
+ approved_message,
+ channel,
+ clock,
+ ctx,
+ )
+}
+```
+
+See here for an [example](https://github.com/axelarnetwork/axelar-contract-deployments/blob/main/sui/its-example.js#L124) of how to receive a transfer with data.
+
+The full `receive_interchain_transfer_with_data()` implementation can be found [here](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/versioned/interchain_token_service_v0.move#L282)
+
+## Coin Management
+
+A centerpiece of the ITS design is the [Coin Management](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/types/coin_management.move) module (akin to the [token manager](/dev/send-tokens/interchain-tokens/token-manager/) contract for EVM chains). The `Coin Management` module facilitates integrating the `coin` and `ITS`. It is created before registering a coin. It encapsulates key functionalities such as minting, burning, managing balances, and enforcing [flow limits](#flow-limit) for cross‐chain operations.
+
+Coin managers can be initialized as either a [capped](#capped-management) manager or [locked](#locked-management). The module stores the following fields:
+
+1. `treasury_cap`: An optional [capability](https://docs.sui.io/standards/coin#treasury-capability) that, if present, allows minting and burning of coins.
+1. `balance`: An optional balance used when managing locked coins (i.e., already in circulation).
+1. `distributor`: An optional address authorized for minting and burning operations.
+1. `operator`: An optional address authorized to set flow limits for the coin.
+1. `flow_limit`: A structure that tracks coins' allowed inflow and outflow to control their movement.
+1. `dust`: A field (type u256) tracking leftover coins after transfers.
+
+```rust
+public struct CoinManagement has store {
+ treasury_cap: Option>,
+ balance: Option>,
+ distributor: Option,
+ operator: Option,
+ flow_limit: FlowLimit,
+ dust: u256,
+}
+```
+
+A coin management object must be created before the coin is registered with ITS.
+
+### Capped Management
+
+Capped Management types create a new `CoinManagement` with a [Treasury Cap](https://docs.sui.io/standards/coin#treasury-capability). This type of `CoinManagement` allows the minting and burning of coins, meaning when the coin is sent out of Sui, it is burned, and when it is sent back into Sui, it is minted. This is a valuable manager type if your coin is natively integrated into a number chain. In other words, when there is no canonical implementation of the coin on a single chain on which all other coins depend, Integrating a `capped` manager type involves calling the following factory function.
+
+```rust
+public fun new_with_cap(treasury_cap: TreasuryCap): CoinManagement {
+ CoinManagement {
+ treasury_cap: option::some(treasury_cap),
+ balance: option::none(),
+ distributor: option::none(),
+ operator: option::none(),
+ flow_limit: flow_limit::new(),
+ dust: 0,
+ }
+}
+```
+
+See [here](https://github.com/axelarnetwork/axelar-contract-deployments/blob/main/sui/its-example.js#L201) for an example of deploying new capped managers.
+
+### Locked Management
+
+Locked Management types Create a new `CoinManagement` with a `Balance`. The stored `Balance` can be used to take and put coins. This manager type will lock the sent coin with ITS when the coin is sent out of Sui and unlock the coin when it is sent back into the Sui ecosystem. This type of manager is very useful if Sui is the _home-chain_ for your ITS integration and you use wrapped coins on other chains that derive back to the canonical coin on Sui. Integrating the ` new_locked` manager type involves calling the following factory function.
+
+```rust
+public fun new_locked(): CoinManagement {
+ CoinManagement {
+ treasury_cap: option::none(),
+ balance: option::some(balance::zero()),
+ distributor: option::none(),
+ operator: option::none(),
+ flow_limit: flow_limit::new(),
+ dust: 0,
+ }
+}
+```
+
+See [here](https://github.com/axelarnetwork/axelar-contract-deployments/blob/main/sui/its-example.js#195) for an example of deploying a new locked manager.
+
+### Give Coin
+
+The Management module triggers the `give_coin()` function when the coin is sent into the Sui ecosystem. This function updates the incoming [flow limit](#flow-limit) and then either mints new coins (if the instance has a [treasury capability](https://docs.sui.io/standards/coin#treasury-capability)) or withdraws coins from the internal balance. It returns the coin object that is ready to be transferred.
+
+```rust
+public(module) fun give_coin(self: &mut CoinManagement, amount: u64, clock: &Clock, ctx: &mut TxContext): Coin {
+ self.flow_limit.add_flow_in(amount, clock);
+ if (has_capability(self)) {
+ self.mint(amount, ctx)
+ } else {
+ coin::take(self.balance.borrow_mut(), amount, ctx)
+ }
+}
+```
+
+### Take Balance
+
+When the coin is out of the Sui ecosystem, the Management module will trigger the `take_balance()` function. This function updates the [flow limit](#flow-limit) for an outgoing transfer and then either burns the coins (if the minting capability is available) or merges the deducted amount into the stored balance. It returns the numeric amount (as a `u64`) taken.
+
+```rust
+public(package) fun take_balance(self: &mut CoinManagement, to_take: Balance, clock: &Clock): u64 {
+ self.flow_limit.add_flow_out(to_take.value(), clock);
+ let amount = to_take.value();
+ if (has_capability(self)) {
+ self.burn(to_take);
+ } else {
+ self.balance.borrow_mut().join(to_take);
+ };
+ amount
+}
+```
+
+### Set Flow Limit
+
+To set a specific [flow limit](#flow-limit) amount, trigger the `set_flow_limit_as_token_operator()` function.
+
+The function takes four parameters:
+
+1. `self`: The module that will be updated once the `flow_limit` is set.
+1. `channel`: A reference to the `Channel` object to derive the caller's address. The address is checked to ensure that only the authorized operator can change the `flow_limit`.
+1. `token_id`: The [token id](#token-id) representing the token to be set.
+1. `limit`: An optional unsigned 64-bit integer representing the new flow limit.
+
+```rust
+public fun set_flow_limit_as_token_operator(
+ self: &mut InterchainTokenService,
+ channel: &Channel,
+ token_id: TokenId,
+ limit: Option,
+) {}
+```
+
+Note: A flow limit of `0` corresponds to no flow limit set at all. If you wish to remove your flow limit it should be set to 0. To halt transfers of your coin in/out of Sui you can set the flow limit to a near `0` value, effectively halting cross-chain transfers.
+
+## Roles
+
+The Coin Management module has set roles that can handle specific functionality.
+
+### Distributor
+
+An address set within the CoinManagement instance that is authorized to perform minting/burning operations. Only CoinManagement instances with a [treasury capability](https://docs.sui.io/standards/coin#treasury-capability) can add a distributor.
+
+#### Add Distributor
+
+The `add_distributor()` function in the [Coin Management package](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/types/coin_management.move) takes two parameters:
+
+1. `self`: The module that will be updated once the `distributor` is set.
+1. `distributor`: The address of the `distributor` to be set. The address that is added should be an [address](https://docs.sui.io/references/sui-api/sui-graphql/reference/types/objects/address) type of your Channel.
+
+```rust
+public fun add_distributor(self: &mut CoinManagement, distributor: address) {
+ assert!(self.has_treasury_cap(), EDistributorNeedsTreasuryCap);
+ self.distributor.fill(distributor);
+}
+```
+
+The `add_distributor()` function must be called before the coin is [registered](#register-coin). This function can be called by the address that owns a [Coin Management](#coin-management). However, once the coin is registered with ITS this function is no longer callable as ownership of the `Coin Management` object (which in turn owns the `Distributor` object) is passed to ITS itself. If in the future you wish to change the `Distributor` that was set before the coin was registered, you can transfer the `Distributor` with the [transfer distributor](#transfer-distributor) function.
+
+
+#### Transfer Distributor
+
+After registration, CoinManagement is owned by ITS and `add_distributor()` is no longer callable. To change/remove the distributor, call `transfer_distributorship()`. This succeeds only if `current_distributor_channel.to_address()` matches the stored distributor.
+
+The function takes four parameters:
+
+1. `self`: The module that will be updated once the `distributor` is set.
+1. `channel`: The channel that is able to update the `distributor`.
+1. `token_id`: The id of the coin that will receive the new operator.
+1. `new_distributor`: The address of the new `distributor` to be set.
+
+```rust
+public(package) fun transfer_distributorship(
+ self: &mut InterchainTokenService_v0,
+ channel: &Channel,
+ token_id: TokenId,
+ new_distributor: Option,
+) {}
+```
+
+
+### Operator
+
+An address authorized to update [flow limits](#flow-limit) for coin transfers. When setting a new flow limit, the module verifies that the caller's channel address matches the stored operator address to ensure only the operator can make that change. An operator can be registered by triggering the `add_operator()` function.
+
+
+#### Add Operator
+
+The `add_operator()` function defined in the [Coin Management package](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/types/coin_management.move) takes two parameters:
+
+1. `self`: The module that will be updated once the `operator` is set.
+1. `operator`: The address of the `operator` to be set. The address that is added should be an [address](https://docs.sui.io/references/sui-api/sui-graphql/reference/types/objects/address) type of your Channel.
+
+It is defined as follows:
+
+```rust
+public fun add_operator(self: &mut CoinManagement, operator: address) {
+ self.operator.fill(operator);
+}
+```
+
+The `add_operator()` function must be called before the coin is [registered](#register-coin). This function can be called by the address that has created the [Coin Management](#coin-management) object. However, once the coin is registered with ITS this function is no longer callable as ownership of the `Coin Management` object (which in turn owns the `Operator` object) is passed to ITS itself. If in the future you wish to change the `Operator` that was set before the coin was registered, you can transfer the `Operator` with the [transfer operator](#transfer-operator) function.
+
+#### Transfer Operator
+
+The `transfer_operatorship()` function takes four parameters:
+
+1. `self`: The module that will be updated once the new `operator` is set.
+1. `channel`: The channel that is able to update the `operator`.
+1. `token_id`: The id of the coin that will receive the new `operator`.
+1. `new_operator`: The address of the new `operator` to be set.
+
+
+```rust
+public fun transfer_operatorship(
+ self: &mut InterchainTokenService,
+ channel: &Channel,
+ token_id: TokenId,
+ new_operator: Option,
+) {}
+```
+
+
+## Flow Limit
+
+A [Flow Limit](/dev/send-tokens/interchain-tokens/flow-limit/) represents the volume of a coin that can be transferred in/out of Sui via ITS. This limit plays a critical role in maintaining network integrity and security. When coins are sent out of Sui. The flow limit logic can be found in its own [Flow Limit Module](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/types/flow_limit.move). The duration of a `flow_limit` is set to an `epoch`. An `epoch` lasts for six hours. It is calculated as follows:
+
+```rust
+const EPOCH_TIME: u64 = 6 * 60 * 60 * 1000;
+```
+
+The module has several pieces of functionality that are triggered by the [Coin Management](#coin-management) module.
+
+### Add Flow In
+
+This is triggered each time the `give_coin()` function is executed. It increments the `flow_in` value to track when the `flow_limit` is reached.
+
+```rust
+public(package) fun add_flow_in(self: &mut FlowLimit, amount: u64, clock: &Clock) {
+ if (self.flow_limit.is_none()) {
+ return
+ };
+ let flow_limit = *self.flow_limit.borrow() as u128;
+
+ update_epoch(self, clock);
+ assert!(self.flow_in + (amount as u128) < flow_limit + self.flow_out, EFlowLimitExceeded);
+ self.flow_in = self.flow_in + (amount as u128);
+}
+```
+
+### Add Flow Out
+
+This is triggered each time the `take_balance()` function is executed. It increments the `flow_out` value to track when the `flow_limit` is reached.
+
+```rust
+public(package) fun add_flow_out(self: &mut FlowLimit, amount: u64, clock: &Clock) {
+ if (self.flow_limit.is_none()) {
+ return
+ };
+ let flow_limit = *self.flow_limit.borrow() as u128;
+
+ update_epoch(self, clock);
+ assert!(self.flow_out + (amount as u128) < flow_limit + self.flow_in, EFlowLimitExceeded);
+ self.flow_out = self.flow_out + (amount as u128);
+}
+```
+
+## Token Id
+
+A `tokenId` is a unique identifier for an ITS integration. Since ITS is a permissionless service, anyone can, in theory, integrate a deployed coin. The `tokenId` differentiates between the potentially many different integrations of a coin with ITS.
+
+The module for the Sui coin id can be found [here](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/types/token_id.move).
+
+A `TokenId` is a wrapper of a coin's address.
+
+```rust
+public struct TokenId has a copy, drop, store {
+id: address,
+}
+
+```
+
+## Coin Info
+
+The coin info defines the `CoinInfo` type, which stores information about a coin:
+
+The following fields are available for CoinInfo
+
+1. `name`: The name of the coin.
+1. `symbol`: The symbol of the coin.
+1. `decimals`: The amount of decimals the coin can hold.
+1. `metadata`: The [metadata](https://docs.sui.io/references/sui-api/sui-graphql/reference/types/objects/coin-metadata) for the coin.
+
+
+ Since coins are `u64,` some conversion might need to happen when receiving
+ coins, as decimals of 18 are too large for Sui to handle.
+
+
+```rust
+public struct CoinInfo has store {
+ name: String,
+ symbol: ascii::String,
+ decimals: u8,
+ metadata: Option>,
+}
+```
+
+You can run one of two factory functionalities to create a new Coin Info module for your coin.
+
+### From Info
+
+This will create new Coin Info based on the given name, symbol, and decimals. The selection alongside the coin type will result in a unique `TokenId`.
+
+```rust
+public fun from_info(name: String, symbol: ascii::String, decimals: u8): CoinInfo {
+ CoinInfo {
+ name,
+ symbol,
+ decimals,
+ metadata: option::none(),
+ }
+}
+
+```
+
+An example of how to register a new Coin Info with `from_info()` can be found [here](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/example/sources/its/its.move#L141)
+
+### From Metadata
+
+This will create a new coin info from the given `CoinMetadata` object. This can only be done once per coin since there is only one CoinMetadata per Coin.
+
+```rust
+public fun from_metadata(metadata: CoinMetadata): CoinInfo {
+ CoinInfo {
+ name: metadata.get_name(),
+ symbol: metadata.get_symbol(),
+ decimals: metadata.get_decimals(),
+ metadata: option::some(metadata),
+ }
+}
+```
+
+## Interchain Transfer Ticket
+
+The Interchain Transfer Ticket contains a unique type to be sent for each transfer, holding all the info required for an interchain transfer. It includes the following fields:
+
+1. `token_id`: The id of the coin being sent cross-chain.
+1. `balance`: A wrapped [balance](https://docs.sui.io/references/sui-api/sui-graphql/reference/types/objects/balance) object representing the coin amount to be transferred, which is later converted to a numeric amount.
+1. `source_address`: The address initiating the transfer.
+1. `destination_chain`: The name of the blockchain where the coin is being sent to.
+1. `destination_address`: The receive address on the destination chain.
+1. `metadata`: Additional executable data to be sent with the coin.
+1. `version`: The version of ITS that is being used for this transfer.
+
+```rust
+public struct InterchainTransferTicket {
+ token_id: TokenId,
+ balance: Balance,
+ source_address: address,
+ destination_chain: String,
+ destination_address: vector,
+ metadata: vector,
+ version: u64,
+}
+
+```
+
+To create an `InterchainTransferTicket,` you can trigger the `prepare_interchain_transfer_ticket()` on ITS.
+
+```rust
+public fun prepare_interchain_transfer(
+ token_id: TokenId,
+ coin: Coin,
+ destination_chain: String,
+ destination_address: vector,
+ metadata: vector,
+ source_channel: &Channel,
+): InterchainTransferTicket {
+ interchain_transfer_ticket::new(
+ token_id,
+ coin.into_balance(),
+ source_channel.to_address(),
+ destination_chain,
+ destination_address,
+ metadata,
+ VERSION,
+ )
+}
+```
\ No newline at end of file
diff --git a/src/content/docs/dev/send-tokens/sui/register-existing-sui-token.mdx b/src/content/docs/dev/send-tokens/sui/register-existing-sui-token.mdx
new file mode 100644
index 000000000..2f1a92c0c
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/sui/register-existing-sui-token.mdx
@@ -0,0 +1,1008 @@
+import { Callout } from "../../../../../components/callout";
+
+
+# Register Existing Sui Token With Interchain Token Service
+
+
+This guide demonstrates, step-by-step, how to use [Axelar's Interchain Token Service (ITS)](/dev/send-tokens/interchain-tokens/intro/#interchain-token-service) to register an existing token on Sui and make it available for cross-chain transfers.
+
+By the end, you will be able to:
+
+1. Register an existing token on Sui with Axelar ITS.
+1. Deploy that token representation on an EVM chain (Ethereum Sepolia testnet).
+1. Transfer tokens seamlessly between Sui and the EVM chain.
+
+## Prerequisites
+
+Before starting, make sure you have the following ready:
+
+- Rust installed with the wasm32 target enabled ([installation instructions](https://www.rust-lang.org/tools/install))
+- A Sui testnet account funded with testnet tokens
+- The [Sui CLI](https://docs.sui.io/references/cli/client) installed and configured
+- A browser wallet like [Slush Wallet](https://chromewebstore.google.com/detail/slush-%E2%80%94-a-sui-wallet/opcgpfmipidbgpenhmajoajpbobppdil) to connect to Sui testnet.
+
+
+
+
+## Part 1: Understanding the Interchain Token Service
+
+The [Interchain Token Service (ITS)](https://github.com/axelarnetwork/axelar-cgp-sui/tree/main/move/interchain_token_service) is a protocol that allows tokens to move freely between different blockchains.
+
+ITS allows you to register existing tokens you own on Sui and seamlessly transfer their value across chains. This example will achieve this through a canonical token integration, meaning:
+
+- When you transfer your Sui token to another chain, ITS _locks_ the token on Sui
+- It _mints_ a corresponding wrapped token on the destination chain
+- When tokens move back to Sui, the wrapped tokens are _burned_ and the original tokens are _unlocked_
+
+
+ There can only be a single lock/unlock token manager for the token for a given integration. If the lock/unlock manager for this coin's integration is on Sui, then the coin managers for the other tokens integrated on other chains must be mint/burn.
+
+
+## Part 2: Set up your Sui ITS project
+
+To setup a new Sui project run the command:
+```bash
+sui move new its_demo
+```
+
+Among other items, this will create a `sources` folder and `move.toml` file. The `sources` folder will contain the Sui Move code for your ITS project, and the `move.toml` file will contain the configuration for your project.
+
+The three key configurations for your `move.toml` file are
+
+1. The package - The name of your package being deployed.
+1. The dependencies - The dependencies your package will need.
+1. The addresses - The address is a spot for a human readable address of the where the package is deployed.
+
+The completed `move.toml` file should look like this:
+
+```toml
+[package]
+name = "my_coin"
+edition = "2024.beta" # edition = "legacy" to use legacy (pre-2024) Move
+
+[dependencies]
+Sui = { git = "https://github.com/MystenLabs/sui.git", subdir = "crates/sui-framework/packages/sui-framework", rev = "framework/testnet" }
+
+[addresses]
+my_coin = "0x0" #0x0 is a placeholder for a package not yet deployed.
+```
+
+## Part 3: Deploy Sui Coin
+
+This part can be skipped if you already have a Sui coin deployed. For the sake of this demo we will use a very straightforward coin implementation on the Sui testnet. Worth noting that although this coin is simple, ITS is able to handle much more robust custom coin implementations as well.
+
+We will use the coin example straight from the official [Sui documentation](https://docs.sui.io/guides/developer/coins).
+
+The coin has the ability to `drop` (burn) and `mint` coins. In it's `init` function, it creates a treasury cap and metadata for the coin, and transfers the initial supply to the sender. When dealing with Sui coins, a [treasury cap](https://docs.sui.io/standards/coin#treasury-capability) is used to grant permission to mint additional coins. A coin's [metadata](https://docs.sui.io/references/sui-api/sui-graphql/reference/types/objects/coin-metadata) corresponds to an object that contains information about the coin, such as its `name`, `symbol`, and `decimals`.
+
+Once the coin is created the rest of the `init` function will freeze the metadata so that anyone can alter this vital information about the coin once it's deployed. Finally, the `treasury cap` object is transferred to the deployer, giving them sole ability to mint new coins.
+
+The `mint()` function allows the owner of the treasury cap to mint new coins and transfer them to a specified recipient.
+
+```rust
+// Declare module
+module my_coin::my_custom_coin;
+
+// Import necessary modules
+use sui::coin::{Self, TreasuryCap};
+
+//move resource type
+public struct MY_CUSTOM_COIN has drop {}
+
+fun init(witness: MY_CUSTOM_COIN, ctx: &mut TxContext) {
+ let (treasury, metadata) = coin::create_currency(
+ witness,
+ 6,
+ b"MCC",
+ b"My Custom Token",
+ b"",
+ option::none(),
+ ctx,
+ );
+ //make metadata immutable
+ transfer::public_freeze_object(metadata);
+ //transfer initial supply to sender
+ transfer::public_transfer(treasury, ctx.sender())
+}
+
+
+public fun mint(
+ treasury_cap: &mut TreasuryCap,
+ amount: u64,
+ recipient: address,
+ ctx: &mut TxContext,
+) {
+ let coin = coin::mint(treasury_cap, amount, ctx);
+ transfer::public_transfer(coin, recipient)
+}
+```
+
+
+At this point you should be able to compile your token. This can be done by running:
+
+```bash
+sui move build
+```
+
+Great! At this point you now have a compiled Sui coin. Before being able to integrate it to ITS you will need to deploy the coin to the Sui testnet.
+
+If you are unable to compile your coin, you can compare your code with the [first checkpoint](https://github.com/benjamin852/sui-its-example/tree/checkpoint1).
+
+
+## Part 4: Deploy Sui Token
+
+Sui allows you to deploy Move packages via the [Sui CLI](https://intro.sui-book.com/unit-one/lessons/5_contract_deployment.html#deploying-the-contract). Although this would work, this document will use Mysten's [JavaScript SDK](https://intro.sui-book.com/unit-one/lessons/5_contract_deployment.html#deploying-the-contract) to deploy the token and interact with deployed packages.
+
+Before building out the deployment script you will need to install the following packages.
+
+```bash
+npm i commander dotenv @mysten/sui @axelar-network/axelar-cgp-sui
+```
+
+You can create a new file to run the script by running the following command:
+
+```bash
+mkdir scripts
+touch scripts/deploy.js
+```
+
+With your packages now installed you can import the necessary modules into your `deploy.js` file.
+
+
+```javascript
+import { execSync } from 'child_process'
+import { Command } from 'commander'
+import { Transaction } from '@mysten/sui/transactions'
+```
+
+You can setup your execution environment for your script as follows
+
+```javascript
+async function run() {}
+
+const program = new Command()
+program.description('Deploy Sui Coin').action(async () => {
+ try {
+ await run()
+ } catch (err) {
+ console.error('❌ Error:', err.message || err)
+ process.exit(1)
+ }
+})
+
+program.parse(process.argv)
+```
+
+#### Get Wallet Helper
+
+To interact with the Sui testnet you will need to connect to a wallet. The following function will help you connect to your wallet and return the connected wallet address. You can do this in a separate `utils` file
+
+```bash
+mkdir utils
+touch utils/index.js
+```
+
+Then in your utils you can write the functionality to connect to your wallet.
+
+```javascript
+import { Ed25519Keypair } from '@mysten/sui/keypairs/ed25519';
+import { SuiClient } from '@mysten/sui/client';
+import 'dotenv/config';
+
+async function getWallet() {
+ const client = new SuiClient({ url: 'https://fullnode.testnet.sui.io/' });
+
+ const rawKey = process.env.PRIVATE_KEY;
+
+ if (!rawKey) {
+ console.error('PRIVATE_KEY not set in your .env');
+ process.exit(1);
+ }
+
+ const keypair = Ed25519Keypair.fromSecretKey(rawKey);
+ return [keypair, client];
+}
+```
+
+For this function to work, you must add your private key to a `.env` file in the root of your project.
+
+The `getWallet()` function will return a key-pair and a client that you can use to interact with the Sui testnet.
+
+With the `getWallet()` function now built out, you can return back the deployment script.
+
+In your `run()` function, you can trigger the `getWallet()` function:
+
+```javascript
+async function run() {
+ const [keypair, client] = await getWallet();
+ const address = keypair.getPublicKey().toSuiAddress();
+}
+```
+
+Next, you can run the `sui move build` command we ran previously. Rather than running it directly in the `cli` this time, you can run it in the script so you do not need to re-build each time in the cli. This can be done as follows
+
+```javascript
+const buildOutput = execSync(`sui move build --dump-bytecode-as-base64`, {
+encoding: 'utf-8',
+})
+```
+
+The `--dump-bytecode-as-base64` flag tells sui move build to emit a JSON blob on stdout.
+
+With the package now built, you can move on to [publishing](https://docs.sui.io/guides/developer/first-app/publish) it on chain.
+
+To do this you need to create a new [Transaction](https://sdk.mystenlabs.com/typescript/transaction-building/basics) object. You can then run the `publish` function to get the instructions to publish the package on chain. This can be done as follows
+
+```javascript
+ const tx = new Transaction()
+ const [upgradeCap] = tx.publish({ modules, dependencies })
+
+ tx.transferObjects([upgradeCap], myAddress)
+
+ console.log('🚀 Sending publish transaction…')
+```
+
+The `transferObject()` function transfers the [upgrade capability](https://docs.sui.io/concepts/sui-move-concepts/packages/upgrade) to the deployer address. To execute on chain you can run the `signAndExecuteTransaction()` function as follows from the Sui Client. This function will be signed by the key-pair that you previously generated and passed in the `tx` object. It can be written as follows:
+
+```javascript
+ const response = await client.signAndExecuteTransaction({
+ signer: keypair,
+ transaction: tx,
+ options: { showObjectChanges: true },
+ })
+ console.log('✅ Publish succeeded!')
+```
+
+The `showObjectChanges` flag will add extra logs to capture all the objects that were updated/created/destroyed throughout the transaction. You will need this flag to be set to `true` to be able to track the relevant `treasury` and new `packageId` of the coin you just deployed. This can be done as follows:
+
+```javascript
+ // Extract published package ID
+ const publishedChange = response.objectChanges.find(
+ (c) => c.type === 'published'
+ )
+
+ const treasuryChange = response.objectChanges.find(
+ (c) =>
+ c.type === 'created' && c.objectType.startsWith('0x2::coin::TreasuryCap')
+ )
+
+ const packageId = publishedChange?.packageId
+ console.log('📦 Published package ID:', packageId)
+
+ const treasuryCapId = treasuryChange.objectId
+ console.log('💰 Treasury cap:', treasuryCapId)
+```
+
+To run the deployment you can run:
+
+```bash
+node scripts/deploy.js
+```
+
+The output should be similar to the following:
+
+```bash
+node scripts/deploy.js
+📦 Building Move package
+INCLUDING DEPENDENCY Sui
+INCLUDING DEPENDENCY MoveStdlib
+BUILDING my_coin
+🚀 Sending publish transaction…
+✅ Publish succeeded!
+📦 Published package ID: 0x129245163917fd5ec0a90ad83216ca1380ddb37ccbd2be246f62e905f78c88a7
+💰 Treasury cap: 0xde83787facc01740a8c0d670ada99364395d4d9a127a723f62316238da2db671
+```
+
+Great, at this point you should now have a completed the deployment of your token. You can compare that your repo matches with [Checkpoint 2](https://github.com/benjamin852/sui-its-example/tree/checkpoint2).
+
+## Part 5: Mint Coin
+
+With the token now deployed you will need to `mint` some coins before being able to actually send a cross-chain transfer. If you are familiar with minting Sui coins feel free to skip this section.
+
+To create a new script to mint tokens you can run the following command:
+
+```bash
+touch scripts/mint.js
+```
+
+You can create the starter code for the mint script similar to the deployments script. This time however the script will require a few arguments to be passed in.
+
+The required arguments for the script are
+
+1. `coinPackageId` - The package ID of the coin you deployed.
+1. `treasury` - The treasury cap ID of the coin you deployed.
+
+You should have both of these values in the logs after running the previous script.
+
+```javascript
+import { Command } from 'commander'
+import { Transaction } from '@mysten/sui/transactions'
+import { getWallet } from '../utils/index.js'
+
+async function run(args) {}
+
+
+const program = new Command()
+program
+ .description('Mint Sui Coin')
+ .requiredOption('--coinPackageId ', 'Coin Package Id')
+ .requiredOption('--treasury ', 'Treasury')
+ .action(async (opts) => {
+ try {
+ await run(opts)
+ } catch (err) {
+ console.error('❌ Error:', err.message || err)
+ process.exit(1)
+ }
+ })
+
+program.parse(process.argv)
+```
+
+You can then begin to writeup the logic in the `run()` function, similarly to how you did in the previous script, starting off with the `getWallet()` function and creating a new `Transaction` object.
+
+```javascript
+ // In the run() function
+ const [keypair, client] = getWallet()
+ const myAddress = keypair.getPublicKey().toSuiAddress()
+ const mintTx = new Transaction()
+```
+
+Next, you will need to call the coin's `mint()` function. As a reminder, the `mint()` function on the Sui token takes in the following parameters:
+
+1. `treasury_cap` - The treasury cap object that allows minting.
+1. `amount` - The amount of coins to mint.
+1. `recipient` - The address to send the minted tokens to.
+1. `ctx` - The transaction context.
+
+```rust
+public fun mint(
+ treasury_cap: &mut TreasuryCap,
+ amount: u64,
+ recipient: address,
+ ctx: &mut TxContext,
+) {}
+```
+
+To call the `mint()` function you will need to use the [moveCall](https://sdk.mystenlabs.com/typedoc/classes/_mysten_sui.transactions.Transaction.html#movecall) function on the `Transaction` object from Sui's SDK. The `moveCall` executes a Move call and returns whatever the Sui Move call returns.
+
+Back in the `mint` script, in your `run()` function, you can create a `move call` as follows:
+
+It requires the first three params from the token's package to be passed in (the context will be injected by the Move VM).
+
+```javascript
+ // In the run() function
+ mintTx.moveCall({
+ target: `${coinPackageId}::my_custom_coin::mint`,
+ arguments: [
+ mintTx.object(treasury), // the cap you extracted
+ mintTx.pure.u64(1), // BigInt for u64
+ mintTx.pure.address(myAddress), // Sui address of the recipient
+ ],
+ })
+```
+
+With the `moveCall` added in, you need to now broadcast the transaction to Sui by running the `signAndExecuteTransaction` as you did before in the deployment script.
+
+```javascript
+ // In the run() function
+ await client.signAndExecuteTransaction({
+ signer: keypair,
+ transaction: mintTx,
+ })
+```
+
+Lastly, you can query the balance of your coin to ensure that the mint was successful. This can be done by running the `getBalance()` function from the Sui SDK.
+
+Unlike with the `mint()` you do not need to make a `moveCall` to query the balance, as no state change is being made to Sui. Instead, you can directly call the `getBalance` function on the client object. This will hits the node’s `JSON-RPC` endpoint (the [sui_getBalance()](https://www.quicknode.com/docs/sui/suix_getBalance) RPC method), which will return whatever the node has indexed for your address and coin type.
+
+
+```javascript
+ // In the run() function
+ const balance = await client.getBalance({
+ owner: myAddress,
+ coinType: `${coinPackageId}::my_custom_coin::MY_CUSTOM_COIN`,
+ })
+
+ console.log('💰 Minted successfully! New balance:', balance)
+```
+
+You can execute the `mint.js` script by running the following command:
+
+```bash
+node scripts/mint.js --coinPackageId 0x129245163917fd5ec0a90ad83216ca1380ddb37ccbd2be246f62e905f78c88a7 --treasury 0xde83787facc01740a8c0d670ada99364395d4d9a127a723f62316238da2db671
+```
+
+If successful, you should see an output similar to the following:
+
+```bash
+🚀 Sending mint transaction…
+💰 my token balance 1
+```
+
+Great! At this point you should be able to deploy a new coin, mint and confirm the balance has increased. You can compare that your repo matches with [Checkpoint 3](https://github.com/benjamin852/sui-its-example/tree/checkpoint3).
+
+## Part 6: Register Coin with ITS
+
+With your coin now deployed and mintable, you can begin the process of registering it with ITS. This will allow you to transfer the token across chains using Axelar's Interchain Token Service.
+
+This will also be done via an script, you can create the script as follows:
+
+```bash
+touch scripts/integrateAxelar.js
+```
+
+Then create the standard script boilerplate as you did in the previous scripts.
+
+```javascript
+import { Command } from 'commander'
+import { Transaction } from '@mysten/sui/transactions'
+import { getWallet } from '../utils/index.js'
+import { suiItsPackageId, suiItsObjectId } from '../utils/constants.js'
+
+async function run(args) {}
+
+const registerCoinCommand = new Command()
+registerCoinCommand
+ .description('Register Sui coin with ITS')
+ .requiredOption('--coinPackageId ', 'Coin Package Id')
+ .action(async (opts) => {
+ try {
+ await run(opts)
+ } catch (err) {
+ console.error('❌ Error:', err.message || err)
+ process.exit(1)
+ }
+ })
+
+registerCoinCommand.parse(process.argv)
+```
+
+This script will only require the `coinPackageId` as an argument, as the treasury cap is not required to register the token with ITS.
+
+In your `run()` function you can then destructure the passed in argument, get your keypair, and create a new `Transaction` object as you did in the previous script.
+
+```javascript
+// In the run() function
+const { coinPackageId } = args
+const [keypair, client] = await getWallet()
+
+const registerCoinTx = new Transaction()
+```
+
+Next you will need to create the correct `typeArgument` that you will need to pass to ITS when interacting with its functionality. This is needed to interact with the [generic](https://move-language.github.io/move/generics.html) `Move` functions in ITS. Generics in Sui (any function using `` need to have an explicitly specified object type when they're called). In our case, the `type` needing to be passed in when interacting with ITS generics will be the type of your Coin that you created in the coin package. This type can be defined as follows:
+
+```javascript
+// In the run() function
+const coinType = `${coinPackageId}::my_custom_coin::MY_CUSTOM_COIN`
+```
+
+With your `coinType` argument now available you can move on to registering the token with ITS.
+
+To register your coin with ITS you will need to trigger the `register_coin()` function on ITS. It is written as follows:
+
+```rust
+public fun register_coin(
+ self: &mut InterchainTokenService,
+ coin_info: CoinInfo,
+ coin_management: CoinManagement
+): TokenId {}
+```
+
+This function will register an existing deployed coin on Sui as the canonical token in relation to other interchain tokens deployed across other blockchains.
+
+In order to trigger this function from your script you must create the necessary `coin_info` and `coin_management` objects that the function expects.
+
+You can create the `coin_info` param in your script as follows:
+
+```javascript
+// In the run() function
+const coinInfo = registerCoinTx.moveCall({
+ target: `${suiItsPackageId}::coin_info::from_info`,
+ typeArguments: [coinType],
+ arguments: [
+ registerCoinTx.object('My Custom Token'),
+ registerCoinTx.object('MCC'),
+ registerCoinTx.object('6'),
+ ],
+})
+```
+
+This will trigger a `MoveCall` on ITS's [Coin Info](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/types/coin_info.move) module, returning an object with the certain fields pertaining to the coins metadata.
+
+Next, you can make another `MoveCall` to get the `Coin Management` object.
+
+```javascript
+// In the run() function
+const coinManagement = registerCoinTx.moveCall({
+ target: `${suiItsPackageId}::coin_management::new_locked`,
+ typeArguments: [coinType],
+ arguments: [],
+})
+```
+
+The call to ITS's [Coin Management](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/types/coin_management.move) will allow you to specify the type of [manager](/dev/send-tokens/interchain-tokens/token-manager/) you want for your coin. For this canonical integration, the `lock/unlock` manager type will suffice. This will lock your coins when you make a cross-chain call for your coin from Sui and unlock your coins when they're moved back into Sui.
+
+When passing in arguments into a Sui function if the argument is a Sui object you need to first make a query to a `Move` package to be able to pass that queried value in as an appropriate `Move` Object.
+
+With your two objects now available, you can make the `MoveCall` to the `register_coin()` function. This can be done as follows:
+
+```javascript
+// In the run() function
+registerCoinTx.moveCall({
+ target: `${suiItsPackageId}::interchain_token_service::register_coin`,
+ typeArguments: [coinType],
+ arguments: [
+ registerCoinTx.object(suiItsObjectId),
+ registerCoinTx.object(coinInfo),
+ registerCoinTx.object(coinManagement),
+ ],
+})
+```
+
+With the `MoveCall` now made, you can move on to broadcasting the transaction. For the `options`, you can include the `showEvents` param to provide the logs that you will need to get the `tokenId` from the integrated Sui Coin.
+
+```javascript
+// In the run() function
+const deployReceipt = await client.signAndExecuteTransaction({
+ signer: keypair,
+ transaction: registerCoinTx,
+ options: { showObjectChanges: true, showEvents: true },
+})
+```
+
+Great! With the call now made you can log the `tokenId` as follows
+
+
+```javascript
+// In the run() function
+const coinRegisteredEvent = deployReceipt.events.find((event) =>
+ event.type.includes('CoinRegistered')
+)
+
+const tokenId = coinRegisteredEvent.parsedJson.token_id.id
+console.log('🎯 Token ID:', tokenId)
+```
+
+You can now run the script as follows
+
+```bash
+ node scripts/integrateAxelar.js --coinPackageId 0x129245163917fd5ec0a90ad83216ca1380ddb37ccbd2be246f62e905f78c88a7
+✅ Coin registration completed
+
+🎯 Token ID: 0x291e9b4f659caeecf96e66c008b794dcce55f1b93bfc4f9ca49af54096316ebd
+```
+
+You can view your transaction [live on the Sui blockchain](https://suiscan.xyz/testnet/tx/JDrH1enDpWzcfvMso5RkdNFPVnGrSDELqderaFAeTcDB). Though this page could be overwhelming at first, the critical piece to note is the first `ObjectId` in the `Object Change` heading. For this token integration the [0x1eebd0cc85790956efbe96763ae1d19a5e548015c7735c1b7929fdc1f26942ef](https://suiscan.xyz/testnet/object/0x1eebd0cc85790956efbe96763ae1d19a5e548015c7735c1b7929fdc1f26942ef/tx-blocks) object corresponds to the [Coin Data](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/types/coin_data.move) module. In the `Coin Data` module you can see the relevant info for your [Coin Info](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/types/coin_info.move), which confirms your coin's name, symbol, and decimals. The [Coin Management](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/interchain_token_service/sources/types/coin_management.move) field contains the relevant configuration for your coin's integration to ITS. This includes the [flow limit](/dev/send-tokens/interchain-tokens/flow-limit/) value, the [operator's](/dev/send-tokens/interchain-tokens/minter-operator-roles/#operator-role) address, as well as the current balance corresponding to any assets locked that are currently bridged out of Sui. Recall, the `lockUnlock` manager type we integrated with is where those assets are be held.
+
+At this point your code should be functioning as the code in [checkpoint 4](https://github.com/benjamin852/sui-its-example/tree/checkpoint4) does.
+
+## Part 7: Deploy Interchain Token on Ethereum from Sui
+
+With your custom coin, now deployed and registered with ITS on Sui, you now need to deploy a token onto another blockchain that you will eventually bridge to/from your Sui ITS integration. ITS has built-in functionality to be able to deploy tokens on a remote chain by making a cross-chain call. This can be done by triggering the `deploy_remote_interchain_token()` function on ITS.
+
+To do this you can create a new script as follows:
+
+```bash
+touch scripts/deployRemoteToken.js
+```
+
+Then you can create the standard script boilerplate as you did in the previous scripts.
+
+```javascript
+import { Command } from 'commander'
+import { Transaction } from '@mysten/sui/transactions'
+import { getWallet } from '../utils/index.js'
+import { ethers } from 'ethers'
+import { SUI_TYPE_ARG } from '@mysten/sui/utils'
+
+async function run(args) {}
+
+const registerCoinCommand = new Command()
+registerCoinCommand
+ .description('Register Sui coin with ITS')
+ .requiredOption('--coinPackageId ', 'Coin Package Id')
+ .requiredOption('--tokenId ', 'Token Id')
+ .action(async (opts) => {
+ try {
+ await run(opts)
+ } catch (err) {
+ console.error('❌ Error:', err.message || err)
+ process.exit(1)
+ }
+ })
+
+registerCoinCommand.parse(process.argv)
+```
+
+For this script, the arguments required are the `coinPackageId` as well as a the `tokenId`, which you should have received when you successfully ran the [Integrate Axelar](/dev/send-tokens/sui/register-existing-sui-token/#part-6-register-coin-with-its) script. In the start of your `run()` function you can go through the standard steps of:
+
+1. Destructuring arguments.
+1. Obtaining your keypair and client.
+1. Creating a new `Transaction` object.
+1. Creating your `typeArgument`.
+
+```javascript
+// In the run() function
+const { coinPackageId, tokenId } = args
+const [keypair, client] = await getWallet()
+
+const deployRemoteTokenTx = new Transaction()
+const coinType = `${coinPackageId}::my_custom_coin::MY_CUSTOM_COIN`
+```
+
+Before calling the `deploy_remote_interchain_token()` function, you will need to query your coin's `tokenId` from ITS so you can pass in the `tokenId` as an appropriate `Move` object. This can be done as follows:
+
+```javascript
+// In the run() function
+const tokenIdObj = deployRemoteToken.moveCall({
+ target: `${suiItsPackageId}::token_id::from_u256`,
+ arguments: [deployRemoteToken.pure.u256(tokenId)],
+})
+```
+
+With the `tokenId` now fetched in the appropriate format, you can writeup your `MoveCall` to the `deploy_remote_interchain_token()`.
+
+
+The `deploy_remote_interchain_token()` function is written on the ITS package follows:
+
+```rust
+// In ITS Move Package
+public fun deploy_remote_interchain_token(
+ self: &InterchainTokenService,
+ token_id: TokenId,
+ destination_chain: String,
+): MessageTicket {}
+```
+
+Once executed, it make a cross-chain call to deploy a fresh [Interchain Token](/dev/send-tokens/glossary/#interchain-token) on a remote blockchain.
+
+You can call the `deploy_remote_interchain_token()` function by passing in the the
+
+1. ITS object id as a type `object`
+1. The `tokenId` from the previous step. Note: The `tokenId` will need to be passed in as the queried `MoveCall` rather than the raw `tokenId` you pass in when calling the script.
+1. Destination chain serialized as a [BCS](https://sdk.mystenlabs.com/bcs) string.
+
+You must also pass in the `coinType` as the `typeArgument` to satisfy the generic type requirement that ITS has for the `deploy_remote_interchain_token()` function.
+
+```javascript
+// In the run() function
+const deployRemoteTokenTicket = deployRemoteToken.moveCall({
+ target: `${suiItsPackageId}::interchain_token_service::deploy_remote_interchain_token`,
+ arguments: [
+ deployRemoteToken.object(suiItsObjectId),
+ tokenIdObj,
+ deployRemoteToken.pure.string('ethereum-sepolia'),
+ ],
+ typeArguments: [coinType],
+})
+```
+
+With the `deploy_remote_interchain_token()` function called, you must now call the standard [General Message Passing (GMP)](https://docs.axelar.dev/dev/general-message-passing/sui/gmp-contracts/#general-message-passing-gmp-sui-contracts) functions in order to send the cross-chain transaction.
+
+
+Unlike in EVM chains where you can make a cross-chain call simply by calling `interchainTransfer()`, Sui requires a two step process due to the nature of how upgradable contracts work in Sui. Any function from the Move package that returns a ticket, (such as `deploy_remote_interchain_token()`) must explicitly be broadcasted in a cross-chain call with `pay_gas()` and `send_message()`. More info on why the 2step call is necessary can be found [here](/dev/general-message-passing/sui/gmp-contracts/#send-message).
+
+
+
+The first of these functions is the [pay_gas()](/dev/general-message-passing/sui/gmp-contracts/#paygas) function, defined on the [Sui Gas Service](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/gas_service/sources/gas_service.move). It will be used to pay the cost of the cross-chain transaction. Further details on gas payment (including the parameters it expects) can be found in the [Sui GMP](/dev/general-message-passing/sui/gmp-tutorial/#send-message-1) tutorial. The gas payment can be written as follows:
+
+```javascript
+// In the run() function
+const unitAmount = ethers.utils.parseUnits('1', 9).toBigInt()
+
+const [gas] = deployRemoteToken.splitCoins(deployRemoteToken.gas, [
+ unitAmount,
+])
+
+deployRemoteToken.moveCall({
+ target: `${gasServicePackageId}::gas_service::pay_gas`,
+ typeArguments: [SUI_TYPE_ARG],
+ arguments: [
+ deployRemoteToken.object(gasServiceObjectId),
+ deployRemoteTokenTicket,
+ gas,
+ deployRemoteToken.object(keypair.getPublicKey().toSuiAddress()),
+ deployRemoteToken.pure.string(''),
+ ],
+})
+```
+
+Note: The gas payment passes in the `generic` `SUI_TYPE_ARG` as the type argument, as the gas payment is done in Sui via the native Sui coin, so a different type is passed in to handle the `generic`.
+
+With the gas payment now made, the final step is to trigger the `send_message()` function defined on the [Sui Gateway](https://github.com/axelarnetwork/axelar-cgp-sui/blob/main/move/axelar_gateway/sources/gateway.move). As with the `pay_gas()` further reading on this topic can be found in the [GMP demo](/dev/general-message-passing/sui/gmp-tutorial/#send-message)
+
+The call to `send_message()` can be made as follows:
+
+```javascript
+ deployRemoteToken.moveCall({
+ target: `${gatewayPackageId}::gateway::send_message`,
+ arguments: [
+ deployRemoteToken.object(gatewayObjectId), // &Gateway
+ deployRemoteTokenTicket, // MessageTicket
+ ],
+ })
+```
+
+With the `pay_gas()` and `send_message()` calls now made, your script can make the cross-chain call to your destination chain to deploy the remote ERC20 token.
+
+At this point the final step is to broadcast the transaction to Sui by running the `signAndExecuteTransaction` as you did in the previous scripts. This can be done as follows:
+
+```javascript
+// In the run() function
+const deployReceipt = await client.signAndExecuteTransaction({
+ signer: keypair,
+ transaction: deployRemoteToken,
+ options: { showObjectChanges: true, showEvents: true },
+})
+
+console.log('✅ Remote token deployment completed:', deployReceipt)
+```
+
+You can now run the script by calling the following command:
+
+```bash
+node scripts/deployRemoteToken.js --coinPackageId 0x129245163917fd5ec0a90ad83216ca1380ddb37ccbd2be246f62e905f78c88a7 --tokenId 0x291e9b4f659caeecf96e66c008b794dcce55f1b93bfc4f9ca49af54096316ebd
+```
+
+If executed successfully the script should return the following logs:
+
+```bash
+🚀 Deploying remote interchain token...
+✅ Remote token deployment completed: {
+ digest: '2GffLMzzsXMCDMs4AhhiR6txFGefmtFBqtnUh7infcq6',
+ events: [
+ ...
+ ]
+```
+
+The live [cross-chain](https://testnet.axelarscan.io/gmp/2GffLMzzsXMCDMs4AhhiR6txFGefmtFBqtnUh7infcq6) call should now be visible on Axelarscan and you should now have a token deployed on your specified destination chain.
+
+You can confirm your code is up to date with the [Checkpoint 5](https://github.com/benjamin852/sui-its-example/tree/checkpoint5)
+
+## Part 8: Transfer Tokens Between Sui and EVM
+
+The final step is to now send a cross-chain transfer between your two deployed tokens. You should have a non-zero balance for your coin in your wallet from the `mint` script that you ran earlier.
+
+You can create your final script to transfer your token the same way you did with the previous scripts
+
+```bash
+touch scripts/interchainTransfer.js
+```
+
+The interchain transfer script will require six different arguments to be passed in.
+
+1. `destinationChain` - The destination chain you want to transfer to (e.g. `ethereum-sepolia`)
+2. `destinationAddress` - The address on the destination chain you want to transfer to.
+3. `coinPackageId` - The package ID of the coin you deployed.
+4. `tokenId` - The token ID of the coin you registered with ITS.
+5. `treasuryCap` - The treasury cap ID of the coin you deployed.
+6. `amount` - The amount of tokens you want to transfer.
+
+You should by now have access to all these values from the logs of your previous scripts.
+
+Add the standard script boilerplate to your `interchainTransfer.js` file
+
+```javascript
+import { Command } from 'commander'
+import { Transaction } from '@mysten/sui/transactions'
+import { getWallet } from '../utils/index.js'
+import { ethers } from 'ethers'
+import { SUI_TYPE_ARG } from '@mysten/sui/utils'
+import { SUI_PACKAGE_ID, CLOCK_PACKAGE_ID } from '@axelar-network/axelar-cgp-sui'
+import {
+ suiItsPackageId,
+ suiItsObjectId,
+ gasServiceObjectId,
+ gatewayPackageId,
+ gasServicePackageId,
+} from '../utils/constants.js'
+
+
+
+async function run(args) {}
+
+const interchainTransferCommand = new Command()
+interchainTransferCommand
+ .description('Transfer coin from Sui to Ethereum with ITS')
+ .requiredOption('--coinPackageId ', 'Coin Package Id')
+ .requiredOption('--tokenId ', 'The ITS token id')
+ .requiredOption(
+ '--destinationChain ',
+ 'The destination chain'
+ )
+ .requiredOption(
+ '--destinationAddress ',
+ 'The destination address'
+ )
+ .requiredOption('--amount ', 'The amount of coins to be sent'),
+ .requiredOption('--coinObjectId ', 'The coin object Id')
+ .action(async (opts) => {
+ try {
+ await run(opts)
+ } catch (err) {
+ console.error('❌ Error:', err.message || err)
+ process.exit(1)
+ }
+ })
+
+interchainTransferCommand.parse(process.argv)
+```
+
+
+You can then destructure the passed in arguments, get your key-pair and client, and create a new `Transaction` object as you did in the previous scripts.
+
+```javascript
+// In the run() function
+const {
+ coinPackageId,
+ tokenId,
+ destinationChain,
+ destinationAddress,
+ amount,
+ coinObjectId
+} = args
+
+const [keypair, client] = await getWallet()
+
+const interchainTransferTx = new Transaction()
+const coinType = `${coinPackageId}::my_custom_coin::MY_CUSTOM_COIN`
+```
+
+To make an [interchain_transfer()](/dev/send-tokens/sui/intro/#send-interchain-transfer) call you must first generate a `ticket` by calling the `prepare_interchain_transfer()` function on ITS. This will generate a ticket that can be used to send the transfer across chains. More info on why the two step process for sending an interchain transfer is necessary can be found in the [prepare_interchain_transfer()](/dev/send-tokens/sui/intro/#why-prepare-interchain-transfer-is-necessary) doc.
+
+The `prepare_interchain_transfer()` call will take in several parameters that must be obtained first.
+
+The first of these parameters is the `tokenId`. To obtain the `tokenId` in the required format needed for the `prepare_interchain_transfer()` call, you will need to make a `moveCall` to the ITS package. This can be done as follows:
+
+```javascript
+// In the run() function
+const tokenIdObj = interchainTransferTx.moveCall({
+ target: `${suiItsPackageId}::token_id::from_u256`,
+ arguments: [interchainTransferTx.pure.u256(tokenId)],
+})
+```
+
+Next, you need to fetch the `source_channel`. The [channel](/dev/general-message-passing/sui/intro/#channels) that is generated will be used as the `sourceAddress` when the transaction arrives on the destination chain. You can obtain your `Move` formatted channel as follows.
+
+```javascript
+// In the run() function
+const gatewayChannelId = interchainTransferTx.moveCall({
+ target: `${gatewayPackageId}::channel::new`,
+})
+```
+
+With the two custom Move types now available you can move on to providing the rest of the arguments for the `prepare_interchain_transfer()` function. The generic `Coin` argument that the `prepare_interchain_transfer()` expects will send the entire balance of the `Coin` object that is sent to it. For example, if you previously minted 100 coins in your `Mint` script you cannot specify an `amount` to send, in other words, if you supply the minted coin object to the `prepare_interchain_transfer()` script it will send the entire 100 coins, even if you only wanted to send 50 coins. To get around this issue you can use the [splitCoins()](https://docs.sui.io/concepts/transactions/prog-txn-blocks/#splitcoins) function to create a new `Coin` to pass in with the exact amount that you actually want to send. This can be done as follows:
+
+```javascript
+// In the run() function
+const [coinsToSend] = interchainTransferTx.splitCoins(coinObjectId, [amount])
+```
+
+The final configuration is to specify the `destination_address`. In the [prepare_interchain_transfer()](/dev/send-tokens/sui/intro/#prepare-interchain-transfer) function signature the `destination_address` is expecting a `vector` rather than a plain `String`. To obtain the `vector` in your script you need to use `ethers.utils.arrayify()` to hex-decode the `0x` string into a `Uint8Array` of 20 raw bytes, then pass that into your call as a `vector`.
+
+Start by obtaining the `Uint8Array` with the available ethers helpers. This will represent your destination address as a raw 20 byte value. This value will be passed in as a vector when calling `prepare_interchain_transfer()`.
+
+```javascript
+// In the run() function
+const destRaw = ethers.utils.arrayify(destinationAddress)
+```
+
+You now can begin to create your `Move` call to `prepare_interchain_transfer()`. For this call you will need to pass in the `tokenIdObj`, `coinsToSend`, and `gatewayChannelId` objects you had created before. You can also pass in the `destinationChain` as a pure `String`. The destination address should now be passed in as a `vector` using the `destRaw` object you created earlier. The `metadata` field can passed in as an empty `String` as we will not be sending any executable data along with this interchain transfer call.
+
+```javascript
+// In the run() function
+const ticket = interchainTransferTx.moveCall({
+ target: `${suiItsPackageId}::interchain_token_service::prepare_interchain_transfer`,
+ typeArguments: [coinType],
+ arguments: [
+ tokenIdObj,
+ coinsToSend,
+ interchainTransferTx.pure.string(destinationChain),
+ interchainTransferTx.pure.vector('u8', destRaw),
+ interchainTransferTx.pure.string('0x'),
+ gatewayChannelId,
+ ],
+})
+```
+
+Once your script runs you should now receive a ticket that you can pass in to your [send_interchain_transfer()](/dev/send-tokens/sui/intro/#send-interchain-transfer) call. Let's go ahead and do that:
+
+```javascript
+// In the run() function
+const interchainTransferTicket = interchainTransferTx.moveCall({
+ target: `${suiItsPackageId}::interchain_token_service::send_interchain_transfer`,
+ typeArguments: [coinType],
+ arguments: [
+ interchainTransferTx.object(suiItsObjectId),
+ ticket,
+ interchainTransferTx.object(SUI_CLOCK_OBJECT_ID),
+ ],
+})
+```
+
+Notice, this call to `send_interchain_transfer()` is a lot more straightforward than the previous call to create the ticket. It requires the object id of the deployed ITS package, the ticket that you just created, and Sui's [clock object](https://docs.sui.io/references/framework/sui/clock) for calculating time. The clock object can be added to your `constants.js` file as follows
+
+```javascript
+// In the constants.js file
+export const SUI_CLOCK_OBJECT_ID = '0x6';
+```
+
+Great, next you must call the `pay_gas()` and `send_message()` functions as you did in your previous cross-chain calls.
+
+These will be very similar to how you called them in your previous script. Notice in these calls the `ticket` that you pass in is not the `ticket` from the `prepare_interchain_transfer()` function, rather it is the ticket generated from the `send_interchain_transfer()` function call.
+
+```javascript
+// In the run() function
+interchainTransferTx.moveCall({
+ target: `${gasServicePackageId}::gas_service::pay_gas`,
+ typeArguments: [SUI_TYPE_ARG],
+ arguments: [
+ interchainTransferTx.object(gasServiceObjectId),
+ interchainTransferTicket,
+ gas,
+ interchainTransferTx.object(keypair.getPublicKey().toSuiAddress()),
+ interchainTransferTx.pure.string(''),
+ ],
+})
+
+interchainTransferTx.moveCall({
+ target: `${gatewayPackageId}::gateway::send_message`,
+ arguments: [
+ interchainTransferTx.object(gatewayObjectId),
+ interchainTransferTicket,
+ ],
+})
+```
+
+The final `moveCall` that must be made before broadcasting this transaction is to destroy the channel was created to send the message. This can be done as follows.
+
+```javascript
+// In the run() function
+interchainTransferTx.moveCall({
+ target: `${gatewayPackageId}::channel::destroy`,
+ arguments: [interchainTransferTx.object(gatewayChannelId)],
+})
+```
+
+The object must be destroyed as in Move every object must be explicitly handled, the VM will not allow you to simply leave an object unused in an open transaction.
+
+
+Your options are either to transfer, share, or destroy the object. Since you will no longer need the object, destroying it is the most cost efficient and safest way to handle the object.
+
+
+Now with the instruction to destroy the unused object destroyed, you can broadcast the transaction and log the transaction digest.
+
+```javascript
+// In the run() function
+const receipt = await client.signAndExecuteTransaction({
+ signer: keypair,
+ transaction: interchainTransferTx,
+ options: { showObjectChanges: true },
+})
+
+console.log('🧾 Transaction digest:', receipt.digest)
+```
+
+Great! Your script can now be run as follows
+
+```bash
+ node scripts/interchainTransfer.js --coinPackageId 0x129245163917fd5ec0a90ad83216ca1380ddb37ccbd2be246f62e905f78c88a7 --tokenId 0x291e9b4f659caeecf96e66c008b794dcce55f1b93bfc4f9ca49af54096316ebd --destinationChain "ethereum-sepolia" --destinationAddress "0xc5DcAC3e02f878FE995BF71b1Ef05153b71da8BE" --amount 1 --coinObjectId 0x3094b9c7c131ec18b35e41566615d45ccdb1f6242e71adedd8b2d971b362a5be
+```
+With the following output in your logs
+
+```bash
+🚀 interchain transfer via ITS
+🧾 Transaction digest: 8msndctx8W5zoef7j6ZueypPzCX2dTkYQzU7VWBMkGGo
+```
+
+This interchain transfer can be viewed on the [Axelarscan](https://testnet.axelarscan.io/gmp/8msndctx8W5zoef7j6ZueypPzCX2dTkYQzU7VWBMkGGo) block explorer.
+
+You can view the completed code here at the [final checkpoint](https://github.com/benjamin852/sui-its-example/tree/main).
+
+## Conclusion
+
+In this guide you have deployed a fresh new custom coin on the Sui blockchain, you have integrated that coin with Axelar's Interchain Token Service and successfully made multiple cross-chain transactions to deploy a remote token on Ethereum and even transfer your integrated token from Sui to Ethereum. Once transferred out of Sui your token will be locked with your token's Token Manager contract on Sui, it will be unlocked when the token is sent back from Ethereum to Sui.
+
+This guide just scratches the service of the exciting possibilities that Axelar now offers the Sui ecosystem. For simpler integrations with non-custom tokens to Sui we highly encourage you to explore the Axelar [ITS portal](https://interchain.axelar.dev/), which offers a no-code solution for integrating assets to ITS. We would also love to see more advanced customized tokens, such as stablecoins integrated to ITS from Sui. For any open questions please reach out at our [support channel on Github](https://github.com/axelarnetwork/support/issues).
+
diff --git a/src/content/docs/dev/send-tokens/xrpl/xrpl-its.mdx b/src/content/docs/dev/send-tokens/xrpl/xrpl-its.mdx
new file mode 100644
index 000000000..f81edc5c5
--- /dev/null
+++ b/src/content/docs/dev/send-tokens/xrpl/xrpl-its.mdx
@@ -0,0 +1,126 @@
+
+# XRPL Interchain Token Service
+
+The XRPL Blockchain is unique in comparison to other blockchains integrated with Axelar. Unlike other blockchains, XRPL does not support smart contracts. As such there is no Interchain Token Service contract deployed on the chain the way there is with other EVM and non-EVM blockchain integrations.
+
+## XRPL Gateway
+
+The integration leverages the [XRPL Multisig Signing](https://xrpl.org/docs/concepts/accounts/multi-signing) account type to facilitate token transfers. The [gateway](https://github.com/commonprefix/axelar-amplifier/blob/xrpl/contracts/xrpl-multisig-prover/src/xrpl_multisig.rs) is controlled by the [Axelar Verifier set](https://axelarscan.io/verifiers).
+
+The testnet address for the XRPL Gateway is: [rNrjh1KGZk2jBR3wPfAQnoidtFFYQKbQn2](https://testnet.xrpl.org/accounts/rNrjh1KGZk2jBR3wPfAQnoidtFFYQKbQn2).
+
+The mainnet address for the XRPL Gateway is: [rfmS3zqrQrka8wVyhXifEeyTwe8AMz2Yhw](https://livenet.xrpl.org/accounts/rfmS3zqrQrka8wVyhXifEeyTwe8AMz2Yhw).
+
+Axelar's integration to XRPL allows for the cross-chain transfer of both the XRPL native token (XRP itself) as well as custom tokens ([IOU](https://learn.xrpl.org/glossary/iou/)).
+
+
+### Transfer Token
+
+The interchain transfer flow is similar to that of the regular [GMP flow](/dev/general-message-passing/xrpl/xrpl-gmp/). As with the regular GMP flow, users will be sending a [payment transaction](https://xrpl.org/docs/references/protocol/transactions/types/payment) to the Gateway account. The main difference is that the `MessageType` being sent to the Gateway is an `interchain_transfer` message type instead of a `call_contract` message.
+
+When transferring a token out of XRPL you will be sending the token from your XRPL account to the Gateway contract. The Gateway will be the custodian of your token on XRPL while it is sent via ITS hub to the destination chain until is bridged back to XRPL. Sending a token will be similar to sending a regular GMP message in that the information that is sent to the Gateway (and eventually to ITS hub) will need to be specified in the [memo](https://xrpl.org/docs/references/protocol/transactions/common-fields#memos-field) field of the transaction.
+
+What needs to be specified in the `memo` is the following:
+
+1. `type`: The type of the transaction (which will be `interchain_transfer`)
+1. `destination_address`: The address of the destination contract on the destination chain.
+1. `destination_chain`: The name of the destination chain.
+1. `gas_fee_amount`: The amount to be used to cover the the [cross-chain transaction fees](/dev/gas-service/intro/).
+1. `payload`: A message to be sent along with the cross-chain asset transfer. This parameter is only needed if you are sending a gmp message, can be ignored if you are simply sending a token without an executable message.
+
+Each of the previously mentioned fields will be passed into the memo as a `MemoType` as an encoded hex. You can then specify the value for each of these fields in the `MemoData` field, also encoded in hex.
+
+A full `JSON` example of the entire required XRPL Interchain Transfer fields can be as follows:
+
+```json
+{
+ TransactionType: "Payment",
+ Account: user.address,
+ Amount: "1000000", // (1 xrp)
+ // Amount: { // alternatively, an IOU token amount can be used to cover gas fees
+ // currency: "ABC", // IOU's currency code
+ // issuer: "r4DVHyEisbgQRAXCiMtP2xuz5h3dDkwqf1", // IOU issuer's account address
+ // value: "1" // IOU amount to bridge (in this case, 1 ABC.r4DVH), *including* gas fee amount
+ // },
+ Destination: gateway.address,
+ Memos: [
+ {
+ Memo: {
+ MemoType: "74797065", // hex("msg type")
+ MemoData: "696e746572636861696e5f7472616e73666572" // hex("interchain_transfer")
+ },
+ },
+ {
+ Memo: {
+ MemoType: "64657374696e6174696f6e5f61646472657373", // hex("destination_address")
+ MemoData: "30413930633041663142303766364143333466333532303334384462666165373342446133353845" // hex("0A90c0Af1B07f6AC34f3520348Dbfae73BDa358E"), in this case: (0x is omitted)
+ },
+ },
+ {
+ Memo: {
+ MemoType: "64657374696E6174696F6E5F636861696E", // hex("destination_chain")
+ MemoData: "7872706c2d65766d2d6465766e6574", // destination chain, hex encoded - hex("xrpl-evm-devnet"), in this case
+ },
+ },
+ {
+ Memo: {
+ MemoType: "6761735f6665655f616d6f756e74", // hex("gas_fee_amount")
+ MemoData: "30", // amount of tokens to allocate to gas fees
+ },
+ },
+ { // Only include this Memo object when performing a GMP call:
+ Memo: {
+ MemoType: "7061796c6f6164", // hex("payload")
+ // abi-encoded payload/data with which to call the Executable destination contract address:
+ MemoData: "0000000000000000000000000000000000000000000000000000000000000020000000000000000000000000000000000000000000000000000000000000000e474d5020776f726b7320746f6f3f000000000000000000000000000000000000",
+ },
+ },
+ ],
+}
+```
+
+### Example
+
+A full example can be found [here](https://github.com/axelarnetwork/axelar-contract-deployments/blob/main/xrpl/interchain-transfer.js).
+
+The example makes use of the [XRPL Client library](https://www.npmjs.com/package/xrpl)
+
+The XRPL client simplifies the process of connecting to the XRPL network, building transactions, signing them, and submitting them for processing. Key components of the XRPL client include:
+
+The key function in this example is the `interchainTransfer()` function written out as follows.
+
+```js
+async function interchainTransfer(_config, wallet, client, chain, options, args) {
+ await client.sendPayment(
+ wallet,
+ {
+ destination: chain.contracts.InterchainTokenService.address,
+ amount: parseTokenAmount(args.token, args.amount), // token is either "XRP" or "."
+ memos: [
+ { memoType: hex('type'), memoData: hex('interchain_transfer') },
+ { memoType: hex('destination_address'), memoData: hex(args.destinationAddress.replace('0x', '')) },
+ { memoType: hex('destination_chain'), memoData: hex(args.destinationChain) },
+ { memoType: hex('gas_fee_amount'), memoData: hex(options.gasFeeAmount) },
+ ...(options.payload ? [{ memoType: hex('payload'), memoData: options.payload }] : []),
+ ],
+ },
+ options,
+ );
+}
+```
+
+This function constructs the `memo` that will be used for the transaction, passing in the `type`, `destination_address`, `destination_chain`, and `gas_fee_amount`. The [request](https://js.xrpl.org/classes/Client.html#request) functionality of the XRPL client is then used to submit a [signed](https://js.xrpl.org/classes/Wallet.html#sign) transaction.
+
+To interact with the example run the following command
+
+```bash
+node xrpl/interchain-transfer.js -e testnet -n xrpl XRP 1 xrpl-evm 0x312dba807EAE77f01EF3dd21E885052f8F617c5B --gasFeeAmount 100000
+```
+
+This will send an ITS transfer to the `0x312dba807EAE77f01EF3dd21E885052f8F617c5B` address on the `XRPL-EVM` chain.
+
+Once the command is run you should as a [transaction](https://testnet.axelarscan.io/gmp/0x8032a4695f4b663a7699da81760997baabb663dea4afc25b78b3434553fcd09d) on the Axelarscan explorer where you can track the entire cross-chain transaction.
+
+#### Insufficient Gas Error
+
+In the event of an `insufficient gas` error, you can unblock the underfunded transaction by running the [Add Gas](/dev/general-message-passing/xrpl/xrpl-gmp/#add-gas) top up the missing funds.
\ No newline at end of file
diff --git a/src/pages/dev/general-message-passing/solidity-utilities.mdx b/src/content/docs/dev/solidity-utilities.mdx
similarity index 92%
rename from src/pages/dev/general-message-passing/solidity-utilities.mdx
rename to src/content/docs/dev/solidity-utilities.mdx
index fee298704..55ac73e56 100644
--- a/src/pages/dev/general-message-passing/solidity-utilities.mdx
+++ b/src/content/docs/dev/solidity-utilities.mdx
@@ -1,8 +1,8 @@
# Solidity utilities
-import { Callout } from '/src/components/callout'
+import { Callout } from "/src/components/callout";
-To facilitate interchain development, we have provided some Solidity utilites. These can be found [here](https://github.com/axelarnetwork/axelar-gmp-sdk-solidity). Each of these is described below, along with their proposed use. To further assist with the development process the [Axelar Chain's Config](https://www.npmjs.com/package/@axelar-network/axelar-chains-config) package has been made available to provide easy access to all the relevant Axelar configurations on each blockchain Axelar is available on.
+To facilitate interchain development, we have provided some Solidity utilities. These can be found [here](https://github.com/axelarnetwork/axelar-gmp-sdk-solidity). Each of these is described below, along with their proposed use. To further assist with the development process the [Axelar Chain's Config](https://www.npmjs.com/package/@axelar-network/axelar-chains-config) package has been made available to provide easy access to all the relevant Axelar configurations on each blockchain Axelar is available on.
Note: When deploying a contract with this tool, the msg.sender in the constructor of the app's contract will be the deployer contract address and not the wallet address. So msg.sender should not be used for setting the owner etc. when using these. Instead it should be passed in as a constructor arg
@@ -32,7 +32,7 @@ In order to pass in data for a contract's constructor arguments you must encode
For example to deploy a contract with a constructor that takes in two arguments, a `uint256` and an `address`, you could call the `deploy()` function as follows:
-```
+```solidity
function deployContract() external {
Create3Deployer.deploy(
keccak256(bytes("")),
@@ -74,7 +74,7 @@ For those who may be using [Create2 Deployer](https://github.com/axelarnetwork/a
#### Create2Deployer JS
-The above can be used directly, but we also provide a script to execute this functionality from a Jasvscript file. Simply import [`create2Deployer.js`](https://github.com/axelarnetwork/axelar-gmp-sdk-solidity/blob/main/scripts/create2Deployer.js). The following methods are exported from from the `create2Deployer.js` file:
+The above can be used directly, but we also provide a script to execute this functionality from a JavaScript file. Simply import [`create2Deployer.js`](https://github.com/axelarnetwork/axelar-gmp-sdk-solidity/blob/main/scripts/create2Deployer.js). The following methods are exported from from the `create2Deployer.js` file:
- `async estimateGasForDeploy(contractJson, args = [])`: estimates the gas needed to deploy a contract with a certain `contractJson` and `args`
- `async estimateGasForDeployAndInit(contractJson, args = [], initArgs = [])`: estimates the gas needed to deploy a contract with a certain `contractJson` and `args`, and to have the `init(...initArgs)` called as part of the deployment.
diff --git a/src/content/docs/dev/what-is-mobius-development-stack.mdx b/src/content/docs/dev/what-is-mobius-development-stack.mdx
new file mode 100644
index 000000000..651cf0e42
--- /dev/null
+++ b/src/content/docs/dev/what-is-mobius-development-stack.mdx
@@ -0,0 +1,20 @@
+# What is Mobius Development Stack?
+
+Axelar [MDS](https://www.axelar.network/blog/mobius-development-stack-launch) is a suite of open tools and protocols that unlock an entirely new omnichain design space. MDS pioneers a new interoperability standard leveraging enhanced AXL token utility to power infinite security and scalability across Web3. For the first time, applications can connect easily to users and logic anywhere on the internet – maintaining verified and open properties end-to-end.
+
+With Axelar MDS, the possibilities extend far beyond simple bridges or oracles. A user could send a message on Telegram that rebalances a vault on Sui, which in turn interacts with DeFi protocols on Arbitrum and a financial institution's private blockchain. This level of integration and interoperability opens up a new world of possibilities for decentralized applications.
+
+
+
+With one connection, infinite possibilities.
+
+The three main components of Axelar MDS are:
+
+- [Interchain Amplifier](/dev/amplifier/chain-integration/): Now on mainnet, a simple, permissionless way to connect your chain with the Axelar network and its interconnected chains. It enables dynamic, customizable integrations, with chains like Sui, Aptos, and Solana cued up to connect.
+- [Interchain Token Service (ITS)](/dev/send-tokens/interchain-tokens/intro/): An institutional-grade set of tokenization tools that replace bridges completely, enabling the minting and managing of tokens across any connected blockchain. With ITS, tokens can move cross-chain natively while maintaining full functionality and fungibility.
+- [Axelar Virtual Machine (AVM)](https://www.axelar.network/blog/axelar-virtual-machine-future-of-interoperability) underpins Amplifier and ITS to enable smart contract logic at the cross-chain layer. This opens doors for a new generation of multichain developer tools and sophisticated dApps. Ethereum introduced programmable money; Axelar introduces programmable interoperability.
+
+Plus these additional features, combining to create the most complete interoperability platform on the market:
+
+- Flexible, augmented economic security: connections to ETH (via [EigenLayer](https://www.eigenlayer.xyz/) and other exogenous collateral adds a layer of customizability to Interchain Amplifier, which already allows custom configuration of security for new integrations.
+- Open interoperability interface built in collaboration with OpenZeppelin and integrated into [OpenZeppelin's](https://www.openzeppelin.com/) leading smart-contract libraries. Developers adopting these open-source semantics can plug in any interoperability technology.
diff --git a/src/pages/learn/axlusdc.mdx b/src/content/docs/learn/axlusdc.mdx
similarity index 76%
rename from src/pages/learn/axlusdc.mdx
rename to src/content/docs/learn/axlusdc.mdx
index 024fa8eb4..88ac7be21 100644
--- a/src/pages/learn/axlusdc.mdx
+++ b/src/content/docs/learn/axlusdc.mdx
@@ -1,33 +1,35 @@
# What is axlUSDC
-* axlUSDC is a wrapped, multi-chain representation of USDC, a dollar stablecoin.
+- axlUSDC is a wrapped, multi-chain representation of USDC, a dollar stablecoin.
-* For each unit of axlUSDC, there is a unit of USDC locked in an Axelar Gateway on Ethereum.
+- For each unit of axlUSDC, there is a unit of USDC locked in an Axelar Gateway on Ethereum.
-* axlUSDC is secured by a dynamic validator set running delegated Proof-of-Stake, which holds key shares in the Axelar Gateways via multi-party cryptography.
+- axlUSDC is secured by a dynamic validator set running delegated Proof-of-Stake, which holds key shares in the Axelar Gateways via multi-party cryptography.
-* Acquire axlUSDC in three ways:
+- Acquire axlUSDC in three ways:
- * Swap via liquid pairs on [any of the DEXs listed here](https://axelar.network/blog/liquidity-pools-for-bridged-assets-via-axelar).
- * Swap via [Squid](https://app.squidrouter.com/), a cross-chain liquidity router built on Axelar.
- * Mint via [Satellite](https://satellite.money/), a cross-chain bridge built by Axelar
+ - Swap via liquid pairs on [any of the DEXs listed here](https://axelar.network/blog/liquidity-pools-for-bridged-assets-via-axelar).
+ - Swap via [Squid](https://app.squidrouter.com/), a cross-chain liquidity router built on Axelar.
+ - Mint via [Satellite](https://satellite.money/), a cross-chain bridge built by Axelar
## USDC and axlUSDC
+
USDC is the ticker for [USD Coin](https://www.circle.com/en/usdc). It's a stablecoin, pegged to the US dollar, issued by Circle, a US company. So, what is axlUSDC, why do we need it, and how can you get it? This post will briefly explain.
USDC is issued on Ethereum – but dApps and users in other ecosystems also value the stablecoin's properties. Many of them use axlUSDC, a wrapped version of USDC that can travel between chains, as a multi-chain stablecoin.
-In brief, axlUSDC is generated via [cross-chain bridges](https://axelar.network/blog/cross-chain-bridges-benefits-limitations-risks). These dApps accept a deposit of USDC at an Axelar Gateway on Ethereum, and mint an equivalent amount of axlUSDC on the destination chain (minus fees).
+In brief, axlUSDC is generated via [cross-chain bridges](https://axelar.network/blog/cross-chain-bridges-benefits-limitations-risks). These dApps accept a deposit of USDC at an Axelar Gateway on Ethereum, and mint an equivalent amount of axlUSDC on the destination chain (minus fees).
Two key points to understand what axlUSDC is and how it can be used:
-* For every unit of axlUSDC, there is a unit of USDC locked in [a Gateway on Ethereum](https://etherscan.io/address/0x4f4495243837681061c4743b74b3eedf548d56a5#tokentxns).
-* Once minted, axlUSDC can flow from chain to chain, without going back through Ethereum.
+- For every unit of axlUSDC, there is a unit of USDC locked in [a Gateway on Ethereum](https://etherscan.io/address/0x4f4495243837681061c4743b74b3eedf548d56a5#tokentxns).
+- Once minted, axlUSDC can flow from chain to chain, without going back through Ethereum.
+
+You can reference [Gateway addresses on various EVM chains and the token addresses of axlUSDC](/resources/contract-addresses/mainnet/).
-You can reference [Gateway addresses on various EVM chains and the token addresses of axlUSDC](/resources/mainnet).
+## How is axlUSDC secured?
-## How is axlUSDC secured?
-Like all Axelar-wrapped assets, axlUSDC's security depends on a dynamic validator set (numbering 70 at this writing), running delegated proof-of-stake. In other words, Axelar secures cross-chain communication using the same approach as many of the chains it connects.
+Like all Axelar-wrapped assets, axlUSDC's security depends on a dynamic validator set (numbering 70 at this writing), running delegated proof-of-stake. In other words, Axelar secures cross-chain communication using the same approach as many of the chains it connects.
Units of axlUSDC are minted when a user deposits USDC into a Gateway contract on the Ethereum chain. Axelar's decentralized validator set secures these Gateways via key shares in a multiparty cryptography scheme. See also [Gateways and how they are secured](/learn).
@@ -36,15 +38,16 @@ Once a cross-chain message is initiated by a dApp user, its first stop is to int
The Gateway is controlled by a key, which is held jointly by all Axelar validators. This is accomplished through a multiparty cryptography scheme, where the key is divided into many pieces, called key shares. Each validator holds many key shares, and the amount of shares is dictated by the amount AXL tokens staked with the validator.
## Where can I get axlUSDC?
-There are three ways to acquire axlUSDC:
+
+There are three ways to acquire axlUSDC:
1. DEXs on many connected chains list pairs in axlUSDC, supported by liquidity pools. We maintain a [regularly updated list of liquid pools for axlUSDC](https://axelar.network/blog/liquidity-pools-for-bridged-assets-via-axelar) (and all Axelar-wrapped assets).
-1. Squid, built with Axelar's General Message Passing, provides liquid [cross-chain swaps](https://axelar.network/blog/what-is-a-cross-chain-swap) using axlUSDC as a routing asset. Using Squid, you can start from any connected chain and swap into axlUSDC on any other connected chain. Squid is the engine powering liquid cross-chain swaps on a growing list of DEXs, and you can always use their [cross-chain swap widget](https://app.squidrouter.com/) to handle any kind of cross-chain swap you like, without having to trust your funds to a centralized exchange.
-1. If you're holding USDC and want to take it cross-chain, you can bridge it via [satellite.money](https://satellite.money), Axelar's bridging app.
+1. Squid, built with Axelar's General Message Passing, provides liquid [cross-chain swaps](https://axelar.network/blog/what-is-a-cross-chain-swap) using axlUSDC as a routing asset. Using Squid, you can start from any connected chain and swap into axlUSDC on any other connected chain. Squid is the engine powering liquid cross-chain swaps on a growing list of DEXs, and you can always use their [cross-chain swap widget](https://app.squidrouter.com/) to handle any kind of cross-chain swap you like, without having to trust your funds to a centralized exchange.
+1. If you're holding USDC and want to take it cross-chain, you can bridge it via [satellite.money](https://satellite.money), Axelar's bridging app.
For now, axlUSDC is widely used in the Cosmos ecosystem, where it is the canonical representation of USDC on [Osmosis](https://osmosis.zone/) and many other Cosmos chains.
-Learn more about cross-chain token transfers using General Message Passing that can send axlUSDC and other wrapped assets:
+Learn more about cross-chain token transfers using General Message Passing that can send axlUSDC and other wrapped assets:
-* Read this [blog post from Axelar co-founder Sergey Gorbunov](https://axelar.network/blog/cross-chain-function-calls-will-replace-bridges).
-* [Start building with General Message Passing and axlUSDC](/dev/general-message-passing/overview)
\ No newline at end of file
+- Read this [blog post from Axelar co-founder Sergey Gorbunov](https://axelar.network/blog/cross-chain-function-calls-will-replace-bridges).
+- [Start building with General Message Passing and axlUSDC](/dev/general-message-passing/overview)
diff --git a/src/pages/learn/cli.mdx b/src/content/docs/learn/cli.mdx
similarity index 92%
rename from src/pages/learn/cli.mdx
rename to src/content/docs/learn/cli.mdx
index 7e588da57..efd89ffd0 100644
--- a/src/pages/learn/cli.mdx
+++ b/src/content/docs/learn/cli.mdx
@@ -1,6 +1,6 @@
# Axelar command-line interface (CLI)
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Some CLI commands require access to a fully synced Axelar node. Learn how to [start your own Axelar node](/node/join).
@@ -17,10 +17,9 @@ In addition to the Axelar-specific CLI features mentioned above, Axelar also off
View the [full CLI documentation](https://github.com/axelarnetwork/axelar-core/blob/main/docs/cli/toc.md) for the latest node version, or choose a specific version:
-
-
+
Tip: If you submit a transaction and encounter an out of gas error, use the following flags to set the gas manually.
-
+
```bash
--gas=auto --gas-adjustment=1.5
```
diff --git a/src/pages/learn/cli/axl-from-evm.mdx b/src/content/docs/learn/cli/axl-from-evm.mdx
similarity index 83%
rename from src/pages/learn/cli/axl-from-evm.mdx
rename to src/content/docs/learn/cli/axl-from-evm.mdx
index 8a5150634..575a0c8e4 100644
--- a/src/pages/learn/cli/axl-from-evm.mdx
+++ b/src/content/docs/learn/cli/axl-from-evm.mdx
@@ -1,13 +1,13 @@
# Redeem AXL from an EVM chain
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Redeem AXL tokens from an EVM chain to Axelar using the terminal.
## Prerequisites
- Skill level: intermediate
-- Prerequisites for [Send AXL to an EVM chain](./axl-to-evm)
+- Prerequisites for [Send AXL to an EVM chain](/learn/cli/axl-to-evm/)
## Redeem AXL tokens from an EVM chain
@@ -32,22 +32,25 @@ axelard q nexus latest-deposit-address {EVM_CHAIN} axelarnet {MY_ADDR}
Use MetaMask to send some wrapped AXL tokens on `{EVM_CHAIN}` to the new temporary deposit address `{EVM_TEMP_ADDR}`. Save the transaction hash `{EVM_TX_HASH}` for later.
- Danger: Send only `Axelar` ERC20 tokens to `{EVM_TEMP_ADDR}`. Any other token sent to `{EVM_TEMP_ADDR}` will be lost.
+ Danger: Send only `Axelar` ERC-20 tokens to `{EVM_TEMP_ADDR}`. Any other token
+ sent to `{EVM_TEMP_ADDR}` will be lost.
Note: Third-party monitoring tools will automatically complete the remaining steps of this process.
-Wait a few minutes then check your Axelar `my_account` account AXL token balance as per [Basic node management](/node/basic).
+Wait a few minutes then check your Axelar `my_account` account AXL token balance as per [Basic node management](/node/basic/).
+
Caution: If you attempt the remaining steps while third-party monitoring tools are active then your commands are likely to conflict with third-party commands. In this case you are likely to observe errors. Deeper investigation might be needed to resolve conflicts and complete the transfer.
The remaining steps are needed only if there are no active third-party monitoring tools and you wish to complete the process manually.
+
-Do not proceed to the next step until you have waited for sufficiently many block confirmations on the EVM chain. Block confirmation minimums can be found at [Testnet resources](/resources/testnet), [Mainnet resources](/resources/mainnet).
+Do not proceed to the next step until you have waited for sufficiently many block confirmations on the EVM chain. Block confirmation minimums can be found at [Testnet Resources](/resources/contract-addresses/testnet/), [Mainnet Resources](/resources/contract-addresses/mainnet/).
Confirm the EVM chain transaction on Axelar.
@@ -87,13 +90,15 @@ Wait for `status: BATCHED_COMMANDS_STATUS_SIGNED` and copy the `execute_data`.
Use MetaMask to send a transaction on `{EVM_CHAIN}` with the `execute_data` to the Axelar gateway contract address `{GATEWAY_ADDR}`.
- Danger: Post your transaction to the correct chain! Set your MetaMask network to `{EVM_CHAIN}`.
+ Danger: Post your transaction to the correct chain! Set your MetaMask network
+ to `{EVM_CHAIN}`.
Caution: Manually increase the gas limit to 5 million gas (5000000). If you don't do this then the transaction will fail due to insufficient gas and you will not receive your tokens.
Before you click "confirm": select "EDIT", change "Gas Limit" to 5000000, and "Save"
+
@@ -101,7 +106,7 @@ Before you click "confirm": select "EDIT", change "Gas Limit" to 5000000, and "S
### 1. Documentation
-[Testnet resources](/resources/testnet), [Mainnet resources](/resources/mainnet).
+[Testnet Resources](/resources/contract-addresses/testnet/), [Mainnet Resources](/resources/contract-addresses/mainnet/).
### 2. Terminal
@@ -113,7 +118,7 @@ axelard q evm gateway-address {EVM_CHAIN}
To send a transaction to `{GATEWAY_ADDR}` using MetaMask: paste hex from `execute_data` above into "Hex Data" field. (Do not send tokens!)
-Optional: Check your Axelar `my_account` account AXL token balance as per [Basic node management](/node/basic) so that you can observe balance change.
+Optional: Check your Axelar `my_account` account AXL token balance as per [Basic node management](/node/basic/) so that you can observe balance change.
Execute the pending transfer:
diff --git a/src/pages/learn/cli/axl-to-evm.mdx b/src/content/docs/learn/cli/axl-to-evm.mdx
similarity index 88%
rename from src/pages/learn/cli/axl-to-evm.mdx
rename to src/content/docs/learn/cli/axl-to-evm.mdx
index 678f3fa1f..b0895905d 100644
--- a/src/pages/learn/cli/axl-to-evm.mdx
+++ b/src/content/docs/learn/cli/axl-to-evm.mdx
@@ -1,27 +1,27 @@
# Send AXL to an EVM chain
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Transfer AXL tokens from Axelar to an EVM chain using the terminal.
## Prerequisites
- Skill level: intermediate
-- You have downloaded the Axelar blockchain and are comfortable with [Basic node management](/node/basic).
+- You have downloaded the Axelar blockchain and are comfortable with [Basic node management](/node/basic/).
- Your Axelar node has an account named `my_account` that you control. Let `{MY_ADDR}` denote the address of your `my_account` account.
- Select an EVM chain `{EVM_CHAIN}` from: Ethereum, Avalanche, Fantom, Moonbeam, Polygon.
-- Complete steps from [MetaMask for EVM chains](/resources/metamask) to connect your MetaMask to `{EVM_CHAIN}`.
+- Complete steps from [MetaMask for EVM chains](/resources/metamask/) to connect your MetaMask to `{EVM_CHAIN}`.
- You need both AXL tokens and `{EVM_CHAIN}` tokens to pay transaction fees.
- **Testnet:**
- - Get some `{EVM_CHAIN}` testnet tokens as per [MetaMask for EVM chains](/resources/metamask).
+ - Get some `{EVM_CHAIN}` testnet tokens as per [MetaMask for EVM chains](/resources/metamask/).
- Get some AXL tokens from the Axelar faucets: [testnet](https://faucet.testnet.axelar.dev/).
- **Mainnet:** You are responsible for obtaining your own tokens.
- `{EVM_DEST_ADDR}` is an address controlled by you on the external EVM chain `{EVM_CHAIN}`. (In your MetaMask, for example.) This is where your AXL tokens will be sent.
-- `{AMOUNT}` is the amount of AXL tokens you wish to transfer, denominated in `uaxl`. Recall that `1 AXL = 1000000 uaxl`. See [Testnet resources](/resources/testnet) or [Mainnet resources](/resources/mainnet) for minimum transfer amounts.
+- `{AMOUNT}` is the amount of AXL tokens you wish to transfer, denominated in `uaxl`. Recall that `1 AXL = 1000000 uaxl`. See [Testnet Resources](/resources/contract-addresses/testnet/) or [Mainnet Resources](/resources/contract-addresses/mainnet/) for minimum transfer amounts.
## Send AXL tokens from Axelar to an EVM chain
-Optional: Verify that your `my_account` account has sufficient balance as per [Basic node management](/node/basic).
+Optional: Verify that your `my_account` account has sufficient balance as per [Basic node management](/node/basic/).
Link your `{EVM_DEST_ADDR}` to a new temporary deposit address on Axelar:
@@ -50,13 +50,15 @@ axelard tx bank send my_account {AXELAR_TEMP_ADDR} {AMOUNT}uaxl --from my_accoun
Note: Third-party monitoring tools will automatically complete the remaining steps of this process.
-Wait a few minutes then check your MetaMask for the AXL tokens. Don't forget to import the AXL token into MetaMask so you can see your balance as described in [MetaMask for EVM chains](/resources/metamask).
+Wait a few minutes then check your MetaMask for the AXL tokens. Don't forget to import the AXL token into MetaMask so you can see your balance as described in [MetaMask for EVM chains](/resources/metamask/).
+
Caution: If you attempt the remaining steps while third-party monitoring tools are active then your commands are likely to conflict with third-party commands. In this case you are likely to observe errors. Deeper investigation might be needed to resolve conflicts and complete the transfer.
The remaining steps are needed only if there are no active third-party monitoring tools and you wish to complete the process manually.
+
Confirm the deposit transaction. Look for `{TX_HASH}` in the output of the previous command.
@@ -89,13 +91,15 @@ Wait for `status: BATCHED_COMMANDS_STATUS_SIGNED` and copy the `execute_data`.
Use MetaMask to send a transaction on `{EVM_CHAIN}` with the `execute_data` to the Axelar gateway contract address `{GATEWAY_ADDR}`.
- Danger: Post your transaction to the correct chain! Set your MetaMask network to `{EVM_CHAIN}`.
+ Danger: Post your transaction to the correct chain! Set your MetaMask network
+ to `{EVM_CHAIN}`.
Caution: Manually increase the gas limit to 5 million gas (5000000). If you don't do this then the transaction will fail due to insufficient gas and you will not receive your tokens.
Before you click "confirm": select "EDIT", change "Gas Limit" to 5000000, and "Save"
+
@@ -103,7 +107,7 @@ Before you click "confirm": select "EDIT", change "Gas Limit" to 5000000, and "S
### 1. Documentation
-[Testnet resources](/resources/testnet), [Mainnet resources](/resources/mainnet).
+[Testnet Resources](/resources/contract-addresses/testnet/), [Mainnet Resources](/resources/contract-addresses/mainnet/).
### 2. Terminal
diff --git a/src/pages/learn/cli/reference.md b/src/content/docs/learn/cli/reference.md
similarity index 62%
rename from src/pages/learn/cli/reference.md
rename to src/content/docs/learn/cli/reference.md
index 8db9beea0..da3e2253a 100644
--- a/src/pages/learn/cli/reference.md
+++ b/src/content/docs/learn/cli/reference.md
@@ -1,11 +1,12 @@
# Axelar CLI reference
-In addition to the Axelar-specific CLI features mentioned in the [CLI Introduction](./), Axelar also offers the same basic set of CLI commands as any other Cosmos SDK project.
+In addition to the Axelar-specific CLI features mentioned in the [CLI Introduction](./), Axelar also offers the same basic set of CLI commands as any other Cosmos SDK project.
## Complete Axelar CLI reference
+
View the [full CLI documentation](https://github.com/axelarnetwork/axelar-core/blob/main/docs/cli/toc.md) for the latest node version, or choose a specific version:
-* [v33](https://github.com/axelarnetwork/axelar-core/blob/v0.33.3/docs/cli/toc.md)
-* [v32](https://github.com/axelarnetwork/axelar-core/blob/v0.32.2/docs/cli/toc.md)
-* [v31](https://github.com/axelarnetwork/axelar-core/blob/v0.31.4/docs/cli/toc.md)
-* [v29](https://github.com/axelarnetwork/axelar-core/blob/v0.29.1/docs/cli/toc.md)
\ No newline at end of file
+- [v33](https://github.com/axelarnetwork/axelar-core/blob/v0.33.3/docs/cli/toc.md)
+- [v32](https://github.com/axelarnetwork/axelar-core/blob/v0.32.2/docs/cli/toc.md)
+- [v31](https://github.com/axelarnetwork/axelar-core/blob/v0.31.4/docs/cli/toc.md)
+- [v29](https://github.com/axelarnetwork/axelar-core/blob/v0.29.1/docs/cli/toc.md)
diff --git a/src/pages/learn/cli/ust-from-evm.mdx b/src/content/docs/learn/cli/ust-from-evm.mdx
similarity index 86%
rename from src/pages/learn/cli/ust-from-evm.mdx
rename to src/content/docs/learn/cli/ust-from-evm.mdx
index 2fbbdcf48..bf55f6ada 100644
--- a/src/pages/learn/cli/ust-from-evm.mdx
+++ b/src/content/docs/learn/cli/ust-from-evm.mdx
@@ -1,13 +1,13 @@
# Redeem UST from an EVM chain
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Redeem UST tokens from an EVM chain to Terra using the terminal.
## Prerequisites
- Skill level: intermediate
-- Prerequisites for [Send UST to an EVM chain](./ust-to-evm)
+- Prerequisites for [Send UST to an EVM chain](/learn/cli/ust-to-evm/)
- `{TERRA_DEST_ADDR}` is an address controlled by you on the Terra chain. This is where your UST tokens will be redeemed.
## Redeem UST tokens from an EVM chain
@@ -27,22 +27,25 @@ successfully linked {EVM_TEMP_ADDR} and {TERRA_DEST_ADDR}
Use MetaMask to send some wrapped AXL tokens on `{EVM_CHAIN}` to the new temporary deposit address `{EVM_TEMP_ADDR}`. Save the transaction hash `{EVM_TX_HASH}` for later.
- Danger: Send only `Axelar Wrapped UST` ERC20 tokens to `{EVM_TEMP_ADDR}`. Any other token sent to `{EVM_TEMP_ADDR}` will be lost.
+ Danger: Send only `Axelar Wrapped UST` ERC-20 tokens to `{EVM_TEMP_ADDR}`. Any
+ other token sent to `{EVM_TEMP_ADDR}` will be lost.
Note: Third-party monitoring tools will automatically complete the remaining steps of this process.
Wait a few minutes then check your Terra `{TERRA_DEST_ADDR}` account UST token balance.
+
Caution: If you attempt the remaining steps while third-party monitoring tools are active then your commands are likely to conflict with third-party commands. In this case you are likely to observe errors. Deeper investigation might be needed to resolve conflicts and complete the transfer.
The remaining steps are needed only if there are no active third-party monitoring tools and you wish to complete the process manually.
+
-Do not proceed to the next step until you have waited for sufficiently many block confirmations on the EVM chain. Block confirmation minimums can be found at [Testnet resources](/resources/testnet), [Mainnet resources](/resources/mainnet).
+Do not proceed to the next step until you have waited for sufficiently many block confirmations on the EVM chain. Block confirmation minimums can be found at [Testnet Resources](/resources/contract-addresses/testnet/), [Mainnet Resources](/resources/contract-addresses/mainnet/).
Confirm the EVM chain transaction on Axelar.
@@ -76,13 +79,15 @@ Wait for `status: BATCHED_COMMANDS_STATUS_SIGNED` and copy the `execute_data`.
Use MetaMask to send a transaction on `{EVM_CHAIN}` with the `execute_data` to the Axelar gateway contract address `{GATEWAY_ADDR}`.
- Danger: Post your transaction to the correct chain! Set your MetaMask network to `{EVM_CHAIN}`.
+ Danger: Post your transaction to the correct chain! Set your MetaMask network
+ to `{EVM_CHAIN}`.
Caution: Manually increase the gas limit to 5 million gas (5000000). If you don't do this then the transaction will fail due to insufficient gas and you will not receive your tokens.
Before you click "confirm": select "EDIT", change "Gas Limit" to 5000000, and "Save"
+
@@ -90,7 +95,7 @@ Before you click "confirm": select "EDIT", change "Gas Limit" to 5000000, and "S
### 1. Documentation
-[Testnet resources](/resources/testnet), [Mainnet resources](/resources/mainnet).
+[Testnet Resources](/resources/contract-addresses/testnet/), [Mainnet Resources](/resources/contract-addresses/mainnet/).
### 2. Terminal
diff --git a/src/pages/learn/cli/ust-to-evm.mdx b/src/content/docs/learn/cli/ust-to-evm.mdx
similarity index 81%
rename from src/pages/learn/cli/ust-to-evm.mdx
rename to src/content/docs/learn/cli/ust-to-evm.mdx
index b5b311b80..67f9a4276 100644
--- a/src/pages/learn/cli/ust-to-evm.mdx
+++ b/src/content/docs/learn/cli/ust-to-evm.mdx
@@ -1,13 +1,13 @@
# Send UST to an EVM chain
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Transfer UST tokens from Terra to an EVM chain using the terminal.
## Prerequisites
- Skill level: intermediate
-- Prerequisites for [Send AXL to an EVM chain](./axl-to-evm)
+- Prerequisites for [Send AXL to an EVM chain](/learn/cli/axl-to-evm/)
## Send UST tokens from Terra to an EVM chain
@@ -35,8 +35,8 @@ Use a web wallet such as Keplr. See [Transfer Terra assets to EVM chains using S
### IBC from the terminal
You need shell access to a Terra node with at least `{AMOUNT}` balance of UST tokens in an account called `terra-validator`.
-Get `{TERRA_TO_AXELAR_CHANNEL_ID}` from [Testnet resources](/resources/testnet) or [Mainnet resources](/resources/mainnet).
-
+Get `{TERRA_TO_AXELAR_CHANNEL_ID}` from [Testnet Resources](/resources/contract-addresses/testnet/) or [Mainnet Resources](/resources/contract-addresses/mainnet/).
+
```bash
terrad tx ibc-transfer transfer transfer {TERRA_TO_AXELAR_CHANNEL_ID} {AXELAR_TEMP_ADDR} --packet-timeout-timestamp 0 --packet-timeout-height "0-20000" {AMOUNT}uusd --gas-prices 0.15uusd --from terra-validator -y -b block
```
@@ -48,16 +48,18 @@ Wait a few minutes for the IBC relayer to relay your transaction to Axelar.
Note: Third-party monitoring tools will automatically complete the remaining steps of this process.
-Wait a few minutes then check your MetaMask for the UST tokens. Don't forget to import the UST token into MetaMask so you can see your balance as described in [MetaMask for EVM chains](/resources/metamask).
+Wait a few minutes then check your MetaMask for the UST tokens. Don't forget to import the UST token into MetaMask so you can see your balance as described in [MetaMask for EVM chains](/resources/metamask/).
+
Caution: If you attempt the remaining steps while third-party monitoring tools are active then your commands are likely to conflict with third-party commands. In this case you are likely to observe errors. Deeper investigation might be needed to resolve conflicts and complete the transfer.
The remaining steps are needed only if there are no active third-party monitoring tools and you wish to complete the process manually.
+
-Verify the IBC transaction by checking the balances of `{AXELAR_TEMP_ADDR}` as per [Basic node management](/node/basic). Output should contain something like:
+Verify the IBC transaction by checking the balances of `{AXELAR_TEMP_ADDR}` as per [Basic node management](/node/basic/). Output should contain something like:
```
balances:
@@ -66,12 +68,14 @@ balances:
```
- Note: You will not see `UST`, `uusd` or a similar token denomination for `{IBC_DENOM}`. IBC token denominations look something like `ibc/6F4968A73F90CF7DE6394BF937D6DF7C7D162D74D839C13F53B41157D315E05F`
+ Note: You will not see `UST`, `uusd` or a similar token denomination for `
+ {IBC_DENOM}`. IBC token denominations look something like
+ `ibc/6F4968A73F90CF7DE6394BF937D6DF7C7D162D74D839C13F53B41157D315E05F`
-Get `{IBC_DENOM}` from [Testnet resources](/resources/testnet) or [Mainnet resources](/resources/mainnet).
+Get `{IBC_DENOM}` from [Testnet Resources](/resources/contract-addresses/testnet/) or [Mainnet Resources](/resources/contract-addresses/mainnet/).
-The remaining steps are similar to [Transfer AXL tokens from Axelar to an EVM chain using the terminal](./axl-to-evm).
+The remaining steps are similar to [Transfer AXL tokens from Axelar to an EVM chain using the terminal](/learn/cli/axl-to-evm/).
Confirm the deposit transaction. Look for `{TX_HASH}` in the output of the previous command.
@@ -103,13 +107,15 @@ Wait for `status: BATCHED_COMMANDS_STATUS_SIGNED` and copy the `execute_data`.
Use MetaMask to send a transaction on `{EVM_CHAIN}` with the `execute_data` to the Axelar gateway contract address `{GATEWAY_ADDR}`.
- Danger: Post your transaction to the correct chain! Set your MetaMask network to `{EVM_CHAIN}`.
+ Danger: Post your transaction to the correct chain! Set your MetaMask network
+ to `{EVM_CHAIN}`.
Caution: Manually increase the gas limit to 5 million gas (5000000). If you don't do this then the transaction will fail due to insufficient gas and you will not receive your tokens.
Before you click "confirm": select "EDIT", change "Gas Limit" to 5000000, and "Save"
+
@@ -117,7 +123,7 @@ Before you click "confirm": select "EDIT", change "Gas Limit" to 5000000, and "S
### 1. Documentation
-[Testnet resources](/resources/testnet), [Mainnet resources](/resources/mainnet).
+[Testnet Resources](/resources/contract-addresses/testnet/), [Mainnet Resources](/resources/contract-addresses/mainnet/).
### 2. Terminal
diff --git a/src/pages/learn/evm-governance.mdx b/src/content/docs/learn/evm-governance.mdx
similarity index 100%
rename from src/pages/learn/evm-governance.mdx
rename to src/content/docs/learn/evm-governance.mdx
diff --git a/src/pages/learn/intro.mdx b/src/content/docs/learn/intro.mdx
similarity index 86%
rename from src/pages/learn/intro.mdx
rename to src/content/docs/learn/intro.mdx
index 9660ebab0..95df64041 100644
--- a/src/pages/learn/intro.mdx
+++ b/src/content/docs/learn/intro.mdx
@@ -1,3 +1,3 @@
# Learn about Axelar
-Dive into all the components that come together to form the Axelar network, for a high-level understanding of the vision and design; go deeper and gain technical knowledge of specialized functions, including our CLI and SDK.
+Dive into all the components that come together to form the Axelar network, for a high-level understanding of the vision and design; go deeper and gain technical knowledge of specialized functions, including our CLI and SDK.
diff --git a/src/pages/learn/network/flow.mdx b/src/content/docs/learn/network/flow.mdx
similarity index 87%
rename from src/pages/learn/network/flow.mdx
rename to src/content/docs/learn/network/flow.mdx
index 245ef0e29..3b009d00e 100644
--- a/src/pages/learn/network/flow.mdx
+++ b/src/content/docs/learn/network/flow.mdx
@@ -1,7 +1,8 @@
# General Flow of Events processed by Axelar Network
-This section will provide a high-level understanding of the end-to-end flow by which Axelar network processes cross-chain messages. It includes:
-- How messages are picked up by Axelar on external connected chains.
+This section will provide a high-level understanding of the end-to-end flow by which Axelar network processes cross-chain messages. It includes:
+
+- How messages are picked up by Axelar on external connected chains.
- How messages are delivered to the destination chains.
- How Axelar validators and cryptography work to securely route and transfer messages.
- An introduction to the underlying relayer services that provide a smooth user experience.
@@ -12,23 +13,29 @@ Before understanding the flow of events processed by Axelar, it's important to u
Axelar is a proof-of-stake blockchain network built using Cosmos SDK. It has its own permissionless set of validators, which constantly produce blocks containing transactions. This validator set is used by the network to securely process cross-chain messages through voting on the legitimacy of all messages. To understand more about the setup, take a look at the Axelar Tech Stack Diagram.
-
+
+
+
+
+
+
+
+
Axelar delivers secure cross-chain communication between separate blockchain networks. This could involve making cross-chain token transfers, calling a smart contract on another chain or passing general, arbitrary messages across chains. While each feature's exact processing flow varies, it can be simplified down to a cross-chain "message" that the network processes.
## Cross-chain General Message Passing requests
-Axelar enables dApp builders to add cross-chain functionality to their applications, through a suite of APIs. These APIs allow a dApp user to send a message containing arbitrary data cross-chain, from the source chain to the destination chain. Thus, a dApp may call a smart contract on the destination chain, and attach general data information to be used as input for the smart contract call. To do this, the dApp interacts with the Axelar Gateway, an Axelar-operated installation on the source chain, which contains the functions and logic needed for initiating and processing any cross-chain messages.
+Axelar enables dApp builders to add cross-chain functionality to their applications, through a suite of APIs. These APIs allow a dApp user to send a message containing arbitrary data cross-chain, from the source chain to the destination chain. Thus, a dApp may call a smart contract on the destination chain, and attach general data information to be used as input for the smart contract call. To do this, the dApp interacts with the Axelar Gateway, an Axelar-operated installation on the source chain, which contains the functions and logic needed for initiating and processing any cross-chain messages.
## Gateways
-Once a cross-chain message is initiated by a dApp user, its first stop is to interact with an Axelar Gateway. On each chain connected to Axelar network, a Gateway is deployed. On EVM chains, it is a smart contract address. On Cosmos and other non-EVM chains, it is an application with logic and the ability to communicate with Axelar network. This Gateway is used to receive messages from a connected dApp and send them into the Axelar network for routing to any connected chain.
+Once a cross-chain message is initiated by a dApp user, its first stop is to interact with an Axelar Gateway. On each chain connected to Axelar network, a Gateway is deployed. On EVM chains, it is a smart contract address. On Cosmos and other non-EVM chains, it is an application with logic and the ability to communicate with Axelar network. This Gateway is used to receive messages from a connected dApp and send them into the Axelar network for routing to any connected chain.
-The Gateway is controlled by a key, which is held jointly by all Axelar validators. This is accomplished through a multiparty cryptography scheme, where the key is divided into many pieces, called key shares. Each validator holds many key shares, and the amount of shares is dictated by the amount AXL tokens staked with the validator.
+The Gateway is controlled by a key, which is held jointly by all Axelar validators. This is accomplished through a multiparty cryptography scheme, where the key is divided into many pieces, called key shares. Each validator holds many key shares, and the amount of shares is dictated by the amount AXL tokens staked with the validator.
Simply put, Gateways enable communication between Axelar and its connected chains, and they have two main functions. On the source chain where the message originates, the Gateway enables initiating cross-chain message requests. On the destination chain where the message is received, the Gateway enables the message to be executed and completes the cross-chain protocol.
-
## Message processing and relayers
Axelar network must be aware of events happening and cross-chain communication requests being submitted on external supported chains. This function is handled by relayers. Once a Gateway receives a message, it will generate an event. Axelar runs relayer services which observe all connected chains, and these relayers will pick up the event and submit it to the Axelar network for processing. These relayer services are a free, operational convenience Axelar provides, and can be run by anyone who wishes to create and use their own relayer service instead.
@@ -37,34 +44,45 @@ Axelar network must be aware of events happening and cross-chain communication r
Since anyone can run their own relayer services and submit events to Axelar network (see the previous section on message processing and relayers), all events received by Axelar must first go through validation, to ensure the submitted events are correct and trustworthy. In many blockchain ecosystems, trust comes from the network validators, who are incentivized to behave honestly through consensus protocols, such as proof-of-stake. These validators are already incentivized by Axelar network’s proof-of-stake consensus model to create blocks and approve transactions, so it is a natural extension to have the validators participate in consensus and vote on the truthfulness of cross-chain events being submitted.
-Once the event sent by an external chain is received by Axelar, a poll is generated and Axelar validators vote on the poll. In order to vote on the legitimacy of a message, Axelar validators need to verify the submitted event. Each validator runs their own node for the source chain where the incoming event originated, and by querying the RPC endpoint of their source-chain node, validators can check if the submitted event was observed on their source-chain node. If the event is found, the validator votes in the poll to approve the message as legitimate.
+Once the event sent by an external chain is received by Axelar, a poll is generated and Axelar validators vote on the poll. In order to vote on the legitimacy of a message, Axelar validators need to verify the submitted event. Each validator runs their own node for the source chain where the incoming event originated, and by querying the RPC endpoint of their source-chain node, validators can check if the submitted event was observed on their source-chain node. If the event is found, the validator votes in the poll to approve the message as legitimate.
-As Axelar grows and connects more and more chains, it becomes increasingly restrictive to require every Axelar validator to run a node for every chain supported by the network. Instead, Axelar validators are incentivized to run nodes for as many supported chains as possible, through increased staking rewards, based on the number of chains they support. By having Axelar’s decentralized, proof-of-stake validator network vote on the legitimacy of each cross-chain message, the network is able to process and route them to the destination chains securely. Only verified events are translated into actions on the destination chain, and events not verified by Axelar validators are discarded. Afterwards, the event is validated by the Axelar network, processed by the network consensus protocol and recorded in a block. The cross-chain message is routed into a queue of messages for the destination chain, and ready to be sent to the destination-chain Gateway.
+As Axelar grows and connects more and more chains, it becomes increasingly restrictive to require every Axelar validator to run a node for every chain supported by the network. Instead, Axelar validators are incentivized to run nodes for as many supported chains as possible, through increased staking rewards, based on the number of chains they support. By having Axelar’s decentralized, proof-of-stake validator network vote on the legitimacy of each cross-chain message, the network is able to process and route them to the destination chains securely. Only verified events are translated into actions on the destination chain, and events not verified by Axelar validators are discarded. Afterwards, the event is validated by the Axelar network, processed by the network consensus protocol and recorded in a block. The cross-chain message is routed into a queue of messages for the destination chain, and ready to be sent to the destination-chain Gateway.
-By using proof-of-stake consensus to secure cross-chain messages, additional assumptions in security are avoided, as most of the Axelar-connected networks use the same proof-of-stake consensus model to validate their transactions.
+By using proof-of-stake consensus to secure cross-chain messages, additional assumptions in security are avoided, as most of the Axelar-connected networks use the same proof-of-stake consensus model to validate their transactions.
## Submitting a message to the destination chain
-After the message is approved by Axelar network validators, it needs to be authorized. The Gateway can only allow actions on the external chain if the number of validators holding key shares who authorize the action reaches a set threshold.
+After the message is approved by Axelar network validators, it needs to be authorized. The Gateway can only allow actions on the external chain if the number of validators holding key shares who authorize the action reaches a set threshold.
-Once a message is authorized, anyone can take this signed message and submit it to the destination chain for processing. Similar to the relayer services described earlier, which observe external chain events and bring them into Axelar network, another set of relayer services monitors outgoing transaction queues containing cross-chain messages that are already approved and signed, and periodically submits these transactions to external chains. Just as for incoming messages, these outbound Axelar relayer services are a free, operational convenience Axelar provides, and can be run by anyone who wishes to create and use their own relayer service instead.
+Once a message is authorized, anyone can take this signed message and submit it to the destination chain for processing. Similar to the relayer services described earlier, which observe external chain events and bring them into Axelar network, another set of relayer services monitors outgoing transaction queues containing cross-chain messages that are already approved and signed, and periodically submits these transactions to external chains. Relayers can be run by anyone who wishes to create and use their own relayer service instead.
-After a relayer sends it out, a Gateway on the destination chain receives the approved message, where its payload is marked as approved by Axelar. The Gateway stores the contract call approval along with a hash of the payload, representing the legitimacy of this cross-chain message. The approved payload can now be executed by anyone at any time.
+After a relayer sends it out, a Gateway on the destination chain receives the approved message, where its payload is marked as approved by Axelar. The Gateway stores the contract call approval along with a hash of the payload, representing the legitimacy of this cross-chain message. The approved payload can now be executed by anyone at any time.
## Gas and executor services
Once the cross-chain payload is marked as approved by the Axelar Gateway contract, it needs to be sent to the destination dApp or contract and executed, in order to perform a function call or token transfer. This execution requires tokens of the destination chain to cover gas fee costs. The gas could be paid in a few different ways. One option is to have the Web3 user pay the fee manually for their own cross-chain message. This makes for an inconvenient user experience, as it requires the user to acquire destination-chain and source-chain tokens. Axelar offers Gas and Executor services to help make this easier.
-Axelar creates and deploys a smart contract called the Gas Receiver to all connected EVM chains. (General Message Passing for Cosmos chains is currently under development and this may enable Gas-Receiver-like services to be deployed there, as well.) This Gas Receiver allows the user to pay for all transaction fees required throughout the entire journey of their cross-chain message in a one-time payment on the source chain, in the source chain's native token. The Gas Receiver estimates the total gas cost required across source chain, Axelar network and destination chain, and converts source-chain tokens (or any token Axelar supports) into AXL, destination-chain tokens and any other required currencies. For more details on this process, see the diagram below and read this [blog post](https://medium.com/@axelar-foundation/the-axl-token-the-cross-chain-future-3dee3dc45e95) providing a high-level description of the AXL token's uses and benefits.
-
-
-
+Axelar creates and deploys a smart contract called the Gas Receiver to all connected EVM chains. (General Message Passing for Cosmos chains is currently under development and this may enable Gas-Receiver-like services to be deployed there, as well.) This Gas Receiver allows the user to pay for all transaction fees required throughout the entire journey of their cross-chain message in a one-time payment on the source chain, in the source chain's native token. The Gas Receiver estimates the total gas cost required across source chain, Axelar network and destination chain, and converts source-chain tokens (or any token Axelar supports) into AXL, destination-chain tokens and any other required currencies. For more details on this process, see the diagram below and read this [blog post](https://medium.com/@axelar-foundation/the-axl-token-the-cross-chain-future-3dee3dc45e95) providing a high-level description of the AXL token's uses and benefits.
+
+
+
## Monitoring and recovery
-Once the message is executed on the destination chain, its cross-chain journey is complete. However, there may be factors that prevent this completion at various stages of the process. These might include a gas limit set too low, or contract logic that is incompatible with a function called on the destination chain. In order to mitigate against these obstructions, Axelar provides various tools for [debugging](https://docs.axelar.dev/dev/debug/error-debugging), [monitoring and recovery](https://docs.axelar.dev/dev/general-message-passing/monitoring).
-
-For example, while a cross-chain message is being processed by Axelar, a user or developer can follow and observe its journey. The Axelarscan explorer has a General Message Passing [tracking tool](https://testnet.axelarscan.io/gmp/search) built for this purpose. The user can enter their source-chain sender address or transaction hash into the Axelarscan search bar to find their cross-chain message. This will bring up a detailed page containing information about the message, and its current status. If there are any issues with the transaction, this page will also suggest possible fixes. Visit this [link](https://docs.axelar.dev/dev/general-message-passing/monitoring) for more information on how to use this monitoring and recovery tool.
-
-
+Once the message is executed on the destination chain, its cross-chain journey is complete. However, there may be factors that prevent this completion at various stages of the process. These might include a gas limit set too low, or contract logic that is incompatible with a function called on the destination chain. In order to mitigate against these obstructions, Axelar provides various tools for [debugging](/dev/general-message-passing/debug/error-debugging/), [monitoring and recovery](/dev/general-message-passing/monitoring/).
+For example, while a cross-chain message is being processed by Axelar, a user or developer can follow and observe its journey. The Axelarscan explorer has a General Message Passing [tracking tool](https://testnet.axelarscan.io/gmp/search) built for this purpose. The user can enter their source-chain sender address or transaction hash into the Axelarscan search bar to find their cross-chain message. This will bring up a detailed page containing information about the message, and its current status. If there are any issues with the transaction, this page will also suggest possible fixes. Visit this [link](/dev/general-message-passing/monitoring/) for more information on how to use this monitoring and recovery tool.
diff --git a/src/pages/learn/security.mdx b/src/content/docs/learn/security.mdx
similarity index 82%
rename from src/pages/learn/security.mdx
rename to src/content/docs/learn/security.mdx
index 17f2779ea..5ce0ffd89 100644
--- a/src/pages/learn/security.mdx
+++ b/src/content/docs/learn/security.mdx
@@ -15,8 +15,12 @@ In Byzantine systems, if you break liveness, the system halts its operation, but
This kind of decentralization is critical to satisfy strong safety and liveness properties needed to handle cross-chain functions. This is why Axelar is built using battle-tested proof-of-stake consensus, supporting a diverse and dynamic validator set. Anyone can join, anyone can participate, anyone can contribute to the security of the network.
-
-
+
+
+
+
+
+
## Quadratic voting
@@ -28,8 +32,13 @@ Quadratic voting is a way to continue decentralizing the system while making it
Note that while quadratic voting is implemented for validation and processing of cross-chain transactions, the underlying consensus follows the standard PoS staking model (1 token, 1 vote) for block production and rewards.
-
+
+
+
+
+
+
## Preemptive measures
@@ -41,18 +50,18 @@ Axelar network supports General Message Passing, but certain major assets (e.g.,
### Key rotations on the network
-Validators of the Axelar network maintain keys that allow them to coauthorize cross-chain requests, a process similar to how validators coauthorize every block on the blockchain. Validators are strongly encouraged to implement best practices for isolating these keys, and are [required to rotate them periodically](https://docs.axelar.dev/validator/operations/mnemonic-rotation). These key rotations secure the network against a persistent attacker, who might try to accumulate malicious keys by compromising validators sequentially.
+Validators of the Axelar network maintain keys that allow them to coauthorize cross-chain requests, a process similar to how validators coauthorize every block on the blockchain. Validators are strongly encouraged to implement best practices for isolating these keys, and are [required to rotate them periodically](/validator/operations/mnemonic-rotation/). These key rotations secure the network against a persistent attacker, who might try to accumulate malicious keys by compromising validators sequentially.
### Audits
-The Axelar network code periodically goes through rigorous audits. Audits are published [here](https://github.com/axelarnetwork/audits).
+The Axelar network code periodically goes through rigorous audits. Audits are published [here](https://github.com/axelarnetwork/audits).
In addition, all Axelar network code and contracts are open-source, meaning anyone can review the code and look for vulnerabilities. Comments and revision from white-hat hackers are actively encouraged. There is also an active [bug-bounty program](https://immunefi.com/bounty/axelarnetwork/) set up, which incentivizes security submissions.
## Application-level security add-ons
-On top of the above security measures, Axelar supports Turing-complete [General Message Passing](https://docs.axelar.dev/dev/gmp-overview). This functionality enables application developers to build their own custom cross-chain security policies. For instance, a DeFi application may impose additional limits on the volume of transferred funds, repeat transactions, co-authoring large transfers, etc. These application-specific features can work alongside the network requirements to deliver an even stronger security guarantee.
+On top of the above security measures, Axelar supports Turing-complete [General Message Passing](/dev/general-message-passing/overview/). This functionality enables application developers to build their own custom cross-chain security policies. For instance, a DeFi application may impose additional limits on the volume of transferred funds, repeat transactions, co-authoring large transfers, etc. These application-specific features can work alongside the network requirements to deliver an even stronger security guarantee.
## Summary conclusion
-In summary, Axelar tackles the complex issue of network security by having multiple layers of defenses in place. The security stack begins with decentralized, proof-of-stake consensus and diverse node tech stacks. Quadratic voting supports continued, scalable decentralization over time by preventing power consolidation among the top validators. To contain any potential errors and other failures that may occur, preventative measures are put in place, like frequent key rotations and transaction rate limits. The codebase has been thoroughly audited and is open source, with a bug bounty program to encourage whitehat submissions from the community. General Message Passing provides the ability for application-layer projects to add security features as needed for their use case, atop the Axelar security stack described here.
+In summary, Axelar tackles the complex issue of network security by having multiple layers of defenses in place. The security stack begins with decentralized, proof-of-stake consensus and diverse node tech stacks. Quadratic voting supports continued, scalable decentralization over time by preventing power consolidation among the top validators. To contain any potential errors and other failures that may occur, preventative measures are put in place, like frequent key rotations and transaction rate limits. The codebase has been thoroughly audited and is open source, with a bug bounty program to encourage whitehat submissions from the community. General Message Passing provides the ability for application-layer projects to add security features as needed for their use case, atop the Axelar security stack described here.
diff --git a/src/pages/learn/txduration.mdx b/src/content/docs/learn/txduration.mdx
similarity index 100%
rename from src/pages/learn/txduration.mdx
rename to src/content/docs/learn/txduration.mdx
diff --git a/src/pages/node/basic.mdx b/src/content/docs/node/basic.mdx
similarity index 88%
rename from src/pages/node/basic.mdx
rename to src/content/docs/node/basic.mdx
index dced20f69..96623f7ee 100644
--- a/src/pages/node/basic.mdx
+++ b/src/content/docs/node/basic.mdx
@@ -1,16 +1,15 @@
# Basic node management
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Start and stop your node, test whether your blockchain is downloaded. Backup your keys and chain data. Create an account, check your AXL balance, get AXL tokens from the faucet.
## Prerequisites
-- Configure your environment as per [CLI configuration](config-cli) and [Node configuration](config-node).
+- Configure your environment as per [CLI configuration](/node/config-cli/) and [Node configuration](/node/config-node/).
- Install [lz4](https://lz4.github.io/lz4/)
- Ensure AXELARD_HOME variable is set in your current session. See https://docs.axelar.dev/node/config-node#home-directory (example AXELARD_HOME="$HOME/.axelar").
-
## Start your Axelar node
You may wish to redirect log output to a file (your command will be launched in background):
@@ -40,7 +39,6 @@ Look for the field `catching_up`:
- `true`: you are still downloading the blockchain.
- `false`: you have finished downloading the blockchain.
-
## Stop your Axelar node
Stop your currently running Axelar node:
@@ -85,7 +83,9 @@ $AXELARD_HOME/bin/axelard keys add my_account --home $AXELARD_HOME
```
- Caution: The above command will print a mnemonic to stdout. This mnemonic allows you to recover the secret key for your new account. Be sure to store a backup of the mnemonic in a safe place.
+ Caution: The above command will print a mnemonic to stdout. This mnemonic
+ allows you to recover the secret key for your new account. Be sure to store a
+ backup of the mnemonic in a safe place.
## Learn your address
@@ -101,7 +101,8 @@ $AXELARD_HOME/bin/axelard keys show validator -a --home $AXELARD_HOME
Let `{MY_ADDRESS}` denote the address of your `my_account` account.
- Tip: Your balance will appear only after you have downloaded the blockchain and exited `catching_up` mode.
+ Tip: Your balance will appear only after you have downloaded the blockchain
+ and exited `catching_up` mode.
```bash
diff --git a/src/pages/node/config-cli.mdx b/src/content/docs/node/config-cli.mdx
similarity index 90%
rename from src/pages/node/config-cli.mdx
rename to src/content/docs/node/config-cli.mdx
index b191d1573..e9697fac3 100644
--- a/src/pages/node/config-cli.mdx
+++ b/src/content/docs/node/config-cli.mdx
@@ -2,7 +2,7 @@
By default, many Axelar CLI commands contain boilerplate material that obfuscates the command and adds complexity to documentation. Here we describe documentation conventions and ways to configure your system so as to reduce this boilerplate.
-Example: As per [Send AXL to an EVM chain](../learn/cli/axl-to-evm) you can use the CLI to get a deposit address for cross-chain transfer of AXL tokens via the command
+Example: As per [Send AXL to an EVM chain](/learn/cli/axl-to-evm/) you can use the CLI to get a deposit address for cross-chain transfer of AXL tokens via the command
```bash
axelard tx axelarnet link {EVM_CHAIN} {EVM_DEST_ADDR} uaxl --from my_account
@@ -16,7 +16,7 @@ echo $KEYRING_PASSWORD | ~/.axelar_testnet/bin/axelard tx axelarnet link {EVM_CH
Let us explain the changes:
-- **Keyring password.** `echo $KEYRING_PASSWORD` : Commands that use `tx` to post a signed transaction to the network require a password to unlock the keyring. For simplicity documentation elides the keyring password. See [Keyring backend](keyring) for more info.
+- **Keyring password.** `echo $KEYRING_PASSWORD` : Commands that use `tx` to post a signed transaction to the network require a password to unlock the keyring. For simplicity documentation elides the keyring password. See [Keyring backend](/node/keyring/) for more info.
- **Path to `axelard`.** `~/.axelar_testnet/bin/axelard` : You can avoid the need to type the full path to `axelard` by putting `axelard` in your `PATH` environment variable or defining a shell alias.
- **Gas.** `--gas auto --gas-adjustment 1.5` : Commands that use `tx` to post a signed transaction to the network must pay transaction fees called _gas_. By default `axelard` estimates the gas fee but sometimes this estimation is inaccurate and the transaction fails due to insufficient gas fee. These gas flags instruct `axelard` to estimate gas more accurately, then increase the maximum gas for the transaction by a factor you specify (`1.5` in this case) so that your transaction is more likely to have sufficient gas even if actual network fees exceed the estimate. For simplicity documentation elides these flags.
- **Chain ID.** `--chain-id axelar-testnet-lisbon-3` : Commands that use `tx` to post a signed transaction to the network must specify the `chain-id` for the transaction. You could instead set the `AXELARD_CHAIN_ID` environment variable.
diff --git a/src/pages/node/config-node.mdx b/src/content/docs/node/config-node.mdx
similarity index 86%
rename from src/pages/node/config-node.mdx
rename to src/content/docs/node/config-node.mdx
index a35e123d3..40d8aaf30 100644
--- a/src/pages/node/config-node.mdx
+++ b/src/content/docs/node/config-node.mdx
@@ -1,16 +1,17 @@
# Node configuration
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
## Prerequisites
- **Operating system:** MacOS(x86 intel chip) or Ubuntu (tested on 18.04).
- **Hardware:** 4 cores, 8-16GB RAM, 512 GB drive, arm64 or amd64. Recommended 6-8 cores, 16-32 GB RAM, 1 TB+ drive.
- Increase the maximum number of open files on your system. Example: `ulimit -n 16384`. You may wish to add this command to your shell profile so that you don't need to execute it next time you restart your machine.
-- [CLI configuration](config-cli).
+- [CLI configuration](/node/config-cli/).
- Tip: Planning to run your own validator? Validators have different hardware requirements. See [Validator setup](../validator/setup/overview).
+ Tip: Planning to run your own validator? Validators have different hardware
+ requirements. See [Validator setup](/validator/setup/overview/).
## Download binaries and initialize configuration
@@ -44,10 +45,13 @@ gpg --verify [axelard_binary_signature_path] [axelard_binary_path]
```
On github the signatures are attached to the releases. To download the signatures from the axelar-releases AWS Bucket, you can add `.asc` to the end of the binary URL. For example, if the path of the binary is:
+
```bash
https://axelar-releases.s3.us-east-2.amazonaws.com/axelard/v0.26.0/axelard-darwin-arm64-v0.26.0
```
+
The path for the signature will be:
+
```bash
https://axelar-releases.s3.us-east-2.amazonaws.com/axelard/v0.26.0/axelard-darwin-arm64-v0.26.0.asc
```
@@ -56,10 +60,10 @@ https://axelar-releases.s3.us-east-2.amazonaws.com/axelard/v0.26.0/axelard-darwi
By default the `setup-node.sh` script sets the home directory for your node as follows:
-| Network | Home directory path |
-| --------- | --------------------- |
-| mainnet | `$HOME/.axelar` |
-| testnet | `$HOME/.axelar_testnet` |
+| Network | Home directory path |
+| ------- | ----------------------- |
+| mainnet | `$HOME/.axelar` |
+| testnet | `$HOME/.axelar_testnet` |
On a fresh install `setup-node.sh` puts the following in your node's home directory:
@@ -73,5 +77,7 @@ On a fresh install `setup-node.sh` puts the following in your node's home direct
│ ├── config.toml
│ ├── genesis.json
│ └── seeds.toml
+├── lib
+│ └── libwasmvm.${arch}.so
└── logs
```
diff --git a/src/pages/node/join-genesis.mdx b/src/content/docs/node/join-genesis.mdx
similarity index 72%
rename from src/pages/node/join-genesis.mdx
rename to src/content/docs/node/join-genesis.mdx
index 1aedcaed8..802987b0e 100644
--- a/src/pages/node/join-genesis.mdx
+++ b/src/content/docs/node/join-genesis.mdx
@@ -1,36 +1,43 @@
# Genesis sync
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
-import UpgradePath from '/src/upgrade-path.md';
-import UpgradePathTestnet from '/src/upgrade-path-testnet.md';
+import UpgradePathTestnet from "/src/upgrade-path-testnet.md";
+import UpgradePath from "/src/upgrade-path.md";
Start your Axelar node and download the blockchain from scratch.
- Tip: Looking for instructions using the old script `node.sh`? See [here](join-old).
+ Tip: Looking for instructions using the old script `node.sh`? See
+ [here](/node/join-old/).
- Tip: These instructions synchronize your Axelar node from scratch using the Axelar peer-to-peer network. You can synchronize your node more quickly by downloading a recent snapshot of the blockchain as per [Quick sync](join).
+ Tip: These instructions synchronize your Axelar node from scratch using the
+ Axelar peer-to-peer network. You can synchronize your node more quickly by
+ downloading a recent snapshot of the blockchain as per [Quick
+ sync](/node/join/).
## Prerequisites
-- [CLI configuration](config-cli).
+- [CLI configuration](/node/config-cli/).
- Ensure AXELARD_HOME variable is set in your current session. See https://docs.axelar.dev/node/config-node#home-directory (example AXELARD_HOME="$HOME/.axelar").
## Follow the upgrade path
-Configure your system as per [Node configuration](config-node) except specify the correct version of `axelard` according to your network and position in the upgrade path:
+Configure your system as per [Node configuration](/node/config-node/) except specify the correct version of `axelard` according to your network and position in the upgrade path:
+
+
-
+
+
@@ -48,13 +55,17 @@ setup-node.sh will download axelard binary version you specified in "$AXELARD_HO
-rwxr-xr-x 1 kalid staff 70832530 Jul 6 11:04 axelard-v0.13.6
lrwxr-xr-x 1 kalid staff 48 Jul 6 11:04 axelard -> /Users/kalid/.axelar_testnet/bin/axelard-v0.13.6
```
-
+
- ./scripts/setup-node.sh -n mainnet -a v0.10.7
+```bash
+./scripts/setup-node.sh -n mainnet -a v0.10.7
+```
- ./scripts/setup-node.sh -n testnet -a v0.13.6
+```bash
+./scripts/setup-node.sh -n testnet -a v0.13.6
+```
diff --git a/src/pages/node/join-old.mdx b/src/content/docs/node/join-old.mdx
similarity index 80%
rename from src/pages/node/join-old.mdx
rename to src/content/docs/node/join-old.mdx
index 3e9004f6c..70815edf3 100644
--- a/src/pages/node/join-old.mdx
+++ b/src/content/docs/node/join-old.mdx
@@ -1,11 +1,14 @@
# Old instructions: Quick sync (recommended)
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Start your Axelar node and download the blockchain.
- Tip: These instructions synchronize your Axelar node quickly by downloading a recent snapshot of the blockchain. If instead you prefer to synchronize your Axelar node using the Axelar peer-to-peer network then see [Genesis sync](./join-genesis)
+ Tip: These instructions synchronize your Axelar node quickly by downloading a
+ recent snapshot of the blockchain. If instead you prefer to synchronize your
+ Axelar node using the Axelar peer-to-peer network then see [Genesis
+ sync](/node/join-genesis/)
## Prerequisites
@@ -16,11 +19,11 @@ Start your Axelar node and download the blockchain.
- Install [`jq`](https://stedolan.github.io/jq/download/).
- Install `lz4`: [MacOS](https://formulae.brew.sh/formula/lz4) | [Ubuntu](https://snapcraft.io/install/lz4/ubuntu)
- Increase the maximum number of open files on your system. Example: `ulimit -n 16384`. You may wish to add this command to your shell profile so that you don't need to execute it next time you restart your machine.
-- You have configured your environment for `axelard` CLI commands as per [Configure your environment](/node/config-node).
+- You have configured your environment for `axelard` CLI commands as per [Configure your environment](/node/config-node/).
## Choose a keyring password
-Your Axelar keyring is encrypted with a password you choose. Learn more about keyring passwords at [Keyring backend](/node/keyring).
+Your Axelar keyring is encrypted with a password you choose. Learn more about keyring passwords at [Keyring backend](/node/keyring/).
In what follows you will execute a shell script `node.sh` to join the Axelar network. Your keyring password is supplied to `node.sh` via a `KEYRING_PASSWORD` environment variable. The script `node.sh` enforces an 8-character minimum for your keyring password.
@@ -32,12 +35,14 @@ Clone the [`axelerate-community`](https://github.com/axelarnetwork/axelarate-com
git clone https://github.com/axelarnetwork/axelarate-community.git
cd axelarate-community
```
-
+
Launch a new Axelar mainnet node with version `0.10.7` of axelar-core:
-
./scripts/node.sh -a v0.10.7 -n mainnet
+```bash
+./scripts/node.sh -a v0.10.7 -n mainnet
+```
Your Axelar node will initialize your data folder `~/.axelar`
Launch a new Axelar testnet node with version `0.13.6` of axelar-core:
-
./scripts/node.sh -a v0.13.6 -n testnet
+```bash
+./scripts/node.sh -a v0.13.6 -n testnet
+```
Your Axelar node will initialize your data folder `~/.axelar_testnet`
~/.axelar/validator.txt
-
+ ```bash
+ ~/.axelar/validator.txt
+ ```
- ~/.axelar_testnet/validator.txt
-
+```bash
+~/.axelar_testnet/validator.txt
+ ```
@@ -76,11 +85,15 @@ BACKUP but do NOT DELETE the Tendermint consensus secret key (this is needed on
- ~/.axelar/.core/config/priv_validator_key.json
+```bash
+~/.axelar/.core/config/priv_validator_key.json
+ ```
- ~/.axelar_testnet/.core/config/priv_validator_key.json
+ ```bash
+ ~/.axelar_testnet/.core/config/priv_validator_key.json
+ ```
@@ -93,11 +106,15 @@ In a new terminal window:
- tail -f ~/.axelar/logs/axelard.log
+```bash
+tail -f ~/.axelar/logs/axelard.log
+ ```
- tail -f ~/.axelar_testnet/logs/axelard.log
+```bash
+tail -f ~/.axelar_testnet/logs/axelard.log
+```
@@ -118,15 +135,19 @@ Delete your `data` directory:
- rm -r ~/.axelar/.core/data
+ ```bash
+ rm -r ~/.axelar/.core/data
+ ```
- rm -r ~/.axelar_testnet/.core/data
+ ```bash
+ rm -r ~/.axelar_testnet/.core/data
+ ```
-
+
# Download the latest Axelar blockchain snapshot
Download the latest Axelar blockchain snapshot for your chosen network (testnet or mainnet) from a provider:
@@ -145,12 +166,16 @@ Decompress the downloaded snapshot into your `data` directory:
- lz4 -dc --no-sparse \{SNAPSHOT_FILE
- | tar xfC - ~/.axelar/.core
+ ```bash
+ lz4 -dc --no-sparse \{SNAPSHOT_FILE
+ | tar xfC - ~/.axelar/.core
+ ```
- lz4 -dc --no-sparse \{SNAPSHOT_FILE
- | tar xfC - ~/.axelar_testnet/.core
+ ```bash
+ lz4 -dc --no-sparse \{SNAPSHOT_FILE
+ | tar xfC - ~/.axelar_testnet/.core
+ ```
@@ -160,11 +185,15 @@ Resume your Axelar node with the latest version of axelar-core:
- ./scripts/node.sh -n mainnet
+ ```bash
+ ./scripts/node.sh -n mainnet
+ ```
- ./scripts/node.sh -n testnet
+ ```bash
+ ./scripts/node.sh -n testnet
+ ```
@@ -192,4 +221,4 @@ Congratulations! You joined the Axelar network and downloaded the blockchain.
Learn what you can do with Axelar:
-- [Basic node management](./basic)
+- [Basic node management](/node/basic/)
diff --git a/src/pages/node/join.mdx b/src/content/docs/node/join.mdx
similarity index 74%
rename from src/pages/node/join.mdx
rename to src/content/docs/node/join.mdx
index 62976d8cb..fe283be18 100644
--- a/src/pages/node/join.mdx
+++ b/src/content/docs/node/join.mdx
@@ -1,29 +1,36 @@
# Quick sync
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Start your Axelar node using a snapshot.
- Tip: Looking for instructions using the old script `node.sh`? See [here](join-old).
+ Tip: Looking for instructions using the old script `node.sh`? See
+ [here](/node/join-old/).
- Tip: These instructions synchronize your Axelar node quickly by downloading a recent snapshot of the blockchain. If instead you prefer to synchronize your Axelar node using the Axelar peer-to-peer network then see [Genesis sync](join-genesis)
+ Tip: These instructions synchronize your Axelar node quickly by downloading a
+ recent snapshot of the blockchain. If instead you prefer to synchronize your
+ Axelar node using the Axelar peer-to-peer network then see [Genesis
+ sync](/node/join-genesis/)
## Prerequisites
-- Configure your environment as per [CLI configuration](config-cli) and [Node configuration](config-node).
-- Ensure `AXELARD_HOME` variable is set in your current session. See [node config](https://docs.axelar.dev/node/config-node#home-directory) (e.g. `AXELARD_HOME="$HOME/.axelar"`).
+- Configure your environment as per [CLI configuration](/node/config-cli/) and [Node configuration](/node/config-node/).
+- Ensure `AXELARD_HOME` variable is set in your current session. See [node config](/node/config-node#home-directory) (e.g. `AXELARD_HOME="$HOME/.axelar"`).
## Download the latest Axelar blockchain snapshot
Download the latest Axelar blockchain snapshot for your chosen network (testnet or mainnet) from a provider:
-- [bwarelabs.com](https://bwarelabs.com/snapshots)
- [quicksync.io](https://quicksync.io/networks/axelar.html)
-- [staketab.com](https://services.staketab.com/snapshots/axelar)
+
+
+ Axelar does not support state sync, so a snapshot should be more than 100GB in
+ size.
+
The following instructions assume you downloaded the `pruned` snapshot from `quicksync.io`.
diff --git a/src/pages/node/keyring.mdx b/src/content/docs/node/keyring.mdx
similarity index 77%
rename from src/pages/node/keyring.mdx
rename to src/content/docs/node/keyring.mdx
index dc8507a07..c5b3e52a6 100644
--- a/src/pages/node/keyring.mdx
+++ b/src/content/docs/node/keyring.mdx
@@ -1,20 +1,23 @@
# Keyring backend
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
-Many Axeler CLI commands require an Axelar account controlled by a secret key. Your secret key must be stored securely so as to minimize the risk of exposure to an attacker.
+Many Axelar CLI commands require an Axelar account controlled by a secret key. Your secret key must be stored securely so as to minimize the risk of exposure to an attacker.
Like every Cosmos-based network, Axelar nodes store secret keys in a _keyring_. The keyring can be configured with one of several _backend_ implementations. Learn more about keyring backend configuration from the [Cosmos keyring documentation](https://docs.cosmos.network/v0.44/run-node/keyring.html).
Axelar nodes use the `file` keyring backend by default. This means that your secret keys are stored in a password-encrypted file on disk. Under the `file` backend, you must provide your keyring password each time you execute certain Axelar CLI commands.
- Protect your keyring password: There are several methods to provide your password for Axelar CLI commands. Each method comes with its own security and convenience properties. Whichever method you choose, be sure to follow best practices to keep your keyring password safe.
+ Protect your keyring password: There are several methods to provide your
+ password for Axelar CLI commands. Each method comes with its own security and
+ convenience properties. Whichever method you choose, be sure to follow best
+ practices to keep your keyring password safe.
## Prerequisites
-- Configure your environment as per [CLI configuration](config-cli) and [Node configuration](config-node).
+- Configure your environment as per [CLI configuration](/node/config-cli/) and [Node configuration](/node/config-node/).
- Ensure AXELARD_HOME variable is set in your current session. See https://docs.axelar.dev/node/config-node#home-directory (example AXELARD_HOME="$HOME/.axelar").
## Manual password entry
@@ -28,7 +31,7 @@ Enter keyring passphrase: {TYPE_YOUR_PASSWORD_HERE}
## Automatic password entry
-It can be inconvenient to type your password for each Axlear CLI command, especially if you wish to automate CLI commands.
+It can be inconvenient to type your password for each Axelar CLI command, especially if you wish to automate CLI commands.
Suppose your keyring password is stored in a shell environment variable called `KEYRING_PASSWORD`. You could prefix your CLI commands with `echo $KEYRING_PASSWORD | `. For example:
@@ -37,7 +40,9 @@ echo $KEYRING_PASSWORD | $AXELARD_HOME/bin/axelard keys show my_account -a
```
- Danger: If an attacker were to gain access to your system then the attacker could read your keyring password from your shell environment and then use it to expose your secret keys.
+ Danger: If an attacker were to gain access to your system then the attacker
+ could read your keyring password from your shell environment and then use it
+ to expose your secret keys.
## Axelar documentation elides password entry
diff --git a/src/content/docs/resources/axelar-commandid.mdx b/src/content/docs/resources/axelar-commandid.mdx
new file mode 100644
index 000000000..0fbe38165
--- /dev/null
+++ b/src/content/docs/resources/axelar-commandid.mdx
@@ -0,0 +1,125 @@
+# The Axelar `CommandID`
+
+Ensuring the authenticity and integrity of messages is crucial in cross-chain communication. The `CommandID` in the [Axelar network](https://www.axelar.network/) plays a significant role in this process, acting as a unique identifier for interchain messages.
+
+This guide explains what an Axelar `CommandID` is, how it is generated, and its importance in the [Solidity Axelar GMP SDK](https://github.com/axelarnetwork/axelar-gmp-sdk-solidity).
+
+## What is the Axelar `CommandID`?
+
+Axelar `CommandID` is a unique identifier assigned to each message or command that facilitates interchain communication. It ensures that each message can be tracked, verified, and validated across different blockchain networks, preventing issues such as replay attacks or message tampering.
+
+## How is an Axelar `CommandID` generated?
+
+Generating an Axelar `CommandID` involves combining specific attributes of the message, such as the `sourceChain`, `messageId`, and other relevant data, and then hashing this combination to produce a unique identifier. This process ensures that each `CommandID` is unique for the message it represents.
+
+### Solidity Implementation
+
+In the provided Solidity contract, the `messageToCommandId()` function generates the `CommandID`.
+
+Here's how it works:
+
+```solidity
+/**
+ * @notice Compute the commandId for a message.
+ * @param sourceChain The name of the source chain as registered on Axelar.
+ * @param messageId The unique message id for the message.
+ * @return The commandId for the message.
+ */
+function messageToCommandId(string calldata sourceChain, string calldata messageId) public pure returns (bytes32) {
+ // Axelar doesn't allow `sourceChain` to contain '_', hence this encoding is unambiguous
+ return keccak256(bytes(string.concat(sourceChain, '_', messageId)));
+}
+```
+
+This function takes two parameters: `sourceChain` and `messageId`. It concatenates these parameters with an underscore (`_`) separator, ensuring the combination is unique and unambiguous. The concatenated string is then hashed using `keccak256` to produce the `CommandID`. You can view the source code [here](https://github.com/axelarnetwork/axelar-gmp-sdk-solidity/blob/1db893b373ec9fcd7cf838ebea4b3a7a24585791/contracts/gateway/BaseAmplifierGateway.sol#L103C14-L103C32).
+
+### Go implementation
+
+The `CommandID` is generated similarly by hashing relevant data in the Go implementation.
+
+Here's an example function for generating a `CommandID`:
+
+```go
+// NewCommandID generates a new CommandID using the provided data and chain ID
+func NewCommandID(data []byte, chainID sdk.Int) []byte {
+ return crypto.Keccak256(data, chainID.Bytes())
+}
+```
+
+This function combines the provided data and chain ID, then hashes the combination using `Keccak256()` to produce the `CommandID`. The source code for this can be found [here](https://github.com/axelarnetwork/axelar-core/blob/main/x/evm/types/command.go).
+
+### Example commands
+
+Here are a few examples of command creation in the provided Go code:
+
+- Burn Token:
+
+```go
+// NewBurnTokenCommand creates a command to burn tokens with the given burner's information
+func NewBurnTokenCommand(chainID sdk.Int, keyID multisig.KeyID, height int64, burnerInfo BurnerInfo, isTokenExternal bool) Command {
+ heightBytes := make([]byte, 8)
+ binary.LittleEndian.PutUint64(heightBytes, uint64(height))
+
+ burnTokenMaxGasCost := burnInternalTokenMaxGasCost
+ if isTokenExternal {
+ burnTokenMaxGasCost = burnExternalTokenMaxGasCost
+ }
+
+ return Command{
+ ID: NewCommandID(append(burnerInfo.Salt.Bytes(), heightBytes...), chainID),
+ Type: COMMAND_TYPE_BURN_TOKEN,
+ Params: createBurnTokenParams(burnerInfo.Symbol, common.Hash(burnerInfo.Salt)),
+ KeyID: keyID,
+ MaxGasCost: uint32(burnTokenMaxGasCost),
+ }
+}
+```
+
+- Deploy Token:
+
+```go
+// NewDeployTokenCommand creates a command to deploy a token
+func NewDeployTokenCommand(chainID sdk.Int, keyID multisig.KeyID, asset string, tokenDetails TokenDetails, address Address, dailyMintLimit sdk.Uint) Command {
+ return Command{
+ ID: NewCommandID([]byte(fmt.Sprintf("%s_%s", asset, tokenDetails.Symbol)), chainID),
+ Type: COMMAND_TYPE_DEPLOY_TOKEN,
+ Params: createDeployTokenParams(tokenDetails.TokenName, tokenDetails.Symbol, tokenDetails.Decimals, tokenDetails.Capacity, address, dailyMintLimit),
+ KeyID: keyID,
+ MaxGasCost: deployTokenMaxGasCost,
+ }
+}
+```
+
+## Importance of the `CommandID` for message verification
+
+The `CommandID` is key for verifying the authenticity and integrity of interchain messages. When a message is received on the destination chain, the `CommandID` allows the system to:
+
+1. **Verify Message Approval:**
+ The `isMessageApproved()` function checks if a message has been approved by comparing the stored message hash with the calculated hash using the `CommandID`.
+ ```solidity
+ function isMessageApproved(
+ string calldata sourceChain,
+ string calldata messageId,
+ string calldata sourceAddress,
+ address contractAddress,
+ bytes32 payloadHash
+ ) external view override returns (bool) {
+ bytes32 commandId = messageToCommandId(sourceChain, messageId);
+ return _isMessageApproved(commandId, sourceChain, sourceAddress, contractAddress, payloadHash);
+ }
+ ```
+2. **Prevent Replay Attacks:**
+ The `validateMessage()` function ensures that a message can only be executed once by marking it as executed after validation.
+ ```solidity
+ function validateMessage(
+ string calldata sourceChain,
+ string calldata messageId,
+ string calldata sourceAddress,
+ bytes32 payloadHash
+ ) external override returns (bool valid) {
+ bytes32 commandId = messageToCommandId(sourceChain, messageId);
+ valid = _validateMessage(commandId, sourceChain, sourceAddress, payloadHash);
+ }
+ ```
+
+Refer to more detailed information on how Axelar verifies GMP transactions [here](/dev/general-message-passing/verify-gmp-tx/).
diff --git a/src/content/docs/resources/axelarscan/axelarscan-add.mdx b/src/content/docs/resources/axelarscan/axelarscan-add.mdx
new file mode 100644
index 000000000..f8cd6902e
--- /dev/null
+++ b/src/content/docs/resources/axelarscan/axelarscan-add.mdx
@@ -0,0 +1,49 @@
+# Label Address in Axelarscan
+
+## Overview
+
+The ability to add metadata about important on-chain addresses allows users to have a simpler experience seeing on-chain activity for these addresses.
+
+Rather than seeing a raw address on Axelarscan, users will be able to see a customized photo and name for a given address:
+
+
+
+## How to Add
+
+To add a new address to the list of tracked addresses in the [accounts directory](https://github.com/axelarnetwork/axelarscan-ui/blob/main/src/data/accounts/index.js), send a [pull request](https://github.com/axelarnetwork/axelarscan-ui/pulls) to the [Axelarscan-UI repository](https://github.com/axelarnetwork/axelarscan-ui/tree/main).
+
+Include the following parameters:
+
+- Address: The address you are looking to add.
+- Name: The name you want to be displayed for your address.
+- Image: The image you want to appear alongside the name.
+- Environment: Whether this address is for mainnet or testnet transactions.
+
+## Example
+
+The following example adds the Axelar Governance Address referenced in the image above to the accounts directory.
+
+```javascript
+export default [
+ {
+ address: "axelar10d07y265gmmuvt4z0w9aw880jnsr700j7v9daj",
+ name: "Axelar Governance",
+ image: "/logos/accounts/axelarnet.svg",
+ },
+];
+```
+
+No `environment` was set, so this address will appear on both [mainnet](https://axelarscan.io/account/axelar10d07y265gmmuvt4z0w9aw880jnsr700j7v9daj) and [testnet](https://testnet.axelarscan.io/account/axelar10d07y265gmmuvt4z0w9aw880jnsr700j7v9daj).
+
+Add the following to include the address on mainnet only:
+
+```javascript
+export default [
+ {
+ address: "axelar10d07y265gmmuvt4z0w9aw880jnsr700j7v9daj",
+ name: "Axelar Governance",
+ image: "/logos/accounts/axelarnet.svg",
+ environment: "mainnet",
+ },
+];
+```
diff --git a/src/pages/dev/general-message-passing/monitoring.mdx b/src/content/docs/resources/axelarscan/monitoring.mdx
similarity index 75%
rename from src/pages/dev/general-message-passing/monitoring.mdx
rename to src/content/docs/resources/axelarscan/monitoring.mdx
index f82296fe2..0a8efb649 100644
--- a/src/pages/dev/general-message-passing/monitoring.mdx
+++ b/src/content/docs/resources/axelarscan/monitoring.mdx
@@ -1,15 +1,17 @@
# Monitoring state of GMP transactions
-Axelar provides two options to check each GMP transaction status:
-1. The Axelarscan UI.
+Axelar provides two options to check each GMP transaction status:
+
+1. The Axelarscan UI.
2. The [AxelarJS SDK](/dev/axelarjs-sdk/tx-status-query-recovery).
## 1. Axelarscan UI
+
Anyone can view General Message Passing calls in realtime on Axelarscan: [Mainnet](https://axelarscan.io/gmp) | [Testnet](https://testnet.axelarscan.io/gmp).
-You can also search for a particular transfer by a transaction hash or a sender address via the search bar.
+You can also search for a particular transfer by a transaction hash or a sender address via the search bar.
Each GMP call comprises five statuses, as described below.
@@ -21,11 +23,15 @@ Each GMP call comprises five statuses, as described below.
- **EXECUTED** informs the executed result whether it is successful or not. If you see an error message in this section, we suggest following this [guide](/dev/general-message-passing/debug/error-debugging) to find the root cause and recover the transfer.
- **GAS REFUNDED** provides the refund information (if any), including the amount of gas paid, the amount of gas used, the refund amount, etc.
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
- If the `Insufficient Fee` tag appears, it means that the prepaid gas is not enough to relay the transaction. Please follow the [Increase gas payment to the gas receiver on the source chain](/dev/general-message-passing/recovery#increase-gas-payment-to-the-gas-receiver-on-the-source-chain) section to recover the transfer.
- 
+ If the `Insufficient Fee` tag appears, it means that the prepaid gas is not
+ enough to relay the transaction. Please follow the [Increase gas payment to
+ the gas receiver on the source
+ chain](/dev/general-message-passing/debug/transaction-recovery/#increase-gas-payment-to-the-gas-receiver-on-the-source-chain)
+ section to recover the transfer.
+ 
## 2. AxelarJS SDK
diff --git a/src/pages/bug-bounty.mdx b/src/content/docs/resources/bug-bounty.mdx
similarity index 84%
rename from src/pages/bug-bounty.mdx
rename to src/content/docs/resources/bug-bounty.mdx
index 11643d442..9ef86d352 100644
--- a/src/pages/bug-bounty.mdx
+++ b/src/content/docs/resources/bug-bounty.mdx
@@ -1,11 +1,11 @@
# Bug bounty
-There are two ways to disclose security vulnerabilities to the Axelar team:
+There are two ways to responsibly disclose security vulnerabilities:
1. Submit a report to our Immunefi bug bounty program.
-2. Send email to `security@axelar.network` describing the vulnerability.
+2. Send an email to `security@interoplabs.io` describing the vulnerability.
-Even if your security vulnerability is not eligible for a bounty from the bug bounty program (option 1) the Axelar team might decide to award a bounty for a security vulnerability submitted by email to `security@axelar.network` (option 2).
+Even if your security vulnerability is not eligible for a bounty from the bug bounty program (option 1) the Axelar team might decide to award a bounty for a security vulnerability submitted by email to `security@interoplabs.io` (option 2).
## Vulnerability Criteria
diff --git a/src/content/docs/resources/community/community-pool-proposals.mdx b/src/content/docs/resources/community/community-pool-proposals.mdx
new file mode 100644
index 000000000..3218e6f42
--- /dev/null
+++ b/src/content/docs/resources/community/community-pool-proposals.mdx
@@ -0,0 +1,90 @@
+# Community Pool Proposals
+
+import { Callout } from "/src/components/callout";
+
+Axelar has an on-chain, governance-managed [pool of funds](https://www.mintscan.io/axelar/proposals) reserved for community projects that benefit developers and users. Proposals require a 2,000 AXL deposit. Anyone from the Axelar community can submit a proposal for consideration.
+
+## Prerequisites
+
+- Access to the [Axelar command-line interface](/learn/cli)
+- 2,000 AXL for each proposal, either from a local wallet or through a community member who can fund the proposal within one hour of submission
+- A running [RPC endpoint](/resources/rpc/resources) or [Axelar node](/node/config-node)
+
+## Get funding for a project
+
+1. Create a project introduction on the [Governance and Grants section](https://community.axelar.network/c/governance2/33) of the [Axelar Governance Forum](https://community.axelar.network/) using the [provided template](https://community.axelar.network/t/community-pool-grants-program/2271#grant-template-3). This introduction helps the community to understand your project.
+1. The introduction will be open on the Forum for **7 days**. During this time, community members can ask questions and give feedback, and you will be able to edit the post. Please engage with all responses, and be prepared to amend the proposal where necessary.
+1. Once the feedback window has passed, you can submit a proposal for an on-chain governance vote using the [Axelar CLI](/learn/cli/) (`axelard`). Include a brief summary of your proposal, along with a link to the project introduction.
+1. After submission, proposals will be voted on by all token holders for **3 days** (**72 hours**). Validators can vote on behalf of the token holders if they abstain from participating, but the token holder’s vote will overwrite their validator’s vote for their amount of stake.
+1. If the vote passes, funds will be sent from the community pool to the Axelar wallet associated with the successful proposal ([example](https://www.mintscan.io/axelar/proposals/29)), along with a refund of the 2,000 AXL deposit. The Axelar Network currently requires a 33.4% quorum of staked tokens (query with `axelard q gov params`).
+
+
+ **All proposals that reach quorum will have their deposit refunded, even if
+ the vote fails.** If a proposal does not reach quorum, the deposit will not be
+ refunded.
+
+
+## Proposal Types
+
+- `CommunityPoolSpend` — For general community proposals
+- `SoftwareUpgrade` — For node software updates
+- `ParameterChange` — For changes to the configuration of the Axelar network
+
+## Create a local wallet
+
+You will need a local wallet for all transactions associated with the proposal. This wallet will receive the funds and deposit refund if the proposal passes.
+
+To create a local wallet, run:
+
+```bash
+axelard keys add wallet
+```
+
+This creates an account named `wallet`. Enter (create) a passphrase. The `address` returned will be your new local wallet address. To display your local wallet address(es), run:
+
+```bash
+axelard keys list
+```
+
+## Fund your local wallet
+
+Once you’ve created a local wallet, you’ll need to fund it with 2,000 AXL for the deposit. You can send funds from your Keplr wallet or from a centralized exchange (CEX) and check your wallet’s balance on Axelarscan. You can also [send AXL from another local wallet](https://github.com/axelarnetwork/axelar-core/blob/main/docs/cli/axelard_tx_bank_send.md) with the following command:
+
+```bash
+axelard tx bank send [account_with_fund_address] [wallet_address] 2000000000uaxl # 20000000000uaxl = 20000AXL
+```
+
+## Submit a proposal
+
+1. In your terminal, create a variable for the proposal such as GOV_PROPOSAL and set its value to the path of your JSON file:Once the 7-day feedback period has passed, create a JSON file with the proposal and save it to a file, such as `gov-proposal.json`:
+
+ ```bash
+ {
+ "title": "[title]",
+ "description": "This proposal withdraw funds from community pool for as mentioned here:\n[link]",
+ "amount": "[amount_in_uaxl]", # 20000000000uaxl = 20000AXL
+ "recipient": "[fund_recipient_address]",
+ "deposit": "2000000000uaxl"
+ }
+ ```
+
+1. In your terminal, create a variable for the proposal such as GOV_PROPOSAL and set its value to the path of your JSON file:
+
+ ```bash
+ export GOV_PROPOSAL="/Users/you/Projects/Axelar/gov-proposal.json"
+ ```
+
+1. [Submit the proposal](https://github.com/axelarnetwork/axelar-core/blob/main/docs/cli/axelard_tx_gov_submit-proposal.md) as a JSON file:
+
+ ```bash
+ export CHAIN_ID="axelar-testnet-lisbon-3"
+ export RPC="https://axelartest-rpc.quickapi.com/"
+ ```
+
+ ```bash
+ $ axelard tx gov submit-proposal community-pool-spend $GOV_PROPOSAL \
+ --from wallet \
+ --chain-id $CHAIN_ID \
+ --node $RPC \
+ --gas auto --gas-adjustment 1.2
+ ```
diff --git a/src/pages/resources/mainnet.mdx b/src/content/docs/resources/contract-addresses/mainnet.mdx
similarity index 64%
rename from src/pages/resources/mainnet.mdx
rename to src/content/docs/resources/contract-addresses/mainnet.mdx
index 8e00361d5..613a638be 100644
--- a/src/pages/resources/mainnet.mdx
+++ b/src/content/docs/resources/contract-addresses/mainnet.mdx
@@ -1,34 +1,48 @@
+---
+title: Axelar Mainnet Contract Addresses
+description: Official Axelar mainnet contract addresses, including gateways and tokens across supported blockchains. Use this reference for secure cross-chain integration.
+---
+
# Mainnet
-import { Callout } from '/src/components/callout'
+import { Callout } from '/src/components/callout';
-import IBCChannels from '/src/components/ibc/channels'
-import TransferFeeCalculator from '/src/components/transfer-fee/calculator'
-import EVMChains from '/src/components/evm/chains'
-import EVMAssets from '/src/components/evm/assets'
-import UpgradePath from '/src/upgrade-path.md'
+import IBCChannels from '/src/components/ibc/channels';
+import TransferFeeCalculator from '/src/components/transfer-fee/calculator';
+import EVMChains from '/src/components/evm/chains';
+import EVMAssets from '/src/components/evm/assets';
+import UpgradePath from '/src/upgrade-path.md';
+import { AXELARD, TOFND } from '/src/config/variables';
-| Variable | Value |
-| --------------------- | --------- |
-| `axelar-core` version | `v0.34.1` |
-| `vald` version | `v0.34.1` |
-| `tofnd` version | `v0.10.1` |
+| Variable | Value |
+| --------------------- | --------------- |
+| `chain-id` | `axelar-dojo-1` |
+| `axelar-core` version | {AXELARD} |
+| `vald` version | {AXELARD} |
+| `tofnd` version | {TOFND} |
-## EVM contract addresses
+## Contract addresses
-
+
+
`Create3 Address Deployer`: `0x6513Aedb4D1593BA12e50644401D976aebDc90d8`
`Create2 Address Deployer`: `0x98b2920d53612483f91f12ed7754e51b4a77919e`
+`Interchain Token Service`: [`0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C`](https://etherscan.io/address/0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C)
+
+`Interchain Token Factory`: [`0x83a93500d23Fbc3e82B410aD07A6a9F7A0670D66`](https://etherscan.io/address/0x83a93500d23Fbc3e82B410aD07A6a9F7A0670D66)
+
- ### Assets
+ ### Assets
+
Learn more about [wrapped assets like axlUSDC](/learn/axlusdc).
+
@@ -82,4 +96,13 @@ The gas relayer fee does not include any transaction fee assessed by the source
## Upgrade Path
+
+
+
+
+
+
+
+
+
diff --git a/src/content/docs/resources/contract-addresses/testnet.mdx b/src/content/docs/resources/contract-addresses/testnet.mdx
new file mode 100644
index 000000000..de59e8a35
--- /dev/null
+++ b/src/content/docs/resources/contract-addresses/testnet.mdx
@@ -0,0 +1,106 @@
+---
+title: Axelar Testnet Contract Addresses
+description: Official Axelar testnet contract addresses for gateways, tokens, and infrastructure. Ideal for testing cross-chain integrations before mainnet deployment.
+---
+
+# Testnet
+
+import { Callout } from "/src/components/callout";
+import IBCChannels from "/src/components/ibc/channels";
+import TransferFeeCalculator from "/src/components/transfer-fee/calculator";
+import EVMChains from "/src/components/evm/chains";
+import EVMAssets from "/src/components/evm/assets";
+import UpgradePathTestnet from "/src/upgrade-path-testnet.md";
+import { AXELARD_TESTNET, TOFND_TESTNET } from "/src/config/variables";
+
+| Variable | Value |
+| --------------------- | --------------------------------------------------------------------------------------------------------------------------------- |
+| `chain-id` | `axelar-testnet-lisbon-3` |
+| `axelar-core` version | v{AXELARD_TESTNET} |
+| `vald` version | v{AXELARD_TESTNET} |
+| `tofnd` version | v{TOFND_TESTNET} |
+| amplifier contracts | see [testnet.json](https://github.com/axelarnetwork/axelar-contract-deployments/blob/main/axelar-chains-config/info/testnet.json) |
+
+## Contract addresses
+
+
+
+
+`Create3 Address Deployer`: `0x6513Aedb4D1593BA12e50644401D976aebDc90d8`
+
+`Create2 Address Deployer`: `0x98b2920d53612483f91f12ed7754e51b4a77919e`
+
+`Interchain Token Service`: [`0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C`](https://sepolia.etherscan.io/address/0xB5FB4BE02232B1bBA4dC8f81dc24C26980dE9e3C)
+
+`Interchain Token Factory`: [`0x83a93500d23Fbc3e82B410aD07A6a9F7A0670D66`](https://sepolia.etherscan.io/address/0x83a93500d23Fbc3e82B410aD07A6a9F7A0670D66)
+
+
+
+
+ ## Faucets
+
+The following faucets can be used to obtain tokens for testing. Note that some of them may require an existing balance in your wallet.
+
+- [Polygon](https://faucet.quicknode.com/polygon/mumbai)
+- [Moonbeam](https://faucet.moonbeam.network/)
+- [Fantom](https://faucet.fantom.network/)
+- [Paradigm](https://faucet.paradigm.xyz/)
+- [Lotus](https://faucet.calibration.fildev.network/)
+- [Kava](https://faucet.kava.io/)
+- [Celo](https://faucet.celo.org/celo-sepolia)
+
+
+
+
+ ### Assets Learn more about [wrapped assets like axlUSDC](/learn/axlusdc).
+
+
+
+
+ ## IBC Channels
+
+
+
+## Cross-chain relayer gas fee
+
+The Axelar network charges a _relayer gas fee_ for all cross-chain token transfers in order to pay for network-level transaction ("gas") fees across chains.
+The relayer gas fee amount depends only on:
+
+- the asset
+- the source chain
+- the destination chain
+
+
+ The relayer gas fee does NOT take a percentage from the transfer amount.
+
+
+
+
+
+
+The current gas relayer fee is also available via node query:
+
+```bash
+axelard q nexus transfer-fee [source chain] [destination chain] [amount]
+```
+
+Example: transfer USDC from Avalanche to Osmosis. (The amount here is arbitrary---gas relayer fees do not depend on the amount. `1 USDC = 10^6 uusdc`).
+
+```bash
+axelard q nexus transfer-fee avalanche osmosis 1000000000uusdc
+```
+
+The per-chain gas relayer fee info can be queried via
+
+```bash
+axelard q nexus fee-info avalanche uusdc
+```
+
+If the total amount of a token sent to a deposit address A is NOT greater than the gas relayer fee
+then those deposits will wait in the queue until a future deposit to A brings the total above the fee.
+
+The gas relayer fee does not include any transaction fee assessed by the source chain for transferring tokens into a deposit address. These fees are usually denominated in native tokens on that chain (for e.g. AVAX on Avalanche, ETH on Ethereum).
+
+## Upgrade Path
+
+
diff --git a/src/pages/resources/keplr.mdx b/src/content/docs/resources/keplr.mdx
similarity index 95%
rename from src/pages/resources/keplr.mdx
rename to src/content/docs/resources/keplr.mdx
index 6e381f0f4..eedf23fbd 100644
--- a/src/pages/resources/keplr.mdx
+++ b/src/content/docs/resources/keplr.mdx
@@ -1,8 +1,8 @@
# Add a custom network to Keplr
-import Button from "../../components/keplr/addKeplrWallet";
-import AddKeplr from "../../components/keplr";
-import Form from "../../components/textarea";
+import AddKeplr from "../../../components/keplr";
+import Button from "../../../components/keplr/addKeplrWallet";
+import Form from "../../../components/textarea";
## Don't have the Keplr Browser extension? Add it here:
diff --git a/src/content/docs/resources/mainnet/upgrades/v1.mdx b/src/content/docs/resources/mainnet/upgrades/v1.mdx
new file mode 100644
index 000000000..5ebf7664b
--- /dev/null
+++ b/src/content/docs/resources/mainnet/upgrades/v1.mdx
@@ -0,0 +1,83 @@
+# Mainnet upgrade: v{AXELARD}
+
+import { Callout } from '/src/components/callout';
+import { AXELARD, TOFND } from '/src/config/variables';
+
+## About the mainnet v1.0 upgrade
+
+This release enables mainnet deployment for [Amplifier](/dev/amplifier/introduction).
+
+This release includes the following version updates:
+- `axelard` and `vald` to [1.0.5](https://github.com/axelarnetwork/axelar-core/releases/tag/v1.0.5)
+- `tofnd` to [1.0.1](https://github.com/axelarnetwork/tofnd/releases/tag/v1.0.1)
+
+## Changelog
+
+Changes since 0.35.x:
+
+- Various fixes that improve stability
+- New queries in the axelarnet module to query the IBC path for a chain and the chain by IBC path
+- Added a new message type “BatchRequest”. In contrast to cosmos default behaviour, where the entire tx gets rolled back if there is an error in any of the contained message executions, this batch only rolls back the state for the specific messages that fail and keeps the rest
+- Allow refundable messages to be batched
+- Correctly pass message IDs between core and the new amplifier
+- Add functionality to quickly (de)activate the connection between core and amplifier in case of emergencies
+
+See all the changes in the [`axelar-core` release notes](https://github.com/axelarnetwork/axelar-core/releases).
+
+Upgrade height `14231100` at approximately **2:30PM UTC on August 28th, 2024** ([countdown](https://www.mintscan.io/axelar/block/14231100))
+
+
+As of v{AXELARD}, the `axelard` [binary releases](https://github.com/axelarnetwork/axelar-core/releases) require `GLIBC_2.34`, which is not present on Ubuntu 20.04.
+
+You will need to compile `axelard` from source, or upgrade to Ubuntu 22.04.
+
+
+
+
+ If using the community node setup scripts, please update to the latest commit
+ on `main` first. `wasmvm` lib will be auto-downloaded to `$AXELARD_HOME/lib`
+ but you'll need to add it to `LD_LIBRARY_PATH` before running the script.
+
+
+1. If you're a validator or have delegated to one, you can vote for the upgrade proposal, while it's active, via
+
+```bash
+axelard tx gov vote 221 yes --from validator
+```
+
+2. Wait for the proposed upgrade block, `14231100`. Your node will panic at that block height with a log: `{"level":"error","module":"consensus","err":"UPGRADE \"v1.0\" NEEDED at height: 14216700", ...}`. Stop your node after chain halt.
+
+```bash
+pkill -f 'axelard start'
+# Validators need to also stop vald/tofnd
+pkill -f 'vald-start'
+pkill -f tofnd
+```
+
+3. Backup the state:
+
+```bash
+cp -r ~/.axelar/.core/data ~/.axelar-lisbon-3-upgrade-0.35/.core/data
+```
+
+
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
+
+
+4. Restart your `axelard` node with the new v{AXELARD} build.
+5. If you're a validator also restart `vald` with v{AXELARD} and `tofnd` with v{TOFND}.
+
+Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
+
+```bash
+# in axelarate-community repo (https://github.com/axelarnetwork/axelarate-community)
+git checkout main
+git pull
+KEYRING_PASSWORD="pw-1" ./scripts/node.sh -n testnet -a v1.0.5
+# For validators, restart vald/tofnd
+KEYRING_PASSWORD="pw-1" TOFND_PASSWORD="pw-2" ./scripts/validator-tools-host.sh -n testnet -a v1.0.5 -q v1.0.1
+```
diff --git a/src/content/docs/resources/mainnet/upgrades/v112.mdx b/src/content/docs/resources/mainnet/upgrades/v112.mdx
new file mode 100644
index 000000000..bf2767ed0
--- /dev/null
+++ b/src/content/docs/resources/mainnet/upgrades/v112.mdx
@@ -0,0 +1,62 @@
+# Mainnet upgrade: v1.1
+
+import { Callout } from "/src/components/callout";
+
+Instructions for the `2024-Dec-18` mainnet upgrade to axelar-core `v1.1.2`.
+Release notes can be found [here](https://github.com/axelarnetwork/axelar-core/releases/tag/v1.1.2)
+
+Upgrade height `15890800` [countdown](https://www.mintscan.io/axelar/block/15890800)
+
+## About the v1.1 upgrade
+The `v1.1.2` upgrade is a consensus breaking release for Axelar mainnet. It enables the deployment of ITS Hub on mainnet.
+
+1. If you're a validator or have delegated to one, please vote for the upgrade proposal via
+
+
+```bash
+axelard tx gov vote 257 yes --from validator
+```
+
+
+ `axelard` must be built with `go-1.23` for this release.
+
+
+
+2. Wait for the proposed upgrade block, `15890800`. Your node will panic at that block height with a log: `{"level":"error","module":"consensus","err":"UPGRADE \"v1.1.2\" NEEDED at height: 15890800",`. Stop your node after chain halt.
+
+```bash
+pkill -f 'axelard start'
+# Validators need to also stop vald/tofnd
+pkill -f 'vald-start'
+pkill -f tofnd
+```
+
+3. Backup the state:
+
+```bash
+cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-1.1.2/.core/data
+```
+
+
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
+
+
+4. Restart your node with the new `v1.1.2` build.
+5. If you're a validator also restart `vald` with `v1.1.2` and `tofnd` with `v1.0.1`.
+
+Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
+
+
+
+```bash
+# in axelarate-community repo
+git checkout main
+git pull
+KEYRING_PASSWORD="pw-1" ./scripts/node.sh -n mainnet -a v1.1.2
+# For validators, restart vald/tofnd
+KEYRING_PASSWORD="pw-1" TOFND_PASSWORD="pw-2" ./scripts/validator-tools-host.sh -n mainnet -a v1.1.2 -q v1.0.1
+```
\ No newline at end of file
diff --git a/src/content/docs/resources/mainnet/upgrades/v121.mdx b/src/content/docs/resources/mainnet/upgrades/v121.mdx
new file mode 100644
index 000000000..c23869fe7
--- /dev/null
+++ b/src/content/docs/resources/mainnet/upgrades/v121.mdx
@@ -0,0 +1,64 @@
+# Mainnet upgrade: v1.2
+
+import { Callout } from "/src/components/callout";
+
+Instructions for the `v1.2` mainnet upgrade to axelar-core `v1.2.1`.
+Release can be found [here](https://github.com/axelarnetwork/axelar-core/releases/tag/v1.2.1)
+
+Upgrade height `16837700` [countdown](https://www.mintscan.io/axelar/block/16837700)
+
+## About the v1.2 upgrade
+The `v1.2` upgrade is a consensus breaking release for Axelar mainnet.
+
+1. If you're a validator or have delegated to one, please vote for the upgrade proposal via
+
+```bash
+axelard tx gov vote 284 yes --from validator
+```
+
+
+ `axelard` must be built with `go-1.23` for this release.
+
+ Node operators using binaries need to update `wasmvm` from `v1.3.1` to `v1.5.8` [libwasmvm.x86_64.so](https://github.com/CosmWasm/wasmvm/releases/tag/v1.5.8), and add the folder containing the library to `LD_LIBRARY_PATH`.
+
+ If using the community node setup scripts, please update to the latest commit on `main` first.
+ `wasmvm` lib will be auto-downloaded to `$AXELARD_HOME/lib` but you'll need to add it to `LD_LIBRARY_PATH` before running the script.
+
+
+
+2. Wait for the proposed upgrade block, `16837700`. Your node will panic at that block height with a log: `{"level":"error","module":"consensus","err":"UPGRADE \"v1.2\" NEEDED at height: 16837700",`. Stop your node after chain halt.
+
+```bash
+pkill -f 'axelard start'
+# Validators need to also stop vald/tofnd
+pkill -f 'vald-start'
+pkill -f tofnd
+```
+
+3. Backup the state:
+
+```bash
+cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-1.2.1/.core/data
+```
+
+
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
+
+
+4. Restart your `axelard` node with the new `v1.2.1` build.
+5. If you're a validator also restart `vald` with `v1.2.1` and `tofnd` with `v1.0.1`.
+
+Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
+
+```bash
+# in axelarate-community repo
+git checkout main
+git pull
+KEYRING_PASSWORD="pw-1" ./scripts/node.sh -n mainnet -a v1.2.1
+# For validators, restart vald/tofnd
+KEYRING_PASSWORD="pw-1" TOFND_PASSWORD="pw-2" ./scripts/validator-tools-host.sh -n mainnet -a v1.2.1 -q v1.0.1
+```
diff --git a/src/pages/resources/mainnet/upgrades/v16.mdx b/src/content/docs/resources/mainnet/upgrades/v16.mdx
similarity index 75%
rename from src/pages/resources/mainnet/upgrades/v16.mdx
rename to src/content/docs/resources/mainnet/upgrades/v16.mdx
index 2406a4470..6da26c9d2 100644
--- a/src/pages/resources/mainnet/upgrades/v16.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v16.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.16
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Mar-21` mainnet upgrade to axelar-core `v0.16.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.16/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
4. Restart your node with the new `v0.16.1` build (`tofnd` still uses `v0.8.2`).
@@ -44,4 +48,4 @@ KEYRING_PASSWORD="pw-1" ./scripts/node.sh -n mainnet -a v0.16.1
KEYRING_PASSWORD="pw-1" TOFND_PASSWORD="pw-2" ./scripts/validator-tools-host.sh -a v0.16.1 -n mainnet
```
-The join scripts should automatically pull the new binary from [Mainnet resources](/resources/mainnet). Or you can add the flag `-a v0.16.1` to force a specific version.
\ No newline at end of file
+The join scripts should automatically pull the new binary from [Mainnet Resources](/resources/contract-addresses/mainnet/). Or you can add the flag `-a v0.16.1` to force a specific version.
diff --git a/src/pages/resources/mainnet/upgrades/v17.mdx b/src/content/docs/resources/mainnet/upgrades/v17.mdx
similarity index 81%
rename from src/pages/resources/mainnet/upgrades/v17.mdx
rename to src/content/docs/resources/mainnet/upgrades/v17.mdx
index 38ea2c290..f5695d85e 100644
--- a/src/pages/resources/mainnet/upgrades/v17.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v17.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.17
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Apr-28` mainnet upgrade to axelar-core `v0.17.1`, vald `v0.17.0`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.17/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
4. Restart your node with the new `v0.17.1` build.
diff --git a/src/pages/resources/mainnet/upgrades/v18.mdx b/src/content/docs/resources/mainnet/upgrades/v18.mdx
similarity index 81%
rename from src/pages/resources/mainnet/upgrades/v18.mdx
rename to src/content/docs/resources/mainnet/upgrades/v18.mdx
index b7a568d61..ac8399ecf 100644
--- a/src/pages/resources/mainnet/upgrades/v18.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v18.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.18
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Jun-8` mainnet upgrade to axelar-core `v0.18.3`, vald `v0.18.3`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.18/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
4. Restart your node with the new `v0.18.3` build.
diff --git a/src/pages/resources/mainnet/upgrades/v19.mdx b/src/content/docs/resources/mainnet/upgrades/v19.mdx
similarity index 81%
rename from src/pages/resources/mainnet/upgrades/v19.mdx
rename to src/content/docs/resources/mainnet/upgrades/v19.mdx
index cad96dab2..517d116c0 100644
--- a/src/pages/resources/mainnet/upgrades/v19.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v19.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.19
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Jun-8` mainnet upgrade to axelar-core `v0.19.2`, vald `v0.19.2`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.19/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
4. Restart your node with the new `v0.19.2` build.
diff --git a/src/pages/resources/mainnet/upgrades/v20.mdx b/src/content/docs/resources/mainnet/upgrades/v20.mdx
similarity index 81%
rename from src/pages/resources/mainnet/upgrades/v20.mdx
rename to src/content/docs/resources/mainnet/upgrades/v20.mdx
index 61f192d30..ff9472d26 100644
--- a/src/pages/resources/mainnet/upgrades/v20.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v20.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.20
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Aug-8` mainnet upgrade to axelar-core `v0.20.0`, vald `v0.20.0`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.20/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
4. Restart your `axelard` node with the new `v0.20.0` build.
@@ -43,4 +47,4 @@ git pull
KEYRING_PASSWORD="pw-1" ./scripts/node.sh -n mainnet -a v0.20.0
# For validators, restart vald/tofnd
KEYRING_PASSWORD="pw-1" TOFND_PASSWORD="pw-2" ./scripts/validator-tools-host.sh -a v0.20.0 -q v0.10.1 -n mainnet
-```
\ No newline at end of file
+```
diff --git a/src/pages/resources/mainnet/upgrades/v21.mdx b/src/content/docs/resources/mainnet/upgrades/v21.mdx
similarity index 75%
rename from src/pages/resources/mainnet/upgrades/v21.mdx
rename to src/content/docs/resources/mainnet/upgrades/v21.mdx
index 852370be3..d7e44debb 100644
--- a/src/pages/resources/mainnet/upgrades/v21.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v21.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.21
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Aug-29` mainnet upgrade to axelar-core `v0.21.1`, vald `v0.21.1`, and tofnd `v0.10.1`.
@@ -28,11 +28,15 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.21/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
-1. Restart your node with the new `v0.21.1` build.
-2. If you're a validator also restart `vald` with `v0.21.1` and `tofnd` with `v0.10.1`.
+4. Restart your node with the new `v0.21.1` build.
+5. If you're a validator also restart `vald` with `v0.21.1` and `tofnd` with `v0.10.1`.
Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
diff --git a/src/pages/resources/mainnet/upgrades/v24.mdx b/src/content/docs/resources/mainnet/upgrades/v24.mdx
similarity index 75%
rename from src/pages/resources/mainnet/upgrades/v24.mdx
rename to src/content/docs/resources/mainnet/upgrades/v24.mdx
index 5d1d18064..56e27f3a3 100644
--- a/src/pages/resources/mainnet/upgrades/v24.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v24.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.24
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Aug-29` mainnet upgrade to axelar-core `v0.24.0`, vald `v0.24.0`, and tofnd `v0.10.1`.
@@ -28,11 +28,15 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.24/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
-1. Restart your node with the new `v0.24.0` build.
-2. If you're a validator also restart `vald` with `v0.24.0` and `tofnd` with `v0.10.1`.
+4. Restart your node with the new `v0.24.0` build.
+5. If you're a validator also restart `vald` with `v0.24.0` and `tofnd` with `v0.10.1`.
Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
diff --git a/src/pages/resources/mainnet/upgrades/v26.mdx b/src/content/docs/resources/mainnet/upgrades/v26.mdx
similarity index 75%
rename from src/pages/resources/mainnet/upgrades/v26.mdx
rename to src/content/docs/resources/mainnet/upgrades/v26.mdx
index 7a11b21d1..520a588b9 100644
--- a/src/pages/resources/mainnet/upgrades/v26.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v26.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.26
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Sep-12` mainnet upgrade to axelar-core `v0.26.5`, vald `v0.26.5`, and tofnd `v0.10.1`.
@@ -28,11 +28,15 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.26/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
-1. Restart your node with the new `v0.26.5` build.
-2. If you're a validator also restart `vald` with `v0.26.5` and `tofnd` with `v0.10.1`.
+4. Restart your node with the new `v0.26.5` build.
+5. If you're a validator also restart `vald` with `v0.26.5` and `tofnd` with `v0.10.1`.
Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
diff --git a/src/pages/resources/mainnet/upgrades/v28.mdx b/src/content/docs/resources/mainnet/upgrades/v28.mdx
similarity index 76%
rename from src/pages/resources/mainnet/upgrades/v28.mdx
rename to src/content/docs/resources/mainnet/upgrades/v28.mdx
index 7a834384f..136ed2d11 100644
--- a/src/pages/resources/mainnet/upgrades/v28.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v28.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.28
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Nov-29` mainnet upgrade to axelar-core `v0.28.0`, vald `v0.28.0`, and tofnd `v0.10.1`.
@@ -30,11 +30,15 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.28/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
-1. Restart your node with the new `v0.28.0` build.
-2. If you're a validator also restart `vald` with `v0.28.0` and `tofnd` with `v0.10.1`.
+4. Restart your node with the new `v0.28.0` build.
+5. If you're a validator also restart `vald` with `v0.28.0` and `tofnd` with `v0.10.1`.
Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
diff --git a/src/pages/resources/mainnet/upgrades/v29.mdx b/src/content/docs/resources/mainnet/upgrades/v29.mdx
similarity index 75%
rename from src/pages/resources/mainnet/upgrades/v29.mdx
rename to src/content/docs/resources/mainnet/upgrades/v29.mdx
index 6b087e6c9..9fb92e1e8 100644
--- a/src/pages/resources/mainnet/upgrades/v29.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v29.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.29
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Nov-29` mainnet upgrade to axelar-core `v0.29.1`, vald `v0.29.1`, and tofnd `v0.10.1`.
@@ -28,11 +28,15 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.29/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
-1. Restart your node with the new `v0.29.1` build.
-2. If you're a validator also restart `vald` with `v0.29.1` and `tofnd` with `v0.10.1`.
+4. Restart your node with the new `v0.29.1` build.
+5. If you're a validator also restart `vald` with `v0.29.1` and `tofnd` with `v0.10.1`.
Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
diff --git a/src/pages/resources/mainnet/upgrades/v31.mdx b/src/content/docs/resources/mainnet/upgrades/v31.mdx
similarity index 75%
rename from src/pages/resources/mainnet/upgrades/v31.mdx
rename to src/content/docs/resources/mainnet/upgrades/v31.mdx
index b68c56367..c18b24dcc 100644
--- a/src/pages/resources/mainnet/upgrades/v31.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v31.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.31
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2023-Jan-30` mainnet upgrade to axelar-core `v0.31.2`, vald `v0.31.2`, and tofnd `v0.10.1`.
@@ -28,11 +28,15 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.31/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
-1. Restart your node with the new `v0.31.2` build.
-2. If you're a validator also restart `vald` with `v0.31.2` and `tofnd` with `v0.10.1`.
+4. Restart your node with the new `v0.31.2` build.
+5. If you're a validator also restart `vald` with `v0.31.2` and `tofnd` with `v0.10.1`.
Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
diff --git a/src/pages/resources/mainnet/upgrades/v33.mdx b/src/content/docs/resources/mainnet/upgrades/v33.mdx
similarity index 75%
rename from src/pages/resources/mainnet/upgrades/v33.mdx
rename to src/content/docs/resources/mainnet/upgrades/v33.mdx
index 40d619d26..110785c50 100644
--- a/src/pages/resources/mainnet/upgrades/v33.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v33.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.33
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2023-April-11` mainnet upgrade to axelar-core `v0.33.2`, vald `v0.33.2`, and tofnd `v0.10.1`.
@@ -28,11 +28,15 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.33/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
-1. Restart your node with the new `v0.33.2` build.
-2. If you're a validator also restart `vald` with `v0.33.2` and `tofnd` with `v0.10.1`.
+4. Restart your node with the new `v0.33.2` build.
+5. If you're a validator also restart `vald` with `v0.33.2` and `tofnd` with `v0.10.1`.
Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
diff --git a/src/pages/resources/mainnet/upgrades/v34.mdx b/src/content/docs/resources/mainnet/upgrades/v34.mdx
similarity index 96%
rename from src/pages/resources/mainnet/upgrades/v34.mdx
rename to src/content/docs/resources/mainnet/upgrades/v34.mdx
index 163db8e39..7eb2c1d02 100644
--- a/src/pages/resources/mainnet/upgrades/v34.mdx
+++ b/src/content/docs/resources/mainnet/upgrades/v34.mdx
@@ -1,6 +1,6 @@
# Mainnet upgrade: v0.34
-import { Callout } from '/src/components/callout'
+import { Callout } from "/src/components/callout";
## About the v0.34 upgrade
@@ -62,8 +62,8 @@ cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.34/.core/data
them from any data backups.
-1. Restart your node with the new `v0.34.1` build.
-2. If you're a validator also restart `vald` with `v0.34.1` and `tofnd` with `v0.10.1`.
+4. Restart your node with the new `v0.34.1` build.
+5. If you're a validator also restart `vald` with `v0.34.1` and `tofnd` with `v0.10.1`.
Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
diff --git a/src/content/docs/resources/mainnet/upgrades/v35.mdx b/src/content/docs/resources/mainnet/upgrades/v35.mdx
new file mode 100644
index 000000000..f00f5954c
--- /dev/null
+++ b/src/content/docs/resources/mainnet/upgrades/v35.mdx
@@ -0,0 +1,73 @@
+# Mainnet upgrade: v0.35
+
+import { Callout } from "/src/components/callout";
+
+## About the v0.35 upgrade
+
+This release adds the Axelar Virtual Machine to the network and adds support for CosmWasm contract creation.
+
+
+ This release enables CosmWasm. Contracts created with CosmWasm will require
+ [governance proposals](/dev/amplifier/chain-integration/governance-proposals/)
+ to be deployed for the indefinite future.
+
+
+Instructions for `2024-March-14` mainnet upgrade to axelar-core `v0.35.5`, vald `v0.35.5`, and tofnd `v0.10.1`.
+Release can be found [on GitHub](https://github.com/axelarnetwork/axelar-core/releases/tag/v0.35.5).
+
+Upgrade height `11795700` [countdown](https://www.mintscan.io/axelar/block/11795700)
+
+
+ [Go v1.21](https://tip.golang.org/doc/go1.21) will be needed to build `axelard`.
+
+Node operators using binaries need to download `wasmvm v1.3.1` [libwasmvm.x86_64.so](https://github.com/CosmWasm/wasmvm/releases/tag/v1.3.1) and add the parent folder to `LD_LIBRARY_PATH`.
+
+Node operators will need to use the updated [`cosmsprund`](https://github.com/binaryholdings/cosmprund/pull/26) to prune their nodes.
+
+If using the community node setup scripts, please update to the latest commit on `main` first.
+`wasmvm` lib will be auto-downloaded to `$AXELARD_HOME/lib` but you'll need to add it to `LD_LIBRARY_PATH` before running the script.
+
+
+
+1. If you're a validator or have delegated to one, please vote for the upgrade proposal via
+
+```bash
+axelard tx gov vote 195 [yes|no] --from validator
+```
+
+2. Wait for the proposed upgrade block, `11795700`. Your node will panic at that block height with a log: `{"level":"error","module":"consensus","err":"UPGRADE \"v0.35\" NEEDED at height: 11795700", ...}`. Stop your node after chain halt.
+
+```bash
+pkill -f 'axelard start'
+# Validators need to also stop vald/tofnd
+pkill -f 'vald-start'
+pkill -f tofnd
+```
+
+3. Backup the state:
+
+```bash
+cp -r ~/.axelar/.core/data ~/.axelar-dojo-1-upgrade-0.34/.core/data
+```
+
+
+ Caution: If you backup the entire folder, `~/.axelar/.core`, that'll also
+ include your private keys (inside `config` and `keyring-file` subfolders).
+ That can be dangerous if anyone gets access to your backups. We recommend
+ backing up keys separately when you first create your node, and then excluding
+ them from any data backups.
+
+
+4. Restart your `axelard` node with the new `v0.35.5` build.
+5. If you're a validator also restart `vald` with `v0.35.5` and `tofnd` with `v0.10.1`.
+
+Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
+
+```bash
+# in axelarate-community repo
+git checkout main
+git pull
+KEYRING_PASSWORD="pw-1" ./scripts/node.sh -n mainnet -a v0.35.5
+# For validators, restart vald/tofnd
+KEYRING_PASSWORD="pw-1" TOFND_PASSWORD="pw-2" ./scripts/validator-tools-host.sh -n mainnet -a v0.35.5 -q v0.10.1
+```
diff --git a/src/pages/resources/metamask.mdx b/src/content/docs/resources/metamask.mdx
similarity index 55%
rename from src/pages/resources/metamask.mdx
rename to src/content/docs/resources/metamask.mdx
index 9f31d1921..441658dc4 100644
--- a/src/pages/resources/metamask.mdx
+++ b/src/content/docs/resources/metamask.mdx
@@ -1,10 +1,10 @@
# Set up MetaMask
-import AddToWeb3 from '../../components/web3'
+import AddToWeb3 from "../../../components/web3";
1. Connect MetaMask to other EVM chains
2. Get testnet tokens for other EVM chains to pay for gas
-3. Import Axelar ERC20 tokens on other EVM chains
+3. Import Axelar ERC-20 tokens on other EVM chains
4. Enable hex data in transactions
## Connect MetaMask to other EVM chains
@@ -15,23 +15,25 @@ Open MetaMask. In the "Networks" dropdown list choose "Add Network". Enter the d
### Mainnet
-| EVM chain | Chain Name | Chain ID | Native Token | RPC URL | Explorer URL | Add Chain |
-| --------- | ---------- | -------- | -------------| -------------------------------------------- | ------------------------------ | ----------------------------------------------------- |
+| EVM chain | Chain Name | Chain ID | Native Token | RPC URL | Explorer URL | Add Chain |
+| --------- | ---------- | -------- | ------------ | -------------------------------------------- | ------------------------------ | ----------------------------------------------------------------- |
| Ethereum | Ethereum | 1 | ETH | [URL](https://rpc.ankr.com/eth) | [URL](https://etherscan.io) |
|
| Avalanche | Avalanche | 43114 | AVAX | [URL](https://api.avax.network/ext/bc/C/rpc) | [URL](https://snowtrace.io) |
|
| Fantom | Fantom | 250 | FTM | [URL](https://rpc.ftm.tools) | [URL](https://ftmscan.com/) |
|
| Polygon | Polygon | 137 | MATIC | [URL](https://polygon-rpc.com) | [URL](https://polygonscan.com) |
|
-| Moonbeam | Moonbeam | 1284 | GLMR | [URL](https://rpc.api.moonbeam.network) | [URL](https://moonscan.io) |
|
+| Moonbeam | Moonbeam | 1284 | GLMR | [URL](https://rpc.api.moonbeam.network) | [URL](https://moonscan.io) |
|
### Testnet
-| EVM chain | Chain Name | Chain ID | Native Token | RPC URL | Explorer URL | Add Chain |
-| --------- | ---------------- | -------- | -------------| -------------------------------------------------------------------- | ------------------------------------- | ----------------------------------------------------- |
-| Ethereum | Ethereum Goerli | 5 | ETH | [URL](https://goerli.infura.io/v3/9aa3d95b3bc440fa88ea12eaa4456161) | [URL](https://goerli.etherscan.io) |
|
-| Avalanche | Avalanche Fuji | 43113 | AVAX | [URL](https://api.avax-test.network/ext/bc/C/rpc) | [URL](https://testnet.snowtrace.io) |
|
-| Fantom | Fantom Testnet | 4002 | FTM | [URL](https://rpc.testnet.fantom.network) | [URL](https://testnet.ftmscan.com/) |
|
-| Polygon | Polygon Mumbai | 80001 | MATIC | [URL](https://matic-mumbai.chainstacklabs.com) | [URL](https://mumbai.polygonscan.com) |
|
-| Moonbeam | Moonbase Alpha | 1287 | DEV | [URL](https://rpc.api.moonbase.moonbeam.network) | [URL](https://moonbase.moonscan.io) |
|
+
+
+| EVM chain | Chain Name | Chain ID | Native Token | RPC URL | Explorer URL | Add Chain |
+| --------- | --------------- | -------- | ------------ | ------------------------------------------------------------------- | ------------------------------------- | ----------------------------------------------------------------- |
+| Ethereum | Ethereum Goerli | 5 | ETH | [URL](https://goerli.infura.io/v3/9aa3d95b3bc440fa88ea12eaa4456161) | [URL](https://goerli.etherscan.io) |
|
+| Avalanche | Avalanche Fuji | 43113 | AVAX | [URL](https://api.avax-test.network/ext/bc/C/rpc) | [URL](https://testnet.snowtrace.io) |
|
+| Fantom | Fantom Testnet | 4002 | FTM | [URL](https://rpc.testnet.fantom.network) | [URL](https://testnet.ftmscan.com/) |
|
+| Polygon | Polygon Mumbai | 80001 | MATIC | [URL](https://matic-mumbai.chainstacklabs.com) | [URL](https://mumbai.polygonscan.com) |
|
+| Moonbeam | Moonbase Alpha | 1287 | DEV | [URL](https://rpc.api.moonbase.moonbeam.network) | [URL](https://moonbase.moonscan.io) |
|
## Get testnet tokens for EVM chains
@@ -45,15 +47,15 @@ You can get native tokens from a faucet. Search the internet for "`[chain]` test
- [Moonbeam](https://docs.moonbeam.network/builders/get-started/moonbase/#get-tokens) -- No known web faucet; need to join the [Moonbeam discord](https://discord.gg/PfpUATX).
- [Polygon](https://faucet.polygon.technology/)
-## Import Axelar ERC20 tokens
+## Import Axelar ERC-20 tokens
Tokens transferred to an EVM chain using Axelar are not visible in MetaMask until you import them.
1. Use the "Networks" dropdown list, select your desired `[chain]`.
2. View "Assets" and select "Import Tokens".
-3. Paste into "Token Contract Address" the ERC20 address for the token. ("Token symbol" and "token decimal" should be fetched automatically.)
+3. Paste into "Token Contract Address" the ERC-20 address for the token. ("Token symbol" and "token decimal" should be fetched automatically.)
-Axelar token contract addresses for each `[chain]` can be found at [Testnet resources](/resources/testnet).
+Axelar token contract addresses for each `[chain]` can be found at [Testnet Resources](/resources/contract-addresses/testnet/).
## Enable hex data in transactions
diff --git a/src/pages/resources/lava-iprpc.mdx b/src/content/docs/resources/rpc/lava-iprpc.mdx
similarity index 53%
rename from src/pages/resources/lava-iprpc.mdx
rename to src/content/docs/resources/rpc/lava-iprpc.mdx
index 8631386ca..cec1b311b 100644
--- a/src/pages/resources/lava-iprpc.mdx
+++ b/src/content/docs/resources/rpc/lava-iprpc.mdx
@@ -1,82 +1,85 @@
# Using Axelar ipRPC
-## Overview 📋
+## Overview 📋
-In order to provide decentralized, reliable and public RPC to all developers in the ecosystem, Axelar uses [Lava](https://www.lavanet.xyz/?utm_source=axelar-iprpc-dev-tutorial&utm_medium=axelar-docs&utm_campaign=axelar-iprpc-dev) to serve RPC to its developer community. Lava aggregates and routes RPC requests to a peer-to-peer network of top-performing node providers, with built-in fraud detection, conflict resolution, and quality of service guarantees for all requests. All relays are conducted securely with no man-in-the-middle. For more details on Lava's protocol, take a look at [the Lava litepaper](https://litepaper.lavanet.xyz/?utm_source=axelar-iprpc-dev-tutorial&utm_medium=axelar-docs&utm_campaign=axelar-iprc-dev).
+In order to provide decentralized, reliable and public RPC to all developers in the ecosystem, Axelar uses [Lava](https://www.lavanet.xyz/?utm_source=axelar-iprpc-dev-tutorial&utm_medium=axelar-docs&utm_campaign=axelar-iprpc-dev) to serve RPC to its developer community. Lava aggregates and routes RPC requests to a peer-to-peer network of top-performing node providers, with built-in fraud detection, conflict resolution, and quality of service guarantees for all requests. All relays are conducted securely with no man-in-the-middle. For more details on Lava's protocol, take a look at [the Lava litepaper](https://cdn.prod.website-files.com/642c9c8327126062770bfdd0/66fd507cdd54cabe7496d478_LavaNetwork-AccessingBlockchains.pdf).
Lava ipRPC aggregates RPC providers and provides a unified endpoint for Axelar's entire ecosystem. Regardless of whether you're using LCD - `REST` or Full Nodes - `TendermintRPC`, you can interact with Axelar blockchain. You can also use websockets to establish a continuous connection instead of conducting a discrete handshake for each relay.
-
## Endpoints 🔗
-A complete list of endpoints available are available [here](https://docs.lavanet.xyz/). For ipRPC, please attend only to addresses on the list which have `Lava Network` as a maintainer. A list is provided below for your convenience, as well!
+A complete list of endpoints available are available [here](https://docs.lavanet.xyz/endpoints-overview). For ipRPC, please attend only to addresses that are under the ipRPC (or Public Endpoints) section. A list is provided below for your convenience, as well!
### Mainnet 🌐
-- **Tendermint-RPC** - `https://tm.axelar.lava.build`
-- **Tendermint-RPC Websocket** - `wss://tm.axelar.lava.build/websocket`
-- **REST** - `https://rest.axelar.lava.build`
-- **gRPC** - `grpc.axelar.lava.build:443`
+- **Tendermint-RPC** - `https://axelar.tendermintrpc.lava.build`
+- **Tendermint-RPC Websocket** - `wss://axelar.tendermintrpc.lava.build/websocket`
+- **REST** - `https://axelar.lava.build`
+- **gRPC** - `axelar.grpc.lava.build:443`
### Testnet 🧪
-- **Tendermint-RPC** - `https://tm.axelar-testnet.lava.build`
-- **Tendermint-RPC Websocket** - `wss://tm.axelar-testnet.lava.build/websocket`
-- **REST** - `https://rest.axelar-testnet.lava.build/`
-- **gRPC** - `grpc.axelar-testnet.lava.build:443`
+- **Tendermint-RPC** - `https://axelart.tendermintrpc.lava.build`
+- **Tendermint-RPC Websocket** - `wss://axelart.tendermintrpc.lava.build/websocket`
+- **REST** - `https://axelart.lava.build`
+- **gRPC** - `axelart.grpc.lava.build:443`
## Using `axelard` with ipRPC ⚡
You can use your `axelard` installation with ipRPC for all calls and requests. To do so, you need to use the Tendermint-RPC URL.
For `mainnet` use:
+
```bash
-./axelard
-n https://tm.axelar.lava.build:443
+./axelard -n https://axelar.tendermintrpc.lava.build:443
```
For `testnet` use:
+
```bash
-./axelard -n https://tm.axelar-testnet.lava.build:443
+./axelard -n https://axelart.tendermintrpc.lava.build:443
```
Using this schema, all `axelard` commands which communicate with the blockchain will be carried out securely and efficiently over Lava ipRPC.
-
## Test Commands 🖥️
You can send requests to each endpoint directly from the command line without intervention from `axelard`. This can be done with the use of different tools such as `curl` for HTTP-responsive protocols, `wscat` for web sockets, and `grpcurl` for gRPC. You can also use any of the endpoints programmatically. Some examples are below:
-
### 🟢 REST
+
Send get requests to the appropriate cosmos endpoints!
```bash
-curl -X GET -H "Content-Type: application/json" https://rest.axelar.lava.build/cosmos/base/tendermint/v1beta1/blocks/latest
-curl -X GET -H "Content-Type: application/json" https://rest.axelar-testnet.lava.build/cosmos/base/tendermint/v1beta1/blocks/latest
+curl -X GET -H "Content-Type: application/json" https://axelar.lava.build/cosmos/base/tendermint/v1beta1/blocks/latest
+curl -X GET -H "Content-Type: application/json" https://axelart.lava.build/cosmos/base/tendermint/v1beta1/blocks/latest
```
### 🟢 Tendermint
+
Send post requests to the Tendermint-RPC endpoint!
```bash
-curl -X POST -H "Content-Type: application/json" https://tm.axelar.lava.build --data '{"jsonrpc": "2.0", "id": 1, "method": "status", "params": []}'
-curl -X POST -H "Content-Type: application/json" https://tm.axelar-testnet.lava.build --data '{"jsonrpc": "2.0", "id": 1, "method": "status", "params": []}'
+curl -X POST -H "Content-Type: application/json" https://axelar.tendermintrpc.lava.build --data '{"jsonrpc": "2.0", "id": 1, "method": "status", "params": []}'
+curl -X POST -H "Content-Type: application/json" https://axelart.tendermintrpc.lava.build --data '{"jsonrpc": "2.0", "id": 1, "method": "status", "params": []}'
```
### 🟢 Tendermint/Websocket
+
Connect using websockets over Tendermint-RPC.
```bash
-wscat -c wss://tm.axelar.lava.build/websocket -x '{"jsonrpc": "2.0", "id": 1, "method": "status", "params": []}'
-wscat -c wss://tm.axelar-testnet.lava.build/websocket -x '{"jsonrpc": "2.0", "id": 1, "method": "status", "params": []}'
+wscat -c wss://axelar.tendermintrpc.lava.build/websocket -x '{"jsonrpc": "2.0", "id": 1, "method": "status", "params": []}'
+wscat -c wss://axelart.tendermintrpc.lava.build/websocket -x '{"jsonrpc": "2.0", "id": 1, "method": "status", "params": []}'
```
### 🟢 gRPC
+
Use gRPC calls directly with the Cosmos API.
```bash
-grpcurl grpc.axelar.lava.build:443 cosmos.base.tendermint.v1beta1.Service/GetLatestBlock
-grpcurl grpc.axelar-testnet.lava.build:443 cosmos.base.tendermint.v1beta1.Service/GetLatestBlock
+grpcurl axelar.grpc.lava.build:443 cosmos.base.tendermint.v1beta1.Service/GetLatestBlock
+grpcurl axelart.grpc.lava.build:443 cosmos.base.tendermint.v1beta1.Service/GetLatestBlock
```
-✅ The rest is up to you! The possibilities are literally endless!
\ No newline at end of file
+✅ The rest is up to you! The possibilities are literally endless!
diff --git a/src/content/docs/resources/rpc/resources.mdx b/src/content/docs/resources/rpc/resources.mdx
new file mode 100644
index 000000000..96b340429
--- /dev/null
+++ b/src/content/docs/resources/rpc/resources.mdx
@@ -0,0 +1,22 @@
+---
+description: Access public Axelar RPC endpoints and resources for mainnet and testnet. Use these to interact with Axelar's network and build cross-chain applications.
+---
+
+import { Callout } from "/src/components/callout";
+
+import Resources from "/src/components/resources/index.jsx";
+
+# Resources
+
+
+
+
+
+
+
+
+
+
+## Looking for help?
+
+Join the [Axelar discord](https://discord.gg/aRZ3Ra6f7D) and visit channels: [developers](https://discord.com/channels/770814806105128977/955655587260170272) | [testnet](https://discord.com/channels/770814806105128977/799299951078408242) | [general](https://discord.com/channels/770814806105128977/770814806105128980)
diff --git a/src/pages/resources/satellite.mdx b/src/content/docs/resources/satellite.mdx
similarity index 63%
rename from src/pages/resources/satellite.mdx
rename to src/content/docs/resources/satellite.mdx
index 4672b12d2..04118175c 100644
--- a/src/pages/resources/satellite.mdx
+++ b/src/content/docs/resources/satellite.mdx
@@ -1,6 +1,6 @@
# Satellite
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
## What is Satellite?
@@ -9,7 +9,9 @@ Satellite is a web application built on top of the Axelar Network. It provides a
## Getting Started
- Caution: Satellite is used to transfer real assets across main networks. When using it for the first time, try transferring small amounts initially. If you need assistance, use the `FAQ` and `Support` buttons in Satellite for help.
+ Caution: Satellite is used to transfer real assets across main networks. When
+ using it for the first time, try transferring small amounts initially. If you
+ need assistance, use the `FAQ` and `Support` buttons in Satellite for help.
Satellite can be found at [https://satellite.money/](https://satellite.money/).
@@ -20,4 +22,4 @@ For a step-by-step walkthrough on how to use Satellite, check out the following
- [Instructional Medium Post](https://medium.com/axelar/transfer-terra-assets-to-evm-chains-using-satellite-f6480c7ff20c)
-See [Mainnet resources](/resources/mainnet) for a reference list of Axelar's cross chain contract addresses, minimum asset transfer amounts, and cross-chain transaction processing fees.
+See [Mainnet Resources](/resources/contract-addresses/mainnet/) for a reference list of Axelar's cross chain contract addresses, minimum asset transfer amounts, and cross-chain transaction processing fees.
diff --git a/src/content/docs/resources/static-configs/static-configs.mdx b/src/content/docs/resources/static-configs/static-configs.mdx
new file mode 100644
index 000000000..d76e4b233
--- /dev/null
+++ b/src/content/docs/resources/static-configs/static-configs.mdx
@@ -0,0 +1,47 @@
+# Static configs
+
+## Introduction
+
+All of the static constants that are relevant for the chain have been aggregated into a single file.
+
+This includes, but is not limited to:
+
+- Chain info and its relevant configs
+- All supported assets on each chain
+
+The configuration documents are versioned so you will know if the object changes.
+
+You can access the configs in one of two ways:
+
+## Point the json files directly
+
+- Testnet: https://axelar-testnet.s3.us-east-2.amazonaws.com/configs/testnet-config-1.x.json
+- Mainnet: https://axelar-mainnet.s3.us-east-2.amazonaws.com/configs/mainnet-config-1.x.json
+
+## Typescript API
+
+Alternatively, you can use the hooks, i.e.
+
+The package can be installed into your dApp as a project dependency with:
+
+```bash
+npm i @axelarjs/api
+```
+
+Then run
+
+```typescript
+import { createAxelarConfigClient } from "@axelarjs/api";
+import { ENVIRONMENTS } from "@axelarjs/core";
+
+const test = async () => {
+ const api = createAxelarConfigClient(ENVIRONMENTS.testnet);
+ const configs = await api.getAxelarConfigs(ENVIRONMENTS.testnet);
+ Object.entries(configs.chains).forEach((v) =>
+ console.log(`config for chain ${v[0]}: ${v[1]}`),
+ );
+};
+test();
+```
+
+Each of the relevant properties in the schema are typed out in the following Typescript interfaces: https://github.com/axelarnetwork/axelarjs/blob/main/packages/api/src/axelar-config/types.ts
diff --git a/src/content/docs/resources/testnet/upgrades/v1.mdx b/src/content/docs/resources/testnet/upgrades/v1.mdx
new file mode 100644
index 000000000..200b35bfa
--- /dev/null
+++ b/src/content/docs/resources/testnet/upgrades/v1.mdx
@@ -0,0 +1,81 @@
+# Testnet upgrade: v1.0
+
+import { Callout } from '/src/components/callout';
+import { AXELARD_TESTNET } from '/src/config/variables';
+
+## About the v1.0 upgrade
+
+This release finalizes initial support for [Amplifier](/dev/amplifier/introduction).
+
+Changes since 0.35.x:
+
+- Various fixes that improve stability
+- New queries in the axelarnet module to query the IBC path for a chain and the chain by IBC path
+- Added a new message type “BatchRequest”. In contrast to cosmos default behaviour, where the entire tx gets rolled back if there is an error in any of the contained message executions, this batch only rolls back the state for the specific messages that fail and keeps the rest
+- Allow refundable messages to be batched
+- Correctly pass message IDs between core and the new amplifier
+- Add functionality to quickly (de)activate the connection between core and amplifier in case of emergencies
+
+See all the changes in the [`axelar-core` release notes](https://github.com/axelarnetwork/axelar-core/releases).
+
+Upgrade height `14625900` at approximately **11AM Eastern Time (15:00 UTC) on August 1st, 2024** ([countdown](https://www.mintscan.io/axelar-testnet/block/14625900))
+
+
+As of v1.0.0, the `axelard` [binary releases](https://github.com/axelarnetwork/axelar-core/releases) require `GLIBC_2.34`, which is not present on Ubuntu 20.04.
+
+You will need to compile `axelard` from source, or upgrade to Ubuntu 22.04.
+
+
+
+
+ If using the community node setup scripts, please update to the latest commit
+ on `main` first. `wasmvm` lib will be auto-downloaded to `$AXELARD_HOME/lib`
+ but you'll need to add it to `LD_LIBRARY_PATH` before running the script.
+
+
+1. If you're a validator or have delegated to one, you can vote for the upgrade proposal, while it's active, via
+
+```bash
+axelard tx gov vote 99 yes --from validator
+```
+
+2. Wait for the proposed upgrade block, `14625900`. Your node will panic at that block height with a log: `{"level":"error","module":"consensus","err":"UPGRADE \"v1.0\" NEEDED at height: 14625900", ...}`. Stop your node after chain halt.
+
+```bash
+pkill -f 'axelard start'
+# Validators need to also stop vald/tofnd
+pkill -f 'vald-start'
+pkill -f tofnd
+```
+
+3. Backup the state:
+
+```bash
+cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.35/.core/data
+```
+
+
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
+
+
+4. Restart your `axelard` node with the new v{AXELARD_TESTNET} build.
+5. If you're a validator also restart `vald` with v{AXELARD_TESTNET} and `tofnd` with `v1.0.1`.
+
+
+ [`tofnd` 1.0.1 has been released](https://github.com/axelarnetwork/tofnd/releases), and we recommend adopting `v1.0.1` of `tofnd` independently from the upgrade.
+
+
+Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
+
+```bash
+# in axelarate-community repo (https://github.com/axelarnetwork/axelarate-community)
+git checkout main
+git pull
+KEYRING_PASSWORD="pw-1" ./scripts/node.sh -n testnet -a v1.0.5
+# For validators, restart vald/tofnd
+KEYRING_PASSWORD="pw-1" TOFND_PASSWORD="pw-2" ./scripts/validator-tools-host.sh -n testnet -a v1.0.5 -q v0.10.1
+```
diff --git a/src/content/docs/resources/testnet/upgrades/v112.mdx b/src/content/docs/resources/testnet/upgrades/v112.mdx
new file mode 100644
index 000000000..34ed31c7c
--- /dev/null
+++ b/src/content/docs/resources/testnet/upgrades/v112.mdx
@@ -0,0 +1,64 @@
+# Testnet upgrade: v1.1
+
+import { Callout } from "/src/components/callout";
+
+Instructions for the `2024-Dec-12` testnet upgrade to axelar-core `v1.1.2`.
+Release can be found [here](https://github.com/axelarnetwork/axelar-core/releases/tag/v1.1.2)
+
+Upgrade height `16665600` [countdown](https://www.mintscan.io/axelar-testnet/block/16665600)
+
+## About the v1.1 upgrade
+The `v1.1.2` upgrade is a consensus breaking release for Axelar testnet. Once live, it will enable the deployment of ITS Hub on testnet.
+
+1. If you're a validator or have delegated to one, please vote for the upgrade proposal via
+
+
+```bash
+axelard tx gov vote 164 yes --from validator
+```
+
+
+ `axelard` must be built with `go-1.23` for this release.
+
+
+
+2. Wait for the proposed upgrade block, `16665600`. Your node will panic at that block height with a log: `{"level":"error","module":"consensus","err":"UPGRADE \"v1.1.2\" NEEDED at height: 16665600",`. Stop your node after chain halt.
+
+```bash
+pkill -f 'axelard start'
+# Validators need to also stop vald/tofnd
+pkill -f 'vald-start'
+pkill -f tofnd
+```
+
+3. Backup the state:
+
+```bash
+cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-1.1.2/.core/data
+```
+
+
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
+
+
+
+4. Restart your `axelard` node with the new `v1.1.2` build.
+5. If you're a validator also restart `vald` with `v1.1.2` and `tofnd` with `v1.0.1`.
+
+Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
+
+
+
+```bash
+# in axelarate-community repo
+git checkout main
+git pull
+KEYRING_PASSWORD="pw-1" ./scripts/node.sh -n testnet -a v1.1.2
+# For validators, restart vald/tofnd
+KEYRING_PASSWORD="pw-1" TOFND_PASSWORD="pw-2" ./scripts/validator-tools-host.sh -n testnet -a v1.1.2 -q v1.0.1
+```
+
diff --git a/src/content/docs/resources/testnet/upgrades/v121.mdx b/src/content/docs/resources/testnet/upgrades/v121.mdx
new file mode 100644
index 000000000..e4e456b9e
--- /dev/null
+++ b/src/content/docs/resources/testnet/upgrades/v121.mdx
@@ -0,0 +1,66 @@
+# Testnet upgrade: v1.2
+
+import { Callout } from "/src/components/callout";
+
+Instructions for the `v1.2` testnet upgrade to axelar-core `v1.2.1`.
+Release can be found [here](https://github.com/axelarnetwork/axelar-core/releases/tag/v1.2.1)
+
+Upgrade height `17629900` [countdown](https://www.mintscan.io/axelar-testnet/block/17629900)
+
+## About the v1.2 upgrade
+The `v1.2` upgrade is a consensus breaking release for Axelar testnet.
+
+1. If you're a validator or have delegated to one, please vote for the upgrade proposal via
+
+```bash
+axelard tx gov vote 201 yes --from validator
+```
+
+
+ `axelard` must be built with `go-1.23` for this release.
+
+ Node operators using binaries need to update `wasmvm` from `v1.3.1` to `v1.5.8` [libwasmvm.x86_64.so](https://github.com/CosmWasm/wasmvm/releases/tag/v1.5.8), and add the folder containing the library to `LD_LIBRARY_PATH`.
+
+ If using the community node setup scripts, please update to the latest commit on `main` first.
+ `wasmvm` lib will be auto-downloaded to `$AXELARD_HOME/lib` but you'll need to add it to `LD_LIBRARY_PATH` before running the script.
+
+
+
+2. Wait for the proposed upgrade block, `17629900`. Your node will panic at that block height with a log: `{"level":"error","module":"consensus","err":"UPGRADE \"v1.2\" NEEDED at height: 17629900",`. Stop your node after chain halt.
+
+```bash
+pkill -f 'axelard start'
+# Validators need to also stop vald/tofnd
+pkill -f 'vald-start'
+pkill -f tofnd
+```
+
+3. Backup the state:
+
+```bash
+cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-1.2.1/.core/data
+```
+
+
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
+
+
+
+4. Restart your `axelard` node with the new `v1.2.1` build.
+5. If you're a validator also restart `vald` with `v1.2.1` and `tofnd` with `v1.0.1`.
+
+Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
+
+```bash
+# in axelarate-community repo
+git checkout main
+git pull
+KEYRING_PASSWORD="pw-1" ./scripts/node.sh -n testnet -a v1.2.1
+# For validators, restart vald/tofnd
+KEYRING_PASSWORD="pw-1" TOFND_PASSWORD="pw-2" ./scripts/validator-tools-host.sh -n testnet -a v1.2.1 -q v1.0.1
+```
+
diff --git a/src/pages/resources/testnet/upgrades/v17.mdx b/src/content/docs/resources/testnet/upgrades/v17.mdx
similarity index 80%
rename from src/pages/resources/testnet/upgrades/v17.mdx
rename to src/content/docs/resources/testnet/upgrades/v17.mdx
index 4588075fe..5a7fff306 100644
--- a/src/pages/resources/testnet/upgrades/v17.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v17.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.17
+# Testnet upgrade: v0.17
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Apr-12` testnet upgrade to axelar-core `v0.17.3`, vald `v0.17.3`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.17/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.17.3` build.
diff --git a/src/pages/resources/testnet/upgrades/v18.mdx b/src/content/docs/resources/testnet/upgrades/v18.mdx
similarity index 80%
rename from src/pages/resources/testnet/upgrades/v18.mdx
rename to src/content/docs/resources/testnet/upgrades/v18.mdx
index 83fea2b73..a44515dd8 100644
--- a/src/pages/resources/testnet/upgrades/v18.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v18.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.18
+# Testnet upgrade: v0.18
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-May-20` testnet upgrade to axelar-core `v0.18.2`, vald `v0.18.2`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.18/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.18.2` build.
diff --git a/src/pages/resources/testnet/upgrades/v19.mdx b/src/content/docs/resources/testnet/upgrades/v19.mdx
similarity index 80%
rename from src/pages/resources/testnet/upgrades/v19.mdx
rename to src/content/docs/resources/testnet/upgrades/v19.mdx
index 84adb7dbe..378423500 100644
--- a/src/pages/resources/testnet/upgrades/v19.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v19.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.19
+# Testnet upgrade: v0.19
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-May-25` testnet upgrade to axelar-core `v0.19.4`, vald `v0.19.4`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.19/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.19.4` build.
diff --git a/src/pages/resources/testnet/upgrades/v20.mdx b/src/content/docs/resources/testnet/upgrades/v20.mdx
similarity index 80%
rename from src/pages/resources/testnet/upgrades/v20.mdx
rename to src/content/docs/resources/testnet/upgrades/v20.mdx
index 99fdd9490..3b7563361 100644
--- a/src/pages/resources/testnet/upgrades/v20.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v20.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.20
+# Testnet upgrade: v0.20
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Aug-6` testnet upgrade to axelar-core `v0.20.0`, vald `v0.20.0`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.20/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.20.0` build.
diff --git a/src/pages/resources/testnet/upgrades/v21.mdx b/src/content/docs/resources/testnet/upgrades/v21.mdx
similarity index 80%
rename from src/pages/resources/testnet/upgrades/v21.mdx
rename to src/content/docs/resources/testnet/upgrades/v21.mdx
index 11dd7cd7c..5df37cc6b 100644
--- a/src/pages/resources/testnet/upgrades/v21.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v21.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.21
+# Testnet upgrade: v0.21
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Aug-11` testnet upgrade to axelar-core `v0.21.1`, vald `v0.21.1`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.21/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.21.1` build.
diff --git a/src/pages/resources/testnet/upgrades/v22.mdx b/src/content/docs/resources/testnet/upgrades/v22.mdx
similarity index 80%
rename from src/pages/resources/testnet/upgrades/v22.mdx
rename to src/content/docs/resources/testnet/upgrades/v22.mdx
index a229604e4..af60dc0d8 100644
--- a/src/pages/resources/testnet/upgrades/v22.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v22.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.22
+# Testnet upgrade: v0.22
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Aug-12` testnet upgrade to axelar-core `v0.22.1`, vald `v0.22.1`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.22/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.22.1` build.
diff --git a/src/pages/resources/testnet/upgrades/v23.mdx b/src/content/docs/resources/testnet/upgrades/v23.mdx
similarity index 80%
rename from src/pages/resources/testnet/upgrades/v23.mdx
rename to src/content/docs/resources/testnet/upgrades/v23.mdx
index 8d457aab8..7dbef3943 100644
--- a/src/pages/resources/testnet/upgrades/v23.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v23.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.23
+# Testnet upgrade: v0.23
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Aug-18` testnet upgrade to axelar-core `v0.23.0`, vald `v0.23.0`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.23/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.23.0` build.
diff --git a/src/pages/resources/testnet/upgrades/v24.mdx b/src/content/docs/resources/testnet/upgrades/v24.mdx
similarity index 80%
rename from src/pages/resources/testnet/upgrades/v24.mdx
rename to src/content/docs/resources/testnet/upgrades/v24.mdx
index 3f42b5723..643187247 100644
--- a/src/pages/resources/testnet/upgrades/v24.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v24.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.24
+# Testnet upgrade: v0.24
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Aug-24` testnet upgrade to axelar-core `v0.24.0`, vald `v0.24.0`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.24/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.24.0` build.
diff --git a/src/pages/resources/testnet/upgrades/v25.mdx b/src/content/docs/resources/testnet/upgrades/v25.mdx
similarity index 80%
rename from src/pages/resources/testnet/upgrades/v25.mdx
rename to src/content/docs/resources/testnet/upgrades/v25.mdx
index 6d2a82b0e..0d919efc5 100644
--- a/src/pages/resources/testnet/upgrades/v25.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v25.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.25
+# Testnet upgrade: v0.25
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Sep-07` testnet upgrade to axelar-core `v0.25.0`, vald `v0.25.0`, and tofnd `v0.10.1`.
@@ -28,7 +28,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.25/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.25.0` build.
diff --git a/src/pages/resources/testnet/upgrades/v26.mdx b/src/content/docs/resources/testnet/upgrades/v26.mdx
similarity index 81%
rename from src/pages/resources/testnet/upgrades/v26.mdx
rename to src/content/docs/resources/testnet/upgrades/v26.mdx
index 6733082c4..b7d23282b 100644
--- a/src/pages/resources/testnet/upgrades/v26.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v26.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.26
+# Testnet upgrade: v0.26
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Sep-07` testnet upgrade to axelar-core `v0.26.5`, vald `v0.26.5`, and tofnd `v0.10.1`.
Release can be found [here](https://github.com/axelarnetwork/axelar-core/releases/tag/v0.26.0).
@@ -29,7 +29,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.26/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.26.5` build.
diff --git a/src/pages/resources/testnet/upgrades/v27.mdx b/src/content/docs/resources/testnet/upgrades/v27.mdx
similarity index 81%
rename from src/pages/resources/testnet/upgrades/v27.mdx
rename to src/content/docs/resources/testnet/upgrades/v27.mdx
index 5fc944463..64d70952c 100644
--- a/src/pages/resources/testnet/upgrades/v27.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v27.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.27
+# Testnet upgrade: v0.27
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Nov-16` testnet upgrade to axelar-core `v0.27.0`, vald `v0.27.0`, and tofnd `v0.10.1`.
Release can be found [here](https://github.com/axelarnetwork/axelar-core/releases/tag/v0.27.0).
@@ -29,7 +29,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.27/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.27.0` build.
diff --git a/src/pages/resources/testnet/upgrades/v28.mdx b/src/content/docs/resources/testnet/upgrades/v28.mdx
similarity index 81%
rename from src/pages/resources/testnet/upgrades/v28.mdx
rename to src/content/docs/resources/testnet/upgrades/v28.mdx
index 659a6ddad..997df63a1 100644
--- a/src/pages/resources/testnet/upgrades/v28.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v28.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.28
+# Testnet upgrade: v0.28
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Nov-16` testnet upgrade to axelar-core `v0.28.0`, vald `v0.28.0`, and tofnd `v0.10.1`.
Release can be found [here](https://github.com/axelarnetwork/axelar-core/releases/tag/v0.28.0).
@@ -29,7 +29,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.28/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.28.0` build.
diff --git a/src/pages/resources/testnet/upgrades/v29.mdx b/src/content/docs/resources/testnet/upgrades/v29.mdx
similarity index 81%
rename from src/pages/resources/testnet/upgrades/v29.mdx
rename to src/content/docs/resources/testnet/upgrades/v29.mdx
index fb2471d31..a51f0c99f 100644
--- a/src/pages/resources/testnet/upgrades/v29.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v29.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.29
+# Testnet upgrade: v0.29
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2022-Dec-01` testnet upgrade to axelar-core `v0.29.1`, vald `v0.29.1`, and tofnd `v0.10.1`.
Release can be found [here](https://github.com/axelarnetwork/axelar-core/releases/tag/v0.29.1).
@@ -29,7 +29,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.29/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.29.1` build.
diff --git a/src/pages/resources/testnet/upgrades/v31.mdx b/src/content/docs/resources/testnet/upgrades/v31.mdx
similarity index 81%
rename from src/pages/resources/testnet/upgrades/v31.mdx
rename to src/content/docs/resources/testnet/upgrades/v31.mdx
index e74639b2d..7641abf7b 100644
--- a/src/pages/resources/testnet/upgrades/v31.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v31.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.31
+# Testnet upgrade: v0.31
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2023-Jan-24` testnet upgrade to axelar-core `v0.31.2`, vald `v0.31.2`, and tofnd `v0.10.1`.
Release can be found [here](https://github.com/axelarnetwork/axelar-core/releases/tag/v0.31.2).
@@ -29,7 +29,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.31/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.31.2` build.
diff --git a/src/pages/resources/testnet/upgrades/v32.mdx b/src/content/docs/resources/testnet/upgrades/v32.mdx
similarity index 81%
rename from src/pages/resources/testnet/upgrades/v32.mdx
rename to src/content/docs/resources/testnet/upgrades/v32.mdx
index 438c75894..58115fb8a 100644
--- a/src/pages/resources/testnet/upgrades/v32.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v32.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.32
+# Testnet upgrade: v0.32
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2023-Feb-21` testnet upgrade to axelar-core `v0.32.2`, vald `v0.32.2`, and tofnd `v0.10.1`.
Release can be found [here](https://github.com/axelarnetwork/axelar-core/releases/tag/v0.32.2).
@@ -29,7 +29,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.31/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.32.2` build.
diff --git a/src/pages/resources/testnet/upgrades/v33.mdx b/src/content/docs/resources/testnet/upgrades/v33.mdx
similarity index 81%
rename from src/pages/resources/testnet/upgrades/v33.mdx
rename to src/content/docs/resources/testnet/upgrades/v33.mdx
index 297f500d2..a82b3520a 100644
--- a/src/pages/resources/testnet/upgrades/v33.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v33.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.33
+# Testnet upgrade: v0.33
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Instructions for `2023-April-3` testnet upgrade to axelar-core `v0.33.2`, vald `v0.33.2`, and tofnd `v0.10.1`.
Release can be found [here](https://github.com/axelarnetwork/axelar-core/releases/tag/v0.33.2).
@@ -29,7 +29,11 @@ cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.32/.core/data
```
- Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll also include your private keys (inside `config` and `keyring-file` subfolders). That can be dangerous if anyone gets access to your backups. We recommend backing up keys separately when you first create your node, and then excluding them from any data backups.
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
4. Restart your `axelard` node with the new `v0.33.2` build.
diff --git a/src/pages/resources/testnet/upgrades/v34.mdx b/src/content/docs/resources/testnet/upgrades/v34.mdx
similarity index 98%
rename from src/pages/resources/testnet/upgrades/v34.mdx
rename to src/content/docs/resources/testnet/upgrades/v34.mdx
index 1e5e9c5a2..5f6211864 100644
--- a/src/pages/resources/testnet/upgrades/v34.mdx
+++ b/src/content/docs/resources/testnet/upgrades/v34.mdx
@@ -1,6 +1,6 @@
-# Testnet-1 upgrade: v0.34
+# Testnet upgrade: v0.34
-import { Callout } from '/src/components/callout'
+import { Callout } from "/src/components/callout";
## About the v0.34 upgrade
diff --git a/src/content/docs/resources/testnet/upgrades/v35.mdx b/src/content/docs/resources/testnet/upgrades/v35.mdx
new file mode 100644
index 000000000..c1328c216
--- /dev/null
+++ b/src/content/docs/resources/testnet/upgrades/v35.mdx
@@ -0,0 +1,73 @@
+# Testnet upgrade: v0.35
+
+import { Callout } from "/src/components/callout";
+
+## About the v0.35 upgrade
+
+This release adds the Axelar Virtual Machine to the network and adds support for CosmWasm contract creation.
+
+
+ This release enables CosmWasm. Contracts created with CosmWasm will require
+ [governance proposals](/dev/amplifier/chain-integration/governance-proposals/)
+ to be deployed for the indefinite future.
+
+
+Instructions for `2024-February-13` testnet upgrade to axelar-core `v0.35.3`, vald `v0.35.3`, and tofnd `v0.10.1`.
+Release can be found [here](https://github.com/axelarnetwork/axelar-core/releases/tag/v0.35.3).
+
+Upgrade height `12017025` [countdown](https://testnet.mintscan.io/axelar-testnet/blocks/12017025)
+
+
+ [Go v1.21](https://tip.golang.org/doc/go1.21) will be needed to build `axelard`.
+
+Node operators using binaries need to download `wasmvm v1.3.1` [libwasmvm.x86_64.so](https://github.com/CosmWasm/wasmvm/releases/tag/v1.3.1) and add the parent folder to `LD_LIBRARY_PATH`.
+
+Node operators will need to use the updated [`cosmsprund`](https://github.com/binaryholdings/cosmprund/pull/26) to prune their nodes.
+
+If using the community node setup scripts, please update to the latest commit on `main` first.
+`wasmvm` lib will be auto-downloaded to `$AXELARD_HOME/lib` but you'll need to add it to `LD_LIBRARY_PATH` before running the script.
+
+
+
+1. If you're a validator or have delegated to one, please vote for the upgrade proposal via
+
+```bash
+axelard tx gov vote 70 yes --from validator
+```
+
+2. Wait for the proposed upgrade block, `12017025`. Your node will panic at that block height with a log: `{"level":"error","module":"consensus","err":"UPGRADE \"v0.35\" NEEDED at height: 12017025", ...}`. Stop your node after chain halt.
+
+```bash
+pkill -f 'axelard start'
+# Validators need to also stop vald/tofnd
+pkill -f 'vald-start'
+pkill -f tofnd
+```
+
+3. Backup the state:
+
+```bash
+cp -r ~/.axelar_testnet/.core/data ~/.axelar-lisbon-3-upgrade-0.34/.core/data
+```
+
+
+ Caution: If you backup the entire folder, `~/.axelar_testnet/.core`, that'll
+ also include your private keys (inside `config` and `keyring-file`
+ subfolders). That can be dangerous if anyone gets access to your backups. We
+ recommend backing up keys separately when you first create your node, and then
+ excluding them from any data backups.
+
+
+4. Restart your `axelard` node with the new `v0.35.3` build.
+5. If you're a validator also restart `vald` with `v0.35.3` and `tofnd` with `v0.10.1`.
+
+Example using join scripts in [axelarate-community git repo](https://github.com/axelarnetwork/axelarate-community):
+
+```bash
+# in axelarate-community repo
+git checkout main
+git pull
+KEYRING_PASSWORD="pw-1" ./scripts/node.sh -n testnet -a v0.35.3
+# For validators, restart vald/tofnd
+KEYRING_PASSWORD="pw-1" TOFND_PASSWORD="pw-2" ./scripts/validator-tools-host.sh -n testnet -a v0.35.3 -q v0.10.1
+```
diff --git a/src/pages/validator/setup/stake-axl.mdx b/src/content/docs/resources/tokens/stake-axl.mdx
similarity index 100%
rename from src/pages/validator/setup/stake-axl.mdx
rename to src/content/docs/resources/tokens/stake-axl.mdx
diff --git a/src/pages/resources/wrapped-tokens.mdx b/src/content/docs/resources/tokens/wrapped-tokens.mdx
similarity index 97%
rename from src/pages/resources/wrapped-tokens.mdx
rename to src/content/docs/resources/tokens/wrapped-tokens.mdx
index 8fec44c21..dc743b6e5 100644
--- a/src/pages/resources/wrapped-tokens.mdx
+++ b/src/content/docs/resources/tokens/wrapped-tokens.mdx
@@ -1,6 +1,6 @@
# Convert between native and wrapped tokens
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
Axelar supports cross-chain transfer of the following native tokens via their wrapped ERC-20 versions:
@@ -42,7 +42,7 @@ Mainnets:
- [Moonbeam](https://moonbeam.moonscan.io/token/0xacc15dc74880c9944775448304b263d191c6077f#writeContract)
- [Polygon](https://polygonscan.com/token/0x0d500B1d8E8eF31E21C99d1Db9A6444d3ADf1270#writeContract)
-If you haven't already, import the wrapped ERC-20 token to your MetaMask account in the appropriate network as described in [Set up MetaMask](metamask).
+If you haven't already, import the wrapped ERC-20 token to your MetaMask account in the appropriate network as described in [Set up MetaMask](/resources/metamask/).
Click the "contract" tab, then click "write contract". (The above links should take you directly to "write contract".)
diff --git a/src/content/docs/validator/amplifier/change-verifier-address.mdx b/src/content/docs/validator/amplifier/change-verifier-address.mdx
new file mode 100644
index 000000000..4cd28e352
--- /dev/null
+++ b/src/content/docs/validator/amplifier/change-verifier-address.mdx
@@ -0,0 +1,57 @@
+# Change Your Verifier Address
+
+If you ever need to change the address of your verifier, you'll have to unbond and unauthorize your current verifier, then claim and transfer the bond. Finally, bond and authorize your new verifier.
+
+## Moving bonded funds
+Move funds by starting with your current verifier and `ampd`/`tofnd`.
+
+1. `ampd unbond-verifier amplifier`
+1. Wait until unbonding completes after the unbonding period
+1. `ampd claim-stake amplifier`
+1. `ampd send-tokens uaxl`
+1. Then setup your new verifier (make sure you run these commands as the new ampd/tofnd)
+1. `ampd bond-verifier amplifier 50000000000 uaxl`
+1. `ampd register-public-key ecdsa`
+1. `ampd register-chain-support amplifier flow`
+
+## Unauthorize and authorize your verifiers
+Before making a governance proposal, You should [make a community forum post](https://community.axelar.network/) explaining what you are doing and link it in your governance proposals. Then make an on-chain proposal for the removal of authorization of your old verifier.
+
+```bash
+axelard tx gov submit-proposal execute-contract axelar1rpj2jjrv3vpugx9ake9kgk3s2kgwt0y60wtkmcgfml5m3et0mrls6nct9m \
+ '{
+"unauthorize_verifiers":{
+"verifiers":[
+"axelar1ejv5td70estc7ed4avnxnqqv4tpef2zafdkgms"
+],
+"service_name":"amplifier"
+}
+}' \
+ --title="Remove verifier addresses for " \
+ --description="Remove old address as part of verifier migrating to new address. See " \
+ --run-as axelar10d07y265gmmuvt4z0w9aw880jnsr700j7v9daj \
+ --deposit=10000000000uaxl \
+ --from wallet \
+ --gas auto --gas-adjustment 1.5 --gas-prices 0.007uaxl \
+ --chain-id axelar-dojo-1 --node https://tm.axelar.lava.build:443
+ ```
+
+ Then authorize your new verifier.
+
+ ```bash
+ axelard tx gov submit-proposal execute-contract axelar1rpj2jjrv3vpugx9ake9kgk3s2kgwt0y60wtkmcgfml5m3et0mrls6nct9m \
+ '{
+"authorize_verifiers":{
+"verifiers":[
+"axelar1g92hckcernmgm60tm527njl6j2cxysm7zg6ulk"
+],
+"service_name":"amplifier"
+}
+}' \
+ --title="Add replacement verifier addresses for " \
+ --description="Add new address as part of verifier migrating to new address. See " \
+ --run-as axelar10d07y265gmmuvt4z0w9aw880jnsr700j7v9daj \
+ --deposit=10000000000uaxl \
+ --from mainnet-interoplabs-hotwallet \
+ --gas auto --gas-adjustment 1.5 --gas-prices 0.007uaxl \
+ --chain-id axelar-dojo-1 --node https://tm.axelar.lava.build:443
\ No newline at end of file
diff --git a/src/content/docs/validator/amplifier/error-messages.mdx b/src/content/docs/validator/amplifier/error-messages.mdx
new file mode 100644
index 000000000..d7a50a77c
--- /dev/null
+++ b/src/content/docs/validator/amplifier/error-messages.mdx
@@ -0,0 +1,30 @@
+# Common Amplifier Error Messages
+
+import { Callout } from "/src/components/callout";
+
+The following are some common error messages encountered when working with verifiers and relayers on the Amplifier.
+
+
+ These errors may be caused by other issues. The reasons given are based off of
+ known causes only.
+
+
+## Verifiers
+
+- `command not found: axelard` — The symlink or alias to `axelard` is not working. Use full binary name instead for commands, such as `./axelard` version instead of `axelard version`. Alternatively you can fix your alias, `PATH`, or symlink.
+
+- `command not found: tofnd` — The symlink or alias to `tofnd` is not working. Use full binary name instead for commands, such as `tofnd-darwin-[version] --help` instead of `tofnd --help`. Alternatively you can fix your alias, `PATH`, or symlink.
+
+- `connection failed: transport error` — `ampd` can't connect to `tofnd`. Make sure that you have tofnd running in the background and that the port and hots `tofnd` is listening on match the information in your `ampd` config file.
+
+- **axelard cannot be opened because the developer cannot be verified** (Mac) — Disable the gatekeeper for a single binary with `sudo xattr -d com.apple.quarantine ~/Downloads/ampd-darwin-arm64-v1.2.0`, or disable gatekeeper globally with `sudo spctl --master-disable`.
+
+- `error trying to connect: received corrupt message` — Your RPC server may not support HTTPS. Try HTTP instead.
+
+- `error trying to connect: invalid dnsname` — Your IP-addressed server may not support HTTPS. Use `http://` instead.
+
+## Message relayers
+
+- `Generic error: Querier contract error: codespace` — The message that was supposed to be routed can’t be found. Search for `unfit_for_routing` in your terminal output to see if the message was actually routed. The transaction will succeed even with unsuccessful routing.
+
+- `message index: 0` — There are no new messages to confirm.
diff --git a/src/content/docs/validator/amplifier/governance-proposals.mdx b/src/content/docs/validator/amplifier/governance-proposals.mdx
new file mode 100644
index 000000000..ce1d0454a
--- /dev/null
+++ b/src/content/docs/validator/amplifier/governance-proposals.mdx
@@ -0,0 +1,60 @@
+# Verifier Governance Proposals
+
+Changes are made to existing Amplifier settings through [community governance](/resources/community/community-pool-proposals). You will need to submit a governance proposal to modify these settings.
+
+## Prerequisites
+
+- Access to the [Axelar command-line interface](/learn/cli)
+- 2,000 AXL for each proposal, either from your [own wallet](/resources/community/community-pool-proposals#create-a-local-wallet) or through a community member who can fund the proposal within one hour of posting
+- A running [RPC endpoint](/resources/rpc/resources) or [Axelar node](/node/config-node)
+
+## Community Forum introduction
+
+You will need to introduce your verifier to the community in order for Axelar token holders to vote for your proposals. This should be done on the governance section of the [Axelar Community Forum](https://community.axelar.network/c/governance2/33). Make a community introduction post that precedes and can be referenced by any on-chain proposals. It should include the following information:
+
+- Team information
+- Team background
+- Relevant experience
+
+All of your on-chain proposals will refer back to this post, so make sure to be thorough. You should stay present and engage with any questions or comments during the seven-day feedback period, which can include public comments as well as a security council review. When the feedback period is over, submit your on-chain governance proposal to finish the approval as a verifier.
+
+## Authorize verifiers with the service registry
+
+Once the 7 day feedback period has passed, submit the proposal on-chain via the command line:
+
+
+
+ ```bash export
+ SERVICE_REGISTRY_ADDRESS="axelar1rpj2jjrv3vpugx9ake9kgk3s2kgwt0y60wtkmcgfml5m3et0mrls6nct9m"
+ export
+ VERIFIER_AXELAR_ADDRESS="axelar16dxsfhyegy40e4eqfxee5jw5gyy2xxtcw4t2na"
+ export NETWORK_GOV_ADDRESS="axelar10d07y265gmmuvt4z0w9aw880jnsr700j7v9daj"
+ export RPC="https://tm.axelar-testnet.lava.build/" export
+ SERVICE_NAME="amplifier" export GAS_PRICE="0.007uaxl" export NAME="My
+ Verifier Name" # Your verifier name export
+ PROPOSAL_URL="https://community.axelar.network/..." # Your proposal URL
+```
+
+
+
+
+```bash
+axelard tx gov submit-proposal execute-contract $SERVICE_REGISTRY_ADDRESS \
+ '{
+ "authorize_verifiers":{
+ "verifiers":[
+ "'"$VERIFIER_AXELAR_ADDRESS"'"
+ ],
+ "service_name":"'"$SERVICE_NAME"'"
+ }
+ }' \
+
+ --title="Add $NAME to approved verifier set" \
+ --description="Add $NAME to approved verifier set. Proposal Link: $PROPOSAL_URL" \
+ --run-as $NETWORK_GOV_ADDRESS \
+ --deposit=100000000uverifiers \
+ --keyring-backend test \
+ --from wallet \
+ --gas auto --gas-adjustment 1.5 --gas-prices $GAS_PRICE \
+ --node $RPC
+```
diff --git a/src/content/docs/validator/amplifier/verifier-onboarding.mdx b/src/content/docs/validator/amplifier/verifier-onboarding.mdx
new file mode 100644
index 000000000..13089a574
--- /dev/null
+++ b/src/content/docs/validator/amplifier/verifier-onboarding.mdx
@@ -0,0 +1,613 @@
+# Become an Amplifier Verifier
+
+import { Callout } from "/src/components/callout";
+import { AMPD } from '/src/config/variables';
+
+
+ The Axelar Virtual Machine (AVM) and Amplifier are currently under active
+ development, so these instructions are likely to change. Please check back
+ frequently for updates.
+
+
+By running a **verifier** for a chain integration with Axelar's Amplifier, you will be responsible for voting on the validity of transactions on the Axelar network and signing command batches for a given chain.
+
+## `tofnd` and `ampd`
+
+A verifier uses `ampd`, an off-chain daemon responsible for voting and signing with the Amplifier protocol, and `tofnd`, a threshold cryptography library that `ampd` depends on.
+
+There are three ways to set up and run a verifier:
+
+- **Option 1: Source** -- Clone and build directly from the GitHub source code.
+- **Option 2: Binaries** -- This method requires you to install and run the `tofnd` and `ampd` binaries on your local machine.
+- **Option 3: Docker** -- Use [Docker](https://docs.docker.com/engine/install/) to set up `tofnd` and `ampd`.
+
+## Set up `tofnd`
+
+`ampd` needs access to a locally running `tofnd` instance in order to onboard as a verifier or run the daemon. See the [tofnd repository](https://github.com/axelarnetwork/tofnd) for more information.
+
+
+
+
+Install `tofnd` from source by cloning and building the [`tofnd` repository](https://github.com/axelarnetwork/tofnd).
+
+```bash
+git clone git@github.com:axelarnetwork/tofnd.git --recursive
+cd tofnd
+cargo build --release --locked
+```
+
+This will create a binary in the `target/release` directory. You can move this binary to a location in your `PATH` or run it directly from the `target/release` directory.
+
+Create a default mnemonic and configuration in `~/.tofnd/`, then back it up and delete it.
+
+```bash
+tofnd -m create
+mv ~/.tofnd/export ~/.tofnd/export-new-location
+```
+
+Create an alias or symlink to the `tofnd` binary in your `.bashrc`. Be sure to specify the correct file name which may be a different architecture or later version than `v1.0.1`.
+
+```bash
+echo "alias tofnd=~/Downloads/tofnd-linux-amd64-v1.0.1" >> ~/.bashrc
+source ~/.bashrc
+```
+
+Now run tofnd.
+
+```bash
+tofnd
+```
+
+
+
+
+Download the [`tofnd` binary](https://github.com/axelarnetwork/tofnd/releases) depending on the type of machine you have:
+ - Linux: [`tofnd-linux-amd64-v1.0.1`](https://github.com/axelarnetwork/tofnd/releases/download/v1.0.1/tofnd-linux-amd64-v1.0.1)
+ - Apple Mac (AMD64 or ARM): [`tofnd-darwin-amd64-v1.0.1`](https://github.com/axelarnetwork/tofnd/releases/download/v1.0.1/tofnd-darwin-amd64-v1.0.1)
+
+Create a default mnemonic and configuration in `~/.tofnd/`, then back it up and delete it.
+
+```bash
+~/Downloads/tofnd*-v1.0.1 -m create
+mv ~/.tofnd/export ~/.tofnd/export-new-location
+```
+
+Now run tofnd.
+
+```bash
+tofnd
+```
+
+
+
+
+
+Pull and run the latest version of `tofnd` from Docker:
+
+```bash
+docker pull axelarnet/tofnd:v1.0.1
+docker run -p 50051:50051 --env MNEMONIC_CMD=auto --env NOPASSWORD=true --env ADDRESS=0.0.0.0 -v tofnd:/.tofnd axelarnet/tofnd:v1.0.1
+```
+
+
+
+
+
+Leave this process running in the background, and perform additional commands in a new terminal window or shell.
+
+
+Note: If you are running a validator as well, you should use a different node for your verifier (the Axelar node that ampd connects to) on both testnet and mainnet than the one being run for your validator node to prevent loss of rewards in case the verifier fails. This node can use the `everything` pruning config to reduce resource use.
+
+
+
+Note: You also must run different `tofnd` instances for `vald` (for your validator) and `ampd` (for your verifier). You cannot use the same `tofnd` instance for both.
+
+
+## Set up `ampd`
+
+
+
+
+ Install `ampd` from source by cloning and building the [`axelar-amplifier`
+ repository](https://github.com/axelarnetwork/axelar-amplifier).
+
+
+
+ Download the [`ampd`
+ binary](https://github.com/axelarnetwork/axelar-amplifier/releases/tag/ampd-v1.2.0)
+ depending on the type of machine you have:
+ - Linux:
+ [`ampd-linux-amd64-v1.2.0`](https://github.com/axelarnetwork/axelar-amplifier/releases/download/ampd-v1.2.0/ampd-linux-amd64-v1.2.0)
+ - Apple Silicon Mac:
+ [`ampd-darwin-arm64-v1.2.0`](https://github.com/axelarnetwork/axelar-amplifier/releases/download/ampd-v1.2.0/ampd-darwin-arm64-v1.2.0)
+ - Intel Mac:
+ [`ampd-darwin-amd64-v1.2.0`](https://github.com/axelarnetwork/axelar-amplifier/releases/download/ampd-v1.2.0/ampd-darwin-amd64-v1.2.0)
+
+
+
+From [Docker](https://hub.docker.com/r/axelarnet/axelar-ampd), pull and run the `1.2.0` version of `ampd`:
+
+
+
+```bash
+docker pull axelarnet/axelar-ampd:v1.2.0
+docker run axelarnet/axelar-ampd:v1.2.0 verifier-address
+```
+
+
+
+
+
+The address for your verifier node will also be the address that rewards are sent to (this will change in the future). You should make sure to claim and move any available rewards regularly to mitigate any associated risks.
+
+
+## Add `ampd` to your `PATH`
+
+This will allow you to begin commands with `ampd`. If you set up `ampd` through source or Docker, you can skip this step.
+
+
+
+
+1. Add a symbolic link named `ampd` in your binaries folder.:
+
+ ```bash
+ sudo ln -s ~/Downloads/ampd-*-v1.2.0 /usr/local/bin/ampd
+ ```
+
+1. Make the binary executable:
+
+ ```bash
+ chmod a+x ~/Downloads/ampd-*-v*
+ ```
+
+1. Restart your terminal.
+
+1. Run `ampd --version` to make sure that the right version of `ampd` is being used. It should be {AMPD}.
+
+
+
+
+
+`ampd` releases can be found [here](https://github.com/axelarnetwork/axelar-amplifier/releases)
+
+
+
+
+ Replace `ampd-darwin-arm64-v1.2.0` with the [`ampd` binary you downloaded](/validator/amplifier/verifier-onboarding#set-up-ampd).
+
+
+1. Add an alias to `ampd` at the end of the `.bashrc` file on your machine:
+
+ ```bash
+ echo "alias ampd=~/Downloads/ampd-darwin-arm64-v1.2.0" >> ~/.bashrc
+ ```
+
+1. Reload the file to apply all changes:
+
+ ```bash
+ source ~/.bashrc
+ ```
+
+1. Restart your terminal.
+
+1. Run `ampd --version` to make sure that the right version of `ampd` was installed on your machine. It should be {AMPD}.
+
+
+
+
+
+ Replace `ampd-darwin-arm64-v1.2.0` with the [`ampd` binary you downloaded](/validator/amplifier/verifier-onboarding#set-up-ampd).
+
+1. Add an alias to `ampd` at the end of the `.zshrc` file on your machine:
+
+ ```bash
+ echo "ampd=~/Downloads/ampd-darwin-arm64-v1.2.0" >> ~/.zshrc
+ ```
+
+1. Save and close the file.
+
+1. Reload the file to apply all changes:
+
+ ```bash
+ source ~/.zshrc
+ ```
+
+1. Restart your terminal.
+
+1. Run `ampd --version` to make sure that the right version of `ampd` was installed on your machine. It should be {AMPD}.
+
+
+
+
+
+## Configure the verifier
+
+Create an `ampd` configuration file at `~/.ampd/config.toml`.
+
+This configuration file tells `ampd` how to connect to your local `tofnd`, how to talk to the devnet and the Amplifier smart contracts, and includes a default configuration for verifying transactions on the Avalanche testnet.
+
+The following are an example `config.toml` files:
+
+
+
+ ```toml
+ tm_jsonrpc="http://devnet-amplifier.axelar.dev:26657/"
+ tm_grpc="tcp://devnet-amplifier.axelar.dev:9090"
+ event_buffer_cap=10000
+
+ [service_registry]
+ cosmwasm_contract="axelar1c9fkszt5lq34vvvlat3fxj6yv7ejtqapz04e97vtc9m5z9cwnamq8zjlhz"
+
+ [broadcast]
+ batch_gas_limit="20000000"
+ broadcast_interval="1s"
+ chain_id="devnet-amplifier"
+ gas_adjustment="2"
+ gas_price="0.00005uamplifier"
+ queue_cap="1000"
+ tx_fetch_interval="1000ms"
+ tx_fetch_max_retries="15"
+
+ [tofnd_config]
+ batch_gas_limit="10000000"
+ key_uid="axelar"
+ party_uid="ampd"
+ url="http://127.0.0.1:50051/"
+
+ [grpc]
+ ip_addr = '127.0.0.1'
+ port = 9090
+ global_concurrency_limit = 1024
+ concurrency_limit_per_connection = 32
+ request_timeout = '30s'
+
+ [tm_grpc_timeout]
+ nanos="0"
+ secs="5"
+
+ [tofnd_config.timeout]
+ nanos="0"
+ secs="3"
+
+
+ [[handlers]]
+ chain_name="ethereum-sepolia"
+ chain_rpc_url="https://rpc.ankr.com/eth_sepolia"
+ cosmwasm_contract="axelar1e6jnuljng6aljk0tjct6f0hl9tye6l0n9p067pwx2374h82dmr0s9qcqy9"
+ type="EvmMsgVerifier"
+ chain_finalization="RPCFinalizedBlock"
+
+ [[handlers]]
+ chain_name="ethereum-sepolia"
+ chain_rpc_url="https://rpc.ankr.com/eth_sepolia"
+ cosmwasm_contract="axelar1e6jnuljng6aljk0tjct6f0hl9tye6l0n9p067pwx2374h82dmr0s9qcqy9"
+ type="EvmVerifierSetVerifier"
+
+ [[handlers]]
+ chain_name="ethereum-sepolia"
+ type="MultisigSigner"
+ cosmwasm_contract="axelar19jxy26z0qnnspa45y5nru0l5rmy9d637z5km2ndjxthfxf5qaswst9290r"
+
+ [[handlers]]
+ chain_name="avalanche"
+ chain_rpc_url="https://avalanche-fuji-c-chain-rpc.publicnode.com/"
+ cosmwasm_contract="axelar1ty7mx0cllgz8xuvhn2j7e3qy8999ssgmjtktyqetl335em0g88lq6rjhl2"
+ type="EvmMsgVerifier"
+ chain_finalization="RPCFinalizedBlock"
+
+ [[handlers]]
+ chain_name="avalanche"
+ chain_rpc_url="https://avalanche-fuji-c-chain-rpc.publicnode.com/"
+ cosmwasm_contract="axelar1ty7mx0cllgz8xuvhn2j7e3qy8999ssgmjtktyqetl335em0g88lq6rjhl2"
+ type="EvmVerifierSetVerifier"
+
+ [[handlers]]
+ chain_name="avalanche"
+ type="MultisigSigner"
+ cosmwasm_contract="axelar19jxy26z0qnnspa45y5nru0l5rmy9d637z5km2ndjxthfxf5qaswst9290r"
+ ```
+
+
+ ```toml
+ # replace with your Axelar testnet node
+ tm_jsonrpc="http://127.0.0.1:26657/"
+ tm_grpc="tcp://127.0.0.1:9090"
+ event_buffer_cap=100000
+
+ [service_registry]
+ cosmwasm_contract="axelar1rpj2jjrv3vpugx9ake9kgk3s2kgwt0y60wtkmcgfml5m3et0mrls6nct9m"
+
+ [broadcast]
+ batch_gas_limit="20000000"
+ broadcast_interval="1s"
+ chain_id="axelar-testnet-lisbon-3"
+ gas_adjustment="2"
+ gas_price="0.007uaxl"
+ queue_cap="1000"
+ tx_fetch_interval="1000ms"
+ tx_fetch_max_retries="15"
+
+ [tofnd_config]
+ batch_gas_limit="10000000"
+ key_uid="axelar"
+ party_uid="ampd"
+ url="http://127.0.0.1:50051/"
+
+ [tm_grpc_timeout]
+ nanos="0"
+ secs="5"
+
+ [tofnd_config.timeout]
+ nanos="0"
+ secs="3"
+
+ [grpc]
+ ip_addr = '127.0.0.1'
+ port = 9090
+ global_concurrency_limit = 1024
+ concurrency_limit_per_connection = 32
+ request_timeout = '30s'
+
+ [[handlers]]
+ chain_name="test-sepolia"
+ chain_rpc_url="https://rpc.ankr.com/eth_sepolia"
+ cosmwasm_contract="axelar1r4rmvn83vrfj4evy5l8cv2nat2v0whm36ds3crn2mhlq8ufmhvts9467zz"
+ chain_finalization="RPCFinalizedBlock"
+ type="EvmMsgVerifier"
+
+ [[handlers]]
+ chain_name="test-sepolia"
+ chain_rpc_url="https://rpc.ankr.com/eth_sepolia"
+ cosmwasm_contract="axelar1r4rmvn83vrfj4evy5l8cv2nat2v0whm36ds3crn2mhlq8ufmhvts9467zz"
+ chain_finalization="RPCFinalizedBlock"
+ type="EvmVerifierSetVerifier"
+
+ [[handlers]]
+ chain_name="test-sepolia"
+ type="MultisigSigner"
+ cosmwasm_contract="axelar14a4ar5jh7ue4wg28jwsspf23r8k68j7g5d6d3fsttrhp42ajn4xq6zayy5"
+
+ [[handlers]]
+ chain_name="test-avalanche"
+ chain_rpc_url="https://api.avax-test.network/ext/bc/C/rpc"
+ cosmwasm_contract="axelar1hupk5du59cgu4ps5s637rhakwsq0060ycdp57j2ccevna7wqqzrqnfrr0p"
+ chain_finalization="ConfirmationHeight"
+ type="EvmMsgVerifier"
+
+ [[handlers]]
+ chain_name="test-avalanche"
+ chain_rpc_url="https://api.avax-test.network/ext/bc/C/rpc"
+ cosmwasm_contract="axelar1hupk5du59cgu4ps5s637rhakwsq0060ycdp57j2ccevna7wqqzrqnfrr0p"
+ chain_finalization="ConfirmationHeight"
+ type="EvmVerifierSetVerifier"
+
+ [[handlers]]
+ chain_name="test-avalanche"
+ type="MultisigSigner"
+ cosmwasm_contract="axelar14a4ar5jh7ue4wg28jwsspf23r8k68j7g5d6d3fsttrhp42ajn4xq6zayy5"
+
+ [[handlers]]
+ chain_name="flow"
+ chain_rpc_url="[flow gateway rpc url]"
+ cosmwasm_contract="axelar1kkqdsqvwq9a7p9fj0w89wpx2m2t0vrxl782aslhq0kdw2xxd2aesv3un04"
+ chain_finalization="RPCFinalizedBlock"
+ type="EvmMsgVerifier"
+
+ [[handlers]]
+ chain_name="flow"
+ chain_rpc_url="[flow gateway rpc url]"
+ cosmwasm_contract="axelar1kkqdsqvwq9a7p9fj0w89wpx2m2t0vrxl782aslhq0kdw2xxd2aesv3un04"
+ chain_finalization="RPCFinalizedBlock"
+ type="EvmVerifierSetVerifier"
+
+ [[handlers]]
+ chain_name="flow"
+ type="MultisigSigner"
+ cosmwasm_contract="axelar14a4ar5jh7ue4wg28jwsspf23r8k68j7g5d6d3fsttrhp42ajn4xq6zayy5"
+
+
+ # For each supported chain
+ #[[handlers]]
+ #chain_name="[chain name]"
+ #chain_rpc_url="[node rpc url]"
+ #cosmwasm_contract="[voting verifier address]"
+ #chain_finalization="[RPCFinalizedBlock or ConfirmationHeight]"
+ #type="EvmMsgVerifier"
+
+ #[[handlers]]
+ #chain_name="[chain name]"
+ #chain_rpc_url="[node rpc url]"
+ #cosmwasm_contract="[voting verifier address]"
+ #chain_finalization=["RPCFinalizedBlock" or "ConfirmationHeight"]
+ #type="EvmVerifierSetVerifier"
+ ```
+
+
+ ```toml
+ # replace with your Axelar mainnet node
+ tm_jsonrpc="http://127.0.0.1:26657/"
+ tm_grpc="tcp://127.0.0.1:9090"
+ event_buffer_cap=100000
+
+ [service_registry]
+ cosmwasm_contract="axelar1rpj2jjrv3vpugx9ake9kgk3s2kgwt0y60wtkmcgfml5m3et0mrls6nct9m"
+
+ [broadcast]
+ batch_gas_limit="20000000"
+ broadcast_interval="1s"
+ chain_id="axelar-dojo-1"
+ gas_adjustment="2"
+ gas_price="0.007uaxl"
+ queue_cap="1000"
+ tx_fetch_interval="1000ms"
+ tx_fetch_max_retries="15"
+
+ [tofnd_config]
+ batch_gas_limit="10000000"
+ key_uid="axelar"
+ party_uid="ampd"
+ url="http://127.0.0.1:50051/"
+
+ [tm_grpc_timeout]
+ nanos="0"
+ secs="5"
+
+ [tofnd_config.timeout]
+ nanos="0"
+ secs="3"
+
+ [grpc]
+ ip_addr = '127.0.0.1'
+ port = 9090
+ global_concurrency_limit = 1024
+ concurrency_limit_per_connection = 32
+ request_timeout = '30s'
+
+ [[handlers]]
+ chain_name="flow"
+ chain_rpc_url="[flow gateway rpc url]"
+ cosmwasm_contract="axelar1kkqdsqvwq9a7p9fj0w89wpx2m2t0vrxl782aslhq0kdw2xxd2aesv3un04"
+ chain_finalization="RPCFinalizedBlock"
+ type="EvmMsgVerifier"
+
+ [[handlers]]
+ chain_name="flow"
+ chain_rpc_url="[flow gateway rpc url]"
+ cosmwasm_contract="axelar1kkqdsqvwq9a7p9fj0w89wpx2m2t0vrxl782aslhq0kdw2xxd2aesv3un04"
+ chain_finalization="RPCFinalizedBlock"
+ type="EvmVerifierSetVerifier"
+
+ [[handlers]]
+ chain_name="flow"
+ type="MultisigSigner"
+ cosmwasm_contract="axelar14a4ar5jh7ue4wg28jwsspf23r8k68j7g5d6d3fsttrhp42ajn4xq6zayy5"
+
+
+ # For each supported chain
+ #[[handlers]]
+ #chain_name="[chain name]"
+ #chain_rpc_url="[node rpc url]"
+ #cosmwasm_contract="[voting verifier address]"
+ #chain_finalization="[RPCFinalizedBlock or ConfirmationHeight]"
+ #type="EvmMsgVerifier"
+
+ #[[handlers]]
+ #chain_name="[chain name]"
+ #chain_rpc_url="[node rpc url]"
+ #cosmwasm_contract="[voting verifier address]"
+ #chain_finalization=["RPCFinalizedBlock" or "ConfirmationHeight"]
+ #type="EvmVerifierSetVerifier"
+ ```
+
+
+
+See the [`ampd` README](https://github.com/axelarnetwork/axelar-amplifier/blob/main/ampd/README.md) on GitHub for instructions on formatting a `config` file for your own projects. For `chain_finalization`, if the chain supports the `finalized` tag via the RPC API, choose `RPCFinalizedBlock`, otherwise choose `ConfirmationHeight`.
+
+
+ If you get a transport error with an `ampd` command, make sure that you have
+ `tofnd` running in the background.
+
+
+## Fund your wallet
+
+Prior to running the `ampd` daemon, you will need to set up your wallet with devnet funds.
+
+1. Determine your verifier address:
+
+ ```bash
+ ampd verifier-address
+ ```
+
+
+ If you get a security warning while trying to run `ampd` on an Apple
+ Silicon Mac, you can disable the
+ [gatekeeper](https://support.apple.com/guide/security/gatekeeper-and-runtime-protection-sec5599b66df/web)
+ for a single binary with `sudo xattr -d com.apple.quarantine
+ ~/Downloads/ampd-darwin-arm64-v1.2.0` or disable gatekeeper globally with
+ `sudo spctl --master-disable`.
+
+
+1. Fund your verifier address.
+
+ 1. Fill out the [Amplifier Verifier Onboarding Form](https://docs.google.com/forms/d/e/1FAIpQLSfQQhk292yT9j8sJF5ARRIE8PpI3LjuFc8rr7xZW7posSLtJA/viewform) for your address to be whitelisted or to receive funds.
+
+## Activate and run the verifier
+
+1. Bond your verifier:
+
+
+
+ ```bash
+ ampd bond-verifier validators 100 uamplifier
+ ```
+
+
+ ```bash
+ ampd bond-verifier amplifier 100000000000 uaxl
+ ```
+
+
+ ```bash
+ ampd bond-verifier amplifier 50000000000 uaxl
+ ```
+
+
+
+ Bonded verifiers will stay bonded until they unbond or are removed by governance. The bond for testnet is 100000000000uamplifier (100k AXL). The bond for mainnet is 50000000000uamplifier (50k AXL).
+
+1. Register your public key with `ecdsa` and `ed25519`:
+
+
+
+ ```bash
+ ampd register-public-key ecdsa
+ ```
+
+
+ ```bash
+ ampd register-public-key ed25519
+ ```
+
+
+
+
+1. Register support for desired chains, enabling `ampd` to participate in voting and signing for your supported chains.
+
+
+
+ ```bash
+ ampd register-chain-support validators flow
+ ```
+
+
+ ```bash
+ ampd register-chain-support amplifier flow
+ ```
+
+
+
+ Multiple chain names can be passed, separated by a space (`ampd register-chain-support [service name] [chains]...`). Note that any chain you want to support here must be configured in your ampd `config.toml` file.
+
+1. Authorize your verifier.
+
+ This is dependent on the environment, and can be done via governance, or by the network operators.
+
+1. Run the `ampd` daemon.
+
+ Running `ampd` without any command will run the daemon.
+
+## Productionizing
+
+As you move towards testnet and mainnet, you should switch to running your own full Axelar node and your own full node or light client for any chains you are voting on.
+
+## Help
+
+For more info about the available commands and options, run:
+
+```bash
+ampd --help
+```
+
+## Feedback
+
+If you have any feedback or would like to report a bug, please file an issue in the [Axelar Developer Support repository](https://github.com/axelarnetwork/support/issues).
diff --git a/src/content/docs/validator/amplifier/verifier-rewards.mdx b/src/content/docs/validator/amplifier/verifier-rewards.mdx
new file mode 100644
index 000000000..dbac44c00
--- /dev/null
+++ b/src/content/docs/validator/amplifier/verifier-rewards.mdx
@@ -0,0 +1,192 @@
+# Verifier Rewards
+
+import { Callout } from "/src/components/callout";
+
+Verifiers are responsible for securing transactions with chains connected to the Axelar Network via the [Axelar Amplifier](/dev/amplifier/introduction). Verifiers vote on the truthfulness of transactions posted to the network and create signatures for outgoing messages. In compensation for these activities and the associated decentralized node running costs, verifiers earn rewards provided by each chain integrator.
+
+Rewards are calculated based on counted contributions. A contribution is counted whenever a poll ends based on the verifiers who voted, and when a verifier signs an event. Contributions are tracked in the [verifier rewards contract](https://github.com/axelarnetwork/axelar-amplifier/tree/main/contracts/rewards).
+
+Contributions are assessed per epoch (a length of time configured by governance). At the conclusion of an epoch, a message can be sent to the rewards contract to process rewards for the most recent window. Rewards are calculated based on a percentage of all traffic for a given chain and paid in AXL.
+
+
+
+
+
+ The `EndBlocker` is code that executes at the end of each block so that
+ rewards are distributed automatically. It has not yet been implemented in the
+ Axelar Amplifier.
+
+
+## Voting flow
+
+
+
+
+
+1. The relayer picks up a `callContract()` event and calls `verify_messages()` on the Axelar gateway.
+1. The Axelar gateway calls `verify_messages()` on the voting verifier, which begins the voting process with the verifier set.
+1. Once enough votes have been cast for the message, a `record_participation()` event is emitted to the rewards contract.
+1. The rewards contract keeps a tally of how many events each verifier correctly participated in.
+
+## Signing flow
+
+
+ 
+
+
+The destination chain uses the prover rather than the voting verifier to pass the message.
+
+1. The multisig prover gets the messages and their contents from the gateway and calls `start_signing_session()` on the multisig contract, which begins the signing process with the verifier set.
+1. Registered chains, who have their own sets of verifiers, become aware that there is a signing session for the chain they support with their public keys and start signing.
+1. Once enough signatures have been gathered, a signed batch will be created and eventually relayed back to the source chain.
+1. If a verifier signed during a certain grace period, the multisig contract emits a `record_participation()` event to the rewards contract.
+1. The rewards contract keeps a tally of how many events each verifier correctly participated in.
+
+## Reward pools
+
+Each integrated chain has two pools that must be funded independently. There is one rewards pool for signing and one pool for voting.
+
+Reward pools are not tied to an epoch. If earned rewards are not claimed, they will continue to grow. If rewards are being earned but the pool has not been sufficiently funded, these rewards can be funded and claimed at a later date. Integrators should ensure that pools always have enough funds so that verifiers can get their rewards quickly.
+
+## Rewards calculation
+
+Rewards are calculated through the following parameters, which are first configured during [contract instantiation](https://github.com/axelarnetwork/axelar-amplifier/blob/6fd3612716fc6cf3b421ebe53939a71341731047/contracts/voting-verifier/src/msg.rs#L13). These parameters can be modified through governance:
+
+- [`epoch_duration`](https://github.com/axelarnetwork/axelar-amplifier/blob/6d6b974e1a911b17b2d019cb14c5ceb748cc244a/contracts/rewards/src/msg.rs#L21) — How often rewards are calculated, specified in number of blocks. For example, an `epoch_duration` of 500 blocks will reward verifiers for their participation in each 500-block window.
+- [`rewards_per_epoch`](https://github.com/axelarnetwork/axelar-amplifier/blob/6d6b974e1a911b17b2d019cb14c5ceb748cc244a/contracts/rewards/src/msg.rs#L24) — The total number of tokens distributed as rewards per epoch, split equally amongst all participating verifiers for a given epoch. The same for both signing and voting.
+- [`participation_threshold`](https://github.com/axelarnetwork/axelar-amplifier/blob/6d6b974e1a911b17b2d019cb14c5ceb748cc244a/contracts/rewards/src/msg.rs#L30C9-L30C32) — The participation threshold that verifiers must meet to receive given rewards in a given epoch, specified as a fraction between 0 (exclusive) and 1 (exclusive). Verifiers must participate in at least this fraction of all events in a given epoch to receive rewards. Participation is reset at the beginning of each epoch, so participation in previous epochs does not affect rewards for future epochs.
+
+## Check the funds in a pool
+
+Use `rewards_pool()` to check the funds in a pool:
+
+
+
+ ```bash export
+ REWARDS_CONTRACT_ADDRESS="axelar1vaj9sfzc3z0gpel90wu4ljutncutv0wuhvvwfsh30rqxq422z89qnd989l"
+ export CHAIN_NAME="fantom" export
+ VOTING_VERIFIER_OR_MULTISIG_CONTRACT_ADDRESS="axelar1ty7mx0cllgz8xuvhn2j7e3qy8999ssgmjtktyqetl335em0g88lq6rjhl2"
+ # or "axelar1g6520uhs8u37el40wqngf60z06mjgk6z7nezytd2mxrmh7yesnmsyc0zjw"
+ export RPC="http://devnet-amplifier.axelar.dev:26657/"
+```
+
+
+ ```bash export
+ REWARDS_CONTRACT_ADDRESS="axelar1harq5xe68lzl2kx4e5ch4k8840cgqnry567g0fgw7vt2atcuugrqfa7j5z"
+ export CHAIN_NAME="test-avalanche" export
+ VOTING_VERIFIER_OR_MULTISIG_CONTRACT_ADDRESS="axelar1hupk5du59cgu4ps5s637rhakwsq0060ycdp57j2ccevna7wqqzrqnfrr0p"#
+ or "axelar1l5k8wlzmkmtnvjvs9x77wdcfweucwgums9e8fh0d8cy76ymqc5aqzguqnn"
+ export RPC="https://tm.axelar-testnet.lava.build/"
+```
+
+
+
+
+ You can get the addresses of the rewards, voting verifier, and multisig
+ contracts through
+ [`devnet-amplifier.json`](https://github.com/axelarnetwork/axelar-contract-deployments/blob/019d41f81b506d35fa89ffd9ebb3a02719563e09/axelar-chains-config/info/devnet-amplifier.json).
+
+
+```bash
+axelard q wasm contract-state smart $REWARDS_CONTRACT_ADDRESS \
+ '{
+ "rewards_pool":
+ {
+ "pool_id":
+ {
+ "chain_name":"'"$CHAIN_NAME"'",
+ "contract":"'"$VOTING_VERIFIER_OR_MULTISIG_CONTRACT_ADDRESS"'"
+ }
+ }
+ }' \
+ --node $RPC
+```
+
+## Distribute rewards
+
+Use `distribute_rewards()` to distribute rewards from a pool:
+
+
+
+ ```bash
+ export REWARDS_CONTRACT_ADDRESS="axelar1vaj9sfzc3z0gpel90wu4ljutncutv0wuhvvwfsh30rqxq422z89qnd989l"
+ export CHAIN_NAME="avalanche"
+ export VOTING_VERIFIER_OR_MULTISIG_CONTRACT_ADDRESS="axelar1elaymnd2epmfr498h2x9p2nezc4eklv95uv92u9csfs8wl75w7yqdc0h67" || "0x7eeE33A59Db27d762AA1Fa31b26efeE0dABa1132"
+ export RPC="http://devnet-amplifier.axelar.dev:26657/"
+ ```
+
+
+ ```bash
+ export REWARDS_CONTRACT_ADDRESS="axelar1harq5xe68lzl2kx4e5ch4k8840cgqnry567g0fgw7vt2atcuugrqfa7j5z"
+ export CHAIN_NAME="test-avalanche"
+ export VOTING_VERIFIER_OR_MULTISIG_CONTRACT_ADDRESS="axelar1hupk5du59cgu4ps5s637rhakwsq0060ycdp57j2ccevna7wqqzrqnfrr0p" || "0x7eeE33A59Db27d762AA1Fa31b26efeE0dABa1132"
+ export RPC="https://tm.axelar-testnet.lava.build/"
+ ```
+
+
+
+
+
+ You can get the addresses of the rewards, voting verifier, and multisig
+ contracts through
+ [`devnet-amplifier.json`](https://github.com/axelarnetwork/axelar-contract-deployments/blob/019d41f81b506d35fa89ffd9ebb3a02719563e09/axelar-chains-config/info/devnet-amplifier.json).
+
+
+```bash
+axelard tx wasm execute $REWARDS_CONTRACT_ADDRESS \
+ '{
+ "distribute_rewards":
+ {
+ "pool_id":
+ {
+ "chain_name":"'"$CHAIN_NAME"'",
+ "contract":"'"$VOTING_VERIFIER_OR_MULTISIG_CONTRACT_ADDRESS"'"
+ },
+ "epoch_count":10
+ }
+ }' \
+ --keyring-backend test \
+ --from wallet \
+ --gas auto --gas-adjustment 1.5 --gas-prices 0.007uamplifier \
+ --node $RPC
+```
+
+Rewards are distributed to verifiers with a participation rate greater than the threshold as the epoch closes. Rewards are calculated based on the time passed since the last event and the total number of verifiers, and split equally amongst all participating verifiers in the epoch.
+
+`epoch_count` is the maximum number of historical epochs for which to distribute rewards, starting with the oldest. If not specified, rewards will be distributed for the last 10 epochs.
+
+
+## Withdrawing rewards
+By default your verifier rewards will be sent to the address of your verifier (change this with `ampd set-rewards-proxy`). To withdraw your rewards, use `ampd`'s `send-tokens` feature.
+
+```bash
+ampd send-tokens uaxl
+```
\ No newline at end of file
diff --git a/src/content/docs/validator/amplifier/verifier-rotations.mdx b/src/content/docs/validator/amplifier/verifier-rotations.mdx
new file mode 100644
index 000000000..1e0f2a08b
--- /dev/null
+++ b/src/content/docs/validator/amplifier/verifier-rotations.mdx
@@ -0,0 +1,63 @@
+# Verifier Rotations
+
+One type of message the network can sign and prove to a destination chain is a message containing an update to the verifier set. To make an update to the verifier set for a chain, the previous verifier set must sign a message communicating the changes.
+
+## Check if a verifier is in an active set
+
+Use `current_verifier_set` to get the active verifier set for an integrated chain. This is the same as the signer set unless there is a verifier set update in progress, since the prover requires a few extra steps before active verifier sets can be confirmed as signers.
+
+```bash
+export CHAIN_MULTISIG_PROVER_ADDRESS="axelar1xz4cya4qm2ws6nzperhvc40wdjcq4872fl6d3j2s4cytyx8j80eqenv87g"
+export RPC="https://tm.axelar-testnet.lava.build/"
+```
+
+```bash
+axelard q wasm contract-state smart $CHAIN_MULTISIG_PROVER_ADDRESS \
+ '"current_verifier_set"' \
+ --node $RPC
+```
+
+## Get proof of a verifier set change
+
+[`get_proof`](https://github.com/axelarnetwork/axelar-amplifier/blob/f76dc8a775b8bb529cf50147bab9259d1ec7f784/contracts/multisig-prover/src/msg.rs#L81) communicates with a destination chain that a [verifier set has been changed](https://github.com/axelarnetwork/axelar-amplifier/blob/main/doc/src/contracts/multisig_prover.md#update-and-confirm-verifierset-sequence-diagram), and tells the destination chain that it must accept signatures from these new verifiers.
+
+```bash
+export MULTISIG_SESSION_ID="3457"
+```
+
+```bash
+axelard q wasm contract-state smart $CHAIN_MULTISIG_PROVER_ADDRESS \
+ '{
+ "get_proof":{
+ "multisig_session_id":"'"$MULTISIG_SESSION_ID"'"
+ }
+ }' \
+ --node $RPC
+```
+
+## Update the verifier set for a given chain
+
+When a verifier set is rotated for a given chain, the existing signers verify the new signers via the `update_verifier_set` command. This is temporarily permissioned to the admin contract established by the network.
+
+```bash
+axelard tx wasm execute $CHAIN_MULTISIG_PROVER_ADDRESS \
+ '"update_verifier_set"' \
+ --from wallet
+ --gas auto --gas-adjustment 1.5 --gas-prices 0.007uverifiers \
+ --chain-id axelar-testnet-lisbon-3 \
+ --node $RPC
+```
+
+## Confirm the verifier set after a vote
+
+Use `confirm_verifier_set` to confirm a verifier set update.
+
+```bash
+axelard tx wasm execute $CHAIN_MULTISIG_PROVER_ADDRESS \
+ '"confirm_verifier_set"' \
+ --keyring-backend test
+ --from wallet
+ --gas auto --gas-adjustment 1.5 --gas-prices 0.007uverifiers \
+ --chain-id axelar-testnet-lisbon-3 \
+ --node $RPC
+```
diff --git a/src/content/docs/validator/amplifier/verifier-security-expectations.mdx b/src/content/docs/validator/amplifier/verifier-security-expectations.mdx
new file mode 100644
index 000000000..c0c482593
--- /dev/null
+++ b/src/content/docs/validator/amplifier/verifier-security-expectations.mdx
@@ -0,0 +1,13 @@
+# Verifier Security Expectations
+
+To maintain the security of the Axelar network, every verifier must:
+
+- Run a full [Axelar node](/node/config-node/).
+- Maintain independent chain nodes.
+- Monitor ampd uptime to maintain a continuous operational availability for voting.
+- Rotate keys on a regular basis.
+- Pull rewards regularly.
+- Only support chains that are fully trustworthy.
+- Be responsive to calls for escalation.
+- Participate in regular security drills.
+- Adhere to the [color-coded messaging scheme](https://bright-ambert-2bd.notion.site/Partners-Messaging-Scheme-Public-Page-0e5021d084eb4824bdf3216e59d3c39a) between partners and the Interop Labs team.
diff --git a/src/pages/validator/external-chains/arbitrum.mdx b/src/content/docs/validator/external-chains/arbitrum.mdx
similarity index 56%
rename from src/pages/validator/external-chains/arbitrum.mdx
rename to src/content/docs/validator/external-chains/arbitrum.mdx
index 57f35bb46..ac943ccf7 100644
--- a/src/pages/validator/external-chains/arbitrum.mdx
+++ b/src/content/docs/validator/external-chains/arbitrum.mdx
@@ -1,18 +1,19 @@
# Arbitrum
-import { Callout } from "/src/components/callout"
+import { Callout } from "/src/components/callout";
-Set up your Arbitrum Mainnet & Goerli Testnet RPC node
+Set up your Arbitrum Mainnet & Sepolia Testnet RPC node
## Prerequisites
-- [Setup your Axelar validator](/validator/setup)
-- [Setup your Ethereum node](ethereum)
+- [Setup your Axelar validator](/validator/setup/overview/)
+- [Setup your Ethereum node](/validator/external-chains/ethereum/)
- Minimum hardware requirements: CPU with 2+ cores, 4GB RAM, 600GB+ free storage space.
- MacOS or Ubuntu 20.04+
- [Official Documentation](https://developer.offchainlabs.com/node-running/running-a-node)
## Steps
+
1. Install Docker
2. Install Arbitrum image
3. Configure vald
@@ -34,22 +35,25 @@ chmod -fR 777 $HOME/data/arbitrum
```
Now, you will see this flag in the command below `--l1.url ` this means that your arbitrum node needs a synced Ethereum node.
-Please provide the RPC URL of your synced [Ethereum node](ethereum) with this flag.
+Please provide the RPC URL of your synced [Ethereum node](/validator/external-chains/ethereum/) with this flag.
- Please use your own Ethereum node instead of using 3rd party providers like alchemy, infura etc. for decentralization/security. Third-party providers also have a specific request limit, and your node can throw 100s of thousands of requests while trying to sync.
+ Please use your own Ethereum node instead of using 3rd party providers like
+ alchemy, infura etc. for decentralization/security. Third-party providers also
+ have a specific request limit, and your node can throw 100s of thousands of
+ requests while trying to sync.