# Solution Sealed is designed as a direct response to the problems described in the previous section. Instead of treating privacy as a single feature, Sealed treats it as a full system design challenge. The goal is not only to encrypt messages, but also to reduce trust, limit unnecessary identity exposure, protect against metadata leaks, and make the infrastructure more transparent and verifiable. ### Removing the central server The first problem is centralization. Traditional messengers depend on company-controlled servers that deliver messages, synchronize devices, and manage communication. Sealed removes this central message server from the core design. There is no infrastructure between the open-source application code and the blockchain. Messages are not routed through a private messaging backend, and there is no company-controlled server that users must trust with the flow of their conversations. The only optional exception is push notifications: if a user chooses to enable them, Sealed may use an indexer for notification delivery, but this component is also open source and does not become the core message server. As a result, Sealed avoids the main point of control, failure, and pressure that exists in traditional messaging systems. ### Making privacy verifiable The second problem is that privacy claims are often hard to verify. A messenger may claim to use end-to-end encryption, but if the code is closed and the backend cannot be inspected, users still need to trust the company or an external auditor. Sealed is open source, which means its code can be inspected, reviewed, and audited by users, developers, and security researchers. The goal is to make privacy less dependent on promises and more dependent on systems that can be checked. Users should not have to trust that Sealed works as described; they should be able to verify how messages, keys, credits, and smart contracts are handled. ### Reducing IP exposure The third problem is network-level exposure. In traditional messengers, the service provider or infrastructure operator may be able to see the IP address of the device connecting to the service. Sealed solves this by using OHTTP when interacting with RPC infrastructure. This gives privacy to the request, meaning the RPC provider can process the blockchain request without learning which user or IP address originally made it. As a result, account activity is not directly tied to the user’s network identity at the RPC level. ### Removing phone numbers from identity The fourth problem is phone-number-based identity. Many messengers use phone numbers because they are convenient, but phone numbers are strongly connected to real-world identity. Sealed does not use a phone number as the foundation of communication. Instead, the user’s identity is a cryptocurrency wallet created locally inside the application. This allows users to communicate without giving the app a personal identifier that can be easily connected to their legal identity, mobile provider, country, SIM card, or other online accounts. ### Separating payment from communication The fifth problem is that payments can expose usage. In many services, the account that pays is directly connected to the account that uses the service, which can link financial activity with communication activity. Sealed solves this through a credit-based access model inspired by privacy-preserving deposit systems. A user can deposit funds, receive a private note, and later use credits from a messaging wallet that does not need to reveal where the original payment came from. Sending messages consumes credits, and message costs can include gas sponsoring, so the messaging wallet does not need to hold ALGO directly. This separates payment from usage and reduces the risk of linking a person’s funding activity with their communication activity. ### Limiting exposure through reports, screenshots, and legal pressure The sixth problem is that conversations can be exposed by companies, users, or legal pressure. Sealed reduces company-side exposure by removing the central server and encrypting messages before they leave the sender’s device. Because Sealed does not operate a traditional messaging backend that stores readable conversations, there is less centralized data available for internal access, moderation systems, or external requests. However, Sealed cannot prevent a recipient from taking a screenshot, copying a message, or reporting what they received. This is an important limitation: Sealed can reduce infrastructure-level exposure, but it cannot control what a conversation participant does after reading a message. ### Reducing censorship and geoblocking risks The seventh problem is that centralized platforms can be blocked, restricted, or pressured from one central point. Sealed reduces this risk by relying on open blockchain infrastructure instead of a single company-controlled messaging server. Since message delivery is handled through public smart contract infrastructure, communication does not depend on one private backend that can be turned off, region-blocked, or pressured in the same way as a traditional platform server. For Android users, Sealed can also be distributed directly from the landing page, which reduces dependence on a single app store as the only access point. This does not make Sealed impossible to block in every situation, but it makes the system less dependent on centralized distribution and infrastructure. ### Treating encryption as one layer, not the whole solution The final problem is that encryption alone is not enough. Sealed uses end-to-end encryption to protect message content, but it also adds other privacy layers around identity, payments, delivery, and infrastructure. The wallet is created locally, phone numbers are not required, payment can be separated from messaging, messages are delivered through smart contracts instead of direct wallet-to-wallet communication, and RPC requests are protected through OHTTP. In this combined model, it becomes extremely difficult to identify who owns a messaging wallet unless someone has physical access to the user’s unlocked phone and open Sealed application. This is what makes Sealed different from a simple encrypted chat running on centralized infrastructure. --- # 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/solution.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.