一、余额模型是否表达了可花费状态
讨论区块链数字货币设计有哪些常见问题，首先要区分交易层与共识层：前者处理资产如何被授权使用，后者处理网络如何形成一致的账本状态。两层相互依赖，但不能互相替代。
Bitcoin Developer Guides 的交易说明以未花费交易输出（UTXO）解释余额：普通交易输入引用已有输出，花费者提供满足该输出条件的数据。这里的余额是输出金额的汇总，不是一个可随意修改的数字。
对采用 UTXO 的系统，设计检查不能停留在余额加减，还需考虑输出引用是否准确、是否已经被花费，以及花费条件是否满足。这一模型不能直接套用于所有数字货币。
二、签名是否被误当成完整验证
上述交易指南还说明，签名用于证明授权并约束被签署的交易数据，脚本则负责检查相应条件。比特币脚本限制表达能力，以提高执行行为的可预测性。
常见误区是认为签名正确就代表整笔交易有效。授权检查只回答某项花费是否获得许可，不能独自证明输入仍然可用、金额关系合法或交易符合其他规则。设计上应分别定义各项检查，避免把全部安全责任交给签名。
脚本功能也并非越丰富越好。需要复杂授权时，应同时评估验证成本与失败条件；表达能力受限不等于没有风险，更不保证任意输出都能被成功花费。
三、是否把资源证明当成完整共识
Ethereum 的共识机制说明区分了完整共识与工作量证明、权益证明：后两者承担抵抗女巫攻击和选择出块者等作用，完整机制还涉及协议规则、分叉选择与激励。
因此，设计文档仅写“采用 PoW”或“采用 PoS”并不足够。还需要说明谁能提出区块、节点如何验证，以及出现竞争区块时如何选择账本分支。只解决参与资格，并没有解决全部一致性问题。
四、分叉选择是否使用了错误指标
Ethereum 的相关说明指出，比特币的链选择依据累计工作量，而不是单纯比较区块个数；权益证明中的相关投票权重则与质押权益有关，不能简单理解成节点数量表决。
这意味着设计时必须准确说明“更长”“更重”和“多数”的计量方式。若把节点数量直接当成安全权重，就可能忽略单个参与者创建多个身份的问题。不同协议的权重规则与确认语义也不能混用。
五、经济激励与适用边界是否清楚
经济约束提高作恶成本，但不能替代交易验证，也不等于系统绝对安全。设计需要区分正常参与的激励、违规行为的处理，以及网络通信异常时的行为。
这些问题主要适用于交易结构与共识机制的基础评估。某个项目即使使用相同术语，也不能据此认定其实现可靠；仍需核对实际验证规则、权限边界及异常处理是否与设计一致。