读懂代币提案的状态标签：Draft、Review、Last Call、Final 分别意味着什么

为什么“标准号”本身信息量很少

NFT 文章里经常出现“本项目遵循 ERC-7432”“采用 ERC-4907”这样的句子。但标准号只说明有这么一份文档，不说明它成熟到什么程度。以太坊改进提案体系里，每个提案都有一个由 EIP-1（本身是一份持续维护的 Living 文档）定义的状态字段，状态才是判断“能不能依赖”的第一信号。

各状态的准确含义

按 EIP-1 的定义，提案在仓库里的状态依次有这些取值：

• Idea： Ideas 阶段的想法，尚未进入仓库，不被正式跟踪。
• Draft（草案）：格式合格后被编辑合入仓库的第一个正式阶段。文本可能继续大幅改动。
• Review（评审中）：作者声明文档准备好接受同行评审。规范趋于稳定，但仍可能修改。
• Last Call（最后征询）：作者认为规范稳定后开启的最后评审窗口，进入时会设置一个通常两周左右的截止日期。期间若出现必须的规范性修改，会退回 Review。
• Final（最终）：规范定稿，此后只应做勘误和非规范性澄清。对开发者来说这是“可以安全写死接口”的信号。
• Stagnant（停滞）：处于 Draft、Review 或 Last Call 的提案如果超过六个月不活跃，会被移入此状态；作者或编辑可以把它复活回原状态，不复活则可能永远停在那里。
• Withdrawn（撤回）：作者主动撤回，状态有终局性，不能再以同一编号复活；若想法日后再提，视为新提案。
• Living（常设）：设计上持续更新的特殊状态，最典型的例子就是描述流程本身的 EIP-1。

需要澄清一个常见误读：状态衡量的是“文档过程”，不是“链上采用率”。一个 Final 的标准可能用者寥寥（比如不少冷门扩展），一个 Draft 也可能在某个生态里事实通用。反过来，看到 Final 也不要自动等于“钱包和市场都支持”——那仍然是采用问题，不是文档问题。

评估一个 NFT 相关标准的正确姿势

把两组信息合起来读：

1. 文档状态：到 eips.ethereum.org 或 ERC 仓库查该标准的 status 字段。Final 表示接口不会再改；Draft 或 Review 表示按它的接口写集成逻辑要有返工准备；Stagnant 意味着生态动力存疑。
2. 采用证据：钱包和主流市场是否识别它的接口标识（ERC-165 探测）、区块浏览器能否正确展示、有没有公开的参考实现和测试套件。文档状态加采用证据，才拼出“兼容现状”。

举个例子：查一枚带“租赁”功能的 NFT，先确认它引用的是 Final 状态的 ERC-4907 还是 Draft 状态的 ERC-7507，再去验证钱包能否读出相应字段。两条检查都通过，功能才既稳定又可见。

对内容读者的提醒

媒体文章引用状态时容易出错：把“提案存在”写成“行业标准”，把 Stagnant 写成“已被淘汰”（准确说法是不活跃、可复活），或者引用过期状态（文档会迁移，注意查看当前仓库文本）。看到绝对化的“官方标准”“合规标准”表述，回仓库核对一次 status 字段只需几秒钟，这是读 NFT 技术新闻时性价比最高的习惯。

一个容易被忽略的对照组

同样值得记住的是“标准成熟、工具缺席”的组合：比如一份 Final 状态的接口提案，文档无可挑剔，但主流市场不调用它、钱包不识别它的接口标识，用户端看到的效果和不存在只差一个报错信息。评估方法很朴素——打开该标准在仓库里的实现列表或讨论帖，看最近一次第三方集成是什么时候；再看两个头部市场的支持页面有没有出现这个编号。两边都空白的标准，哪怕状态是 Final，也应该在脑中标注为“文档已定，采用未至”。这类落差在 NFT 扩展类提案中格外常见，因为 ERC 标准的通过门槛考察文档质量，而集成成本由钱包和市场承担，两拨人的节奏天然不同步。

风险提示：标准状态与采用情况会随时间变化，本文所述状态定义以 EIP-1 当前文本为准；本文不构成任何投资建议。