API Reference
Source Code
The API is designed to be run serverlessly (without storing state) and is a wrapper on top of the SDK. See full implementation here.
Caching & Liveness
Users of the Across API are requested to cache results for no longer than 300 seconds.
The Across API serves data that is derived from the on-chain state of the Across contracts and relayer bots. The on-chain state is subject to change each block, and cached data can quickly become invalid as a result.
The exception is the /deposit/status
endpoint which is implemented in this stateful repository because it relies on an indexing solution.
API Endpoints
Returns suggested fees based inputToken
+outputToken
, originChainId
, destinationChainId
, and amount
. Also includes data used to compute the fees.
/suggested-fees
Address of token to bridge on the origin chain. Must be used together with parameter outputToken
. For ETH, use the wrapped address, like WETH.
Note that the address provided must exist on the specified originChainId
below.
Address of token to bridge on the destination chain. Must be used together with parameter inputToken
. For ETH, use the wrapped address, like WETH.
Note that the address provided must exist on the specified destinationChainId
below.
Chain ID where the specified token
or inputToken
exists.
The desired destination chain ID of the bridge transfer.
Amount of the token to transfer.
Note that this amount is in the native decimals of the token. So, for WETH, this would be the amount of human-readable WETH multiplied by 1e18. For USDC, you would multiply the number of human-readable USDC by 1e6.
Recipient of the deposit. Can be an EOA or a contract. If this is an EOA and message is defined, then the API will throw a 4xx error.
Example: 0xc186fA914353c44b2E33eBE05f21846F1048bEda
Calldata passed to the recipient
if recipient
is a contract address. This calldata is passed to the recipient via the recipient's handleAcrossMessage() public function.
Example: 0xABC123
Optionally override the relayer address used to simulate the fillRelay() call that estimates the gas costs needed to fill a deposit. This simulation result impacts the returned suggested-fees. The reason to customize the EOA would be primarily if the recipientAddress is a contract and requires a certain relayer to submit the fill, or if one specific relayer has the necessary token balance to make the fill.
Example: 0x428AB2BA90Eba0a4Be7aF34C9Ac451ab061AC010
The quote timestamp used to compute the LP fees. When bridging with across, the user only specifies the quote timestamp in their transaction. The relayer then determines the utilization at that timestamp to determine the user's fee. This timestamp must be close (within 10 minutes or so) to the current time on the chain where the user is depositing funds and it should be <= the current block timestamp on mainnet. This allows the user to know exactly what LP fee they will pay before sending the transaction.
If this value isn't provided in the request, the API will assume the latest block timestamp on mainnet.
Example: 1653547649
Returns transfer limits for inputToken
+outputToken
, originChainId
, and destinationChainId
.
/limits
Address of token to bridge on the origin chain. Must be used together with parameter outputToken
. For ETH, use the wrapped address, like WETH.
Note that the address provided must exist on the specified originChainId
.
Address of token to bridge on the destination chain. Must be used together with parameter inputToken
. For ETH, use the wrapped address, like WETH.
Note that the address provided must match the token address on the specified destinationChainId
below.
Chain ID where the specified token
or inputToken
exists.
The intended destination chain ID of the bridge transfer.
Returns available routes based on specified parameters.
/available-routes
Chain ID of the originating chain.
Chain ID of the destination chain.
Origin chain address of token contract to transfer.
Example: 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2
0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2
Destination chain address of token contract to receive.
Example: 0x4200000000000000000000000000000000000006
0x4200000000000000000000000000000000000006
Returns the fill status of a deposit along with a corresponding fill transaction hash if filled.
This endpoint loads data queried by an indexing service that polls relevant events on a 10-second cadence. Users should therefore expect an average latency of 1 to 15 seconds after submitting a deposit to see the status changed in this endpoint. This delay comes from the time it takes for the internal indexing to include the deposit transaction.
/deposit/status
Chain Id where the deposit originated from.
The deposit id that is emitted from the DepositV3
function call as a V3FundsDeposited
event.
Last updated