什么是 DYOR？

DYOR 是“Do Your Own Research”的缩写，中文常译为“自行研究”。在加密资产语境中，它指不直接把宣传、帖子或他人的结论当成事实，而是自己查找原始材料、交叉核对证据，并把已经确认的信息与仍然未知的部分分开。

DYOR 不是一种统一认证，也不是保证项目可靠或避免损失的方法。它更像一套信息核对过程：先明确某项说法具体声称什么，再判断哪些资料能够支持它、资料是否仍适用于当前版本，以及哪些结论只是推测。研究结果也不是简单的“可以买”或“不能买”标签。

自行研究从一条可以核对的主张开始

“这个项目很好”“社区很强”或“技术领先”都很难直接验证。更具体的主张才知道去哪里找证据，例如：

• 某个地址是不是项目当前使用的代币合约；
• 代币总量能否增加，谁有增发权限；
• 合约能否暂停、升级或冻结某些操作；
• 页面显示的交易量来自哪些市场和时间范围；
• 某份审计报告检查的是哪个代码版本；
• 某项合作、集成或产品功能是否得到相关各方确认；
• 宣称已经上线的功能是否能在代码、界面或链上活动中找到对应记录。

先写清主张还能避免把不同问题混在一起。合约源代码已经公开，不等于代码没有缺陷；团队身份已经公开，不等于产品能够兑现全部计划；链上有人交易，也不等于这些交易来自独立用户或具有持续需求。

不同主张需要不同种类的证据

没有一种来源能够回答所有问题。研究时常见的证据可以分成几类：

“官方来源”适合确认项目自己声称什么，但它仍然是项目方发布的材料。独立来源可以提供不同视角，也可能引用错误或过时信息。可靠结论通常来自多个来源对同一具体主张的相互印证，而不是给某个网站贴上“可信”标签后接受它的全部内容。

先核对网络和合约地址，再看名称与图标

链上代币可以重名，也可以使用相同的图标和交易代码。识别一项数字资产时，网络名称和合约地址通常比展示名称更有区分力；对于非同质化代币，还可能需要核对代币编号。

项目网站或文档可以提供合约地址，区块浏览器则可以显示这个地址的部署交易、余额、代币转移和合约调用。Ethereum.org 对区块浏览器的介绍列出了区块、交易、账户、合约和代币等常见链上数据。

地址仍要交叉核对。仿冒网站也可以展示一个真实存在的合约，搜索结果和社交媒体帖子也可能指向同名假代币。页面上的“已验证”标记具体表示什么，要看该服务的验证规则，不能只凭图标或标签下结论。

链上记录能证明发生了什么，不能自动解释为什么

区块链可以记录某个地址在何时发起交易、资产怎样转移，以及合约状态怎样变化。这类记录适合核对供应量变化、资金流向、治理投票和特定功能是否被调用。

链上记录通常不会直接告诉读者地址背后的真实身份，也不能单独解释一笔交易的目的。一个人可以控制多个地址，多个人也可以通过同一个托管平台地址操作。地址数量不能直接等同于用户数量，代币转移次数也不能直接等同于实际采用程度。

链上数据还可能经过索引、标签和计算后再展示。链上可独立核对的交易字段属于协议记录，服务提供的地址标签、持有人分类和统计图表则包含额外判断。使用这类结果时，需要查看计算口径、覆盖网络和更新时间。

已验证源代码只说明代码与部署版本相符

智能合约是部署在区块链上、按代码执行操作的程序。在 Ethereum 等使用以太坊虚拟机（Ethereum Virtual Machine，EVM）的网络中，源代码验证通常会按相同设置重新编译公开代码，再与合约地址上实际运行的机器代码进行比较。机器代码是供网络直接执行的编译结果。Ethereum.org 的合约验证说明把这种匹配检查与形式化验证分开；形式化验证是用数学方法检查程序是否满足预先指定的性质。其他网络需要按各自的部署和版本机制核对程序代码。

