> ## 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 选项
> 四种代替用户处理 gas 的机制，以及针对不同链和不同账户类型该选用哪一种。
用户持有想要转移的代币，却没有该链的原生代币时，就无法发送交易。LI.FI 对此提供了四种方案，分别解决问题的不同侧面：其中三种消除了在源链上对 gas 的需求，另一种在目标链上补充 gas。
请根据用户所处的位置以及其账户的具体情况来选择。
## 你需要哪一种
| 场景 | 机制 | 由谁支付 |
| ---------------------------- | -------------------------------------------------------------------- | --------------------------- |
| 用户在 EVM 链上没有原生代币，需要签名而不是发送交易 | [无 gas 执行](/guides/gasless-transactions) | LI.FI 代为中继，并通过输入代币收取费用来回收成本 |
| 用户在 Solana 上，你希望代为承担其手续费 | [Solana gas 赞助](/introduction/solana-ecosystem#gasless-transactions) | 你，通过一个赞助账户 |
| 用户首次到达某条链，且在该链上一无所有 | [Gas Fronting](/guides/gas-subsidy) | 用户，从被转移的金额中扣除 |
| 已经基于中继接口构建的现有集成 | 下文的 Permit2 中继器 | LI.FI 代为中继 |
前三种机制相互独立，可以在同一产品中同时运行。用户可以先通过 gas fronting 到达某条链，之后再从该链正常消费。
## EVM 上的无 gas 执行
在报价请求中加入 `gasless=true`，响应返回的就是一个待签名的载荷，而不是一笔待发送的交易。用户完成签名后，你将已签名的载荷提交到中继接口，由 LI.FI 支付 gas，并以输入代币收取相应费用，该费用会在报价中单独列出。
决定该功能是否对你可用的关键约束在于账户本身：它必须是一个已经通过 EIP-7702 委托给 LI.FI 代为中继的委托合约的 EOA。未完成委托的账户会被拒绝。
报价接口在这种情况下可能返回一个通用的"无可用报价"错误。如果你需要一个可展示或记录的具体原因，可以改为请求路由，并检查 `unavailableRoutes.filteredOut[].reason`；原因内容可能类似：
```
0xd8dA...96045 is an undelegated EOA and chain 42161 cannot delegate it,
so the relayer has no way to execute for it
```
请勿以编程方式解析该原因文本。
源链必须是 LI.FI 当前为该账户已安装的委托合约提供中继服务的 EVM 链。可用性在报价时确定。目标链可以是 LI.FI 支持的任意链。
完整流程详见：[无 gas 交易](/guides/gasless-transactions)。
## Solana gas 赞助
Solana 的运作方式不同，因此不使用中继器。取而代之的是，由一个赞助账户替代作为交易的手续费支付方。在报价请求中传入赞助方的公钥，返回的交易就会构建为由该账户支付。
有必要向掌握预算的一方明确说明支付方的差异。在 EVM 路径中，LI.FI 先垫付 gas，再从输入金额中回收成本，因此成本落在这笔交易上。而在这里，支付方是你，从你自己出资并监控的账户中扣除。
哪些内容由赞助方承担、哪些仍需要 SOL：详见 [Solana 生态系统](/introduction/solana-ecosystem#gasless-transactions)。
## 目标链上的 Gas Fronting
以上两种机制解决的是用户无法发送交易的问题。这一种解决的是用户到达一个新环境后完全无法操作的问题：资产已经到账，但原生代币余额为零，下一步操作被卡住。
设置 `fromAmountForGas`，转账的一部分会在同一笔转移中被兑换为目标链的原生代币。用户从自己要发送的金额中支付这部分成本，因此没有任何补贴，但"冷启动"的问题消失了。
Gas Fronting 不适用于合约调用接口或 Composer。如果你的流程需要在到账后组合执行某个操作，该链上的 gas 需要从其他来源获取。
完整流程详见：[Gas Fronting](/guides/gas-subsidy)。
## Permit2 中继器
一种较早期的无 gas 机制，基于 Permit2 签名和一个外部中继网络构建，目前仍在运行，仍为基于它构建的集成提供服务：
| 接口 | 用途 |
| --------------------------------- | ---------------- |
| `POST /v1/relayer/relay` | 提交已签名的步骤，交由中继器分发 |
| `GET /v1/relayer/status/{taskId}` | 轮询已分发任务的状态 |
| `GET /v1/gas/refetch` | 强制重新获取中继器遗漏的交易 |
新集成请改用无 gas 执行路径。这些接口仍面向已在使用它们的现有集成保留，新项目不应从这里开始。
## 你需要决定的事项
决定当无 gas 请求被拒绝时，你的界面该如何呈现。这里的每一种机制都有其无法服务的用户群体，拒绝本身是用户可以据此采取行动的信息，而不是一个错误。需要先完成委托的账户，和交易金额太小无法覆盖中继费用的交易，应该给出不同的提示。
决定成本落在哪里，以及是否让用户看到。gas fronting 和无 gas 执行的成本都来自被转移的金额本身，这意味着用户最终收到的金额会小于其输入的金额。赞助方式的成本来自你自己的账户，因此不会出现在用户界面上，但会出现在你的账单上。
决定下限。中继费用必须在扣除后为输入金额留下足够的余量才值得执行，因此无 gas 方式会对交易规模设一个下限。请在用户自己发现这个下限之前，先算清楚它对你的交易对来说是多少。
## 后续步骤
EVM 路径：签名、中继、跟踪，以及费用机制。
手续费支付方替换机制，以及赞助账户承担的内容。
将转账的一部分兑换为目标链的原生 gas。
离开你手中之后，如何跟踪执行过程。