Fee Sponsorship allows you to cover the destination chain fees for your users’ Relay transactions. By sponsoring these fees, you can reduce costs for your users and create a more seamless experience. This is particularly valuable for onboarding new users or providing a premium experience for your application.
Fee sponsorship covers all destination chain fees (including gas topup amounts), but not the origin chain gas fee. Users will still need to pay the gas required to submit their transaction on the origin chain.
An API Key — Required to authenticate your sponsorship requests and associate them with your app balance. Request an api key.
Enterprise Partnership — Reach out to the Relay team to become an Enterprise Partner. Learn more about the Enterprise Partner Program.
A Linked Funding Address — A wallet address must be linked to your API key. This is the address that will fund your app balance. Reach out to the relay team to link your wallet address.
Sufficient App Balance — Your app balance must have enough funds to cover the fees you wish to sponsor.
Once you’re set up, you can begin depositing funds and sponsoring transactions.
You can programmatically deposit to your app balance by sending a transaction on Base to the Relay solver. This method involves appending specific calldata in place of the request ID to identify the deposit.
When you transfer funds to the solver using specific calldata, Relay treats it as a deposit to your app balance. This method uses a fixed 12-character prefix and suffix (012345abcdef) with the middle portion specifying which address to credit:Calldata Format:
Copy
Ask AI
0x[prefix][address-to-credit][suffix]
Prefix:012345abcdef
Address to Credit: The wallet address to deposit funds for (use 0000000000000000000000000000000000000000 for msg.sender)
The ability to specify a different address is useful for building auto-topup systems or having more granular control over which accounts receive deposits.
Add these parameters to your Get Quote API request:
Parameter
Type
Description
subsidizeFees
boolean
Set to true to have the sponsor pay for all fees associated with the request, including gas topup amounts.
maxSubsidizationAmount
string
(Optional) The maximum amount to subsidize in USDC with 6 decimal places (e.g., "1000000" = $1.00). If the total fees exceed this threshold, the entire request will not be subsidized.
subsidizeRent
boolean
(Optional) Set to true to sponsor Solana ATA rent fees. Requires subsidizeFees to also be enabled. See Solana Fee Sponsorship.
depositFeePayer
string
(Optional) A Solana address to pay deposit transaction fees for Solana origin transactions. See Solana Fee Sponsorship.
sponsoredFeeComponents
string[]
(Optional) You can also choose to sponsor specific Relay fees for your users using the sponsoredFeeComponents parameter. This allows integrators to selectively cover different fee types (such as gas fees or relayer fees) while still collecting app fees.
Solana transactions involve unique cost structures that differ from EVM chains. In addition to standard transaction fees, Solana requires rent payments for creating new accounts, such as Associated Token Accounts (ATAs). Relay provides specific parameters to handle these costs.
When a user receives a token on Solana for the first time, an Associated Token Account must be created to hold that token. This account creation requires a rent payment (approximately 0.002 SOL). Without sponsorship, this cost falls on the user.
The subsidizeRent parameter allows you to sponsor the rent fees for ATA creation on Solana destination transactions.
Parameter
Type
Description
subsidizeRent
boolean
Set to true to have the sponsor pay for Solana rent fees associated with ATA creation on the destination chain.
The subsidizeRent parameter must be used in conjunction with subsidizeFees. There is currently no system for separating destination gas and rent fees. If you enable subsidizeRent without subsidizeFees, the rent will not be sponsored.
Important considerations:
When subsidizeFees is enabled but subsidizeRent is not, requests involving ATA creation will automatically fall back to user-paid fees. This is because rent sponsorship without explicit opt-in presents an exploitation vector.
The exploitation risk stems from the fact that users can close their ATA after the transaction completes and reclaim the rent. This effectively converts sponsored rent into a direct transfer of funds to the user.
Only enable subsidizeRent when you have a trusted relationship with your users or have implemented safeguards against abuse.
In this example, a user bridges USDC from Base to Solana. Both subsidizeFees and subsidizeRent are enabled, ensuring the sponsor covers all destination fees including any ATA rent required for the recipient to receive USDC on Solana.
For transactions originating from Solana, you can designate an alternative account to pay the transaction fees and rent for the deposit transaction using depositFeePayer.
Parameter
Type
Description
depositFeePayer
string
A Solana address that will pay the transaction fees and rent for deposit transactions on Solana. This account must have sufficient SOL to cover these costs. Must be different from the user address.
The depositFeePayer parameter operates independently from the subsidizeFees and subsidizeRent parameters. It applies specifically to Solana origin transactions and does not draw from your app balance.
Important restrictions and security considerations for depositFeePayer:
The depositFeePayer and user addresses must be different. You cannot use the same wallet address for both parameters.
Signing order is critical. Relay returns a transaction that requires the integrator’s sponsoring wallet to sign first. The integrator must sign the transaction before passing it to the user. If the user receives an unsigned transaction, they could potentially modify it to drain the sponsoring wallet.
Avoid same-chain swaps with untrusted users. The depositFeePayer parameter is exploitable when used for same-chain swaps on Solana. Only use it for same-chain operations when the wallet is under your control.
When to use depositFeePayer:
When you want to provide a gasless experience for users depositing from Solana
When your application maintains a dedicated fee-paying wallet for Solana transactions
When you want to abstract away the complexity of SOL requirements from your users
In this example, a user bridges USDC from Solana to Base. The depositFeePayer address will cover the Solana transaction fees for the deposit, allowing the user to transact without holding SOL.
Fee sponsorship is designed to cover relay and execution costs, but certain fees remain outside its scope:
Origin chain gas fees — Users must pay the gas required to submit their transaction on the origin chain (unless using depositFeePayer for Solana origins).
App fees — Fees configured via the appFees parameter are not deducted from your sponsor balance. These are separate charges that accrue to the specified recipient addresses.
First-time approval transactions when using usePermit — The initial approval transaction required for permit-based flows is not covered by fee sponsorship. However, all subsequent requests after the approval will be sponsored.