Web3 Identity and Access Control on Sui: zkLogin, Seal, and SuiNS

September 2, 2026

6min read

Main Takeaways

"Web3 identity" is two separate problems. Authentication is how a person proves they control an account without managing a seed phrase. Authorization is who is allowed to read or act on a piece of data once it is on-chain. Sui answers both with native primitives rather than third-party services.
zkLogin lets a person create and control a Sui account using an existing Google, Apple, Facebook, Twitch, or Slack login, in a single sign-in step. The provider never learns the user's on-chain address and the chain never learns the user's email.
Seal encrypts sensitive data and enforces the policies that decide who can decrypt it, and SuiNS replaces 32-byte hex addresses with readable @names that resolve consistently across wallets, DeFi protocols, NFT marketplaces, and dApps.

A wallet address is a 32-byte string. For most people it is the worst part of using a blockchain, because nothing about it tells you whose it is, what it can do, or whether the person sending to it typed it correctly. This guide explains how identity, authentication, and permissioned data work on Sui, and why the design matters for anyone building financial or consumer applications.

The two problems hiding inside "Web3 identity"

When developers ask for identity tooling, they are usually asking about two different things.

The first is authentication: how a person proves they control an account without managing a seed phrase. Seed phrases are the reason most people never finish onboarding. Lose the seed phrase and the assets are gone with it, because the seed phrase is the only route to recovery. Any application that wants users beyond crypto-natives has to solve this.

The second is authorization: who is allowed to read or act on a given piece of data once it is on-chain. Public blockchains publish everything by default, which is fine for a token transfer and a problem for a private bid or a credential. Building real applications means controlling access to sensitive data without handing it to a centralized server that can leak it.

Sui addresses both with native primitives rather than third-party add-ons. zkLogin handles authentication, Seal handles encryption and access control, and SuiNS handles human-readable identity.

zkLogin: sign in with credentials you already have

zkLogin lets a person create and access a Sui account using an existing Google, Apple, Facebook, Twitch, or Slack login. There is no seed phrase to write down. The closest comparison is "Sign in with Google" for a Web2 app, except the same single step creates and controls a Web3 account.

It helps to be precise about what the user sees. There is still a screen, and an account is still created. What changes is the nature of that screen: it is a sign-in, not a key-generation ceremony. The user does not copy down twelve words or guard a private key. They authenticate the way they already authenticate everywhere else, and the account exists on the other side of that one step.

Here is what happens underneath. When the user signs in with an OAuth provider, that login generates a zero-knowledge proof. The proof verifies that the user owns the credential without putting any part of that credential on-chain. The provider never learns the user's on-chain address, and the chain never learns the user's email. The two identities stay cryptographically linked while remaining separately private.

For a builder, this is a choice about how much blockchain to expose. You can implement zkLogin as an invisible layer, where the user logs in the way they log into any app and never thinks about keys. Or you can offer it alongside traditional mnemonic and hardware wallet options, as a gentler entry point for people who are not ready to manage keys. Both paths use the same primitive.

The practical effect is that the hardest drop-off point in consumer Web3, the seed-phrase setup, collapses into a single familiar sign-in. A developer building a payments app or a game does not have to choose between self-custody and a usable signup flow.

Seal: encryption and access control the user actually owns

Storing data on a public chain raises an obvious question: how do you keep some of it private? The usual Web2 answer is a permissions server, a database, and a company you have to trust not to misuse or lose your data. That reintroduces the centralized point of failure a blockchain was supposed to remove.

Seal is Sui's encryption and access control layer. It encrypts sensitive data and enforces the policies that decide who can decrypt it, in a way that is decentralized, programmable, and composable with the rest of the stack. A builder does not encrypt data somewhere else and then bolt permissions on top; Seal handles the encryption and the access rules together. The closest analogy is a hardware security module that the user owns rather than rents from a provider, with permissions enforced by the chain and by cryptography instead of by a central operator.

This is the piece that makes a large class of applications possible. A lending protocol can gate access to underwriting data. An auction can keep bids sealed until reveal. A credential issuer can grant a verifier read access for a fixed window and revoke it afterward. In each case Seal encrypts the data and governs the decryption rights, and the encrypted payload can live on decentralized storage such as Walrus so the data and the rules about who reads it sit in the same stack.

SuiNS: names instead of addresses

SuiNS replaces wallet addresses with human-readable names. Instead of sending to a 32-byte hex string, you send to @gia.

The system supports subnames at no extra cost. A single name like @gia can spawn gaming@gia and lending@gia, with nested hierarchies and two ownership models depending on whether the owner wants to delegate control of a subname or keep it. Names resolve across wallets, DeFi protocols, NFT marketplaces, and other dApps, so one identity follows the user through the ecosystem. SuiNS is governed by the NS token.

For identity verification, readable names reduce one of the most common and costly errors in crypto: sending to the wrong address because no human can verify a hex string by eye. A name is checkable in a way an address is not.

What this looks like for a builder

Putting the pieces together, a developer building a financial application on Sui can let users sign in with Google through zkLogin, give them a readable @name through SuiNS, encrypt their sensitive records with Seal, and control exactly who can decrypt them through Seal's access policies. None of these require a centralized identity provider, and none require the user to manage a seed phrase. Authentication, naming, encryption, and access control were built to compose, so a builder wires them together rather than assembling them from services that were never meant to work as one.

FAQ

Does Sui have built-in identity verification?

Sui provides native primitives for the components of identity: zkLogin for authentication through existing OAuth providers, SuiNS for human-readable names, and Seal for encryption and access control over sensitive data. Developers compose these rather than relying on third-party identity services.

How do users sign in without a seed phrase?

zkLogin uses an existing Google, Apple, Facebook, Twitch, or Slack credential to generate a zero-knowledge proof of ownership. The user signs in once, much like "Sign in with Google," and that single step creates and controls their Sui account. There is no seed phrase to record.

How does Sui keep data private on a public chain?

Seal encrypts the data and manages the access control policies that decide who can decrypt it. Permissions are enforced by the chain and by cryptography rather than by a centralized server, so sensitive data can be stored on decentralized infrastructure without being readable by anyone who lacks decryption rights.