### Install Across SDK and Viem

Source: https://docs.across.to/developer-quickstart/bridge-integration-guide

Installs the necessary packages for integrating Across Protocol, including the App SDK and Viem for blockchain interactions. Supports multiple package managers like pnpm, npm, yarn, and bun.

```sh
pnpm i @across-protocol/app-sdk viem
```

```sh
npm i @across-protocol/app-sdk viem
```

```sh
yarn add @across-protocol/app-sdk viem
```

```sh
bun add @across-protocol/app-sdk viem
```

--------------------------------

### Available Routes: Native USDC to Native USDC

Source: https://docs.across.to/introduction/migration-guides/migration-to-cctp/migration-guide-for-api-users

Example showing a new route available from USDC on Ethereum to Native USDC on Optimism, following CCTP migration.

```json
{
  "originChainId": 1,
  "originToken": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
  "destinationChainId": 10,
  "destinationToken": "0x0b2c639c533813f4aa9d7837caf62653d097ff85"
}
```

--------------------------------

### Solana Deposit Utility Script

Source: https://docs.across.to/introduction/migration-guides/solana-migration-guide

Demonstrates how to call the `deposit()` function with an `integratorID` for seamless transaction execution on Solana. This script serves as an example for developers integrating Solana routes.

```typescript
import { deposit } from "@across-protocol/contracts/scripts/svm/simpleDeposit";

// Example usage:
const integratorId = "yourIntegratorId";
const amount = "1000000"; // Example amount in smallest unit
const destinationChain = "ethereum"; // Example destination chain

// Call the deposit function
deposit(integratorId, amount, destinationChain);
```

--------------------------------

### Available Routes: Native USDC to Bridged USDC

Source: https://docs.across.to/introduction/migration-guides/migration-to-cctp/migration-guide-for-api-users

Example route showing a deposit from USDC on Ethereum to Bridged USDC on Optimism, illustrating the addition of routes with Native USDC as a destination token.

```json
{
  "originChainId": 1,
  "originToken": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
  "destinationChainId": 10,
  "destinationToken": "0x7F5c764cBc14f9669B88837ca1490cCa17c31607"
}
```

--------------------------------

### Install and Build Relayer

Source: https://docs.across.to/relayers/running-a-relayer

Clones the relayer repository, sets up environment files with secure permissions for the private key, installs dependencies using yarn, and builds the relayer. Requires Node.js and yarn.

```shell
git clone https://github.com/across-protocol/relayer-v3.git
cd relayer-v3

touch .env
chmod 0600 .env

touch .secret
chown <user>:<group> .secret
chmod 0600 .secret
echo <private-key-or-mnemonic> > .secret
chmod 0400 .secret

yarn install
yarn build
```

--------------------------------

### Relayer-v2 Installation

Source: https://docs.across.to/reference/security-model-and-verification/disputing-root-bundles

Steps to clone the relayer-v2 repository, install dependencies, and set up the environment for automated dispute procedures.

```shell
git clone https://github.com/across-protocol/relayer-v2.git
cd relayer-v2
yarn install && yarn build

cp .env.example .env
```

--------------------------------

### Relayer Solana Dependencies

Source: https://docs.across.to/introduction/migration-guides/solana-migration-guide

Lists the required package dependencies for relayers who will support Solana operations, including the SDK, contracts, and Solana web3 libraries.

```json
{
  "dependencies": {
    "@across-protocol/sdk": "^latest",
    "@across-protocol/contracts": "^latest",
    "@solana/kit": "^latest",
    "@solana/web3.js": "^2.0.0" 
  }
}
```

--------------------------------

### Across V3 API Detailed Fees Structure

Source: https://docs.across.to/introduction/migration-guides/migration-from-v2-to-v3

Details the new `v3` fee properties added to the `GET /suggested-fees` response for a granular fee breakdown, and how to use them in the `SpokePool.deposit` function.

