Articles

• 同一 spender 多次调整授权额度时，怎样记录完整变化顺序
• 授权额度高于当前代币余额时，为什么不能只按现有余额评估权限范围
• 代币授权长时间没有使用时，为什么不能假设它会自动过期
• 两个授权查询工具显示不同额度时，应该先核对哪些条件
• 审查代币授权时，怎样落实最小范围原则
• 撤销授权交易显示已确认后，为什么仍应重新读取 allowance
• 代币已经授权给 spender 后，为什么后续支出不一定再次弹出批准窗口
• 授权额度看起来异常巨大时，为什么要先核对 token decimals 和显示单位
• 钱包切换网络后，为什么授权清单要重新核对
• 为什么授权清单至少要同时记录账户、代币、spender和网络
• 签署 Permit 类消息以前，为什么要看域名、链和有效期
• 一份授权核对记录需要包含哪些字段
• 代币授权和实际转账是两类事件，为什么不能在记录中混成一笔
• 批量撤销多个授权时，为什么仍要逐笔检查
• 清除浏览器数据或重装钱包后，为什么旧代币授权仍可能存在
• 撤销后工具仍显示旧额度时，怎样区分缓存、网络错误和真实未撤销
• 应用更新后 spender 地址改变，应该怎样重新核对
• 连接钱包、签消息和代币授权有什么不同
• 钱包里断开网站连接后，为什么代币授权可能仍然有效
• 断开网站连接，不等于撤销代币授权
• 断开钱包网站连接以后，为什么仍要单独核对代币授权
• approve交易收据显示失败时，为什么仍要查询授权前后的实际状态
• 授权撤销交易失败后，为什么原有权限可能仍然有效
• 应用更换域名或前端后，为什么要重新核对授权对象
• 从钱包界面隐藏代币以后，为什么既有allowance不会因此被撤销
• 看到历史 Approval 事件时，为什么不能直接当作当前剩余额度
• 误连可疑应用以后，怎样跨账户和网络检查遗留授权
• 同一钱包有多个账户时，授权清单为什么要逐地址核对
• 同一种代币出现多个spender时，为什么每条授权都要独立审查
• 代币授权检查显示为零时，为什么仍不能证明原生资产绝对安全