因此，“合约代码已验证”通常说明读者看到的代码能够对应链上程序，不表示代码已经过安全审计，也不表示程序没有逻辑缺陷。公开代码中的注释和变量名称也可能带有误导性，实际行为要看可执行逻辑。

还要确认入口合约是否会把请求转发给另一份实现代码。这类入口常称为代理合约。可升级代理允许具有相应权限的账户更换实现代码；OpenZeppelin 的代理合约文档说明了代理、实现合约和升级管理员怎样配合。只阅读代理地址本身的短代码，可能漏掉真正执行功能的合约和升级权限。

代码仓库展示开发记录，不等于线上功能

公开代码仓库可以显示文件、提交记录、版本标签、问题讨论和贡献者。提交是一次被记录的代码变更，版本标签则常用来标记某次发布。它们可以帮助核对项目是否持续修改代码、某项功能何时加入，以及不同版本之间改了什么。

GitHub 的仓库活动说明展示了推送、合并、强制推送和分支变化等记录。活动多不等于代码质量高，提交少也不一定表示项目停止；自动更新、复制代码和不在公开仓库进行的开发都会影响表面数据。

仓库代码还要与实际部署版本对应。研究某个链上应用时，应查看发布标签、部署记录或合约验证信息是否能把仓库中的版本与链上地址连接起来，否则只能确认“仓库里存在这份代码”，不能确认线上正在运行它。

审计报告要看范围、版本、日期和处理结果

安全审计是专业人员在一定范围和时间内检查代码、设计或运行假设，并记录发现的问题。阅读报告时，重要的不只是“做过审计”，还包括：

• 受检文件、合约地址或代码提交是否写清；
• 审计完成后代码是否又发生重大变化；
• 哪些组件、外部依赖和运行条件不在检查范围内；
• 报告发现了哪些问题，项目如何回应；
• 修复是否经过复核，未修复问题是否仍然存在；
• 报告是否由审计方公开，链接是否指向完整文件。

审计不能证明不存在未知缺陷。OpenZeppelin 的上线准备文档也说明审计不能保证代码没有错误。把旧版本、局部模块或尚未复核的报告当作整个系统的安全证明，会超出报告本身能够支持的范围。

白皮书说明计划，不等于完成记录

白皮书通常介绍项目要解决的问题、设计思路、代币安排或发展计划。它适合用来确认项目方公开提出了什么目标，却不能单独证明目标已经实现。

研究时可以把白皮书中的可验证主张分别与当前文档、代码发布、链上部署和实际功能核对。路线图日期已经过去但没有对应发布记录、代币规则与已部署合约不一致，或文档长期没有更新，都是需要继续确认的差异；它们本身不必然证明项目存在欺骗。

文档还可能描述旧版本。页面发布日期、最后一次修改、适用网络和版本号，决定一段说明能否用于当前系统。没有日期或版本信息时，应把结论标为不确定，而不是自行补全缺失背景。

社交媒体热度不是事实证明

点赞、转发、群组人数和搜索热度描述内容传播情况，不能直接证明技术功能、用户身份、资金安全或市场需求。账号可能被仿冒、盗用，互动也可能来自自动程序或协调推广。

社交媒体更适合用来发现需要核对的主张，而不是作为主张的唯一证据。涉及合约地址、版本更新、安全事件或外部关系时，可以回到项目文档、代码仓库、链上记录和相关各方原始声明进行确认。

来源是否披露利益关系也很重要。内容作者可能持有相关代币、接受报酬、参与项目或通过推荐链接获益。没有披露不一定证明内容错误，但读者无法据此判断潜在利益冲突，证据权重需要与可独立核对的材料分开。

一个完整核对过程会保留未解决的问题

DYOR 的结果不应只有一串链接，还应说明每条证据回答了什么。一个通用的信息核对过程可以这样记录：