```typescript
type FeesResponse = {
     // ... other fields
    totalRelayFee: {
        pct: string;
        total: string;
    }; // relayerCapitalFee + relayerGasFee + lpFee
    relayerCapitalFee: {
        pct: string;
        total: string;
    };
    relayerGasFee: {
        pct: string;
        total: string;
    };
    lpFee: {
        pct: string;
        total: string;
    };
}

// Usage in SpokePool.deposit (with detailed fees):
const tx = await spokePool.deposit(
    // ... other args
    feesResponse.totalRelayFee.pct
)
```

--------------------------------

### Configure RPC Providers

Source: https://docs.across.to/relayers/running-a-relayer

Sets up environment variables for RPC providers for different chains. It includes examples for Infura and Alchemy, and demonstrates how to specify preferences and per-chain overrides.

```shell
# Do change the following configs:

# SECRET identifies a separate file containing a private key or mnemonic
# to be used by the relayer. The file must contain only the raw key or
# mnemonic. Critical: Ensure that the filesystem permissions for this
# file are properly configured (i.e. owned by one specific user, not
# world-readable, ...).
# SECRET=<path-to-private-key-or-mnemonic>
SECRET=.secret

# Define RPC providers for each chain. One RPC provider is specified
# per line. Format:
# RPC_PROVIDER_<PROVIDER-NAME>_<CHAIN-ID>=<ENDPOINT-URL>
RPC_PROVIDER_INFURA_1=https://mainnet.infura.io/v3/...
RPC_PROVIDER_INFURA_10=https://optimism-mainnet.infura.io/v3/...
# Repeat this for each supported chain (1, 10, 137, 42161, ...)

RPC_PROVIDER_ALCHEMY_1=https://eth-mainnet.g.alchemy.com/v2/...
# Repeat this for each supported chain (1, 10, 137, 42161, ...)

# Specify RPC provider preferences. The first provider is always used.
# Subsequent providers are used as backups in event of a higher
# priority provider being unavailable, or failing quorum. If
# NODE_QUORUM is > 1, there must be at least NODE_QUORUM number of
# providers defined, and some RPC queries will be performed against
# NODE_QUORUM number of providers in parallel.
RPC_PROVIDERS=INFURA,ALCHEMY

# Per-chain overrides are possible. In the example below, LlamaNodes
# is preferred on Ethereum and Polygon.
RPC_PROVIDERS_1=LLAMANODES,INFURA,ALCHEMY
RPC_PROVIDERS_137=LLAMANODES,INFURA,ALCHEMY

# Enable on-chain relayer functionality. This is disabled by default
# and must be explicitly enabled for the relayer to send transactions.
# This can be used to run bot in "simulation mode". To turn bot on,
# set to "true".
SEND_RELAYS=false

# Deposit lookback window, specified in seconds. This is subtracted
# from the current time and is resolved to a block number on each
# chain, effectively controlling how far back in time the relayer
# will scan for unfilled deposits. 
MAX_RELAYER_DEPOSIT_LOOK_BACK=1800

# Gas fees are difficult to estimate correctly, and the strategy for
# setting  gas might depend on the priorities of the relay bot operator.
```

--------------------------------

### Bridge Integration Steps

Source: https://docs.across.to/developer-quickstart/bridge-ui-guides

The bridge integration involves a simple two-step process using the SDK to provide bridge quotes to users. This enables users to onboard and bridge funds without leaving your application.

```APIDOC
getQuote()
  - Description: Requests bridge quotes for users.
  - Related: executeQuote()

executeQuote()
  - Description: Executes a deposit after a quote has been obtained.
  - Related: getQuote()
```

--------------------------------

### Available Routes: Bridged USDC to Native USDC

Source: https://docs.across.to/introduction/migration-guides/migration-to-cctp/migration-guide-for-api-users

Example route showing a deposit from Bridged USDC on Polygon to USDC on Ethereum, illustrating the replacement of Bridged USDC addresses with Native USDC addresses after CCTP migration.

