先明确来源能证明什么
区块链dao功能的资料来源如何核验，首先要把功能描述拆成可验证的问题：谁可以提案，投票权从哪里来，通过需要什么条件，最后由谁执行。不同问题需要不同证据，不能仅凭一篇介绍文章确认全部功能。
ethereum.org的DAO介绍将提案、投票和共同资金管理作为主要机制，并区分委托投票、自动交易治理及多签治理。这适合解释DAO的基本组织方式，但不能证明某个DAO采用了其中哪种机制。
用技术文档核对实现条件
OpenZeppelin Contracts的5.x治理文档说明，Governor采用模块化设计，投票权来源、计票方式及时间锁可以分别配置。时间锁涉及排队、等待和执行，执行需要相应调用。这类文档能解释软件组件的能力，具体部署是否具备该能力仍需另行核验。
两个独立来源的交叉核对，应关注各自支持的结论范围。概念文章解释治理用途，技术文档解释实现条件；两者内容相容，也不能直接推出某个项目已部署相关模块。
把功能主张连接到部署证据
核验具体DAO时，应将项目公布的网络、合约地址与对应代码、配置联系起来。文档版本应与实际使用的软件版本对应；仅见到某个扩展名称，无法确认它已被启用。
投票功能需要核对投票权来源、计票规则、法定票数及投票期限。资金管理需要核对资产所在地址，以及治理合约、时间锁或多签之间的权限关系。历史提案则可用于比对通过、排队和执行是否形成完整记录。
常见问题：通过是否等于执行
“投票通过就自动执行”需要明确适用条件。在时间锁机制中，等待期结束意味着操作可以执行，仍需执行者触发交易。多签治理还涉及签署者执行社区决定，因此提案通过记录不能单独证明资金操作已经完成。
“规则不可随意改变”也不能理解成所有参数永久固定。治理文档中的设置模块允许通过提案调整部分参数。核验时应分别检查哪些参数可变、更改权限属于谁，以及变更需要经过什么流程。
证据不完整时如何表述
来源核验还应保留页面地址、版本及支撑结论的具体段落，检查摘录是否缺词或截断。若只有概念介绍和组件文档，结论应限定为通用机制及其适用条件；只有取得对应部署、权限和执行证据后，才适合确认具体DAO的功能。