# Identity

In Sealed, identity is created inside the application, not on a company server. The user does not register with a phone number, email address, password, or social login. Instead, the app creates a local cryptographic wallet that becomes the user’s base identity inside Sealed. For a regular user, this should feel like creating a private app account. The difference is that this account is not owned or managed by Sealed as a company. It is generated locally, controlled from the user’s device, and does not require personal information to exist.

### Identity creation

When a user opens Sealed for the first time, the application creates a new wallet directly on the device. This happens locally, without asking a central server to create an account or assign an identity. After the wallet is created, the user sets an access code on the device. This code is used to unlock access to the app locally. It works as a familiar security layer for the user, similar to protecting an app with a passcode. From the user’s perspective, this process should feel simple. They open the app, Sealed prepares their identity in the background, and the user protects access to it with a local code.

### Identity ownership

Ownership of a Sealed identity is based on the wallet generated inside the application and the 24-word mnemonic phrase connected to it. The mnemonic phrase acts as the user’s backup. It allows the user to restore or move their Sealed identity to another device. This is especially important because Sealed does not keep a traditional account on a company server and does not offer a standard password reset. The access code protects the identity on the current device, but the mnemonic phrase is what allows the identity to survive device loss, replacement, or migration. In simple terms: the access code unlocks the app on one device, while the mnemonic phrase restores the identity on another device.

### No personal identifier by default

Sealed does not require a phone number, email address, real name, or social login to create an identity. This matters because these identifiers are often connected to a person’s real-world profile, mobile provider, country, billing history, contact list, or other online accounts. By avoiding personal identifiers during identity creation, Sealed reduces the amount of information attached to the user from the beginning. The user starts with a local app identity, not with an identity imported from the outside world.

### No traditional password reset

Because Sealed does not create a standard company-managed account, it also does not use a traditional password reset flow. There is no central account team or server that can recover access by sending an email link or SMS code. This is intentional. A standard reset system would require Sealed to keep stronger control over user identities, which would weaken the privacy model. Instead, recovery is based on the 24-word mnemonic phrase. This gives the user control, but it also means the user is responsible for keeping the phrase safe.

### Identity inside the user experience

Although Sealed uses a wallet as the technical identity layer, the user should not need to think like a blockchain user. The wallet should stay mostly invisible during normal use. The goal is for identity to feel familiar: the user opens the app and has an account-like identity ready to use. Under the hood, that identity is cryptographic and locally controlled, but the interface should remain simple enough for non-technical users.

### Recovery and device changes

Because identity is local, recovery and device migration depend on the 24-word mnemonic phrase. If a user loses their device but has safely stored the mnemonic phrase, they can restore their Sealed identity on a new device. This phrase also works as a backup for encrypted data that passes through the blockchain. Since Sealed does not store the user’s account on a central server, the mnemonic phrase becomes the user’s recovery path. This creates a clear privacy trade-off. Sealed avoids central account recovery because central recovery would require Sealed to control or manage user identities. Instead, the user remains in control, but also becomes responsible for protecting their mnemonic phrase.

### Identity architecture summary

Sealed identity is based on a locally generated wallet, protected on the device by an access code and recoverable through a 24-word mnemonic phrase. It does not require a phone number, email address, password, social login, or company-managed account. This gives Sealed a user identity model that is closer to a private, locally controlled app account than a traditional messenger profile.


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.sealed.channel/architecture/identity.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