```json
{
  "originChainId": 137,
  "originToken": "0x2791Bca1f2de4661ED88A30C99A7a9449Aa84174",
  "destinationChainId": 1,
  "destinationToken": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48"
}
```

--------------------------------

### Across V3 API Fees Response Structure (Backward Compatible)

Source: https://docs.across.to/introduction/migration-guides/migration-from-v2-to-v3

Shows the backward-compatible changes to the `FeesResponse` for the V3 API's `GET /suggested-fees` endpoint, indicating how `relayFeePct` now includes `lpFeePct`.

```typescript
type FeesResponse = {
    // ... other fields
    capitalFeePct: string;
    capitalFeeTotal: string;
    relayGasFeePct: string;
    relayGasFeeTotal: string;
    relayFeePct: string; // capitalFeePct + gasFeePct + lpFeePct
    relayFeeTotal: string; // capitalFeeTotal + gasFeeTotal + lpFeeTotal
    lpFeePct: "0";
}

// Usage in SpokePool.deposit (no change required for backward compatibility):
const tx = await spokePool.deposit(
    // ... other args
    feesResponse.relayFeePct
)
```

--------------------------------

### Initialize Across Client with Chains

Source: https://docs.across.to/developer-quickstart/bridge-integration-guide

Initializes the AcrossClient with a provided integrator ID and a list of supported Viem chains. This client is the primary interface for interacting with the Across Protocol SDK.

```javascript
import { createAcrossClient } from "@across-protocol/app-sdk";
import { mainnet, optimism, arbitrum } from "viem/chains";

const client = createAcrossClient({
  integratorId: "your-integrator-ID", 
  chains: [mainnet, optimism, arbitrum],
});
```

--------------------------------

### Bridge Integration Guide

Source: https://context7_llms

Provides instructions and best practices for integrating the Across bridge into existing or new applications. This guide covers the technical steps required to enable crosschain asset transfers.

```APIDOC
Bridge Integration Guide:
  - Instructions and best practices for integrating the Across bridge.
  - Covers technical steps for crosschain asset transfers.
  - Aimed at developers building applications on top of Across.
```

--------------------------------

### Solana Deposit Transaction Execution

Source: https://docs.across.to/introduction/migration-guides/solana-migration-guide

Illustrates the process of building and executing a deposit transaction to Solana. This involves fetching fee details from the API and calling the `deposit()` function on the SVM SpokePool contract.

```APIDOC
Transaction Building and Execution for Solana Deposits:

1. Fetch Transaction Details:
   Call the `/suggested-fees` API to obtain current fee estimates and relevant addresses.

2. Construct Transaction:
   - Obtain the `integratorID`.
   - Add the `integratorID` to the transaction parameters.
   - Identify the target SVM SpokePool contract address on Solana.

3. Execute Deposit:
   Call the `deposit()` function on the Solana SVM SpokePool contract, passing the necessary parameters including the `integratorID`.

Example Contract Interaction (Conceptual):
// Assuming you have the contract ABI and instance
const spokePoolContract = await getSolanaSpokePoolContract("JAZWcGrpSWNPTBj8QtJ9UyQqhJCDhG9GJkDeMf5NQBiq");

const tx = await spokePoolContract.deposit(
  "yourIntegratorId", // integratorID
  "1000000",          // amount (in smallest unit)
  "ethereum"          // destinationChain (example)
);

// Sign and send the transaction
await sendTransaction(tx);
```

--------------------------------

### API Reference: Suggested Fees and Limits

Source: https://docs.across.to/introduction/migration-guides/migration-to-cctp/migration-guide-for-api-users

Documentation for the /suggested-fees and /limits API endpoints, detailing the addition of optional query parameters 'inputToken' and 'outputToken', and the deprecation of the single 'token' parameter for specific route types.

