Neo联合创始人Erik Zhang于2026年7月5日发布NEP-33标准，这是他在两周内提出的第三个Neo增强提案（NEP）。该提案定义了一种基于URI的传输机制，允许原生应用程序调用钱包应用进行身份认证，从而完成了标准化用户使用Neo钱包登录的三层堆栈。
三层认证架构完成闭环
此前Zhang发布的NEP-20确立了密码学认证规则，NEP-21定义了去中心化应用（dApp）与钱包提供商通信的统一接口。NEP-33则定位为入口层，解决一个应用如何将认证请求传递给钱包并接收结果的问题。至此，Neo生态形成了从认证逻辑、钱包能力到交互入口的完整标准体系。
在NEP-33推出之前，移动端或桌面端应用调用Neo钱包进行认证缺乏标准化方式，每个钱包和应用各自实现调用和回调格式，导致碎片化问题。NEP-33引入 neoauth:// 自定义URI方案，为原生应用提供了通用的“Sign in with Neo”入口。操作系统将请求路由到兼容钱包，钱包通过回调URI返回结果。开发者无需为每个钱包提供商编写特定代码即可集成钱包认证。
网络无关性与前向兼容设计
NEP-33在设计上考虑了前向兼容性。在提案的GitHub Pull Request评论中，Zhang回应了关于是否应为不同Neo网络版本设立独立URI方案的问题：“由于N3和N4的地址格式相同，无需区分。这只是一个传输层协议，网络协商过程已在NEP-20中处理。”因此，neoauth://方案保持网络无关性，网络选择由NEP-20层处理。这意味着未来Neo升级至N4网络时，现有集成无需修改URI方案。
工作原理与安全模型
NEP-33的工作流程如下：应用构造使用 neoauth:// 方案的请求URI，嵌入经URL编码的NEP-20挑战负载和dApp标识符。操作系统将该请求路由至已注册的钱包应用（可以是通用目标，由OS或用户选择钱包，也可以指定具体钱包实现）。钱包解码并验证负载，向用户显示包括请求域名在内的认证详情，并需要显式批准。若用户批准，钱包生成NEP-20响应负载并通过 dapp:// 回调URI返回；若拒绝或发生错误，则通过同一回调机制返回结构化错误响应。
所有认证验证遵循NEP-20的密码学规则，请求应用必须验证返回的签名，而非将回调URI本身视为认证凭证。安全模型方面，由于自定义URI方案无法保证机密性或应用身份，NEP-33的安全完全依赖于NEP-20签名验证。标准要求钱包清晰显示请求域名以防止钓鱼攻击，强制使用一次性nonce（推荐5分钟过期）防止重放攻击，并在生成签名前要求用户显式批准。
NEP-33专门用于一次性认证流程，不应被用于交易签名、资产转账、智能合约调用或基于会话的授权。
对Neo生态的影响
NEP-33的发布标志着Neo在Web3身份认证领域迈出了重要一步。通过统一钱包调用协议，Neo有望降低dApp开发者的集成门槛，提升用户体验。类似以太坊的EIP-4361（Sign-in with Ethereum）标准，Neo如今拥有了原生的“Sign-in with Neo”能力，这将吸引更多关注去中心化身份的应用迁移至Neo生态。分析人士认为，标准化的认证堆栈有助于Neo在竞争激烈的公链市场中形成差异化优势，尤其是在企业级应用和游戏领域，安全且便捷的登录体验是关键需求。随着NEP-20、NEP-21和NEP-33的全面落地，Neo钱包生态的互操作性将得到显著增强。