# Step by step Sealed is designed to feel like a regular private messenger, even though it works differently behind the scenes. Instead of creating an account on a company server, paying through a platform-controlled subscription, and sending messages through a central backend, Sealed uses a local app identity, credits, smart contracts, and end-to-end encryption. This page explains the basic user flow: from creating a Sealed identity, to buying credits, to sending a message directly or through Alias Chat. ### 1. The user creates a Sealed identity When a user opens Sealed for the first time, the application creates a private identity locally on the device. The user does not need to register with a phone number, email address, username, or social login. After the identity is created, the user protects access to the app with a local access code, while the 24-word mnemonic phrase works as the backup and recovery method for moving the identity to another device. ### 2. The user gets credits To send messages in Sealed, the user needs credits. Credits can be obtained through a simple interface on the Sealed website. In the first version, users buy credits with ALGO. In the future, Sealed can also support card payments, so users who are not familiar with crypto can still access the system in a more traditional way. After the user buys credits, the website generates a private code. This code proves that credits were purchased, but it does not need to publicly connect the payment wallet with the messaging identity used inside the app. ### 3. The user activates credits inside the app The user then enters the code into the Sealed app. Once the code is accepted, the app activates messaging credits for the user’s Sealed identity. These credits are used to send messages, and they can also include the cost of blockchain fees, so the user does not need to manually manage ALGO inside the messaging wallet. From the user’s perspective, this should feel similar to topping up an account with credits. The difference is that Sealed is designed to separate the payment step from the messaging identity. ### 4. The user can optionally create a nickname After setting up the app, the user can optionally create a nickname. A nickname makes it easier for other people to find the user through the Sealed search interface, instead of relying only on wallet addresses or wallet's QR code. Creating or editing a nickname costs credits, because it requires a transaction on the network. This means the user needs active credits before setting or changing a nickname. This step is optional. Users who want easier discovery can use a nickname, while users who prefer stronger separation can communicate without making their identity easier to search. ### 5. The user chooses how to start a conversation After credits are available, the user can start communicating in two main ways. The first way is a regular Sealed conversation, where the user sends an encrypted message to another person’s Sealed identity. The second way is Alias Chat, which allows the user to create a more separated communication path when they do not want to expose their main Sealed identity. Both options use the same general privacy principles: messages are encrypted before leaving the device, delivery is handled through Sealed’s decentralized infrastructure, and readable content stays only on user devices. ### 6. Sending a regular Sealed message In a regular Sealed conversation, the sender writes a message and chooses the recipient. Before the message leaves the device, Sealed encrypts it using the recipient’s wallet address. The encrypted message is then sent through the Sealed smart contract on Algorand, rather than directly from one wallet to another. This means that outside observers do not simply see one wallet sending a readable or directly addressed message to another wallet. Instead, they see interaction with the Sealed smart contract, where many users use the same function for message delivery. ### 7. Sending through Alias Chat Alias Chat is used when the user wants stronger separation between their main identity and a specific conversation. Instead of starting from the main Sealed identity, the user can communicate through an alias that is not meant to expose the primary identity behind it. For the user, Alias Chat should feel like starting a conversation from a separate profile. For the system, it helps reduce the risk that different conversations can be easily connected to the same person. This is useful when the user wants to communicate without revealing their main Sealed identity to the other side. ### 8. The smart contract processes the message When the message is sent, the Sealed smart contract handles the delivery action. Credits are consumed, blockchain fees can be sponsored, and the encrypted message becomes available through the decentralized delivery layer. The smart contract does not read the message. It does not understand the conversation. It only processes encrypted data and the rules required to send it. ### 9. The recipient’s app detects the message The recipient’s application checks the Sealed message flow and looks for messages intended for that user. It can recognize the correct message through an encrypted hint generated from the recipient’s wallet. This allows the recipient’s device to detect the message without requiring the recipient to be exposed in a simple public way. To everyone else, the message remains encrypted data inside a larger flow of similar smart contract interactions. ### 10. The recipient reads the message Once the recipient’s app detects the message, it decrypts it locally on the recipient’s device. The readable message is not downloaded from a Sealed server, because there is no central message server holding the conversation. The message becomes readable only after the recipient’s device decrypts it. This completes the message flow: the sender writes locally, Sealed encrypts locally, the smart contract delivers encrypted data, and the recipient decrypts locally. --- # 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/introduction/step-by-step.md?ask= ``` 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.