先明确核验对象与适用范围
讨论drc区块链安全风险的资料来源如何核验，首先要确认DRC究竟指什么。仅凭缩写，不能确定项目身份、所属网络或合约地址。这里解释的是智能合约安全资料的通用核验方法，不代表任何具体DRC项目已经存在漏洞或通过安全验证。
核验前宜记录项目全称、网络、合约地址和待核实的说法。例如，“管理员能够增发”与“已经发生非法增发”是两种不同判断，所需证据不能混用。
两个来源分别能支持什么
ethereum.org的智能合约安全文档讨论访问控制、测试和独立审查，强调审计并不能发现全部缺陷。这类说明可用于建立检查方向，不能直接证明某个具体合约安全或不安全。
OpenZeppelin Contracts的访问控制文档解释所有者权限、角色划分及角色管理员。角色分工不等于权限天然分散，核验时还要关注谁能授予、撤销权限。引用其5.x文档前，应确认被讨论代码是否采用相应版本和实现。
从来源名称追溯到证据内容
核验记录应保留发布主体、页面标题、版本标识、相关段落和适用范围。不要只保存搜索摘要、转载截图或“官方认证”等宣传措辞；应检查原始内容是否真正支持被引用的说法。
两个不同发布主体可以提供互补解释，但不能仅凭来源数量认定结论成立。上述两类文档支持通用安全分析，并不是针对DRC的两份独立调查。具体项目判断仍需与对应代码、配置或事件记录建立联系。
把风险描述改写成可验证的问题
面对“权限集中”的说法，可分别核对：哪些操作需要授权，谁持有权限，谁能够调整权限，以及这些信息对应哪个状态时点。不要仅凭代码出现所有者或角色名称，就推断实际控制关系。
面对“使用多签所以安全”的说法，应进一步核对多签是否实际管理目标合约、适用哪些操作，以及权限是否还有其他入口。核验目标不是寻找安全标签，而是确定标签背后的配置是否与结论一致。
审计与测试结论要保留边界
引用审计报告时，应对应报告涉及的代码版本、检查范围、发现项与修复复核情况。若无法确认报告覆盖当前部署对象，结论应限于受审查版本，不能延伸为当前系统的全面安全保证。
测试或形式化验证也应说明检查了哪些性质、采用什么假设。不能把某项检查通过，改写成所有风险都已排除。
常见问题与记录方式
找不到项目级证据怎么办？应标记“尚未核实”，而不是用通用漏洞案例替代证据。不同材料发生冲突怎么办？先比较对象、版本和时间范围，再判断是否真正矛盾。
可按“待核实说法、来源、对应对象、版本或时点、支持内容、尚缺证据”记录。最终明确区分技术原理、已核实事实与待确认判断，让读者能够追溯每项结论的依据。