Deposit Addresses

Deposit addresses let users bridge or swap tokens by simply sending funds to an address — no wallet connection or signing required. This works for both cross-chain bridges and same-chain swaps. The integrator requests a quote with useDepositAddress: true, receives a deposit address, and the user transfers funds there. Relay detects the deposit and fills on the destination chain. This makes deposit addresses ideal for CEX withdrawals, fiat onramps, and headless systems where the sender can’t sign transactions. The user just sends to an address — same UX as a normal transfer.

How It Works

Quote — Integrator requests a quote with useDepositAddress: true. The response includes a depositAddress and requestId.
User Deposit — User sends funds to the deposit address (wallet transfer or exchange withdrawal).
Detect + Sweep — Relay detects the deposit onchain and sweeps funds to the depository contract. For open-ended addresses, the amount, currency, and chain are validated and the quote may be regenerated if different from the original. For strict addresses, the deposit is validated against the original order.
Fill — Relay fills on the destination chain from pre-positioned liquidity. Funds are delivered to the recipient address.

Key Parameters

Parameter	Type	Details
`useDepositAddress`	boolean	Set to `true` to receive a deposit address instead of transaction calldata.
`user`	address	The recipient wallet on the destination chain. Can be any valid address, including the zero address.
`recipient`	address	The address that receives funds on the destination chain.
`refundTo`	address	Address to send refunds if the transfer fails. Required for strict deposit addresses and for routes that include a destination-side swap. Omitting this on open addresses disables automatic refund. See Refund Behavior.
`tradeType`	string	Must be `EXACT_INPUT`. Deposit addresses only support exact input trades — output varies based on market conditions at fill time.
`amount`	string	The quoted amount in the origin token’s smallest unit. Open-ended addresses support variable deposit amounts. Strict addresses should be treated as exact-payment instructions.
`strict`	boolean	Set to `true` for a strict deposit address tied to a specific order. Omit or set to `false` for an open deposit address.

Address Reuse

Open deposit addresses can be reused for the same route (same origin currency, origin chain, destination currency, and destination chain). Each new deposit triggers a fresh quote and fill. Strict addresses should not be presented as reusable. They are bound to the original order and intended for single-use payment instructions.

Open vs Strict Deposit Addresses

Relay supports two deposit address modes that differ in how flexible they are when handling deposits.

Open Deposit Addresses

Open-ended deposit addresses are the flexible mode for supported routes. They can handle variable deposit amounts, and on some supported chain families they can also adapt to a different supported input token or a deposit on a different chain.

refundTo is recommended. Omitting refundTo disables automatic refund — there is no internal fallback.
Best for: general-purpose integrations where you want tolerance for user variability.

Strict Deposit Addresses

Strict deposit addresses are bound to the original order and should be treated as predictable payment instructions. They are not flexible intake points.

refundTo is required. The request will fail without it.
Set strict: true in your /quote/v2 request.
Best for: integrations that need predictable behavior and explicit refund handling (e.g., payment processors).

Comparison

Behavior	Open	Strict
Accepted currencies	Flexible — may adapt to a different supported token depending on chain family	Only the currency specified in the original quote
Wrong token (solver currency)	Requote and fill on some chain families (not universal)	Not supported — refund or manual recovery
Wrong token (non-solver)	Not supported in the normal fill flow; may require manual recovery	Not supported in the normal fill flow
Wrong chain (same VM)	Auto-reroute on EVM; other chain families may refund	Not supported
Wrong chain (different VM)	Not possible — address formats differ	Not possible — address formats differ
Amount mismatch	Usually requotes for actual amount; too-small deposits may refund	Exact payment expected
`refundTo`	Recommended (omitting disables automatic refund)	Required
Address reuse	Yes, same route	No — bound to original order

Example Request and Response

Open Deposit Address

Bridging 0.01 ETH from Base to Optimism using an open deposit address:

curl -X POST \
  'https://api.relay.link/quote/v2' \
  -H 'Content-Type: application/json' \
  -d '{
	"user": "0xF0AE622e463fa757Cf72243569E18Be7Df1996cd",
	"originChainId": 8453,
	"originCurrency": "0x0000000000000000000000000000000000000000",
	"destinationChainId": 10,
	"destinationCurrency": "0x0000000000000000000000000000000000000000",
	"tradeType": "EXACT_INPUT",
	"recipient": "0xF0AE622e463fa757Cf72243569E18Be7Df1996cd",
	"amount": "100000000000000000",
	"useDepositAddress": true,
	"refundTo": "0xF0AE622e463fa757Cf72243569E18Be7Df1996cd"
}'

Strict Deposit Address

Same route, but using a strict deposit address. Note the addition of strict: true and the required refundTo:

