A user whose wallet holds tokens but no native asset cannot pay for a deposit. As an integrator you can absorb that cost in three ways: send the deposit from a wallet that you control and that holds the funds, relay a deposit the user signed from the user’s own wallet, or request a gasless quote and let the operator do the relaying. Gasless in turn has two payers: by default the relay cost is priced out of the user’s output, and with sponsor_fees it is charged to your partner funding balance instead, so the user gets the full quoted output. canPayGas(owner) on a chain adapter tells you whether the wallet could pay for a normal deposit, which is the usual trigger for switching to one of these paths.

Send from your own wallet

The quote binds the recipient and the refund_address, not the depositor; the deposit itself can come from any wallet that holds the tokens and pays its own gas. The exception is a Solana deposit that swaps first: its route is built for the quote’s depositor, so pass the depositing wallet as depositor when it is not the refund_address. If you custody the source funds, or move them to a treasury wallet first, deposit from that wallet and put the user as recipient.
Set refund_address to your own wallet, not the user’s: if the order cannot be fulfilled, the refund returns the deposit on the source chain, and it should come back to the wallet that sent it. This is a normal deposit in every other respect. The entry point, allowance handling, and tracking are exactly as described in Deposit on EVM and Deposit on Solana, and you pay the source-chain gas directly.

Relay the deposit yourself

When the user holds the tokens but should not send a transaction, you can be the relayer instead of the operator. The user signs a permit2 witness signature bound to the quote hash, and your relayer wallet submits depositTokenWithPermit2Witness and pays the gas. The router’s witness entry points accept only allowlisted callers, so contact us to have your relayer wallet allowlisted on each chain before you submit; a call from any other wallet reverts with Unauthorized(). Request a normal quote, not a gasless one; the sponsor_gas component prices the operator’s relay, and here you are relaying.
routerAddress is the chain’s router from GetChains, which is both the transaction target and the spender in the typed data. The witness binds the signature to the quote hash, so it authorizes exactly this deposit and nothing else. The user needs a standing permit2 allowance on the token; for EIP-2612 tokens the last argument takes a permit signature approving permit2 instead, for the maximum uint256 value and with the same deadline as the permit2 signature, collected in the same signing session. When the quote has a source swap (src_token differs from lock_token), use permit2WitnessSwapDepositTypedData and depositWithSwapAndPermit2Witness with the aggregator and calldata from GetSwapInstructions; the witness additionally binds lock_token and min_lock_amount. On Solana there is no signature scheme to relay: build the deposit with your own wallet as fee payer, have the user sign it, co-sign, and send it yourself. Sui works the same way through its sponsored transactions: build the deposit block with your own address as gas owner, have the user sign it, sign it as the sponsor, and execute it with both signatures.

Gasless through the API

When you would rather not run relaying infrastructure, request the quote with gasless: true. The user signs an authorization instead of sending a transaction (a permit2 witness signature on EVM, a sponsor-paid transaction on Solana and Sui), you submit it through SubmitGaslessOrder, and an operator wallet lands the deposit and pays its gas. The relay cost is priced into the quote as the sponsor_gas fee component, so it comes out of the user’s output like any other fee. If the order is refunded instead, sponsor_gas comes out of the refund, since the relay gas was spent either way.
Gasless is available for cross-chain quotes whose source token is not the native asset, on chains where GetChains reports gasless: true. The relayer never spends more gas on the deposit than the quote priced. On EVM, while the source chain’s gas price sits above that, the submission stays pending and is retried; if the permit deadline passes first, it turns failed and the user needs a new quote. Quotes sponsored with sponsor_fees and no sponsor_gas_max are relayed at the current gas price instead, since the partner pays the actual cost.

Pay the relay yourself with sponsor_fees

Add sponsor_fees: true to a gasless quote to charge the relay gas to your partner funding balance instead of the user’s output. Without a cap, the sponsor_gas component disappears from the fee breakdown, amount_out is what the user actually receives, and each sponsored order debits your prepaid balance.
The submission flow is identical to plain gasless. Two things change on the request side:
  • The quote must be requested with your x-api-key; without one it fails with sponsor_fees requires an api key.
  • The key must have sponsoring enabled, which you turn on per key in the partner panel. New keys start with it off, and it fails with sponsor_fees requires an api key with sponsoring enabled otherwise. Never enable it on a key that ships in a public client, since anyone holding that key could spend your balance.
  • Your funding balance must be positive when the order is submitted, or SubmitGaslessOrder fails with insufficient funding balance.
Fund the balance through the router’s fundPartner entry point on the designated chain and watch it in the partner panel or through ListPartnerFundingActivity, where each sponsored order appears as a debit carrying its quote_hash.

Capping what you sponsor

Add sponsor_gas_max to a sponsor_fees quote to bound what one order can cost you. It is a decimal string in base units of the source chain’s native asset: wei on EVM, lamports on Solana, MIST on Sui.
  • When the quote is priced, relay gas above the cap is charged to the user as sponsor_gas, so amount_out drops by that amount. When the cap covers the estimate, sponsor_gas is absent, as without a cap.
  • When the relayed deposit lands, your balance is debited its actual gas cost plus 1%, never more than sponsor_gas_max. The relayer never lets the deposit cost more gas than the quote priced, so the cap and the user’s share always cover it.
  • If the relayed transaction lands but the deposit fails, for example because the user moved the tokens first, the user pays nothing and your balance is debited the transaction’s gas, still never more than sponsor_gas_max.
  • If the order is refunded, the refund deducts only the sponsor_gas the user paid.
The cap is echoed on the quote as sponsor_gas_max. Without sponsor_fees it is ignored.

Choosing a path

Sending from your own wallet works on every chain and token, including native deposits. The other three keep custody with the user end to end and need a non-native source token. Relaying yourself gives you control over submission and works from any wallet you run; gasless through the API needs no infrastructure but is limited to source chains where GetChains reports gasless: true.