先确定要核验的设计命题
核验应从具体命题开始，而不是仅判断网站是否可信。例如，余额属于账户状态还是输出汇总，钱包是否等同于账户，输入如何关联被花费的输出。每项命题分别记录支持段落、适用网络和未覆盖情形，才能识别哪些是技术事实，哪些只是应用设计选择。
两个来源分别支持什么
ethereum.org 的账户说明区分外部拥有账户与合约账户，介绍 nonce、balance、codeHash 和 storageRoot，并明确钱包是与账户交互的应用或界面。这支持在模型中区分账户状态与钱包功能，不能据此把钱包、账户和私钥视为同一个实体。
developer.bitcoin.org 的交易指南介绍输入引用既有输出、输出在被花费前作为 UTXO 存在，以及通过 txid 和输出索引定位输出。正文明确暂不讨论 coinbase，并以 P2PKH 展开示例，因此不能把示例中的签名脚本结构推广到所有交易类型。
建立可追溯的证据记录
来源登记宜包含页面标题、完整链接、相关小节、正文快照及实际核验时间。若版本或更新时间不明，应保留未知状态，不推测其适用时间。网页地址只是定位线索，摘录是否完整、是否遗漏前提，也需要单独检查。
这里引用的网页正文可用于概念对照，但尚不能据此确认链接当前全文及其版本状态。涉及协议规则的实现约束，应进一步对照目标网络适用的规范、升级说明和实现测试；在核对完成前，将相应结论标记为待确认。
把来源结论映射到模型
账户说明可支持账户实体及状态字段的概念设计；交易指南可支持交易、输入、输出及引用关系的设计。数据库主键、缓存方式和服务边界则属于工程决策，不应写成文档强制要求。
两份资料适合用于比较账户与 UTXO 两种组织方式，并不相互证明同一条链的细节。跨链系统可以抽取共同业务概念，但应保留各链的状态与验证差异，避免为了统一接口而抹去约束。
适用条件与常见问题
这套方法适用于术语梳理、模型评审和设计依据归档。它不能替代协议一致性测试，也不能单凭教程证明某个具体系统已经正确实现。
常见误区是认为两个来源就能互证、文档出现字段就必须原样建表、教程示例等于完整规则。更可靠的交付物是设计结论与证据的对应记录：写清支持什么、不支持什么，以及尚待验证的边界。