The Neo Auth Trinity Is Complete: NEP-33 Brings 'Sign In With Neo' to the Masses

Neo co-founder Erik Zhang just dropped NEP-33, the third Neo Enhancement Proposal in his apparent two-week sprint of standards writing that would make a caffeinated developer weep. The new standard defines a URI-based transport mechanism that lets native applications invoke wallet applications for authentication—essentially giving Neo its own "Sign in with Neo" button that won't embarrass you at a conference demo.

This completes a neat three-layer stack that even your project's documentation writer can understand:

• NEP-20: cryptographic authentication rules (the muscle)
• NEP-21: unified interface for dApps to talk to wallet providers (the nervous system)
• NEP-33: the entry point that ties it all together (finally, the doorbell)

Where the first two standards handle the heavy lifting (authentication logic and wallet capabilities), NEP-33 focuses on the handshake—how one app passes an auth request to a wallet and gets the result back. Think of it as the diplomatic protocol nobody talks about but everyone's grateful exists.

The problem it solves

Before NEP-33, integrating wallet authentication meant writing custom code for each wallet. No standardized invocation format existed, so developers juggled compatibility headaches and users dealt with fragmented experiences that made onboarding feel like a part-time job.

NEP-33 introduces neoauth://, a custom URI scheme that acts as a universal "Sign in with Neo" entry point. The OS routes the request to a compatible wallet, which returns the result via a callback URI. It's like having a universal translator for wallet communications—finally, a world where your dApp doesn't need a custom integration guide for every wallet that exists.

Forward compatibility, handled

Zhang addressed questions about separate URI schemes for different Neo network versions in a GitHub comment. His take: N3 and N4 share the same address formats, so there's no need to distinguish them. Since NEP-33 is just a transport layer, network selection happens upstream at the NEP-20 layer, keeping things clean and network-agnostic. Translation: they didn't overengineer this, which is honestly refreshing.

How it works

An application builds a request URI using the neoauth:// scheme, embedding a URL-encoded NEP-20 challenge payload and a dApp identifier. The OS routes this to a registered wallet—either a generic target (letting the OS or user pick) or a specific wallet implementation. The wallet then decodes and validates the payload, shows the user the authentication details (including the requesting domain), and waits for explicit approval. It's basically a very polite bouncer asking for your ID before letting you into the club.

If the user approves, the wallet generates a NEP-20 response payload and fires it back via a callback URI using the dapp:// scheme. Rejection or errors also come through the same callback mechanism, just with a structured error response that won't leave you guessing what went wrong.

Security model

Custom URI schemes don't provide confidentiality or verify application identity, so NEP-33's security hinges entirely on NEP-20 signature verification. The standard includes: