代币官网和白皮书不一致，应该信哪份？

官网和白皮书不一致时，没有一条“永远信官网”或“白皮书最权威”的规则。先看冲突在回答什么问题：合约现在是什么状态，链上记录优先；平台现在提供什么服务，平台当前页面与正式公告优先；项目原本怎样设计，带版本和日期的白皮书更接近原始意图。

真正要找的不是一份万能文件，而是一条从旧说法到新状态的证据链。把两边原文、发布日期、适用版本和后续执行记录并排放，冲突通常会落进三类：正常更新、范围不同，或尚未解释。最后一类别硬选边，直接标成未确认。

先问“谁有资格回答这个问题”

资料权重取决于问题。白皮书能讲代币为什么设计、计划怎样分配，却未必跟得上合约升级；区块浏览器能显示交易、代码和权限调用，却不知道团队为什么改变计划；交易所公告能确认该平台的上架、迁移或下架安排，却不能替项目方定义所有链上的官方版本。

同一句“官方资料”里可能混着不同发布者。项目博客、基金会文档、DAO 治理论坛、核心开发团队仓库和交易平台都有官方色彩，但它们承担的责任不同。先给每一页写一句权限说明：“它能证明平台在某时点这样安排”，或“它能证明项目方当时这样声明”。别把声明扩大成它证明不了的事实。

版本、发布日期、适用范围要绑在一起

只看页面底部的更新时间不够。网站改了导航、纠正错字，也会刷新日期；PDF 文件名写着最新版，也可能由旧链接继续分发。最有用的组合是版本号、发布日期、变更说明和稳定地址。四项越完整，越容易回答“它从什么时候开始取代上一版”。

项目把文档放在公开代码仓库时，历史更好追。GitHub 官方文件历史说明指出，History 或 Blame 视图可以看到具体行由哪个提交改变；Compare 功能还能比较两个提交或标签。这里的提交记录不是内容一定正确的证明，但它能回答某个数字或地址何时被改、改动说明写了什么。

RSS3 的官方白皮书仓库就是一个清楚例子：仓库同时保留 current 与 v1 目录，并说明白皮书会随项目变化更新。遇到这种结构，应先确认你读的是 current 还是历史版，再看改动有没有治理提案或实现记录承接。旧版仍有研究价值，却不能悄悄冒充当前规则。

• 记录完整网址，别只保存搜索结果标题。
• 下载文件时保留文件名、版本号与页面发布日期。
• 动态网页没有版本号，就保存查看日期和相关公告链接。
• 页面引用另一个文档时，继续打开原始文件，不从转述猜结论。
• 更改涉及合约时，寻找部署、升级、铸币或迁移的链上记录。

很多“打架”，其实是句子状态不同

读资料时把动词分成四种：已经发生、计划发生、有条件发生、估算可能发生。“已部署”需要可查的部署记录；“计划上线”只是一项安排；“治理可调整”表示规则留有变更入口；“预计解锁”则需要继续核假设。把它们都改写成现在时，冲突就会被人为放大。

供应资料尤其明显。Optimism 的治理文档把 OP 的解锁追踪器标成 estimated，也就是估算。若第三方页面把这张表写成精确实时流通，两个页面数字不同，并不能先判官方“错了”；要检查第三方使用的流通定义、更新时间和是否把未领取或国库余额算进去。估算、计划、链上已释放、市场可售不是同一个状态。

还要留意范围。官网可能讲全生态，白皮书讲一条主链，Gate 公告只讲平台支持的那条网络。一个项目有原生币、桥接币和包装版本时，供应或地址不一致可能是对象不同。把每个数字前面补上“哪条链、哪个合约、哪个时点”，许多表面冲突会消失。

从新说法追到执行，才算完成核对

如果官网把最大供应从一个数字改成另一个数字，不能因为网页更新较新就结束。继续问：合约是否允许这个变化，治理是否通过，执行交易是否发生，区块浏览器当前值怎样，平台是否完成对应迁移。新页面是线索，执行证据才说明变化落地到哪一步。

可以用一条四段链来整理：

1. 提出：项目公告、治理提案或新版文档提出什么变化。
2. 授权：谁有权决定，投票或多签条件是否满足。
3. 执行：有没有对应链上交易、合约升级或代币兑换。
4. 承接：钱包、区块浏览器与交易平台是否切换到新资产。

四段不一定全部存在。中心化平台自己的下架决定，不需要项目治理授权；纯品牌文案变化也不需要链上交易。这个框架的作用是防止跳步，不是强行给每个事件凑齐四张凭证。

Gate 上币公告适合证明“Gate 当时宣布支持某个代码、网络或合约”。例如其 SWELL 公开公告把代码、项目网站与 ERC-20 地址并列。若日后项目迁移合约，这份旧公告仍能证明当时的平台安排，却不能单独证明当前充值网络。当前状态要回到当下币种页与最新公告复核。

用一张冲突工作表，避免凭印象选边

别在浏览器标签之间来回切。把冲突双方原句压缩成可比较字段，保留原文链接。下面这张工作表足够应付大多数情况：

示意：旧白皮书写“代币将在 Ethereum 发行”，新官网列出 Base 地址。不能直接宣布项目换链。工作表先记为对象可能变化，再找迁移公告、旧合约处理办法、Base 部署交易和平台支持网络。若这些都没有，就把结论停在“官网新增 Base 地址，旧白皮书仍写 Ethereum，关系未获解释”。

对于金额和供应数字，同样保留原单位。不要一边是枚数、一边是百分比，就靠猜测分母凑成一致。需要换算时，把公式和公开输入写出来，并标明“示意”或“按该页口径计算”。不能复算的数字不进最终结论。

别让页面更新把旧证据抹掉

动态官网可能直接覆盖旧内容，所以发现冲突时先保存原句、页面标题、完整网址和查看日期。能下载的 PDF 保留原文件名；代码仓库记录提交或标签；治理帖子记录提案编号与最终状态。截图适合证明当时看见的排版和文字，却不方便搜索，也可能漏掉折叠内容，因此还要抄下关键原文所在段落。

保存旧版不是为了抓项目“前后不一”。正常项目也会改路线、迁移合约或调整治理。它的价值在于判断改变是否被解释、从哪一刻生效、旧资产怎样承接。若页面后来消失，你仍能说明自己的判断依据，而不是只剩一句“我记得以前不是这样”。

证据包里不要放助记词、账户余额、KYC 页面或私聊中的个人资料。公开研究只需要公开页面和链上标识；涉及平台账户的当前状态，由本人在官方界面重新确认。

多语言页面还会制造另一种假冲突。中文页可能落后于英文主文档，地区站点也可能适用不同产品规则。不要因为语言更熟就默认它更新。比较各页明确日期、版本和适用地区；若项目说明某种语言仅为便利翻译，解释冲突时应回到它指定的控制版本，同时把中文页仍未更新这件事记下来。

如果资料被无声改动，可以把“没有变更说明”本身列为限制，但别据此断言对方恶意隐瞒。研究者能确认的是页面前后内容不同，动机需要另有证据。

什么情况下可以暂时采用一份，什么情况下应停手

如果新版资料有明确版本、变更说明、授权记录和执行证据，旧资料也被标为历史版本，可以采用新版，同时在笔记里保留过渡说明。如果两份资料讨论的网络或时间不同，就分别使用，不必判一份为假。如果只有页面新旧，没有解释链，最合适的标签是“未确认”。

涉及代币身份、兑换比例、截止时间、提现网络和可增发权限时，未确认就足以暂停操作。这些不是可以靠市场情绪补齐的细节。尤其当客服转述、社交帖子与正式公告冲突时，不要用私聊答案覆盖公开规则；请对方给出可公开访问的正式页面，再核适用地区、产品与日期。

下一步取决于冲突类型。地址不一致，回到网络与合约地址核对；供应口径不一致，拆读代币流通量、总供应量、最大供应量有什么区别？；项目宣布换币，则按更名、换币与合约迁移追公告和执行；平台服务发生变化，再看交易与提现截止时间。

最后把结论写窄一点。写“截至查看日，项目 current 文档采用新地址，旧版仍可查，链上部署记录与平台公告一致”，比“官网永远比白皮书可信”有用得多。前一句允许别人复核，也给未来更新留下位置；后一句只是在制造新的误导。