前置条件
- 你能在Etherscan（或对应链的浏览器）上查看该合约的"Read Contract"和"Write Contract"页面。
- 你已确认合约的owner()或DEFAULT_ADMIN_ROLE指向了0x000...dead这类黑洞地址。
项目方放弃所有权，只关掉了"超级管理员"这一个后门。但合约里可能还有其他角色权限，能做同样危险的事。
"放弃所有权"通常指renounceOwnership()被调用，owner变成黑洞地址。但很多项目用的是AccessControl模块，它支持多角色体系。Owner没了，不代表MINTER_ROLE（增发）、PAUSER_ROLE（暂停交易）这些角色也跟着没了。
步骤1：查看"Read Contract"——找出当前所有角色持有者
做什么：在Etherscan合约页面的"Read Contract"标签下，逐一查询高危角色对应的地址。
怎么做：在"Read Contract"列表中找到并点击查询以下函数：
- DEFAULT_ADMIN_ROLE 或 getRoleAdmin：查看是否有地址仍持有管理权限。
- hasRole(role, address)：需要知道该合约定义的具体角色名（如MINTER_ROLE）。如果不知道，找getRoleMemberCount和getRoleMember列出所有持有者。
情况 A：MINTER_ROLE、PAUSER_ROLE、BURNER_ROLE等角色的hasRole查询结果显示为非黑洞地址 → 高危。这些地址仍有权增发代币或暂停交易。操作：此时项目方只是"放弃了自己"，但把权限留给了别人。不应该认为该项目是安全的。
情况 B：所有可查询的高危角色均指向0x000...dead或0x000...000 → 权限基本干净。但还要检查是否存在未列出的自定义角色。
完成标准：你已确认合约中所有公开可查的角色权限，当前持有者要么是黑洞，要么是多签钱包。
高危风险：在Solana生态中，Mint Authority、Freeze Authority、Update Authority是三个独立权限。即使项目方说"放弃所有权"，也只可能对应其中某一项，另外两项可能仍被保留。Mint Authority可以无限增发，Freeze Authority可以冻结任意钱包的代币交易，这种攻击不需要owner身份。放弃所有权不代表放弃所有特权。
步骤2：检查"代理模式"——真正的逻辑在"实现合约"里
做什么：确认该合约是否使用了可升级代理模式（Proxy），如果是，则权限可能在"逻辑合约"而非当前"代理合约"中。
怎么做：在Etherscan页面顶部，看是否有一个"Read as Proxy"或"Upgradeable"标识。如果有，点击"Read as Proxy"实际读取的是逻辑合约的内容。
情况 A：页面显示为"Proxy"或"Upgradeable" → 必须用"Read as Proxy"模式重新执行步骤1。因为权限设置存储在逻辑合约中，而不是代理合约里。
情况 B：页面无代理标识 → 非代理模式，跳过此步骤。
完成标准：确认你查询的权限数据来自该合约的实际逻辑层，而非"壳合约"。
常见失败原因
"放弃所有权"后的合约，owner()字段确实是0地址。但管理员只是"忘记"或"故意保留"了MINTER_ROLE，并在项目后期用该角色增发代币砸盘。只看owner不看其他角色，相当于只锁了大门，却没注意到墙上还有一扇没锁的小门。
操作完成的校验方式
在Etherscan"Write Contract"页面中，检查grantRole和revokeRole函数——如果当前发起地址没有这些函数的调用权限，平台会提示"连接的钱包无权限执行此操作"。这一步可以反向验证你步骤1的查询结果是否准确。
下一步的衔接动作
如果发现可疑角色持有者，在项目社群询问该地址的作用——是"团队预留多签"、"时间锁合约"，还是"已被丢弃但未清理的旧地址"。若对方回答模糊或拒绝说明，按"权限未完全放弃"处理。核验渠道：Etherscan合约页面"Contract"标签下的"Read Contract"和"Write Contract"列表。
