授权(approve)是一笔要花Gas、留在链上的交易;Permit、Permit2这类授权型签名不少时候一分钱不花,钱包也不会提示”即将转出资产”,效果却可能和授权一样,甚至更隐蔽。反诈机构Scam Sniffer的2025年度统计显示,在损失超百万美元的大额被盗案件里,Permit和Permit2这类签名机制是当年占比靠前的手法之一。
核心要点
- 授权(approve)是一笔链上交易,需要付Gas,额度会记进代币合约的存储里,谁都能查得到。
- Permit(EIP-2612)和Permit2这类机制,让用户先签一段链下消息代替自己发起链上交易;这个签名要等被提交上链后才真正改变链上的额度或权限,用户本人通常不用为这一步付Gas。
- Scam Sniffer《2025年度加密钓鱼报告》统计:全年可追踪的EVM链上钱包抽水器(drainer)钓鱼网站活动造成约8385万美元损失(按被盗时美元价值计算,不含交易所被黑、合约漏洞、私钥泄露等其他被盗方式,官方标注为下限估计),同比2024年的约4.94亿美元下降83%;在损失超百万美元的11起大额案件中,Permit和Permit2签名类操作合计占损失金额的38%,其中一笔通过Permit签名在9月造成约650万美元损失,是当年占比靠前的单一手法。
- 判断风险高低,不能只看”是签名还是授权”,域名、链、合约地址、spender、金额、期限任何一项核对不清楚,都应该先不签。
- 撤销方式也不一样:链上allowance要发一笔新交易主动改成0,需付Gas;一次性签名消费后自动失效,不需要额外操作;但没用过的一次性签名要提前作废、或收回可重复使用的额度签名,都得由用户本人再发一笔链上交易、付Gas才能完成,不是免费动作。
风险与边界卡
- 适用地区:钱包授权与签名是全球通用的链上机制,本文只解释技术原理和识别方法,不涉及具体地区的业务合规判断。
- 个人可参与度:本文不构成投资、交易建议,也不指导任何资产操作;是否参与虚拟货币相关活动,需按所在地规则自行判断。
- 主要风险点:无法读懂签名内容的”盲签”、额度或有效期设置过大、把签名误当作”不花钱所以更安全”的操作。
- 该核对的证据:钱包弹窗显示的域名、合约地址、额度和有效期;必要时用授权查询工具核对链上记录。
- 资料截至:2026-08-29。
授权和签名,到底谁在动你的资产?
签名本身只是一个密码学动作,证明这条消息确实由你的私钥签出,不等于自动把资产使用权限交给别人。钱包里的登录验证签名、证明地址归属的签名,通常不涉及任何资产权限。真正会产生和授权类似效果的,是Permit、Permit2这类专门写进合约逻辑里、用来设置或消费代币额度的授权型签名——这类签名和链上approve都是把资产使用权限交给别人的方式,区别在于这个权限是通过一笔链上交易设置的,还是通过一段链下消息签出来的。本文接下来讨论的”签名”,如果没有特别说明,指的都是这类授权型签名。
授权(approve):一笔看得见的链上交易
授权对应ERC-20标准里的approve函数,调用时需要发起一笔正式的链上交易,支付Gas费用,交易确认后,对应的额度(allowance)会被写进代币合约的存储空间。这笔额度谁都能通过区块浏览器查到:哪个地址授权给了哪个spender、额度是多少、什么时候设置的。这也是为什么钱包授权类文章总强调”授权不是转账,但留痕清楚”——它的风险是持续存在的,但至少可以被找到、被核对、被撤销。
签名(sign):不一定花钱,也不一定上链
签名对应的是钱包弹出的”Signature Request”,而不是”Transaction”。以太坊改进提案EIP-2612(俗称Permit)于2020年4月提出,目前状态为Final(已定稿),允许ERC-20代币用一段符合EIP-712结构化数据标准的链下签名,替代原本需要单独发起的approve交易。
用户签完名后,由某个中继方或应用把签名连同调用一起提交上链,设置的还是同一个allowance,但这一步的Gas通常由中继方或应用垫付,用户本人不需要为这次授权单独付Gas,甚至不需要主动发起交易。是否支持这套机制,取决于代币合约有没有实现permit函数:USDC等部分主流稳定币原生支持EIP-2612;DAI虽然更早就有自己的permit函数,但参数和签名结构与EIP-2612标准不完全一致,不能直接当作同一套实现看待。具体某个代币是否兼容,需要查它的合约源码或官方文档确认。
签名不代表”更安全”,只代表”没花钱”
不少人把”要不要花Gas”当成判断风险的标准:花钱的操作会更谨慎,不花钱的随手就点。这个直觉在签名场景里会失效。MetaMask官方帮助中心把恶意代币授权和签名列为web3里的常见钓鱼手法:诱导用户签下一个看起来无关紧要、实际内容却是恶意代币授权的签名或交易;其中”盲签”(blind signing)尤其危险——钱包弹窗展示的意思,和签名实际授权的内容可能完全对不上,用户以为在完成一次登录验证或者领取空投,实际签出去的是一整个代币系列的操作权限。
Permit2为什么让”一次签名”变成了更常见的风险入口?
Permit2是Uniswap Labs推出的通用代币授权协议。用法通常分几步:先给Permit2合约本身做一次链上ERC-20授权(approve,需要付一次Gas)→之后每次要转账或设置额度时,只需要签一段链下消息,不用再发交易→这段签名被提交(或消费)到链上后,才会真正触发转账,或者在Permit2合约里写入、更新一条额度记录。Permit2把后续流程拆成两种模式:一种一次性用完即失效,另一种和传统approve一样可以重复使用、持续挂在链上。
SignatureTransfer:一次性签名,用完即焚
Permit2里的SignatureTransfer模式,不会在Permit2合约里留下持续生效的额度,签名只在被消费的那一笔交易里起作用,通常包含代币种类、金额、不重复的编号(nonce)和截止时间。接收方是否也被签名本身锁定,取决于调用这个签名的应用怎么实现——部分场景会用额外的witness数据把接收方等信息一并绑进签名,但这不是Permit2协议层面对所有调用方式的统一保证,具体要看当次交互用的是哪种调用方式。
一旦这笔转账被消费,同一个签名不能再被使用,这一步不需要用户再额外操作。但如果签名还没被消费、用户想提前作废,就得由用户本人再发起一笔链上交易,调用Permit2合约让对应nonce失效,同样要付Gas——“提前作废”不是免费动作,只是”用完自动失效”才不需要。按官方文档的说法,这种设计原本是为了减少”挂在链上一直生效”的老旧授权,消费后即失效,风险窗口比长期挂着的allowance更短。
AllowanceTransfer:签名之后,风险和普通授权一样持续
Permit2的另一种模式AllowanceTransfer,效果更接近传统approve:用户签一段链下消息设置额度和有效期,这段签名提交上链后,额度记录写入Permit2合约(不是代币合约本身),在有效期内可以反复使用,直到额度用完,或者用户主动去Permit2合约发起一笔链上操作把它撤销。这也是Scam Sniffer报告里提到的风险点——攻击者拿到一个有效期较长的Permit2签名后,不一定立刻转走资产,可能故意等上一段时间。用户签完之后钱包余额没有变化,容易误判”这次操作是安全的”,放松警惕,几周后资产才被转走。
新型态:EIP-7702签名滥用
2025年5月7日在以太坊主网激活的Pectra升级引入EIP-7702,允许普通钱包地址(EOA)通过签一次授权,为自己设置一段委托代码,从而获得可编程的执行能力。这个授权不会随一笔交易结束就自动消失,而是持续生效,直到用户签下新的授权把它替换掉,或者签一份指向空地址的授权把它清除。
Scam Sniffer的年度报告统计,2025年8月出现了利用这一新机制的恶意签名案例,两起合计损失约254万美元。机制越新,安全工具和用户认知跟上的速度往往越慢,这类新签名类型出现时,更应该谨慎对待,而不是因为”没见过”就默认它风险更低。
一张表看懂:授权和签名到底差在哪
记账方式和留痕位置
把授权和三种常见的签名机制放进同一张表,能看出它们在是否上链、是否付费、留痕位置、可读性、生效时长和撤销/失效方式上分别怎么运作。
| 维度 | 授权(approve) | EIP-2612 Permit | Permit2 SignatureTransfer | Permit2 AllowanceTransfer |
|---|---|---|---|---|
| 是否需要首次前置授权 | 不适用,approve本身就是这笔授权 | 不需要,代币合约原生支持permit | 需要,用户先对Permit2合约做1次链上approve,付Gas | 需要,用户先对Permit2合约做1次链上approve,付Gas |
| 本次授权动作是否为链下签名 | 否,本身就是链上交易 | 是 | 是 | 是 |
| 签名生效/消费是否需要链上交易 | 本身即链上交易,用户本人发起并付Gas | 需要,签名连同调用一起提交上链,通常由第三方/应用提交并付Gas,直接设置allowance | 需要,签名连同转账一起提交上链,通常由应用/中继方提交并付Gas,直接完成转账 | 需要,先由应用/中继方把签名提交上链、写入额度并付Gas;之后spender实际动用额度转移资产时,还要再发起一笔链上交易,由spender一方付这笔Gas |
| 额度/权限记录位置 | 写入代币合约存储,链上可查 | 写入代币合约存储(签名提交上链后),链上可查 | 不产生持续额度,仅在被消费的那笔交易内有效 | 写入Permit2合约存储,链上可查 |
| 弹窗内容可读性 | 通常显示为标准交易确认 | 依赖钱包是否解析EIP-712结构化数据 | 依赖钱包是否解析EIP-712及witness字段 | 依赖钱包是否解析EIP-712结构化数据 |
| 生效时长 | 持续有效,直到被修改或撤销 | 持续有效,直到被修改或撤销 | 一次性,消费后立即失效 | 持续有效,直到用完、过期或撤销 |
| 撤销/失效方式 | 发起新交易把额度改为0,需付Gas | 发起新交易把额度改为0,需付Gas | 已消费的签名自动失效,不用操作;未消费但想提前作废,需用户本人再发一笔链上交易让对应nonce失效,同样要付Gas | 在Permit2合约发起新交易把额度改为0或调整有效期,需付Gas |
| 常见滥用场景 | 假DApp诱导授权无限额度 | 冒充登录验证、假空投领取页面诱导签名 | 冒充活动/领取页面诱导签名,把接收方或金额构造成对攻击者有利 | 冒充DApp诱导长有效期、大额度签名,之后延迟转移 |
表格之外还要看什么
表格之外要多问一句:不管弹窗写的是”确认交易”还是”签名请求”,真正决定风险大小的,从来不是这个操作花不花钱,而是你签的这段内容,实际授权了谁、多少、多久,以及这次请求本身的域名和发起方是否可信。
钱包弹窗出现时,怎么判断风险高低?
判断一次弹窗的风险,建议按几项逐一核对:域名和发起方是否可信、内容能不能读懂、链和合约地址对不对、对象(spender/接收方)是谁、额度和有效期有多大。这些信号只能降低部分疑点,无法单独确认这次请求确实安全;任何一项核对不清楚,就先不签。
第一步:核对域名、链和弹窗类型
打开弹窗前先看清楚触发它的网页域名,和你原本要访问的官方地址逐字比对——钓鱼站常用相近拼写,官方前端页面本身也可能被入侵后临时篡改,用得再熟的域名也要每次核对。确认弹窗是”Transaction”(交易)还是”Signature Request”(签名请求):是交易,钱包通常会显示Gas费用估算;是签名请求,很多钱包会额外提示”该请求不产生链上交易费用”,这句提示只说明不花钱,不代表内容无害。
第二步:内容能不能读懂,spender和合约地址对不对
支持EIP-712的钱包,会把签名内容解析成人能看懂的字段:授权对象(spender)、代币种类、额度、截止时间,部分钱包还会显示chain ID和verifying contract地址,可以逐项核对是否和你要交互的官方合约一致。如果钱包只显示一长串十六进制哈希、看不出授权了什么,这就是典型的”盲签”场景。
MetaMask将恶意签名和代币授权列为web3里的常见钓鱼手法,也把签署任意哈希、内容完全不可读的eth_sign列为高风险请求,目前已限制或默认禁用,但具体表现取决于钱包版本。遇到读不懂或核对不上的内容,比较稳妥的做法是先不签,回到发起请求的页面确认这次操作到底是要做什么。有条件的话,用带交易模拟功能的钱包或插件,在确认前预览这笔签名/交易实际会改变哪些资产和权限。
判断表:核对完这几项,才谈得上疑点高低
把域名、内容可读性、spender、额度和有效期放进同一张表,能看出这次操作还剩多少没核实的疑点;只要有一项显示”未核实”,就该归入”仍需核验”,不建议直接确认。
| 域名/发起方 | 内容是否可读 | spender/链/合约地址是否核对 | 额度/有效期 | 判断 | 建议动作 |
|---|---|---|---|---|---|
| 已核实、官方域名 | 是 | 是,均一致 | 具体数额,短期 | 疑点较少 | 仍需留意额度和有效期,确认后再继续 |
| 已核实、官方域名 | 是(EIP-712结构化) | 是,均一致 | 一次性、指定金额 | 疑点较少 | 仍需留意额度和有效期,确认后再继续 |
| 未核实或域名存疑 | 是 | 否或无法确认 | 无限额度 | 仍需核验 | 先不签,核实域名和spender后再决定 |
| 已核实 | 是 | 是 | 长有效期、可重复使用 | 仍需核验 | 先不签,尤其警惕”先签后转”的延迟手法 |
| 任意 | 否(哈希不可读) | 无法确认 | 不明 | 仍需核验 | 直接不签,域名、spender、内容任一项核不清楚就先停下 |
这张表不是用来证明”完全无风险”的:域名、spender、链、合约地址、额度、有效期,只要有一项没核对清楚,就先别签;能核对清楚的项目全部通过,也只代表疑点较少,不代表可以跳过核对直接确认。
不同人该怎么应对签名请求?
操作频率不一样,能接受的核对成本也不同,分场景看会更靠谱一些。
经常在DeFi协议里操作的人
操作频率高不代表可以简化核对步骤,每次签名前依然要核对域名、spender、链和有效期;长有效期的额度型签名尤其要留意,隔一段时间查一查是否还在用、要不要提前撤销。可以配合区块浏览器,核对签名对应的合约地址与官方文档是否一致。
偶尔连接陌生DApp或参与活动的人
参与新项目、领活动奖励时,弹窗里出现的往往是签名请求而不是交易确认,这类情况也更容易诱导人误操作。域名存疑、内容读不懂、spender认不出,任何一项对不上,都先把页面关掉,别因为”不花钱”就随手点确认。识别域名、弹窗和话术的具体做法,可以对照钓鱼网站识别的检查清单。
已经签过陌生请求,不确定有没有问题
先别急着继续操作。用授权查询工具核对当前钱包地址名下的allowance和已有的Permit2记录,把可疑的撤掉。如果资产已经被转走,撤销授权解决不了已经发生的损失,得按钱包被盗的处理顺序来,先止损、再留证。
下次点确认前,先分清签的是哪一种
弹窗弹出来的那几秒,先别看花不花钱,看它能不能读懂在授权什么、授权给了谁、能用多久。签名机制本身是为了省Gas、提体验,这个设计初衷没啥问题,容易出事的还是”不花钱所以不用防”这个想当然的判断。
常见问题
Q: 签名和授权,哪个风险更高?
答: 不能简单说哪个更高,两者防的风险环节不一样。授权的风险在于额度可能设得过大、旧授权容易被遗忘;签名的风险在于内容可能读不懂、有效期可能设得很长而不容易察觉。Scam Sniffer的2025年度报告显示,在损失超百万美元的11起大额案件中,Permit和Permit2签名类操作合计占损失金额的38%,是当年占比靠前的单一手法,不过这更多反映的是攻击者的偏好正在转移,并不代表签名机制本身有漏洞。
Q: 不花Gas的签名请求是不是就不会损失资产?
答: 不是。签名本身确实不需要用户付费,但Permit、Permit2这类授权型签名一旦生效,可能允许对方动用你的资产——Permit和Permit2的AllowanceTransfer模式,效果和普通approve类似,会写入一笔可反复使用的额度;Permit2的SignatureTransfer模式虽然不产生持续额度,但被消费的那一笔也会直接转走资产。有没有损失,要看签名授权了谁、多少额度、多长时间,而不是这次操作花了多少钱。
Q: Permit和Permit2是同一个东西吗?
答: 不是。Permit对应EIP-2612标准,是部分ERC-20代币自带的功能,让approve可以用链下签名来完成。Permit2是Uniswap Labs推出的独立协议,不依赖代币本身是否支持EIP-2612,可以给任意ERC-20代币提供签名授权能力,还额外提供一次性转账的SignatureTransfer模式。
Q: 钱包弹窗只显示一串哈希,看不懂在签什么,该怎么办?
答: 优先选不签。这种情况通常说明钱包没能把签名内容解析成可读字段,也就是俗称的”盲签”。可以先回到发起请求的页面,确认这次操作具体要干什么,或者换成支持结构化签名解析的钱包版本,等确认内容可读后再继续。
Q: 已经签过一个长期有效的Permit2授权,现在想收回,该怎么做?
答: 一次性签名(SignatureTransfer)用完会自动失效,不用额外操作;但如果还没用过、想提前作废,得由你本人再发一笔链上交易,让对应nonce失效,同样要付Gas。额度型签名(AllowanceTransfer)需要专门去Permit2合约发起一笔链上操作来降低或清零额度,具体入口可以在支持Permit2查询的授权管理工具里找到,操作前也同样要核对清楚工具本身的域名是否可信。
Q: 境内用户使用支持Permit或Permit2的钱包,本身违法吗?
答: Permit和Permit2是钱包处理授权的技术机制,签名本身不等同于虚拟货币交易或投资行为。但具体使用场景是否合规,要结合所在地规则和实际行为类型判断——如果涉及境内虚拟货币相关的交易、兑换、经营等业务活动,还是得遵守当地监管要求;技术机制能用,不代表相关业务活动就一定合规,具体判断建议以所在地监管部门的最新规定为准。
参考资料
- Ethereum Improvement Proposals:ERC-2612 Permit Extension for EIP-20 Signed Approvals
- Uniswap Developers:Permit2 Overview
- MetaMask Help Center:Signature phishing
- Scam Sniffer:2025 Crypto Phishing Losses Fall 83% to $84 Million
- ethereum.org:Prague-Electra (Pectra) upgrade
版本 1.0 · 更新于 2026-08 · 资料截至 2026-08-29 · 本文仅解释钱包授权与签名机制,不构成投资或交易建议,具体风险判断仍需结合实际弹窗内容核对