Skip to main content
Gasless Execution: stablecoin payments that only require stablecoins. Your users sign. Relay executes. No gas token required. A user holding 100 USDC should be able to pay 100 USDC. But without a gas token they can’t move it: the balance is functionally frozen until they go buy ETH, on the right chain, at the right time. That’s the state most payers are in: new users, stablecoin holders, and anyone arriving from an exchange. The payment fails not for lack of money, but for lack of a second token they’ve never heard of. Decouple signing from submitting. Your user signs a payload offchain; Relay submits the transaction and fronts the origin gas. The user never needs to hold or buy a native gas token: costs are deducted from the token in the flow, so a user holding only USDC pays in USDC. To make it free for the user too, pair it with Fee Sponsorship: Gasless Execution removes the gas token, while sponsorship removes the cost. Gasless Execution covers any EVM transaction, not just payments:
  • 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.
Gasless Execution is one of four ways to get gas out of your users’ way, alongside Fee Sponsorship, just-in-time gas, and pay-with-any-token. They combine. For stablecoin payments that arrive exactly 1:1, pair Gasless Execution with Fee Sponsorship and price stabilization.

​
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 on tx.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.
Use 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
If Relay cannot map a custom error selector to a known contract error, the response uses a label of the form UNKNOWN_CUSTOM_ERROR_<selector> and includes rawArgsHex when encoded revert arguments are available.

​
More Use Cases

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.
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.