```APIDOC
/suggested-fees and /limits

Description:
  Retrieves suggested fees or transaction limits for cross-chain deposits.

Parameters:
  - token (string, optional): The token address for querying fees/limits. Will be deprecated for Native USDC to Bridged USDC routes.
  - inputToken (string, optional): The input token address. Required for Native USDC to Bridged USDC routes.
  - outputToken (string, optional): The output token address. Required for Native USDC to Bridged USDC routes.

Notes:
  - If 'inputToken' and 'outputToken' are provided, 'token' becomes optional and is inferred to be equal to 'inputToken'.
  - 'token' parameter can only be used for Native USDC to Native USDC routes.
  - Limits for Native USDC and Bridged USDC may differ due to relayer capacity.
  - For routes with Native USDC as output, fees will be equivalent to Bridged USDC for the foreseeable future, but migration to new parameters is encouraged.
```

--------------------------------

### Across V2 API Fees Response Structure

Source: https://docs.across.to/introduction/migration-guides/migration-from-v2-to-v3

Describes the structure of the `FeesResponse` object returned by the V2 API's `GET /suggested-fees` endpoint and how it was used in the `SpokePool.deposit` function.

```typescript
type FeesResponse = {
    // ... other fields
    capitalFeePct: string;
    capitalFeeTotal: string;
    relayGasFeePct: string;
    relayGasFeeTotal: string;
    relayFeePct: string; // capitalFeePct + gasFeePct
    relayFeeTotal: string; // capitalFeeTotal + gasFeeTotal
    lpFeePct: string;
}

// Usage in SpokePool.deposit:
const tx = await spokePool.deposit(
    // ... other args
    feesResponse.relayFeePct // capitalFeePct + gasFeePct
)
```

--------------------------------

### Initialize Testnet Client

Source: https://docs.across.to/reference/app-sdk-reference

Initializes the Across App SDK client for use in a testnet environment. Requires an integrator ID and a list of Viem chains. Setting `useTestnet: true` enables testnet mode, which has slower transaction times compared to mainnet.

```javascript
import { createAcrossClient } from "@across-protocol/app-sdk";
import { mainnet, optimism, arbitrum } from "viem/chains";

const client = createAcrossClient({
  integratorId: "<your-integratorId>", // 2-byte hex string
  chains: [mainnet, optimism, arbitrum],
  useTestnet: true,
});
```

--------------------------------

### Across API: Get Suggested Fees

Source: https://docs.across.to/developer-quickstart/embedded-crosschain-actions/crosschain-actions-integration-guide

Requests quotes for cross-chain transactions from the Across API. Requires a 'message' parameter containing the set of transactions to execute on the destination. Used to determine fees and initiate deposits.

```APIDOC
GET /suggested-fees
  Parameters:
    message: string (required) - The encoded set of transactions to execute on the destination.
  Returns:
    Fee quote details and other parameters needed to initiate a deposit.
```

--------------------------------

### Append Identifier to depositV3 Transaction Data

Source: https://docs.across.to/developer-quickstart/embedded-crosschain-actions/crosschain-actions-integration-guide

This example demonstrates the depositV3 function signature and provides an encoded transaction data payload. Integrators are required to append a specific delimiter ('1dc0de') and their unique identifier to the call data of deposit transactions for tracking purposes.

```Solidity
Function: depositV3(address depositor,address recipient,address inputToken,address outputToken,uint256 inputAmount,uint256 outputAmount,uint256 destinationChainId,address exclusiveRelayer,uint32 quoteTimestamp,uint32 fillDeadline,uint32 exclusivityDeadline,bytes message)

0x7b939232000000000000000000000000c30c7ea910a71ce06ae840868b0c7e47616ba4c9000000000000000000000000c30c7ea910a71ce06ae840868b0c7e47616ba4c9000000000000000000000000833589fcd6edb6e08f4c7c32d4f71b54bda02913000000000000000000000000af88d065e77c8cc2239327c5edb3a432268e5831000000000000000000000000000000000000000000000000000000009502f9000000000000000000000000000000000000000000000000000000000094fd2f84000000000000000000000000000000000000000000000000000000000000a4b10000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000066799bfb000000000000000000000000000000000000000000000000000000006679f0f40000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000018000000000000000000000000000000000000000000000000000000000000000001dc0def001
```

