先界定资料能够证明什么
区块链新币风险的资料来源如何核验，关键在于让结论与证据对应。技术文档能够解释风险机制；涉及某个代币的判断，还需要对应合约和权限状态的证据。本文讨论智能合约安全资料的核验，不覆盖新币的全部风险。
核对来源身份与适用版本
核验时应保留原始域名、页面路径、文档版本及引用段落，区分原站文档、转载和项目宣传。ethereum.org 的智能合约安全文档强调访问控制、测试和独立审查，并指出审计不能发现所有缺陷。这些原则可以帮助确定核验问题，不能为具体新币背书。
OpenZeppelin Contracts 的访问控制文档解释了所有者、角色及角色管理员的关系，也指出默认管理员具有较高权限。引用其中机制时，需要核对项目实际使用的版本和实现；名称相同不足以证明行为相同。
把安全声明转化为可核对的问题
遇到“已放弃权限”的声明，应明确放弃的是所有者权限，还是也涉及其他管理角色。所有者权限被移除后，角色管理员或升级权限是否仍存在，需要分别核验，不能从单一状态推导全部权限均已消失。
遇到“不能增发”的声明，应检查增发功能的权限条件、角色持有人，以及谁能重新授予角色。核验记录应注明对应网络、合约地址和状态时点，避免把不同合约或不同时期的证据混在一起。
审计结论需要对应代码范围
核对审计资料时，应确认报告发布方、审查范围、代码版本、问题处理情况，以及这些内容与部署合约的对应关系。仅展示审计标识，无法说明哪些代码经过检查；后续修改也需要另行判断是否仍在报告覆盖范围内。
多个页面重复同一份声明，并未增加独立证据。技术文档适合解释机制，审计报告适合说明特定审查结果，合约状态适合核对权限配置，各自承担不同的证明任务。
常见问题与结论边界
多签是否意味着权限风险消失？多签增加了敏感操作的签署要求，但仍需核对签名门槛、管理范围和实际控制关系。多个角色也可能由同一账户持有，角色数量不能直接证明权力分散。
查不到权限持有人是否代表无人持有？基础 AccessControl 不提供链上成员枚举，可能需要结合角色授予和撤销事件核对。证据不足时，应明确写出尚未核实的事项；未发现问题与已证明安全之间仍有距离。