The Trilogy Is Complete: Erik Zhang Drops NEP-33, Neo Wallets Can Now 'Sign In' Everywhere

Neo co-founder Erik Zhang has published NEP-33, the third Neo Enhancement Proposal in a two-week blitz. The standard introduces a URI-based transport mechanism enabling native applications to invoke wallet applications for authentication—completing a three-layer stack that standardizes how users sign in with their Neo wallet. Because apparently, Neo couldn't resist finishing what it started, and we love it for that.

NEP-33 follows NEP-20, which established cryptographic authentication rules, and NEP-21, which defined a unified interface for dApps to communicate with wallet providers. While those two 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. Think of it like the trilogy nobody asked for but everyone secretly needed—complete with exposition, climax, and whatever NEP-33 is.

Before NEP-33, no standardized method existed for mobile or desktop applications 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 providing 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 can now integrate wallet authentication without writing wallet-specific code for each provider. Finally, a universal remote for the Neo authentication theater—and we all know how much developers love not reinventing the wheel every time they want to log someone in.

NEP-33 was designed with forward compatibility in mind. In a GitHub pull request comment, Zhang addressed 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. The scheme remains network-agnostic, with network selection handled at the NEP-20 layer. So the URI scheme won't need a midlife crisis upgrade when N4 rolls around—elegant, or as elegant as crypto standards get.

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 or a specific wallet implementation. The wallet decodes and validates the payload, displays authentication details including the requesting domain, and requires explicit user approval. Upon approval, 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, requiring the requesting application to verify the returned signature rather than trusting the callback URI itself. It's like passing notes in class—the teacher doesn't stop you, but you better make sure your signature at the bottom actually proves you wrote it.

NEP-33 does not redefine authentication—it brings that capability into the interaction flow between dApps and wallets. Think of it as the missing puzzle piece that doesn't change what the puzzle is, just makes it actually solvable without swearing at the picture on the box.

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. In short, it's security through cryptographic rigor and a gentle reminder to users