Neo co-founder Erik Zhang has finalized NEP-20, an authentication standard that allows users to log in to websites, games, and applications using their Neo wallet. The standard, which defines a Challenge/Response protocol for address-based identity verification, is aimed at eliminating the need for usernames, passwords, and separate account registration. Now, several years after it was first proposed, the standard has now reached “Accepted” status in the Neo Enhancement Proposals repository.
NEP-20 was first proposed in March 2021, with active review and revisions resuming in late March 2026. Contributors from across the Neo developer community participated in the finalization process.
The problem with platform-controlled identity
In most internet applications, identity depends on the platform. Users create accounts managed by the service, credentials are stored on the service’s servers, and users have only indirect control over their own identity data. This creates two recurring issues: centralized security risk (a single breach can expose an entire user base) and fragile dependence on third-party login providers whose APIs, policies, and availability can change without warning.
Login services like “Sign in with Google” were designed to simplify onboarding, but applications often require users to bind a phone number or email afterward because no product can fully trust an external identity solution it does not control.
How NEP-20 works
NEP-20 shifts authentication from platform verification to user proof. Instead of a centralized service confirming identity, users prove ownership of their Neo address directly through a cryptographic signature.
The process follows a Challenge/Response interaction, which is a security mechanism where a system issues a unique “challenge” to a device that then needs to generate a “response” using a shared secret, or a password, to prove their identity. NEP-20’s process will follow accordingly:
- 1) The application server generates a Challenge payload, a structured JSON request containing the server’s domain, a one-time nonce (a random number valid for a recommended five minutes), a timestamp, supported signature algorithms, and the Neo network identifiers the authentication applies to.
- 2) The user’s wallet presents key details for confirmation, including the requesting domain and action. If the user approves, the wallet signs the Challenge data and returns a Response payload containing the user’s public key, address, nonce, timestamp, and signature.
- 3) The application verifies the signature against the returned public key and address, checks that the domain, nonce, and timestamp are valid and consistent, and, if everything matches, completes authentication.
No password is transmitted, no credentials are stored on the server, and no on-chain transaction is required. Identity is proven through a valid signature alone.
Security model
NEP-20 incorporates several constraints to prevent common attack vectors:
- Domain binding requires the Challenge to include the server’s domain, which the wallet must verify and display to the user before signing. This mitigates phishing and cross-site misuse.
- Nonce expiration ensures each authentication request uses a unique, time-limited random number. The server must prevent nonce reuse, blocking replay attacks.
- Timestamp validation in both the Challenge and Response allows each side to verify time synchronization and detect stale or replayed requests.
- Signature verification requires the app to approve that the signature matches the returned public key.
- Explicit user consent requires the wallet to display critical information and obtain user confirmation before producing a signature.
The currently supported signature algorithm is ECDSA-P256, though the standard’s allowed_algorithms field is designed as an array to accommodate future additions.
Three interaction modes
NEP-20 defines three scenarios for how users and applications can interact during authentication.
In QR Code Mode, a website displays a QR code encoding the Challenge payload. A user scans the code with a mobile wallet, confirms the login on their device, and the wallet sends the signed Response to a callback URL provided in the Challenge. This enables cross-device authentication, allowing a user to log in to a desktop session from a mobile phone.
In Plugin Mode, a browser extension wallet detects whether a website supports NEP-20. The website’s frontend requests a Challenge from its server, passes it to the wallet’s authenticate method, and the wallet verifies the domain, prompts the user, and returns the signed Response. This enables seamless, near-automatic login for users with compatible browser wallets.
In Connection Mode, the protocol works over persistent connections. A game client or command-line tool connects to a server, receives a Challenge, signs and returns a Response, and proceeds with the session if authentication succeeds. This covers native applications, backend services, and CLI tools that do not operate in a browser.
Design decisions
A key design choice in NEP-20 is that it operates entirely off-chain. The standard supports only standard single-key Neo accounts System.Crypto.CheckSig, which represent the vast majority of Neo addresses. During the review process, Neo SPCC suggested extending support to multi-signature and script-based accounts. Zhang responded:
I do not intend to support addresses other than System.Crypto.CheckSig here. Doing so would mean that NEP-20-enabled applications would need to run a NEO node, or at least a trusted RPC server. This is currently unacceptable for traditional applications or gaming platforms. We need a fully off-chain authentication scheme.
The standard’s grant_type field, currently set to “Signature,” is designed to be extended in the future to support additional authentication methods, leaving the door open for script-based verification in later iterations.
Possible Use cases
NEP-20 is designed to function as a universal authentication layer across different environments. Web applications can offer wallet-based login alongside or in place of traditional credentials. Games can authenticate players without requiring a separate account system. Backend services and CLI tools can integrate wallet signing directly.
The NEP-20 standard’s network field uses magic numbers from Neo’s ProtocolSettings, enabling applications to support authentication across multiple Neo networks within a single implementation.
The full announcement can be found at the link below:
https://x.com/erikzhang/status/2040305260628197511
