先区分“代码对应”与“代码正确”
研究借贷合约时，最容易混淆的是源代码验证和形式化验证。源代码验证关注公开的 Solidity 等高级语言代码，经过指定编译器版本、优化设置和相关参数编译后，是否得到与链上合约相同的字节码。匹配成功，说明公开代码与该地址实际执行的代码具有对应关系。
形式化验证关注的是代码行为是否满足预先定义的性质，例如利息计算、抵押率检查、清算条件或权限限制是否符合规格。源代码验证并不等于形式化验证，也不等于已经完成安全审计。因此，研究证据应明确写出：某项证据证明的是代码身份、行为性质，还是外部审计意见。
第一步：锁定合约地址和部署上下文
核验应从具体合约地址开始，而不是只看项目网页、接口名称或一段代码。需要记录网络名称、合约地址、部署交易以及研究对象对应的功能，例如借款池、抵押品管理、利率模型、清算模块或价格预言机。相同名称的合约可能部署在不同网络，地址不同，代码和参数也可能不同。
还要区分创建交易中的部署字节码与合约当前的运行字节码。合约部署时，交易数据通常包含编译后的代码以及构造函数参数；部署后，链上地址保存的是可执行的运行代码。验证服务会根据源文件和编译设置重新编译，并将结果与链上代码比较。研究记录应保留这些输入条件，避免把某个版本的源代码误认为所有部署地址都适用。
第二步：检查验证状态和匹配范围
区块浏览器上的“已验证”标记通常表示源代码经过重新编译后，与链上代码在相应范围内匹配。核验时应查看编译器版本、优化器设置、构造参数、库地址以及多文件源代码，而不能只看页面上是否出现一个标签。参数不同可能导致重新编译结果不同，代理或库合约也可能需要分别核验。
还应关注部分匹配与完整匹配的区别。变量名和注释不会影响通常的编译字节码，因此仅比较可执行代码时，存在不同源文件得到相同结果的可能。完整匹配会进一步利用合约元数据及其哈希，核对源文件、编译信息和相关文件指纹是否一致。部分匹配可以作为重要线索，但研究结论应准确描述其范围，不能将其表述为对每一个源文件字节都已确认。
不同工具的核验能力和展示方式存在差异。部分区块浏览器主要提供重新编译和字节码比对；支持元数据匹配的工具还可以核对更完整的源文件指纹，并提供与元数据关联的文件。使用工具时，应查看其匹配类型、网络支持和公开文件内容，避免仅凭第三方页面的摘要得出结论。
第三步：遇到代理合约要追到实现合约
借贷协议常使用代理结构，使用户交互的地址与实际承载业务逻辑的实现合约分离。此时核验入口地址的源代码还不够，必须确认代理指向的实现地址，并对实现合约进行独立核验。还要记录实现地址在研究时的链上状态，因为代理模式可能允许在满足权限条件时更换实现。
常见代理设计会把实现地址存放在特定存储槽中，代理把调用转发给实现合约。透明代理通常在代理侧保留管理员和升级接口；UUPS 模式则把升级逻辑放在实现合约中；信标代理还可能从单独的信标合约取得实现地址。因此，研究证据应覆盖代理、实现、管理员或升级控制者，以及信标（如存在）这几层关系。
升级权限是借贷合约风险判断的重要组成部分。即使当前实现代码已经验证，也不能据此推断未来实现不可更换。应检查升级函数的访问控制、管理员地址或控制合约、升级事件和当前实现地址，并确认研究结论对应的是某个时间点的部署状态。材料只能支持对结构和核验方法的说明，不能据此断言某个具体协议一定安全。
第四步：把代码证据与借贷规则逐项对应
代码匹配后，还需要阅读与资金风险直接相关的逻辑。可按抵押品登记、借款额度、利率或费用计算、偿还、清算、价格读取、暂停机制、资产转移和权限控制等功能建立证据表。每一项结论都应能回到具体函数、状态变量、事件或调用关系，而不是只依据函数名称或项目说明。
研究者还应检查外部依赖。借贷合约可能调用价格预言机、代币合约、利率模型、奖励模块或其他池合约。主合约源代码已验证，并不代表这些依赖的代码、参数和权限也已核验。对于代理、克隆合约或工厂批量部署的实例，还要确认实例所指向的固定实现地址、初始化参数和初始化是否已经完成。
常见问题与适用边界
问：合约显示已验证，是否代表没有漏洞？答：不是。它主要说明公开源代码与链上字节码存在匹配关系，不能替代漏洞分析、形式化验证、审计或对经济机制的审查。
问：看到公开源代码后，是否可以直接按代码理解代理地址？答：不能直接假设。应先识别代理类型，确认当前实现地址及升级权限，再阅读实际执行的实现代码。
问：为什么同一份代码在不同地址不能直接互相证明？答：网络、编译设置、构造参数、库地址、代理状态和初始化数据都可能不同。应以具体地址和具体部署上下文为核验单位。
问：研究报告怎样写得更可靠？答：明确记录地址、网络、核验工具、匹配类型、编译条件、代理链路、升级权限和核验时间点，并把“代码已对应”“规则已审阅”“行为已验证”等不同层次的结论分开表述。