--------------------------------

### Get Supported Chains with Across App-SDK (TypeScript)

Source: https://docs.across.to/developer-quickstart/bridge-integration-guide

Fetches all necessary data about origin and destination chains using the `getSupportedChains()` function. This function is crucial for building user interfaces like dropdown menus for cross-chain selections. It requires an initialized SDK client and can optionally filter by a specific chainId.

```TypeScript
const fetchChains = async () => {
  const chains = await client.getSupportedChains({});
  console.log("supported chains are: ", chains);
  return chains;
};

fetchChains();
```

```TypeScript
const fetchChain = async (chainId: number) => {
  const chains = await client.getSupportedChains({chainId:chainId});
  console.log("supported chains are: ", chains);
  return chains; // Note: Original text had 'return chain;' which might be a typo
};

fetchChain(1)
```

--------------------------------

### Contract Functions: Deposit vs DepositV3

Source: https://docs.across.to/introduction/migration-guides/migration-to-cctp/migration-guide-for-api-users

Comparison of the 'deposit()' and 'depositV3()' contract functions, highlighting the need to migrate to 'depositV3()' for supporting Native USDC to Bridged USDC routes and future cross-chain token swaps.

```APIDOC
deposit() vs depositV3()

Description:
  Functions for submitting deposit transactions to Across contracts.

deposit():
  - Signature: deposit(originToken: address, ...)
  - Limitation: Only allows specifying a single 'originToken' address.
  - Compatibility: Does not support Native USDC to Bridged USDC deposits.

depositV3():
  - Signature: depositV3(inputToken: address, outputToken: address, ...)
  - Enhancement: Allows specifying both 'inputToken' and 'outputToken' parameters.
  - Compatibility: Supports Native USDC to Bridged USDC routes and future cross-chain token swaps.

Recommendation:
  API users and direct smart contract users are encouraged to migrate to 'depositV3()' to access new features and routes.
```

--------------------------------

### DepositV3 Function Usage

Source: https://docs.across.to/introduction/migration-guides/bnb-smart-chain-migration-guide

Illustrates the correct usage of the DepositV3 contract function, specifically highlighting the importance of passing the `outputAmount` obtained from the API and specifying a valid `outputToken` address for BNB Smart Chain routes.

```javascript
// deprecated approach
// const outputAmount = inputAmount * (1 * 10^18 - feesResponse.totalRelayerFee.pct)
// const tx = spokePool.deposit(...args, outputAmount)

// correct approach
// Assuming feesResponse is obtained from the /suggested-fees API call
// const feesResponse = await api.get('/suggested-fees', { ... });

// For BNB Smart Chain routes, ensure outputToken is a valid address, not '0x0'
// const outputTokenAddress = '0x...'; // Replace with actual token address
// const outputAmount = feesResponse.outputAmount;

// const tx = spokePool.deposit(...args, outputAmount, outputTokenAddress);

// Example of calling DepositV3 with correct parameters:
// const spokePool = new Contract(spokePoolAddress, spokePoolAbi);
// const inputTokenAddress = '0x...';
// const outputTokenAddress = '0x...'; // Must be valid for BSC routes
// const inputAmount = '1000000000000000000'; // Example: 1 ETH
// const chainId = 56; // BNB Smart Chain ID

// Fetch fees first
// const feesResponse = await fetchFees(inputTokenAddress, outputTokenAddress, 1, chainId, inputAmount);
// const correctOutputAmount = feesResponse.outputAmount;

// const transaction = await spokePool.deposit(
//   inputTokenAddress,
//   outputTokenAddress,
//   inputAmount,
//   correctOutputAmount,
//   // ... other required parameters for DepositV3
// );

// Note: The exact parameters for DepositV3 depend on the contract implementation.
// This snippet focuses on the outputAmount and outputToken handling.

```

