- ERC-4337 smart accounts: The user signs a user operation; Relay submits it and covers the origin gas.
- EIP-7702 wallets: Delegate an EOA to a smart account and execute atomic, gasless batches. Even the upgrade itself can be executed gaslessly.
- Any raw transaction that doesn’t depend on the submitter: Sign the payload, and Relay executes it.
Why it matters
For integrators
- Serve the payers you’re currently losing. Users who hold stablecoins but no gas include most new users; today their transactions simply fail.
- Payments never stall on gas. No “insufficient funds for gas” dead ends mid-checkout.
- You choose the cost model. Fees come out of the stablecoin in motion, or you sponsor them for a full 1:1.
- Use one integration across account types. Support ERC-4337 smart accounts, EIP-7702-delegated EOAs, embedded wallets, and custodial wallets without building paymaster or bundler infrastructure.
For your users
- Stablecoins are enough. Pay in the token they hold; no gas tokens or chains to understand.
- Sign, don’t submit. Nothing to configure and no transaction to send.
- Get 1:1 payments when sponsored. Send a dollar, and a dollar arrives.
Who it’s for
- Payment service providers: Payers hold stablecoins, not gas tokens, and every gas requirement is a failed payment. Gasless Execution makes stablecoin payments self-contained; pair it with Fee Sponsorship for 1:1 settlement. A user can pay in USDC from a wallet holding only USDC.
- Wallets and wallet infrastructure: Users arrive holding tokens but no gas, and their first action stalls. Gasless Execution makes the first transaction work instantly. A new user can send from a fresh wallet holding zero ETH.
- Onchain apps: High-frequency flows stall when users run out of gas mid-session. Gasless Execution keeps them transacting in the token they’re already using.
How does it work?
Gasless transactions on EVM are regular transactions where the transaction signer and the gas payer are two different addresses. Rather than signing with the same address and then submitting their transaction and paying gas, a user can simply sign a transaction payload, and other entities (relayers, solvers, etc.) can submit the transaction on their behalf and sponsor the gas costs. This is not natively possible, so there are custom transaction payloads to enable this: Permit2, EIP-3009, ERC-2771 payloads, ERC-4337 user operations, etc. The core concept is that as long as the transaction execution does not rely ontx.origin (the transaction submitter), any user can sign permit payloads or Smart Account actions (EIP-7702, ERC-4337 user operations etc.) and a relayer can post those payloads on chain by wrapping them in a transaction.
This is where the /execute API comes in. The API allows users to submit raw calls (the partial payload of a regular EVM transaction). It includes the to, data, value and an optional EIP-7702 authorizationList.
How to use it?
To use gasless execution you’ll need an API key with a linked funding address and a funded app balance. Create an API key in the Relay Dashboard, then see Fee Sponsorship for details on linking a funding address and funding your app balance.Executing a gasless quote
In this example use case you want to execute a gasless Relay quote with the execute API.1
Get a quote
This flow assumes that the user is using a smart wallet. Use the quote endpoint to get a quote for the transaction you want to execute. The
originGasOverhead indicates how much additional gas overhead will be necessary to include the user operation on the chain as compared to a normal EOA transaction.2
Execute the transaction
With the quote in hand, you can now execute the transaction. You’ll need to pass the data from previous steps to the api.
3
Monitor
Now that the transaction has been submitted, you can monitor the status of the transaction using the requestId from the quote data and the status endpoint.
Handling simulation errors
Relay simulates/execute raw calls before submission. If the simulation reverts, the API returns 400 with a decoded error label, a message, the requestId, and trace details when Relay can decode the revert path.
error and message for integration handling, and include requestId when contacting Relay support. Use details.innermost and details.revert to identify the contract, function selector, and revert data that caused the simulation failure.
Response
UNKNOWN_CUSTOM_ERROR_<selector> and includes rawArgsHex when encoded revert arguments are available.
More Use Cases
Gasless ERC-20 transfer from ERC-4337 Smart Account
Gasless ERC-20 transfer from ERC-4337 Smart Account
If the user has a Smart Account (such as an ERC-4337 Smart Account), any transaction can be made gasless for the Smart Account by signing an ERC-4337 user operation and submitting it to the /execute API.The only step is to create the user operation, get it signed by the user and then create the final call data of the handleOps call of the Entry Point before submitting to the /execute endpoint.Note: The maxFeePerGas and maxPriorityFeePerGas The ERC-4337 user operation should be 0; it will result in a double payment to the solver (The solver already has adjusted the cost in the quote, so no need for this payment)
1
Create the user operation
2
Send the payload to the /execute endpoint
3
Monitor
Now that the transaction has been submitted, you can monitor the status of the transaction using the requestId returned in the api response and the status endpoint.
Gasless upgrade to an EIP-7702 Smart Account
Gasless upgrade to an EIP-7702 Smart Account
Another example of a flow where the transaction execution does not depend on
tx.origin is the action of upgrading a regular EOA to an EIP-7702 smart account. In this flow, any entity can execute an upgrade payload and a signed EIP-7702 authorizationList from the EOA.The client must pass the correct fields for the to (which is the EOA that is to be upgraded), data is the call data for the initialization of the EOA’s EIP-7702 Smart Account and the authorizationList which contains the signed information about the Smart Account to upgrade to.1
Sign the EIP-7702 authorizationList
2
Send the payload to the /execute endpoint
3
Monitor
Now that the transaction has been submitted, you can monitor the status of the transaction using the requestId returned in the api response and the status endpoint.
Caveats
- Only EVM chains are supported currently.
- Partial sponsorship is not yet supported. Should the fees amount to more than the app balance, the transaction will not be sponsored.
- If the transaction relies on
msg.sender, the transaction signer must be a smart wallet (EIP-7702, ERC-4337, etc). - The API won’t work if the transaction relies on
tx.origin.