先明确核验对象与适用范围
“TBT”这一名称本身不足以唯一识别项目。当前参考正文没有提供可将该名称对应到具体项目的专属证据，因此不能确认其所属网络、合约实现或运行状态。以下方法适用于区块链项目资料的通用核验，不构成对某个TBT项目的事实认证。
核验应从具体主张开始：资料是在解释技术标准，还是声称某个项目已经采用该标准？前者可以由通用文档支持，后者还需要连接项目身份与实际实现的证据。
两个独立来源分别能说明什么
OpenZeppelin Contracts的ERC-20文档说明了同质化代币的基本实现，并用示例展示余额记录、转账和初始铸造。文档还解释，decimals用于显示单位换算，合约内部仍以整数计算。这些内容可帮助理解代币字段，但示例中的GLD不能作为TBT的部署证明。
Bitcoin Developer Guides的区块链章节解释了节点验证、区块哈希链接与交易记录，并指出区块高度不能充当全局唯一标识。这些原理适用于理解比特币账本，不能直接用来证明其他网络采用相同的共识或交易模型。
让来源与待核验主张对应
核验“采用ERC-20”之类的说法，需要明确所属网络和具体合约，再检查实际实现是否支持相应描述。引用OpenZeppelin文档只能解释标准实现的机制，不能证明项目使用了该代码，更不能证明其没有额外修改。
核验链上记录时，应保留网络、交易标识或区块哈希等定位信息，而非只依赖名称、截图或区块高度。记录能够定位后，还需区分“发生了某笔交易”和“交易证明了某项业务主张”，两者需要的证据不同。
常见问题与判断边界
两个独立来源是否足够？数量不能替代相关性。上述两份文档分别讨论代币合约与比特币账本，不能因为来源独立，就视为共同证实了TBT项目。只有来源确实支持同一项待核验主张时，交叉印证才有意义。
余额数字不同是否意味着资料造假？应先检查单位。ERC-20的原始整数与界面显示金额可能因decimals换算而不同；具体精度须以对应合约为准，不能把示例或默认值直接套用。
链上可查是否等于项目可信？链上记录支持的是相应链上行为的核验，无法单独确认团队身份、线下业务或全部代码的安全性。证据缺失时，应保留“尚未确认”的判断，避免把通用技术说明扩展为项目背书。