在 Cosmos 系链上，一个新地址第一次转币，最经典的失败是手续费不足：账户里刚收到的代币不能直接当油钱，而换油又得先有一笔交易。x/feegrant 模块就是为了拆掉这个先有鸡还是先有蛋的死结：官方规范一句话概括——账户可以授出费用额度、允许别人从自己账上取用手续费，被授权方无需维持自己的手续费余额就能执行交易。发额度的人叫 granter，收额度的人叫 grantee，一条授权记录同时记下这两个地址和你给的额度形态。规范有两道硬约束：同一个 granter 对同一个 grantee 只能存在一条授权，且不允许自己给自己发。
三种额度形态
第一种是 BasicAllowance：一组 spend_limit（最多被花掉多少币）加一个可选的 expiration（到期时间）。两个字段的空值语义都反直觉，值得背下：spend_limit 留空表示不设金额上限，被授权人在到期前可以从你账上取任意数量的可用余额；expiration 留空表示永不过期。两者同时留空的授权完全合法，此时唯一能止损的办法只剩手动撤销。任一限制触顶，授权会直接从链上状态里删掉，而不是躺在账本里当僵尸。第二种是 PeriodicAllowance：给授权装上周期表——period 定多久重置一次，period_spend_limit 定每期的总额度，period_can_spend 记录本期还剩多少，period_reset 记下下次重置时间；外面还能再包一层 basic 作为总闸门。第三种是 AllowedMsgAllowance：里面装着前两种之一，外加 allowed_messages 白名单——只有列进来的消息类型才能花这份代付，比如只许转账、不许提现。
过滤器要烧你自己的补贴额度
按消息类型过滤不是免费的。官方规范写得明白：为了防止拒绝服务，使用带过滤的 feegrant 要付 gas——SDK 会遍历白名单逐条检查，每条过滤消息收 10 gas，再遍历你实际提交的消息逐条核对，每条再收 10 gas，遇到不合规的消息直接把交易判失败。最扎心的一句警告是：这笔 gas 从你的授权额度里扣。也就是说，往白名单里塞一百个消息类型，等于每次用这份补贴都先白烧一千 gas 的额度，规范围绕这一点的建议是：发消息前先确认自己的消息类型在白名单里。命令行执行时用 --fee-granter 标志，客户端会把补贴方地址写进交易的 fee.granter 字段。
发放、扣费与回收的链路
建立授权发 MsgGrantAllowance，撤销发 MsgRevokeAllowance；执行交易用到授权时，扣费发生在 x/auth 的 antehandler（前置处理器）里，按授权形态核减。三类动作都会广播事件：set_feegrant、revoke_feegrant、use_feegrant，属性字段带上 granter 与 grantee 地址——在浏览器或索引服务里按这两个地址检索事件，就是普通人核对“谁给我发过补贴、我签掉过多少补贴”的主要途径。带到期时间的授权在存储里另挂一条以到期时间排序的队列，每个区块结束的例程扫一遍队列，把到期项从授权存储里清掉，不需要任何人手动清理。
普通用户的核对清单
如果你是受益方：新账户收到“代付”邀请时，先查事件确认 granter 地址与额度形态（无限额加永不过期，意味着这份补贴随时可被撤销，别把关键操作押在它上面）；执行时看回执的 fee 字段，granter 非空说明这一笔确实在花别人的油钱。如果你是出钱方：定期翻 revoke_feegrant 与自己发过的 set_feegrant 事件对账，发现无限额度且无期限的授权，评估是否改成带周期或带白名单的形态再重发。查询通道上，官方文档同时给了 CLI、gRPC 与 REST 三套接口，其中按授权方地址导出名下全部授权的 allowancesbygranter 查询适合做定期清单，再拿 use_feegrant 事件逐笔核销，就能揪出发出去后被遗忘的补贴。它与 x/authz 解决的是两类问题——authz 替你执行消息，feegrant 只替你出手续费，两者组合的讲法可看 不给私钥也能代你发消息：Cosmos SDK 的 x/authz 授权怎么发、怎么过期。涉及资产的授权与代付都不构成投资建议，机制描述以 Cosmos SDK 官方文档 2026-10 抓取版本为准。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。