neonewstoday.com
Neo co-founder Erik Zhang has published NEP-33, the third Neo Enhancement Proposal he has put forward in two weeks. The standard defines a URI-based transport mechanism that allows native applications to invoke wallet applications for authentication, completing a three-layer stack that standardizes how users sign in with their Neo wallet.
NEP-33 follows NEP-20, which established the cryptographic authentication rules, and NEP-21, which defined a unified interface for dApps to communicate with wallet providers. Where those two standards handle authentication logic and wallet capabilities, NEP-33 addresses the entry point: how one application hands off an authentication request to a wallet and receives the result.
What this enables
Before NEP-33, there was no standardized way for a mobile or desktop application to invoke a Neo wallet for authentication.
Each wallet and application implemented its own invocation and callback format, creating fragmentation. NEP-33 introduces neoauth://, a custom URI scheme that gives native applications a universal “Sign in with Neo” entry point. The operating system routes the request to a compatible wallet, which returns the result via a callback URI.
Developers building on Neo can now integrate wallet authentication without writing wallet-specific code for each provider.
Additionally, NEP-33 has been designed with forward compatibility in mind. In a comment on the proposal’s GitHub pull request, Zhang addressed a question about whether separate URI schemes should exist for different Neo network versions:
Since the address formats of N3 and N4 are the same, there is no need to distinguish them. And this is just a transport layer protocol. There is a network negotiation process in NEP-20.
The design keeps the neoauth:// scheme network-agnostic, with network selection handled at the NEP-20 layer.
How NEP-33 works
An application constructs a request URI using the neoauth:// scheme, embedding a URL-encoded NEP-20 challenge payload and a dApp identifier. The operating system routes this to a registered wallet application, which can be a generic target (delegating wallet selection to the OS or user) or a specific wallet implementation.
The wallet decodes and validates the payload, displays the authentication details (including the requesting domain) to the user, and requires explicit approval. If the user approves, the wallet generates a NEP-20 response payload and returns it via a callback URI using the dapp:// scheme. If the user rejects the request or an error occurs, the wallet returns a structured error response through the same callback mechanism.
All authentication verification follows NEP-20’s cryptographic rules, meaning the requesting application must verify the returned signature rather than trusting the callback URI itself as proof of authentication.
NEP-33 is not redefining what authentication is or how it functions, rather it brings that capability into the interaction flow between dApps and wallets.
Security model
Because custom URI schemes do not guarantee confidentiality or application identity, NEP-33’s security relies entirely on NEP-20 signature verification.
The standard requires wallets to display the requesting domain clearly to protect against phishing, enforces unique single-use nonces with a recommended five-minute expiration to prevent replay attacks, and mandates explicit user approval before any signature is produced.
NEP-33 is designed exclusively for one-time authentication flows. It should not be used for transaction signing, asset transfers, smart contract invocation, or session-based authorization.
The full announcement can be found at the link below:
https://x.com/erikzhang/status/2042931327943741471