--------------------------------

### API Reference: Suggested Fees

Source: https://docs.across.to/introduction/migration-guides/bnb-smart-chain-migration-guide

Details the updates to the /suggested-fees API for BNB Smart Chain support. Includes the new outputAmount field and the allowUnmatchedDecimals parameter for handling decimal differences between tokens on different chains.

```APIDOC
GET /suggested-fees

Description:
Retrieves suggested fees for bridging assets. Supports BNB Smart Chain integration.

Parameters:
- inputToken (string, required): The address of the input token.
- outputToken (string, required): The address of the output token.
- inputChainId (integer, required): The chain ID of the input chain.
- outputChainId (integer, required): The chain ID of the output chain.
- inputAmount (string, required): The amount of input token to bridge.
- allowUnmatchedDecimals (boolean, optional): If true, allows API to return results when inputToken and outputToken have different decimal places. If false or not set, a 4XX error is returned in such cases. Defaults to false.

Responses:
- 200 OK:
  {
    "outputAmount": "string", // The amount of output token expected after bridging.
    "totalRelayerFee": {
      "pct": "string", // Percentage of the fee.
      "amount": "string" // Absolute amount of the fee.
    },
    // ... other fee-related fields
  }
- 4XX Error:
  Returned if required parameters are missing or if allowUnmatchedDecimals is false and decimal mismatch occurs.

Notes:
- For BNB Smart Chain routes, integrators must explicitly define a valid outputToken address. Using '0x0' for outputToken is not supported for BSC routes and will cause transaction failure.
- The `outputAmount` field is now included in responses for all routes, providing the exact amount to be received.
- The `allowUnmatchedDecimals` parameter is crucial for handling tokens with varying decimal representations across chains, such as USDC (6 vs 18 decimals).
```

--------------------------------

### V3 Deposit and Speed-up Functions

Source: https://docs.across.to/introduction/migration-guides/migration-from-v2-to-v3

Provides the new `depositV3` and `speedUpV3Deposit` functions for handling V3 deposits, along with their older counterparts for comparison. These functions are essential for cross-chain transfers and managing deposit lifecycles.

```Solidity
// New function to initiate a V3 deposit.
// The fillDeadline will be set to MAX_UINT, outputToken to 0x0, exclusivityDeadline and exclusiveRelayer to 0 and 0x0.
// outputAmount will be equal to inputAmount * (1 - totalRelayFeePct).
function depositV3(
    address depositor,
    address recipient,
    address inputToken,
    address outputToken,
    uint256 inputAmount,
    uint256 outputAmount,
    uint256 destinationChainId,
    address exclusiveRelayer,
    uint32 quoteTimestamp,
    uint32 fillDeadline,
    uint32 exclusivityDeadline,
    bytes calldata message
) external payable;

// Old function for deposits.
function deposit(
    address recipient,
    address originToken,
    uint256 amount,
    uint256 destinationChainId,
    int64 relayerFeePct,
    uint32 quoteTimestamp,
    bytes memory message,
    uint256 maxCount
) external payable;

// New function to speed up a V3FundsDeposited event.
// Allows updating recipient, message, and output amount for a deposit.
function speedUpV3Deposit(
    address depositor,
    uint32 depositId,
    uint256 updatedOutputAmount,
    address updatedRecipient,
    bytes calldata updatedMessage,
    bytes calldata depositorSignature
) external;

// Old function to speed up a deposit.
function speedUpDeposit(
    address depositor,
    int64 updatedRelayerFeePct,
    uint32 depositId,
    address updatedRecipient,
    bytes memory updatedMessage,
    bytes memory depositorSignature
) external;
```