1. 把模糊评价改写成一条具体、可验证的主张；
2. 找到最接近该主张的原始材料，并记录发布者、日期和版本；
3. 使用链上记录、代码、完整报告或另一独立来源交叉核对；
4. 区分直接观察到的事实、根据事实作出的推断和个人观点；
5. 写下来源之间的冲突，以及仍然缺少什么证据；
6. 当合约、权限、版本或外部关系无法确认时，保留“不确定”，不要把空白当成肯定或否定结论。

同一研究结论会随时间失效。合约可以升级，管理权限可以转移，文档和审计范围可以改变，流动性与代币分布也会变化。引用动态信息时，需要保留数据时间点，不能把一次检查写成永久结论。

常见警示信号需要继续核对，而不是直接定罪

下面的情况表示现有资料不足或存在冲突，需要进一步核对：

• 合约地址只出现在无法确认身份的帖子或私信中；
• 名称、图标和交易代码相同，但所属网络或合约地址不同；
• 页面宣称代码开源，却没有与部署版本对应的仓库或验证记录；
• 宣称经过审计，却不提供完整报告、检查版本或修复状态；
• 白皮书中的供应或权限说明与当前合约行为不一致；
• 使用“保证收益”“没有风险”或制造紧迫感的语言；
• 宣称获得外部机构支持，但相关方没有可核对的对应说明；
• 管理员能够升级、暂停或转移资产，但公开说明没有提及这些权限；
• 数据截图没有来源、时间范围或可复查链接；
• 讨论只引用互相转载的文章，最终找不到原始材料。

单个警示信号并不能自动证明项目欺诈。例如，开发团队没有公开全部身份、代码更新较少或合约具有管理员权限，都可能有不同原因。结论需要与具体承诺、技术结构和可核对记录对应。

DYOR 有边界，也不应用来把责任推给受害者

普通读者不可能独立审计全部代码、验证所有团队信息或发现专业攻击。信息可能故意隐藏，界面和账号可能被仿冒，审计和公开数据也可能存在盲区。自行研究只能减少部分信息缺口，不能把所有未知风险变成已知。

“你应该自己研究”也不能替代项目方准确披露重要信息，或为虚假陈述开脱。有人因误导、仿冒或技术漏洞遭受损失时，简单指责其“没有 DYOR”忽略了信息不对称和专业门槛。

当问题需要专业技术、安全、财税或法律判断时，普通的信息核对无法覆盖同样的证据范围和责任。

常见问题

看过白皮书就算完成 DYOR 吗？

不算。白皮书主要说明项目方的目标和设计。仍需核对当前代码、部署、权限、链上活动、审计范围和文档版本是否与这些说明一致。

合约代码已验证，就代表安全吗？

不代表。源代码验证主要确认公开代码与部署的机器代码相符，不会自动发现所有逻辑缺陷，也不会消除升级权限、外部依赖和操作风险。

链上数据不会造假，所以结论一定可靠吗？

链上交易记录可以验证，但地址标签、身份归属、用户数量和交易动机通常需要额外解释。计算口径错误或把多个地址误当成多个用户，也会产生错误结论。

匿名团队一定不可靠吗？

不能只凭是否匿名下结论。公开身份可以增加可核对信息，但不能证明代码、安全或承诺；匿名则会减少身份和履历方面可验证的材料，需要明确记录这一信息缺口。

DYOR 能告诉我应该买哪种资产吗？

不能。DYOR 是核对信息、来源和未知项的过程，不会自动得出适合某个人的买卖或持有结论，也不能预测未来价格。

相关词条

继续了解数字资产、智能合约、加密代币和私钥，或返回加密货币术语表。

参考来源

• Ethereum.org：Block explorers——区块浏览器可展示的区块、交易、账户、合约和代币数据。
• Ethereum.org：Verifying smart contracts——源代码匹配、机器代码与形式化验证之间的区别。
• OpenZeppelin Docs：Upgrades Plugins FAQ——代理、实现合约和升级管理员的关系。
• OpenZeppelin Docs：Preparing for mainnet——审计、源代码验证、管理权限和审计局限。
• GitHub Docs：Using the activity view——仓库变更、推送、合并与分支活动记录。