curl -X POST \
  'https://api.relay.link/quote/v2' \
  -H 'Content-Type: application/json' \
  -d '{
	"user": "0xF0AE622e463fa757Cf72243569E18Be7Df1996cd",
	"originChainId": 8453,
	"originCurrency": "0x0000000000000000000000000000000000000000",
	"destinationChainId": 10,
	"destinationCurrency": "0x0000000000000000000000000000000000000000",
	"tradeType": "EXACT_INPUT",
	"recipient": "0xF0AE622e463fa757Cf72243569E18Be7Df1996cd",
	"amount": "100000000000000000",
	"useDepositAddress": true,
	"strict": true,
	"refundTo": "0xF0AE622e463fa757Cf72243569E18Be7Df1996cd"
}'

Key differences in the strict request:

strict is set to true
refundTo is required — the request fails without it
The deposit address is bound to this specific order and is not reusable

Quote Regeneration

When funds arrive at a deposit address, Relay evaluates what was sent versus what was originally quoted. How mismatches are handled depends on the deposit address mode.

Open-Ended Addresses

Same Token, Different Amount

Exact match — The original quote is reused and the fill proceeds directly.
More than quoted — A new quote is generated for the larger amount, and the fill proceeds.
Less than quoted — If the smaller amount still covers fees and the minimum fill, a new quote is generated and the fill proceeds. If not, the deposit is refunded to the refundTo address (if set).

Different Token (Solver Currency)

On some chain families, if the user sends a different token that is a solver currency, Relay can regenerate the quote using the actual currency deposited and fill the order. This is not universal across all chains — some chain families will fail or refund on token mismatch. If a different supported token was sent and nothing happens immediately, use the reindex endpoint as a fallback.

Different Chain (Same VM)

On EVM chains, if the user deposits on the wrong chain but the address exists on that chain, Relay can auto-reroute the deposit. Other chain families may treat chain mismatch as an error and refund instead.

Different Chain (Different VM)

This is not possible — deposit address formats differ across VM types (e.g., EVM vs Solana vs Bitcoin), so a user cannot accidentally send to the wrong VM.

Strict Addresses

Strict addresses are bound to the original order. The handling is narrower:

Exact amount — The fill proceeds using the original order.
Amount mismatch — The deposit may fail and be refunded to refundTo. Send the exact quoted amount.
Wrong token or wrong chain — Not supported. Strict addresses do not have automatic wrong-token or wrong-chain recovery paths.

Open-ended mismatches often create a new requestId. Always track transactions by deposit address, not by requestId. See Tracking Transactions.

Refund Behavior

What happens when a deposit can’t be processed depends on the token type and the refundTo configuration.

Refund Flows

There are two distinct refund scenarios:

Correct currency, fill failed (e.g., slippage, network issues) — If refundTo is set, the deposit is automatically refunded to that address, minus the cost of gas. No additional fees are taken.
Wrong currency (non-solver token) — Not supported in the normal fill flow. Automatic recovery is not available; manual handling may be required.

`refundTo` Configuration

`refundTo` value	Behavior
User’s address	Refund directly to the user
App-controlled address	Refund to integrator’s address — your support team handles returning funds to the user
Not set (open)	Automatic refund is disabled — no internal fallback
Not set (strict)	Not allowed — `refundTo` is required for strict deposit addresses

If users may send from a centralized exchange, do not use “refund to sender” — the sender address will be the exchange’s hot wallet, not the user’s. Use an app-controlled address instead so your support team can handle the last mile.

Recommended Setup

Open deposit addresses: Set refundTo to the user’s address for automatic refunds.
Strict deposit addresses: Always set refundTo. If the sender is unknown (e.g., CEX withdrawal), use an app-controlled address so your support team can manage refunds.

Tracking Transactions

Querying by Deposit Address

The most reliable way to track deposit address transactions is to poll the Get Requests API using the depositAddress query parameter:

curl -X GET "https://api.relay.link/requests/v2?depositAddress=<DEPOSIT_ADDRESS>&sortBy=updatedAt&sortDirection=desc&limit=20"

Handling Quote Regeneration

When a quote is regenerated (different amount, token, or chain), a new requestId may be generated. Use includeChildRequests=true to find all related requests, including regenerated ones:

curl -X GET "https://api.relay.link/requests/v2?depositAddress=<DEPOSIT_ADDRESS>&includeChildRequests=true"

Request-Level Status

Once you have a requestId, you can use Get Status for detailed status polling:

curl -X GET "https://api.relay.link/intents/status/v3?requestId=<REQUEST_ID>"

Reindexing Stuck Deposits

Relay runs a background monitor that checks for deposits of the originally quoted token. If a user sent a different supported (solver) token, the background monitor may not detect it automatically. Use the Deposit Address Reindex endpoint to trigger on-demand re-detection. This checks all solver currency balances on the specified chain and triggers sweeps for any detected deposits.

curl -X POST 'https://api.relay.link/transactions/deposit-address/reindex' \
  -H 'Content-Type: application/json' \
  -d '{
    "chainId": 8453,
    "depositAddress": "0x1ba74e01d46372008260ec971f77eb6032b938a4"
  }'

