1
月
在社区成长 1 月
LEVEL 1
1 XP
## 一、背景：钱包被盗不一定是私钥泄露
在以太坊及兼容 EVM 的网络中，常见资产损失大致可分为三类：私钥或助记词泄露、签署了具有直接转账效果的交易、授予恶意合约长期资产操作权限。第三类尤其容易被忽略：用户只是点击了一次“授权”，资产当时没有移动，但合约随后可以依据 allowance 或 operator 权限转走代币或 NFT。
本文建立一套可重复的防御流程：先理解交易与签名的边界，再使用公开 RPC、本地工具和区块浏览器审计 ERC-20、ERC-721、ERC-1155 授权，最后在本地 Anvil 实验链上验证授权风险。全文不要求导入真实私钥，不针对任何真实目标进行攻击，也不构成投资建议。
## 二、核心原理
### 1. 私钥、签名与交易
EOA 钱包使用私钥生成数字签名。签名通常证明“某地址同意了某段确定的数据”，但签名对象不只有链上交易，还可能是 EIP-191 消息或 EIP-712 结构化数据。
一笔 EVM 交易通常包含 chainId、nonce、to、value、data、gasLimit，以及费用字段。chainId 用于降低跨链重放风险；nonce 保证同一账户的交易顺序；to 指向接收地址或合约；value 是原生币数量；data 决定合约调用的方法和参数。
必须注意：钱包弹窗显示“签名”不等于操作无风险。Permit、Permit2、订单签名等链下消息可能授权第三方在稍后提交交易。判断风险时应同时核对签名域、验证合约、链 ID、spender、资产、数量、nonce 和 deadline。
### 2. 三类常见资产授权
ERC-20 常见接口是 approve(spender, amount)，授权 spender 从持有人地址划转最多 amount 数量的代币；allowance(owner, spender) 用于查询剩余额度。
ERC-721 既可能使用 approve(to, tokenId) 对单个 NFT 授权，也可能使用 setApprovalForAll(operator, true) 把整个系列的操作权交给 operator。
ERC-1155 通常使用 setApprovalForAll。它没有 ERC-20 式按数量 allowance，因此全局 operator 权限需要更谨慎地检查。
“无限授权”一般指授权值接近 uint256 最大值。它可以减少重复授权交易，但也扩大了 spender 合约失陷、升级后逻辑改变或操作员密钥泄露时的损失范围。
### 3. 代理合约与实现合约
链上交互地址可能只是代理。审计时不能只看代理表面的源码，还要确认实现地址、升级管理员和升级机制。常见 EIP-1967 代理把实现地址存放在固定槽位；可升级并不等于恶意，但意味着未来行为可能发生变化。
## 三、前置条件与安全边界
建议准备：
1. 一台可信电脑，系统和浏览器已更新；
2. Foundry 工具集中的 cast 与 anvil；
3. jq，用于处理 JSON；
4. 可信或自建的只读 RPC 地址；
5. 待检查的钱包地址、代币合约地址和 spender/operator 地址；
6. 一个全新的本地测试账户，绝不使用真实助记词。
安装后可检查版本：
cast --version
anvil --version
jq --version
本文所有 RPC 示例均以环境变量表示，避免把服务商密钥写进终端历史：
export RPC_URL='https://你的只读RPC地址'
export WALLET='0x待检查的钱包地址'
export TOKEN='0x代币合约地址'
export SPENDER='0x被授权地址'
RPC 服务商可以看到查询来源、时间和地址组合。对隐私要求较高时，应使用自建节点、可信内网节点或隔离后的查询环境。
## 四、分步骤实践
### 步骤一：确认网络，避免查错链
先读取链 ID 和最新区块：
cast chain-id --rpc-url "$RPC_URL"
cast block-number --rpc-url "$RPC_URL"
同一个十六进制地址可能同时出现在多条 EVM 链上，但代码、余额与授权状态彼此独立。记录实际 chainId，不要仅凭钱包界面中的网络名称判断。
### 步骤二：确认目标地址是否为合约
cast code "$TOKEN" --rpc-url "$RPC_URL"
cast code "$SPENDER" --rpc-url "$RPC_URL"
如果结果为 0x，通常表示该地址在当前区块没有合约代码；如果返回较长字节码，则是合约地址。这个检查不能单独证明安全：合约可能通过代理执行其他实现，EOA 也可能是高风险收款地址。
可进一步查询 EIP-1967 实现槽。该槽位为标准固定值：
cast storage "$SPENDER" 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc --rpc-url "$RPC_URL"
返回值末尾 20 字节可能是实现地址；全零不代表一定不是代理，因为还有其他代理模式。应结合已验证源码、浏览器的代理标识、部署交易和升级事件综合判断。
### 步骤三：审计 ERC-20 allowance
查询代币精度、符号、余额和授权额度：
cast call "$TOKEN" 'decimals()(uint8)' --rpc-url "$RPC_URL"
cast call "$TOKEN" 'symbol()(string)' --rpc-url "$RPC_URL"
cast call "$TOKEN" 'balanceOf(address)(uint256)' "$WALLET" --rpc-url "$RPC_URL"
cast call "$TOKEN" 'allowance(address,address)(uint256)' "$WALLET" "$SPENDER" --rpc-url "$RPC_URL"
假设 decimals 为 6，allowance 返回 500000000，则人类可读额度为 500 个代币，而不是五亿个。不要忽略精度换算。
识别无限授权时，可与 uint256 最大值比较：
cast max-uint
即使 allowance 不是最大值，只要明显高于业务所需，仍应视为过度授权。审计表至少记录：链、owner、token、spender、原始额度、精度、可读额度、spender 用途、首次发现时间和处理结论。
### 步骤四：审计 NFT 全局授权
ERC-721 与 ERC-1155 都常见以下查询：
cast call "$TOKEN" 'isApprovedForAll(address,address)(bool)' "$WALLET" "$SPENDER" --rpc-url "$RPC_URL"
如果返回 true，operator 通常能够操作该系列下持有人的多个资产。对于 ERC-721，还可检查特定 tokenId：
export TOKEN_ID='123'
cast call "$TOKEN" 'getApproved(uint256)(address)' "$TOKEN_ID" --rpc-url "$RPC_URL"
cast call "$TOKEN" 'ownerOf(uint256)(address)' "$TOKEN_ID" --rpc-url "$RPC_URL"
这里需要区分“单个 NFT 授权”和“整个系列授权”。只检查 getApproved 可能漏掉 setApprovalForAll。
### 步骤五：从 calldata 识别高风险方法
交易 data 的前 4 字节是函数选择器，来源于函数签名的 Keccak-256 哈希。可本地计算常见选择器：
cast sig 'approve(address,uint256)'
cast sig 'setApprovalForAll(address,bool)'
cast sig 'transferFrom(address,address,uint256)'
cast sig 'safeTransferFrom(address,address,uint256)'
获得待签交易 calldata 后，可以尝试解码：
cast 4byte-decode '0x完整calldata'
公共选择器数据库可能存在碰撞或错误标签，因此解码结果只能作为线索。可靠判断还要结合目标合约 ABI、已验证源码和参数类型。尤其要检查 spender/operator 是否与界面宣称的对象一致，数量是否异常，以及布尔参数是否为 true。
### 步骤六：签名前进行只读模拟
对于普通合约调用，可先使用 eth_call 模拟。以下示例只读查询，不会广播交易：
cast call "$TOKEN" 'allowance(address,address)(uint256)' "$WALLET" "$SPENDER" --rpc-url "$RPC_URL"
若要模拟待发送交易，可在本地构造 calldata，再调用 RPC 的 eth_call。需要注意：模拟成功只说明在指定区块状态下调用没有回滚，不证明合约安全，也不能保证正式上链时状态不变。某些合约会根据 msg.sender、区块时间、预言机、余额或调用路径表现出不同结果。
如果 RPC 支持 trace_call 或 debug_traceCall，可检查内部调用、事件和资产流向；但不同客户端参数格式不同，不应把节点不支持误判为交易恶意。
### 步骤七：在本地 Anvil 验证“授权后可被划转”
启动本地实验链：
anvil
另开终端，将 RPC 指向本机：
export LOCAL_RPC='http://127.0.0.1:8545'
cast chain-id --rpc-url "$LOCAL_RPC"
Anvil 会打印仅供本地测试的预置账户和私钥。这些私钥公开且不安全，绝不能在主网或任何有价值的网络中使用，也不要向对应地址转入真实资产。
可在本地部署一个最小 ERC-20 测试合约，分别扮演 owner 与 spender：owner 先执行 approve，spender 再执行 transferFrom。实验应观察三个状态：owner 余额下降、接收者余额上升、allowance 按实际划转量减少。这样可以直观看到 approve 本身不移动资产，但会为后续划转建立权限。
如果使用 forge 项目，建议测试至少包含以下断言：
assertEq(token.allowance(owner, spender), approvedAmount);
vm.prank(spender);
token.transferFrom(owner, receiver, transferAmount);
assertEq(token.balanceOf(receiver), transferAmount);
assertEq(token.allowance(owner, spender), approvedAmount - transferAmount);
该实验只应针对自建合约和本地账户，不要复制真实项目合约并尝试寻找可利用缺陷。
### 步骤八：安全撤销授权
ERC-20 通常通过把额度设为 0 撤销：
cast calldata 'approve(address,uint256)' "$SPENDER" 0
NFT 全局授权通常通过设置 false 撤销：
cast calldata 'setApprovalForAll(address,bool)' "$SPENDER" false
以上命令只生成 calldata，不会签名或广播。真正发送前，应在硬件钱包或可信钱包中再次核对 chainId、to、函数、spender、参数和费用。
撤销操作存在竞态窗口：旧 spender 可能在撤销交易确认前使用现有权限。因此，一旦怀疑 spender 已经恶意或失陷，应先停止交互，评估是否需要把仍可控制的资产迁移至全新钱包，再从安全环境处理遗留授权。迁移也要考虑 NFT、质押仓位、账户抽象权限和跨链资产，不能只转原生币。
## 五、链上风险识别清单
遇到新合约或陌生授权请求，可按以下维度打标，而不是只看单一“安全分数”：
1. 合约代码是否已验证，验证代码是否与当前实现地址对应；
2. 是否为可升级代理，谁能升级，实现最近是否变化；
3. 管理员是否可暂停、增发、冻结、拉黑或任意转移资产；
4. spender 是否与官方文档公布地址一致，域名是否存在拼写差异；
5. 请求额度是否远高于本次操作所需，是否要求 NFT 全局授权；
6. EIP-712 domain 中的 name、version、chainId、verifyingContract 是否合理；
7. deadline 是否过长，nonce 是否可复用，签名是否限定具体资产和接收者；
8. 合约创建时间是否很短，资金来源与交互路径是否异常；
9. 前端展示与实际 calldata 是否一致；
10. 是否出现催促、空投诱导、客服私信索要助记词等社会工程迹象。
代码已验证、审计报告存在或合约运行时间较长，都不能独立证明绝对安全。反过来，合约未验证也不必然表示恶意，但透明度较低，应提高审慎等级。
## 六、风险与注意事项
第一，不要把助记词、私钥或 keystore 密码粘贴到网页、聊天软件、截图、云笔记或命令行示例中。命令行参数可能进入 shell history，真实签名应优先使用硬件钱包或隔离签名设备。
第二，撤销授权需要链上交易费。任何声称“无需签名即可替你撤销全部权限”的陌生网站都应谨慎对待。
第三，授权查看工具本身也可能被仿冒。只读查询尽量交叉验证：区块浏览器、cast 查询和钱包展示至少核对两处。
第四，代币实现可能不完全遵循标准。有些旧代币要求先把 allowance 设为 0，才能改成新值；有些代币包含转账税、暂停或黑名单逻辑。标准 ABI 调用成功不代表经济结果与普通 ERC-20 完全一致。
第五，Permit2、智能账户 session key、Safe 模块、委托执行和跨链桥授权不会全部体现在传统 ERC-20 allowance 列表中。高价值账户应额外审计 EIP-712 签名记录、账户模块、守护者、恢复机制及链上部署配置。
## 七、常见问题
### Q1：钱包没有余额，还需要撤销授权吗？
需要结合未来用途判断。只要授权仍有效，账户以后收到相同代币时仍可能被 spender 划转。若地址不再使用，可以停止入金并做好标记；若继续使用，建议清理不必要权限。
### Q2：把代币转到新钱包后，旧钱包的授权会跟过去吗？
不会。allowance 通常绑定 owner、token 与 spender，NFT operator 权限也绑定原持有人地址。但如果新钱包再次连接同一恶意前端并重新授权，风险会重新出现。
### Q3：签名消息不消耗 Gas，所以一定安全吗？
不是。链下签名可由第三方提交，也可能形成订单、Permit 或资产操作授权。是否消耗 Gas 与是否具有资产风险没有必然关系。
### Q4：撤销 ERC-20 allowance 后，历史授权记录会消失吗？
不会。区块链历史不可删除，但当前 allowance 可以变为 0。审计时要区分历史事件与当前状态。
### Q5：为什么区块浏览器显示的授权和 RPC 查询不一致？
可能原因包括网络选错、浏览器索引延迟、代理或代币识别错误、查询区块高度不同，以及工具只通过事件推导而没有读取当前状态。以正确网络上合约当前状态的 eth_call 为重要依据，并交叉核对。
### Q6：只使用硬件钱包就不会被盗吗？
硬件钱包能降低私钥直接泄露风险，但不能阻止用户确认恶意交易或危险授权。屏幕上显示的目标地址、金额和方法仍需人工核对。
## 八、总结
钱包安全不应只停留在“保管好助记词”。更完整的防线包括：确认 chainId，识别交易 data，区分交易签名与结构化消息签名，定期检查 ERC-20 allowance 和 NFT operator，核对代理实现与升级权限，使用只读模拟和本地实验验证行为，并对不再需要的权限及时撤销。
建议形成固定习惯：小额专用交互钱包与长期保管钱包分离；新协议优先使用精确额度而非无限额度；每次签名前核对 to、spender、数量、deadline 和 verifyingContract；每月导出一次授权清单并记录处置结果。这样即使某个前端、合约或服务出现问题，也能把权限范围和潜在损失控制在更小范围内。
在以太坊及兼容 EVM 的网络中，常见资产损失大致可分为三类：私钥或助记词泄露、签署了具有直接转账效果的交易、授予恶意合约长期资产操作权限。第三类尤其容易被忽略：用户只是点击了一次“授权”，资产当时没有移动，但合约随后可以依据 allowance 或 operator 权限转走代币或 NFT。
本文建立一套可重复的防御流程：先理解交易与签名的边界，再使用公开 RPC、本地工具和区块浏览器审计 ERC-20、ERC-721、ERC-1155 授权，最后在本地 Anvil 实验链上验证授权风险。全文不要求导入真实私钥，不针对任何真实目标进行攻击，也不构成投资建议。
## 二、核心原理
### 1. 私钥、签名与交易
EOA 钱包使用私钥生成数字签名。签名通常证明“某地址同意了某段确定的数据”，但签名对象不只有链上交易，还可能是 EIP-191 消息或 EIP-712 结构化数据。
一笔 EVM 交易通常包含 chainId、nonce、to、value、data、gasLimit，以及费用字段。chainId 用于降低跨链重放风险；nonce 保证同一账户的交易顺序；to 指向接收地址或合约；value 是原生币数量；data 决定合约调用的方法和参数。
必须注意：钱包弹窗显示“签名”不等于操作无风险。Permit、Permit2、订单签名等链下消息可能授权第三方在稍后提交交易。判断风险时应同时核对签名域、验证合约、链 ID、spender、资产、数量、nonce 和 deadline。
### 2. 三类常见资产授权
ERC-20 常见接口是 approve(spender, amount)，授权 spender 从持有人地址划转最多 amount 数量的代币；allowance(owner, spender) 用于查询剩余额度。
ERC-721 既可能使用 approve(to, tokenId) 对单个 NFT 授权，也可能使用 setApprovalForAll(operator, true) 把整个系列的操作权交给 operator。
ERC-1155 通常使用 setApprovalForAll。它没有 ERC-20 式按数量 allowance，因此全局 operator 权限需要更谨慎地检查。
“无限授权”一般指授权值接近 uint256 最大值。它可以减少重复授权交易，但也扩大了 spender 合约失陷、升级后逻辑改变或操作员密钥泄露时的损失范围。
### 3. 代理合约与实现合约
链上交互地址可能只是代理。审计时不能只看代理表面的源码，还要确认实现地址、升级管理员和升级机制。常见 EIP-1967 代理把实现地址存放在固定槽位；可升级并不等于恶意，但意味着未来行为可能发生变化。
## 三、前置条件与安全边界
建议准备：
1. 一台可信电脑，系统和浏览器已更新；
2. Foundry 工具集中的 cast 与 anvil；
3. jq，用于处理 JSON；
4. 可信或自建的只读 RPC 地址；
5. 待检查的钱包地址、代币合约地址和 spender/operator 地址；
6. 一个全新的本地测试账户，绝不使用真实助记词。
安装后可检查版本：
cast --version
anvil --version
jq --version
本文所有 RPC 示例均以环境变量表示，避免把服务商密钥写进终端历史：
export RPC_URL='https://你的只读RPC地址'
export WALLET='0x待检查的钱包地址'
export TOKEN='0x代币合约地址'
export SPENDER='0x被授权地址'
RPC 服务商可以看到查询来源、时间和地址组合。对隐私要求较高时，应使用自建节点、可信内网节点或隔离后的查询环境。
## 四、分步骤实践
### 步骤一：确认网络，避免查错链
先读取链 ID 和最新区块：
cast chain-id --rpc-url "$RPC_URL"
cast block-number --rpc-url "$RPC_URL"
同一个十六进制地址可能同时出现在多条 EVM 链上，但代码、余额与授权状态彼此独立。记录实际 chainId，不要仅凭钱包界面中的网络名称判断。
### 步骤二：确认目标地址是否为合约
cast code "$TOKEN" --rpc-url "$RPC_URL"
cast code "$SPENDER" --rpc-url "$RPC_URL"
如果结果为 0x，通常表示该地址在当前区块没有合约代码；如果返回较长字节码，则是合约地址。这个检查不能单独证明安全：合约可能通过代理执行其他实现，EOA 也可能是高风险收款地址。
可进一步查询 EIP-1967 实现槽。该槽位为标准固定值：
cast storage "$SPENDER" 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc --rpc-url "$RPC_URL"
返回值末尾 20 字节可能是实现地址；全零不代表一定不是代理，因为还有其他代理模式。应结合已验证源码、浏览器的代理标识、部署交易和升级事件综合判断。
### 步骤三：审计 ERC-20 allowance
查询代币精度、符号、余额和授权额度：
cast call "$TOKEN" 'decimals()(uint8)' --rpc-url "$RPC_URL"
cast call "$TOKEN" 'symbol()(string)' --rpc-url "$RPC_URL"
cast call "$TOKEN" 'balanceOf(address)(uint256)' "$WALLET" --rpc-url "$RPC_URL"
cast call "$TOKEN" 'allowance(address,address)(uint256)' "$WALLET" "$SPENDER" --rpc-url "$RPC_URL"
假设 decimals 为 6，allowance 返回 500000000，则人类可读额度为 500 个代币，而不是五亿个。不要忽略精度换算。
识别无限授权时，可与 uint256 最大值比较：
cast max-uint
即使 allowance 不是最大值，只要明显高于业务所需，仍应视为过度授权。审计表至少记录：链、owner、token、spender、原始额度、精度、可读额度、spender 用途、首次发现时间和处理结论。
### 步骤四：审计 NFT 全局授权
ERC-721 与 ERC-1155 都常见以下查询：
cast call "$TOKEN" 'isApprovedForAll(address,address)(bool)' "$WALLET" "$SPENDER" --rpc-url "$RPC_URL"
如果返回 true，operator 通常能够操作该系列下持有人的多个资产。对于 ERC-721，还可检查特定 tokenId：
export TOKEN_ID='123'
cast call "$TOKEN" 'getApproved(uint256)(address)' "$TOKEN_ID" --rpc-url "$RPC_URL"
cast call "$TOKEN" 'ownerOf(uint256)(address)' "$TOKEN_ID" --rpc-url "$RPC_URL"
这里需要区分“单个 NFT 授权”和“整个系列授权”。只检查 getApproved 可能漏掉 setApprovalForAll。
### 步骤五：从 calldata 识别高风险方法
交易 data 的前 4 字节是函数选择器，来源于函数签名的 Keccak-256 哈希。可本地计算常见选择器：
cast sig 'approve(address,uint256)'
cast sig 'setApprovalForAll(address,bool)'
cast sig 'transferFrom(address,address,uint256)'
cast sig 'safeTransferFrom(address,address,uint256)'
获得待签交易 calldata 后，可以尝试解码：
cast 4byte-decode '0x完整calldata'
公共选择器数据库可能存在碰撞或错误标签，因此解码结果只能作为线索。可靠判断还要结合目标合约 ABI、已验证源码和参数类型。尤其要检查 spender/operator 是否与界面宣称的对象一致，数量是否异常，以及布尔参数是否为 true。
### 步骤六：签名前进行只读模拟
对于普通合约调用，可先使用 eth_call 模拟。以下示例只读查询，不会广播交易：
cast call "$TOKEN" 'allowance(address,address)(uint256)' "$WALLET" "$SPENDER" --rpc-url "$RPC_URL"
若要模拟待发送交易，可在本地构造 calldata，再调用 RPC 的 eth_call。需要注意：模拟成功只说明在指定区块状态下调用没有回滚，不证明合约安全，也不能保证正式上链时状态不变。某些合约会根据 msg.sender、区块时间、预言机、余额或调用路径表现出不同结果。
如果 RPC 支持 trace_call 或 debug_traceCall，可检查内部调用、事件和资产流向；但不同客户端参数格式不同，不应把节点不支持误判为交易恶意。
### 步骤七：在本地 Anvil 验证“授权后可被划转”
启动本地实验链：
anvil
另开终端，将 RPC 指向本机：
export LOCAL_RPC='http://127.0.0.1:8545'
cast chain-id --rpc-url "$LOCAL_RPC"
Anvil 会打印仅供本地测试的预置账户和私钥。这些私钥公开且不安全，绝不能在主网或任何有价值的网络中使用，也不要向对应地址转入真实资产。
可在本地部署一个最小 ERC-20 测试合约，分别扮演 owner 与 spender：owner 先执行 approve，spender 再执行 transferFrom。实验应观察三个状态：owner 余额下降、接收者余额上升、allowance 按实际划转量减少。这样可以直观看到 approve 本身不移动资产，但会为后续划转建立权限。
如果使用 forge 项目，建议测试至少包含以下断言：
assertEq(token.allowance(owner, spender), approvedAmount);
vm.prank(spender);
token.transferFrom(owner, receiver, transferAmount);
assertEq(token.balanceOf(receiver), transferAmount);
assertEq(token.allowance(owner, spender), approvedAmount - transferAmount);
该实验只应针对自建合约和本地账户，不要复制真实项目合约并尝试寻找可利用缺陷。
### 步骤八：安全撤销授权
ERC-20 通常通过把额度设为 0 撤销：
cast calldata 'approve(address,uint256)' "$SPENDER" 0
NFT 全局授权通常通过设置 false 撤销：
cast calldata 'setApprovalForAll(address,bool)' "$SPENDER" false
以上命令只生成 calldata，不会签名或广播。真正发送前，应在硬件钱包或可信钱包中再次核对 chainId、to、函数、spender、参数和费用。
撤销操作存在竞态窗口：旧 spender 可能在撤销交易确认前使用现有权限。因此，一旦怀疑 spender 已经恶意或失陷，应先停止交互，评估是否需要把仍可控制的资产迁移至全新钱包，再从安全环境处理遗留授权。迁移也要考虑 NFT、质押仓位、账户抽象权限和跨链资产，不能只转原生币。
## 五、链上风险识别清单
遇到新合约或陌生授权请求，可按以下维度打标，而不是只看单一“安全分数”：
1. 合约代码是否已验证，验证代码是否与当前实现地址对应；
2. 是否为可升级代理，谁能升级，实现最近是否变化；
3. 管理员是否可暂停、增发、冻结、拉黑或任意转移资产；
4. spender 是否与官方文档公布地址一致，域名是否存在拼写差异；
5. 请求额度是否远高于本次操作所需，是否要求 NFT 全局授权；
6. EIP-712 domain 中的 name、version、chainId、verifyingContract 是否合理；
7. deadline 是否过长，nonce 是否可复用，签名是否限定具体资产和接收者；
8. 合约创建时间是否很短，资金来源与交互路径是否异常；
9. 前端展示与实际 calldata 是否一致；
10. 是否出现催促、空投诱导、客服私信索要助记词等社会工程迹象。
代码已验证、审计报告存在或合约运行时间较长，都不能独立证明绝对安全。反过来，合约未验证也不必然表示恶意，但透明度较低，应提高审慎等级。
## 六、风险与注意事项
第一，不要把助记词、私钥或 keystore 密码粘贴到网页、聊天软件、截图、云笔记或命令行示例中。命令行参数可能进入 shell history，真实签名应优先使用硬件钱包或隔离签名设备。
第二，撤销授权需要链上交易费。任何声称“无需签名即可替你撤销全部权限”的陌生网站都应谨慎对待。
第三，授权查看工具本身也可能被仿冒。只读查询尽量交叉验证：区块浏览器、cast 查询和钱包展示至少核对两处。
第四，代币实现可能不完全遵循标准。有些旧代币要求先把 allowance 设为 0，才能改成新值；有些代币包含转账税、暂停或黑名单逻辑。标准 ABI 调用成功不代表经济结果与普通 ERC-20 完全一致。
第五，Permit2、智能账户 session key、Safe 模块、委托执行和跨链桥授权不会全部体现在传统 ERC-20 allowance 列表中。高价值账户应额外审计 EIP-712 签名记录、账户模块、守护者、恢复机制及链上部署配置。
## 七、常见问题
### Q1：钱包没有余额，还需要撤销授权吗？
需要结合未来用途判断。只要授权仍有效，账户以后收到相同代币时仍可能被 spender 划转。若地址不再使用，可以停止入金并做好标记；若继续使用，建议清理不必要权限。
### Q2：把代币转到新钱包后，旧钱包的授权会跟过去吗？
不会。allowance 通常绑定 owner、token 与 spender，NFT operator 权限也绑定原持有人地址。但如果新钱包再次连接同一恶意前端并重新授权，风险会重新出现。
### Q3：签名消息不消耗 Gas，所以一定安全吗？
不是。链下签名可由第三方提交，也可能形成订单、Permit 或资产操作授权。是否消耗 Gas 与是否具有资产风险没有必然关系。
### Q4：撤销 ERC-20 allowance 后，历史授权记录会消失吗？
不会。区块链历史不可删除，但当前 allowance 可以变为 0。审计时要区分历史事件与当前状态。
### Q5：为什么区块浏览器显示的授权和 RPC 查询不一致？
可能原因包括网络选错、浏览器索引延迟、代理或代币识别错误、查询区块高度不同，以及工具只通过事件推导而没有读取当前状态。以正确网络上合约当前状态的 eth_call 为重要依据，并交叉核对。
### Q6：只使用硬件钱包就不会被盗吗？
硬件钱包能降低私钥直接泄露风险，但不能阻止用户确认恶意交易或危险授权。屏幕上显示的目标地址、金额和方法仍需人工核对。
## 八、总结
钱包安全不应只停留在“保管好助记词”。更完整的防线包括：确认 chainId，识别交易 data，区分交易签名与结构化消息签名，定期检查 ERC-20 allowance 和 NFT operator，核对代理实现与升级权限，使用只读模拟和本地实验验证行为，并对不再需要的权限及时撤销。
建议形成固定习惯：小额专用交互钱包与长期保管钱包分离；新协议优先使用精确额度而非无限额度；每次签名前核对 to、spender、数量、deadline 和 verifyingContract；每月导出一次授权清单并记录处置结果。这样即使某个前端、合约或服务出现问题，也能把权限范围和潜在损失控制在更小范围内。
