新钱包没币却要链上操作，很多链的方案是“先送点手续费”。Aptos 走的是另一条路：交易照你的意图执行，Gas 却从别人账户里扣。这个机制在官方文档里叫 sponsored transaction，源自 AIP-39，本质是给多签交易加了一个付费人角色。官方举的例子也直白：应用为以太坊背景的用户开 Aptos 钱包并承担全部交易费用，或者社区应用替没有钱包的用户垫付交互成本。
流程：谁先签、谁后签
官方文档给出的标准流程是这样：发送方先决定要执行的操作，构成一笔 RawTransaction；然后把它包进一个叫 MultiAgentWithFeePayer 的结构；发送方和其他次要签名人各自签名；签完的包可以转给付费人，付费人补上自己的签名后提交链上。顺序也可以反过来——付费人如果事先知道操作和全部签名人，可以由它生成并签名，再拿回去让其他人补签。无论哪个方向，交易的执行意图始终由发送方的签名确定，付费人只改“钱从谁扣”，不改“事按谁的想法办”。
签名到底签了什么
从结构上看，代付交易与普通交易共用同一套 SignedTransaction，差别在授权器：代付版把发送方签名、次要签名人列表、fee_payer_address 和付费人签名分四个槽位装在一起。所有相关方签名时覆盖的载荷里都包含付费人地址——这意味着在旧版本里，不知道谁付费就没办法签这笔交易。
一条重要的版本分界
官方文档特别标出框架 1.8 的变化：1.8 之前，签名载荷里必须填入真实的付费人地址，所有签名人都要预先知道谁会代付；1.8 之后，签名人可以先填 0x0，只由付费人在最终签名时带上自己的真实地址。做钱包兼容和排错时，这条分界线决定了“先签的人能不能换付费方”。同一个文档还说明：交易执行时 Gas 从付费人扣除，多付的退款也回到付费人；而发送方的序列号照常递增——换句话说，你的账户历史仍然记录这笔“你发起的交易”，只是账单落在了别人名下。无序列号（orderless）变体则改用 nonce 防重放，不占这条序列号。
空账户的第一笔交易
另一个容易误读的细节：框架 1.8 配合 AIP-115 的无状态账户后，发送方不再需要链上已经存在账户资源才能收交易；但官方同时注明，那笔会创建账户资源的首次交易，仍然要有足够的 Gas 覆盖创建成本再加执行成本。代付场景下这份预算自然由付费方兜住——对集成方是设计题，对用户则意味着“第一次到账就能被使用”本身不免费。
用户视角的边界
把机制翻译成核对动作：第一，代付改变的是 Gas 来源，不改变资产归属与操作发起方，你的转账仍然是“你的账户发出的转账”；第二，在支持该机制的钱包与 dApp 组合里，弹窗信息与传统交易不同，看到 fee payer 相关字段时可以对照官方定义判断，其他栏目的钱包连接问题见 Aptos 的 dApp 怎么找钱包：AIP-62 让钱包自己登记并亮出能力；第三，以太坊世界同类需求走的是另一条工程路线（比如 paymaster 接口标准 代付服务怎么和钱包说话：ERC-7677 给 paymaster 定的标准接口），跨链套用术语容易踩坑。免 Gas 是成本补贴，不是资产无风险的承诺，本文只讲机制，不构成投资建议。
官方 SDK 的落地形态
文档同时给出了四条语言线的参考示例：TypeScript、Python、Go 与 Rust 的官方 SDK 都内置了代付交易的构建方式，流程统一为带 fee payer 标记地构建、发送方先完成自己的签名、付费人再执行付费签名两步走。对集成方这是接口题；对普通用户它意味着一个可核实的锚点——应用宣称支持代付时，其背后大概率走的就是这套官方路径，签名弹窗里出现付费人相关字段是正常形态，而不是异常。文档还把代付与 APT 转账、稳定币支付等官方支付场景列成可以组合的清单，说明付费人角色是被当作通用积木设计的：同一笔交易里可以有多个签名人，付费人不必是参与者，参与者也不一定肯付费。理解这一层，你就不会被某个界面里单独一个免 Gas 开关牵着走，而会去看这次签名的载荷里究竟列了谁。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。