什么是 Permit 签名授权？不用先发 Approve，为什么也能花你的代币
Permit 能用结构化签名设置或使用代币权限。本文讲清 ERC-2612、Permit2、nonce、期限、spender、撤销方式与盲签风险。
你在 DEX 换币时，钱包没有先弹出一笔 Approve 交易，只要求“签名”，随后应用却能使用你的代币。很多人因此以为这一步不花 Gas、也不发送交易，所以没有权限风险。实际上，这可能是 Permit：你签的不是普通登录消息，而是一份允许合约设置或使用代币额度的授权凭证。
Permit 改善了两笔交易的体验，也把一部分风险从“看得见的链上交易”搬到了“容易被忽略的离线签名”。理解它，关键不是背接口，而是看清谁授权谁、能花什么、最多多少、有效多久，以及签名将在哪个合约和网络生效。
先回顾传统 Approve
ERC-20 代币通常由持有人调用 approve(spender, amount)，在代币合约里写入 allowance；之后 spender 才能通过 transferFrom 转走额度内的代币。第一次使用某个协议往往需要先发 Approve，再发交换或存款交易，用户要付两次 Gas 并等待两次确认。
EIP-2612 把授权变成可提交的签名
ERC-2612 为支持它的 ERC-20 增加 permit。持有人按照 EIP-712 结构化数据签名，任何地址都可以把这份签名提交给代币合约。验证成功后，合约设置 allowance[owner][spender]、增加 nonce，并发出 Approval 事件。
签名动作本身通常不上链，因此签名者不一定需要持有原生币支付 Gas；项目方或中继者可以提交 Permit，并在同一流程里继续执行操作。但最终改变额度仍然发生在链上，也必须有人为那笔交易付费。
一份 Permit 里有哪些关键字段
| 字段 | 含义 | 核对重点 |
|---|---|---|
| owner | 代币持有人 | 是否为当前钱包 |
| spender | 将获得额度的地址 | 是否为预期协议合约 |
| value | 授权额度 | 精度换算后是否过大或无限 |
| nonce | 防止同一授权重复使用 | 由合约按账户记录 |
| deadline | 签名提交截止时间 | 是否过长或近似永不过期 |
| domain | 名称、版本、Chain ID、验证合约等 | 是否属于正确代币与网络 |
签名后代币会立刻转走吗
标准 ERC-2612 Permit 本身设置额度，不直接规定把代币转给谁。随后获得额度的 spender 可以调用 transferFrom，或协议在同一笔交易中完成 Permit 与后续操作。对用户而言，最终结果仍可能是代币被转走，因此不能因为签名页面显示“Gas 费为零”就降低警惕。
nonce 和 deadline 如何防重放
每个 owner 有当前 nonce。合约只接受与当前值一致的签名，成功执行后 nonce 加一，同一份 Permit 便不能再次使用。deadline 限制最晚提交时间。两者减少重复使用和长期暴露，但前提是实现与域分离正确，而且用户没有签一个期限极长、额度极大的授权。
Domain 为什么很重要
EIP-712 Domain 常包含代币名称、版本、Chain ID 和验证合约地址。它把签名绑定到特定应用环境，避免一份消息在另一个代币或网络被当成相同授权。若页面隐藏验证合约，或钱包只能显示难读的十六进制内容，用户就难以确认签名真正指向哪里。
安全判断：“签名”只是交互形式，不代表低风险。要判断风险，必须读签名赋予了什么权限。
Permit 并不只有一种
历史上有些代币使用不同的 Permit 形式。例如 DAI 风格授权用 allowed 表示零额度或最大额度，字段和语义与 ERC-2612 的 value 不完全相同。不能只看函数名叫 permit，就假设所有代币使用同一结构、同一撤销方式。
Permit2 又是什么
Uniswap Permit2 是独立合约，旨在让更多 ERC-20 使用基于签名的权限。它不是给每个代币增加 ERC-2612；用户通常要先在具体代币上做一次传统 Approve，把 Permit2 合约设为 spender，之后再通过 Permit2 管理更细的金额、期限和下游 spender。
这意味着“使用 Permit2 不需要 Approve”并不准确：首次针对该代币通常仍需链上批准 Permit2。若先给了最大额度，这个底层授权会长期存在，因此核对 Permit2 地址、前端来源和后续权限尤其重要。
AllowanceTransfer 与 SignatureTransfer
Permit2 的 AllowanceTransfer 保存带金额和到期时间的持续额度，适合重复交互；SignatureTransfer 则用一次性、带 nonce 的签名授权单次转移，不留下持续的下游额度。两者都使用签名，但权限持续时间和调用方式不同，钱包页面应明确展示实际类型。
最危险的不是 Permit，而是盲签
钓鱼页面可能把“领取空投”“验证钱包”包装成 Permit 或 Permit2 请求。一旦签名覆盖了高额度、长期限和攻击者控制的 spender，对方可以提交它并尝试转走代币。签名不需要你再次输入助记词，也可能暂时不显示链上交易，因此更容易让人放松。
收到签名请求时逐项核对
- 网站：域名是否来自官方渠道，是否有相似拼写和广告跳转？
- 网络：Chain ID 是否与要使用的资产一致？
- 验证合约：是正确代币、Permit2 或协议部署地址吗？
- spender：真正能使用额度的地址是谁，是否经过验证？
- 代币与金额：精度换算后是多少，是否被设为最大整数？
- 期限：只够完成本次操作，还是几乎永久有效？
- 操作目的：一次登录为什么需要代币额度？理由对不上就拒绝。
钱包显示不完整怎么办
不要依赖按钮颜色和“签名请求”四个字。展开结构化数据，查看 Domain、primaryType 和 message；如果钱包无法解码、只显示十六进制，先取消，再换可信界面或区块浏览器核对合约。硬件钱包只能保护私钥不离开设备，无法替你判断屏幕上的授权是否合理。
如何撤销已经生效的权限
ERC-2612 最终形成的是代币 allowance，可以在可信授权管理工具或代币合约中把对应 spender 的额度改为零。Permit2 还存在“代币对 Permit2 的底层批准”和“Permit2 内部给具体 spender 的权限”两个层次，需要分别检查。撤销前先确认链、代币和 spender，撤销交易本身也需要 Gas。
未提交的签名能像文件一样删除吗
已经交给别人的离线签名不能从对方设备远程删除。它会在过期、对应 nonce 被有效消费，或具体协议的取消机制生效后失去作用。贸然发送另一份同 nonce 请求还可能被抢先提交，因此发现可疑签名时，应尽快转移高风险资产、撤销相关链上额度，并依据具体代币或 Permit2 机制处理，而不是只断开网站连接。
开发者也要防止集成失误
前端应展示人类可读的 spender、代币、金额和到期时间，避免默认无限额度。合约要验证签名域、nonce、期限和 owner，正确处理 Permit 已被其他人提前提交的情况，并让组合调用具备清晰失败语义。还要测试不支持 ERC-2612、使用 DAI 风格 Permit、手续费代币与合约钱包等差异。
Permit、Approve 与普通签名对比
| 操作 | 是否立即上链 | 可能产生代币权限 | 主要检查 |
|---|---|---|---|
| Approve | 是 | 是，写入 allowance | spender 与额度 |
| ERC-2612 Permit | 签名时否，提交后是 | 是，写入 allowance | Domain、spender、value、deadline |
| Permit2 Allowance | 签名可离线，使用时上链 | 是，带额度和期限 | 底层批准与下游 spender |
| Permit2 SignatureTransfer | 签名可离线，使用时上链 | 授权一次转移 | 接收逻辑、金额、nonce、期限 |
| 普通登录签名 | 通常否 | 正常情况下不应有代币额度 | 域名、用途、消息内容 |
官方资料
标准字段和安全边界见 ERC-2612：Permit Extension for EIP-20 Signed Approvals；Permit2 两类权限及首次批准关系见 Uniswap Permit2 官方概览。
Permit 的价值是减少步骤、支持代付和组合交互，不是把授权变成无风险操作。每次签名前把 spender、额度、期限和验证合约读清楚，才能享受便利而不把控制权悄悄交给错误的人。
本文为链上指南原创科普内容，不构成任何投资建议。签名可能授予真实资产权限；看不懂内容、地址不明或网站来源可疑时，请立即取消，并使用可信工具核查已有授权。