适用范围与来源分工
本文讨论以太坊上的 ERC-721 类 NFT。其他网络或代币标准需要对应的技术依据，不能直接套用全部字段和接口。核验的核心是让每项结论都有对应证据，并明确证据的边界。
ethereum.org 的交易文档解释签名、交易字段、合约调用及交易进入区块的过程；OpenZeppelin Contracts 的 ERC-721 文档解释独特代币的所有权表示、持有地址查询和元数据接口。两个独立来源分别支持交易机制与代币机制，均不能单独证明某个具体项目的真实性。
交易哈希与交易内容分开核对
交易哈希用于定位记录。核验时需同时明确所属网络，查看发送地址、接收地址、输入数据以及执行结果。提交或广播交易只是生命周期中的环节，不能据此直接写成 NFT 已成功转移；进入区块也需要与执行成功区分。
合约调用中，交易的 to 字段通常指向被调用合约，不能直接当作 NFT 的最终接收地址。value 表示随交易转移的 ETH 数量，也不能脱离合约执行内容直接解释为 NFT 成交价。
用合约和代币编号明确对象
核验对象应落实到网络、合约地址和 tokenId。名称与图片属于展示信息，仅凭外观相同不足以认定是同一枚代币。解释输入数据时还需结合目标合约的接口，不能只凭函数选择器猜测操作含义。
ERC-721 的 ownerOf 可查询指定代币的持有地址，Transfer 事件提供转移相关线索。引用这些信息时，应交代查询状态或对应交易，避免用当前持有地址反推全部历史。文档中的示例合约和事件只用于说明机制，不能充当实际项目的交易证明。
元数据需要单独核验
tokenURI 提供元数据入口，名称、描述和图片等内容可能存储在链外。核验时应区分合约返回的地址与该地址实际返回的内容，不能因为入口来自链上，就认定全部展示内容均已上链。
OpenZeppelin 的示例说明，链外元数据可能被修改。因此，引用图片或属性时需要限定所核对的内容状态；交易记录本身不足以证明这些展示信息始终未变。
常见问题与结论边界
有效签名能否证明项目可信？签名用于验证交易授权关系，不能据此确认作品来源或项目宣传。技术文档是否足够证明某笔交易？文档说明如何理解记录，具体结论仍需对应网络中的实际记录。
可复核的说明应保留来源网址、对象标识和支撑结论的字段。若只有技术文档而没有具体交易证据，结论应停留在机制解释；若只核对了所有权，也不应扩展为元数据真实性或完整交易历史已经得到确认。