You can also pass targetChainId to reindex a deposit that landed on a different chain than originally quoted. This is useful for operational recovery when funds were sent to the right address but on the wrong chain. Pass currency to scope the reindex to a single currency address rather than iterating every depositable currency on the chain. This accepts any currency registered with Relay on the target chain — including currencies that aren’t on the standard solver-depositable list — and is useful when funds landed in a token outside that list (for example, a HyperCore-registered token when the deposit address was created for HyperEVM). Unknown currencies return 400.

curl -X POST 'https://api.relay.link/transactions/deposit-address/reindex' \
  -H 'Content-Type: application/json' \
  -d '{
    "chainId": 999,
    "depositAddress": "0x1ba74e01d46372008260ec971f77eb6032b938a4",
    "targetChainId": 1337,
    "currency": "0x6d1e7cde53ba9467b783cb7c530ce054"
  }'

The background monitor only checks the originally quoted input token. If a different supported token was sent, the monitor won’t detect it. Reindex checks all solver-depositable currencies and is the fallback path for these cases.

The deposit transaction hash cannot be used to look up the status of a deposit address bridge. Always use the deposit address itself or the requestId to track status.

Caveats

Gas Overhead

Deposit addresses add gas overhead compared to direct calldata execution because Relay must sweep funds from the deposit address:

Method	Token Type	Gas Overhead
Receiver	Native tokens (ETH, MATIC, etc.)	~33,000 gas
Protocol	ERC-20 tokens	~70,000 gas

For very small amounts, the gas overhead may make deposit addresses less cost-effective than direct calldata execution.

Supported Currencies

Only tokens listed as solver currencies for a given chain can be processed by deposit addresses. The input token must be a solver-depositable currency for the requested route. The destination token can differ and be completed through a destination-side swap — in that case, refundTo is required. Relay treats certain tokens as equivalent within currency groups (e.g., ETH and WETH) — depositing any token in a group triggers the same fill behavior. The table below is loaded live from the chains API. Each chain’s solverCurrencies array is the authoritative source for which tokens are supported.

Non-solver tokens and NFTs sent to deposit addresses are not recoverable through normal processes. Always verify the token is a solver currency before depositing.

Chain-Specific Notes

Bitcoin — Requires 1 block confirmation before Relay processes the deposit. Deposits are detected via mempool monitoring but only acted on after confirmation.
Solana — Supports SPL tokens through the protocol deposit method. Native SOL and SPL tokens like USDC are solver currencies on Solana.
Hyperliquid — Uses bridged USDC (USDC.e) with different decimal precision than native USDC on other chains. Be aware of decimal mismatches when computing amounts.

Other Limitations

Calldata execution on destination is not allowed.

Introduction

Solutions

Use Cases

Features

Safety & Security

Resources

Deposit Addresses

How It Works

Key Parameters

Address Reuse

Open vs Strict Deposit Addresses

Open Deposit Addresses

Strict Deposit Addresses

Comparison

Example Request and Response

Open Deposit Address

Strict Deposit Address

Quote Regeneration

Open-Ended Addresses

Same Token, Different Amount

Different Token (Solver Currency)

Different Chain (Same VM)

Different Chain (Different VM)

Strict Addresses

Refund Behavior

Refund Flows

`refundTo` Configuration

Recommended Setup

Tracking Transactions

Querying by Deposit Address

Handling Quote Regeneration

Request-Level Status

Reindexing Stuck Deposits

Caveats

Gas Overhead

Supported Currencies

Chain-Specific Notes

Other Limitations

Introduction

Solutions

Use Cases

Features

Safety & Security

Resources

Documentation Index

​How It Works

​Key Parameters

​Address Reuse

​Open vs Strict Deposit Addresses

​Open Deposit Addresses

​Strict Deposit Addresses

​Comparison

​Example Request and Response

​Open Deposit Address

​Strict Deposit Address

​Quote Regeneration

​Open-Ended Addresses

​Same Token, Different Amount

​Different Token (Solver Currency)

​Different Chain (Same VM)

​Different Chain (Different VM)

​Strict Addresses

​Refund Behavior

​Refund Flows

​refundTo Configuration

​Recommended Setup

​Tracking Transactions

​Querying by Deposit Address

​Handling Quote Regeneration

​Request-Level Status

​Reindexing Stuck Deposits

​Caveats

​Gas Overhead

​Supported Currencies

​Chain-Specific Notes

​Other Limitations

How It Works

Key Parameters

Address Reuse

Open vs Strict Deposit Addresses

Open Deposit Addresses

Strict Deposit Addresses

Comparison

Example Request and Response

Open Deposit Address

Strict Deposit Address

Quote Regeneration

Open-Ended Addresses

Same Token, Different Amount

Different Token (Solver Currency)

Different Chain (Same VM)

Different Chain (Different VM)

Strict Addresses

Refund Behavior

Refund Flows

`refundTo` Configuration

Recommended Setup

Tracking Transactions

Querying by Deposit Address

Handling Quote Regeneration

Request-Level Status

Reindexing Stuck Deposits

Caveats

Gas Overhead

Supported Currencies

Chain-Specific Notes

Other Limitations