> ## Documentation Index
> Fetch the complete documentation index at: https://docs.li.fi/llms.txt
> Use this file to discover all available pages before exploring further.
# Gas Options
> Four mechanisms for handling gas on your users' behalf, and which one fits the chain and the account you're dealing with.
A user who holds the token they want to move but none of the chain's native token cannot send a transaction. LI.FI has four answers to that, and they solve different halves of the problem: three remove the need for gas at the source, one supplies gas at the destination.
Pick by where the user is standing and what their account looks like.
## Which one you need
| Situation | Mechanism | Who pays |
| ---------------------------------------------------------------------- | ----------------------------------------------------------------------------- | -------------------------------------------------------------- |
| User on an EVM chain with no native token, signing rather than sending | [Gasless execution](/guides/gasless-transactions) | LI.FI relays and recovers the cost as a fee in the input token |
| User on Solana whose fee you want to cover | [Solana gas sponsorship](/introduction/solana-ecosystem#gasless-transactions) | You, through a sponsor account |
| User arriving on a chain for the first time and holding nothing there | [Gas Fronting](/guides/gas-subsidy) | The user, out of the amount being transferred |
| An existing integration already built on the relayer endpoints | Permit2 relayer, below | LI.FI relays |
The first three are independent and can run in the same product. A user can arrive somewhere through gas fronting and later spend from that chain normally.
## Gasless execution on EVM
Add `gasless=true` to a quote request and the response comes back as a payload to sign rather than a transaction to send. The user signs, you submit the signed payload to the relay endpoint, and LI.FI pays the gas and charges the cost as a fee in the input token, itemized in the quote.
The constraint that decides whether this is available to you at all is the account. It has to be an EOA already delegated under EIP-7702 to a delegate contract LI.FI relays for. An undelegated account is refused.
The quote endpoint can return a generic no-quote error for this case. If you need a reason you can surface or log, request routes and inspect `unavailableRoutes.filteredOut[].reason`; a reason can look like this:
```
0xd8dA...96045 is an undelegated EOA and chain 42161 cannot delegate it,
so the relayer has no way to execute for it
```
Do not parse the reason text programmatically.
The source has to be an EVM chain on which LI.FI currently relays the account's installed delegate. Availability is determined at quote time. The destination can be any chain LI.FI supports.
Full walkthrough: [Gasless Transactions](/guides/gasless-transactions).
## Solana gas sponsorship
Solana does not work the same way, so it does not use the relayer. Instead, a sponsor account is substituted as the transaction's fee payer. Pass the sponsor's public key on the quote request and the transaction that comes back is built for that account to pay.
The difference in who pays is worth stating plainly to whoever owns the budget. On the EVM path LI.FI fronts the gas and recovers it from the input amount, so the cost lands on the trade. Here you are paying, out of an account you fund and monitor.
What is sponsored, and what still needs SOL: [Solana ecosystem](/introduction/solana-ecosystem#gasless-transactions).
## Gas Fronting at the destination
The two mechanisms above solve a user who cannot send the transaction. This one solves a user who lands somewhere new and then cannot do anything: the asset arrives, the native balance is zero, and the next action is blocked.
Set `fromAmountForGas` and part of the transfer is converted into the destination chain's native token in the same movement. The user pays for it out of what they were sending, so nothing is subsidized, but the cold start disappears.
Gas Fronting isn't available through the contract-calls endpoint or Composer. If your flow composes an action on arrival, gas for that chain has to come from somewhere else.
Full walkthrough: [Gas Fronting](/guides/gas-subsidy).
## The Permit2 relayer
An earlier gasless mechanism, built on Permit2 signatures and an external relay network, is still live and still serving the integrations built on it:
| Endpoint | Purpose |
| --------------------------------- | ------------------------------------------------------- |
| `POST /v1/relayer/relay` | Submit a signed step for the relayer to dispatch |
| `GET /v1/relayer/status/{taskId}` | Poll a dispatched task |
| `GET /v1/gas/refetch` | Force a transaction the relayer missed to be re-fetched |
Build new integrations on the gasless execution path instead. These endpoints remain available for integrations already using them and are not where new work should start.
## What to decide
Decide what your interface does when gasless is refused. Every mechanism here has a population it cannot serve, and the refusal is information the user can act on rather than an error. An account that needs delegating is a different message from a trade that is too small to carry the relay fee.
Decide where the cost lands and whether the user sees it. Gas fronting and gasless execution both come out of the amount being moved, which means the number the user receives is smaller than the number they entered. Sponsorship comes out of your account, which means it does not show up on their screen at all and does show up on your bill.
Decide the floor. The relay fee has to leave enough of the input behind to be worth executing, so gasless puts a minimum on trade size. Work out what that is for your pairs before a user finds it for you.
## Next steps
The EVM path: sign, relay, track, and the fee mechanics.
Fee-payer substitution, and what the sponsor account pays for.
Converting part of a transfer into destination native gas.
Following execution once it leaves your hands.