# What is Sealed? **Sealed is a private messenger designed to protect both your messages and your identity.** It allows people to communicate without relying on a central message server, a phone number, or blind trust in a company that promises privacy behind closed doors. Most messaging apps work in a similar way: even when the content of your messages is encrypted, the app still depends on servers controlled by the company behind it. These servers may not be able to read your messages, but they can often see important information around them, such as when you are active, when you send messages, and which accounts interact with each other. Sealed is built differently. Instead of sending messages through a traditional company-controlled server, Sealed uses public blockchain infrastructure and privacy-focused smart contracts to move encrypted messages between users. In simple terms, messages are not handled by one central server that users must trust. Before a message leaves your device, Sealed encrypts it. After that, only the intended recipient can read it. To everyone else, including the network that helps deliver it, the message looks like unreadable data. ### A private messenger without a central server The main idea behind Sealed is simple: private communication should not depend on a central company server. In traditional messengers, the server plays a key role. It helps send, receive, route, and synchronize messages. This creates a point of control and a point of trust. Sealed removes that dependency. Messages are handled through open blockchain infrastructure instead of a private messaging backend. Users interact with the same public system, which makes it harder to clearly see who is talking to whom. The content of the message remains encrypted, while the delivery process avoids direct wallet-to-wallet messaging by default. For a non-technical user, the experience should still feel familiar: 1. You write a message. 2. Sealed encrypts it on your device. 3. The encrypted message is sent through Sealed’s decentralized infrastructure. 4. The recipient’s app finds it. 5. Only the recipient can read it. The complexity stays under the hood. The user simply gets a private messenger. ### Public infrastructure, private conversations Sealed is based on the idea that infrastructure can be public, while conversations remain private. At first, this may sound unusual. Public infrastructure means that the system can be inspected and verified. Private conversations mean that the content of your messages is protected before it ever reaches that infrastructure. Sealed does not rely on the system being hidden. It relies on encryption and verifiable design. That is the core difference. A traditional messenger asks users to trust that the company is handling their data correctly. Sealed is built so that the way the system works can be checked, reviewed, and improved by the community. ### Private access without exposing your messaging wallet Sealed also separates payment from communication. In many digital services, the account that pays is directly connected to the account that uses the service. This can create a privacy problem, because payment activity can become linked to user activity. Sealed uses a credit-based access model. A user can receive messaging credits and use them from a wallet that does not need to reveal where the original payment came from. These credits can also include the cost of sending messages, so the messaging wallet does not need to hold the blockchain’s native token directly. For the user, this means a simpler and more private experience: * you can use credits to send messages, * your messaging wallet does not need to hold ALGO, * sending costs can be covered automatically, * payment activity is separated from messaging activity. The goal is to make private communication easier to use without forcing users to expose unnecessary information. ### No phone number required Sealed does not use a phone number as your identity. A phone number is closely connected to the real world. It can be linked to your name, country, mobile provider, payment history, and other online accounts. For a private messenger, this is a weak starting point. Sealed uses cryptographic identity instead. This means that your access and conversations are based on digital keys and wallets, not on your phone number. You do not need to give up a personal identifier just to start a private conversation. ### More than message encryption Encryption protects what you say, but real privacy also depends on what can be learned around the message. This surrounding information is called metadata. It can include things like when messages are sent, how often users communicate, which accounts appear active, or whether payment activity can be linked to messaging activity. Sealed is designed to reduce this type of exposure by combining several privacy-focused ideas: * end-to-end encryption, * separate keys for different conversations, * message padding, * decentralized message delivery, * credit-based access, * separation between payment and messaging wallets, * and private access to blockchain infrastructure through OHTTP. These mechanisms do not make every trace disappear. No honest privacy system should claim that. However, they are designed to make communication amost impossible to track, link, or profile. ### Optional direct communication Sealed can also support direct peer-to-peer communication between devices. This option is useful for highly sensitive information, because the message does not need to be placed on-chain, even in encrypted form. However, direct communication comes with trade-offs. Both devices usually need to be online at the same time, and each side may expose its IP address to the other. For that reason, direct communication is best used with trusted devices and specific situations where users understand the trade-off. ### Open by design Sealed is open source. This means the code can be inspected by users, developers, and security researchers. The goal is not to ask people to believe privacy claims, but to make the system verifiable. # Problem Most people think private messaging is only about encrypting message content. If nobody can read what you write, the conversation feels private. In reality, privacy is much broader than that. Even when a message is encrypted, a messaging service may still collect, process, or expose information around the conversation. This information is called metadata. It can include when you are active, when you send messages, how often you communicate, which account you interact with, what device you use, what IP address you connect from, or which server handles your connection. Metadata can reveal patterns without revealing the actual words. A company may not know what you said, but it may still know who you contacted, when the conversation happened, where the connection came from, and how often it happens. For many users, this can be just as sensitive as the message itself. ### Central servers create central points of trust Most messengers depend on company-controlled servers that deliver messages, synchronize devices, manage accounts, and keep the service online. This creates a central point of trust. Users must trust that the company does not collect more metadata than necessary, does not misuse data, does not silently change the rules, and does not expose sensitive information through technical failures, business decisions, legal requests, or external pressure. Even if the company has good intentions, a central server remains a valuable target. If one system handles communication for millions or billions of users, it becomes attractive to attackers, data brokers, surveillance systems, governments, and anyone trying to understand how people communicate. ### Privacy claims are hard to verify Many messengers claim to use end-to-end encryption, but for most users it is almost impossible to verify how the system really works. If the application is closed source, users cannot fully inspect the code. If the backend is closed, users cannot verify what happens on the server side. In practice, they must trust the company, its public statements, or external auditors. This creates a gap between a privacy promise and a privacy guarantee. The controversy around WhatsApp in early 2026 shows why this matters: lawsuits and media reports alleged that Meta could access WhatsApp users’ private communications despite public end-to-end encryption claims, while Meta denied the allegations. The technical details remain disputed, but the broader lesson is clear: users should not be forced to rely only on marketing claims when the system itself cannot be independently verified. A privacy system should be open, inspectable, and designed to minimize trust from the beginning. ### IP addresses can expose users A message does not only travel through an app. It also travels through a network connection. In many traditional messengers, the service provider or infrastructure operator may be able to see the IP address of the device connecting to the service. An IP address can reveal approximate location, internet provider, network type, and sometimes patterns of movement or behavior. This creates another layer of exposure: even if message content is encrypted, network-level information may still help identify, locate, or profile a user. For a private messenger, protecting the message content is not enough. The system also needs to reduce unnecessary exposure around how the user connects. ### Phone numbers are not private identities Many messengers use phone numbers as the foundation of identity. This is convenient, but it creates a privacy problem because a phone number is not just a random login. It is usually connected to a real person, a country, a mobile provider, a SIM card, payment history, and other online accounts. Once a communication identity is built around a phone number, it becomes much easier to connect digital activity with a real-world person. For a private messenger, this is a weak starting point. Users should not need to expose a personal identifier just to start a conversation. ### Payments can expose usage Privacy can also be weakened by the way access is paid for. In many digital services, the same account that pays for the service is also the account that uses it. This can link financial activity with user activity. Even if messages are encrypted, payment records may still help connect a person to an account, a subscription, or a pattern of usage. This is especially important for a privacy-focused messenger. A system that protects messages but exposes the relationship between payment and communication still leaves a major privacy gap. ### Conversations can be exposed by companies, users, or legal pressure Private conversations can become exposed in many ways. A company may receive legal requests. A group member may report a message. A participant may share screenshots. A platform may cooperate with authorities according to its policies and local law. This means users should not assume that a conversation is fully protected only because it happens inside an app with encryption claims. A recent case in the United States shows how serious this can become: in April 2026, a Florida International University student was arrested after messages in a large WhatsApp group chat were interpreted by authorities as a threat, even though reports described the message as a joke or sarcastic comment. The case shows that group chats can create a false sense of safety. Even when a platform uses encryption, a conversation can still become visible through reports, screenshots, participants, moderation flows, or legal processes. ### Censorship and geoblocking can limit communication Centralized communication platforms can be blocked, restricted, or pressured in different parts of the world. Governments may block access to messaging apps during protests, conflicts, elections, or political unrest. Platforms may also be forced to comply with regional laws, remove access to features, or limit availability in certain countries. For users, this means that access to communication can depend on geography and political conditions. In 2025, for example, Iranian state television urged people to delete WhatsApp, and Iran has previously blocked major social media and messaging platforms during periods of unrest. A private communication system should not depend entirely on a single company-controlled infrastructure that can be blocked, pressured, or restricted from one central point. ### Encryption alone is not enough End-to-end encryption is essential, but it does not solve every privacy problem. Encryption protects the content of a message. It does not automatically hide who is using the service, when messages are sent, which accounts are active, what IP address is used, whether two users are likely communicating with each other, or whether payment activity can be linked to communication activity. This is why a private messenger must be designed as a full system, not only as an encrypted chat window. Privacy depends on how messages are delivered, how identity is handled, how payments work, what infrastructure is used, whether the code is verifiable, and how much metadata the system creates. # 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. # 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. ### Step 1. Create local wallet 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.

click "create account"

click "next" until you get to "create or recover" screen

click "create local wallet" to move to below screen

carefully read infomration and after that click "create account"

### Step 2. Set up a passcode After the wallet is created, the user sets an access code. This code is used to unlock Sealed on the current device. It works like a local app PIN and protects access to the user’s Sealed identity, messages, and local app data. The access code is not a cloud password and cannot be reset by Sealed through email or SMS. The user can change it later in the app settings. If the user enters the wrong access code 5 times, the app resets itself. To restore the main Sealed identity after a reset, the user needs the 24-word mnemonic phrase.

set up a pass code by typing 6 figures, after that you'll be asked to type it again in order to confirm it

### Step 3. Set up a termination code During the same setup flow, the user also creates a termination code. This code is used for emergency situations. It is entered on the same PIN screen as the normal access code, but instead of opening the app, it silently wipes local Sealed data from the device. The termination code can be changed later in the app settings. It does not remove anything from the blockchain. Its purpose is to remove the local data needed to access the Sealed identity and conversations from that device, including Alias Chat content and Peer-to-Peer messages stored locally.

read information about termination code carefully and click "set code"

type termination code

all set, click "continue" now to enter the app

### Step 4. Prepare an Algorand wallet and ALGO To generate credit codes, you need an Algorand wallet outside the Sealed app. Use one of the dedicated Algorand wallets supported by the top-up flow, such as **Lute**, **Pera**, or **Defly**. These wallets are used only for the top-up process and remain separate from the local Sealed wallet created inside the messaging app. Lute is an Algorand wallet, while Algorand’s own ecosystem page lists Pera, Defly, and Lute among supported wallet options. If you do not already have ALGO in that wallet, you need to obtain it first. One common way is to use a centralized exchange, withdraw ALGO to your Algorand wallet, and then use that wallet on the Sealed top-up page. Examples of large exchanges users may check for ALGO availability include **Coinbase**, **Kraken**, and **Binance**; availability depends on country, account status, and exchange policy. CoinGecko currently lists Coinbase Exchange, Kraken, and Binance among the largest tracked exchanges by trust score/reserves, while Algorand’s own onboarding page also mentions Coinbase and Binance as CEX examples for funding an Algorand wallet. This step is only needed for users who want to generate credit codes through the top-up page. If free access is available through the [**official Sealed Discord channel**](https://discord.gg/GUKD8E6xCx), you may be able to claim access without completing the ALGO top-up flow. ### Step 5. Open the top-up page and connect your wallet The top-up process starts on the Sealed top-up page: [sealed.channel/top-up](https://sealed.channel/topup) This page is used to generate credit codes that can later be activated inside the Sealed app. To create those codes, the page needs to connect with an external Algorand wallet, such as **Lute**, **Pera**, or **Defly**. This wallet is used only to approve the top-up transaction. Connecting it allows the page to prepare the transaction, but it does not give Sealed control over the wallet or its funds. The transaction is submitted only after the user confirms it directly inside their wallet application.

choose wallet you want to connect and after that click "connect wallet"

sign connection in your wallet, if it is not confirmed, error will occur

### Step 6. Deposit Algo Credit codes are created by depositing ALGO into the Sealed top-up smart contract. The top-up page explains how the process works before the user continues, because the generated codes are private access materials that must be saved safely. The user chooses how many standard credit codes they want to generate, and the connected Algorand wallet is used to confirm the deposit transaction. Each code represents the same standard credit package, which helps keep the credit system more consistent and supports the privacy model behind top-ups. Once the deposit is confirmed on the network, the top-up page generates the credit code or codes connected to that deposit. These codes are later activated inside the Sealed app.

read instruction carefully and click "continue"

type amount of codes you want to generate

click (top up) if it is not green, you lack enough Algo in your wallet

confirm transaction in your wallet, if transaction is not cofirmed "error" will occur

### Step 7. Receive codes After the deposit is confirmed, the top-up page generates the credit code or codes connected to that deposit. These codes are required to activate credits inside the Sealed app, so they should be saved before finishing the process. Codes work like private access materials. Anyone who has a valid code may be able to activate the credits connected to it, so they should not be shared unless the user intentionally wants someone else to use them. Sealed cannot resend lost codes through a traditional account system, so the user is responsible for storing them safely.

read important information carefully and mark "I understand" boxes, after that click "continue"

copy codes by clicking button under "action" column, download them via clicking "download codes" button, or save them "on paper" after that click "finish"

read information carefully and click "finish anyway" or click "back" in order to copy codes once again

### Step 8. redeem credits Credit codes are not used directly on the website after they are generated. They must be redeemed inside the Sealed app, because the app needs to connect the credits with the user’s local Sealed identity. This step makes the credits available for normal app usage, such as sending messages or using supported features. It also allows the local Sealed wallet to work without holding ALGO directly, because the required network costs are handled through the credit system in the background.

go to "settings"

find redeem field and type received code if everything is fine you should see available credits above, otherwise error pop-up will occur

### Step 9. Start a conversation After credits are redeemed, the app has everything it needs to let the user send a message. The next step is choosing who the message should be encrypted for. In Sealed, the recipient can be found by wallet address, and if the recipient has set a nickname, discovery can be easier through the search interface. This step is necessary because Sealed must know which recipient should be able to decrypt the message. Once the recipient is selected, the app can prepare the correct encryption path, protect the message locally, and send only encrypted data through Sealed’s delivery flow. The recipient’s app then detects the message and decrypts it on their device.

click search bar on the top

type receiver's wallet address or nickname and after that click profile

type a message and click send button after that

That's it, now the receiver get the message, so you can wait for a response

# 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. # Messaging Messaging is the core function of Sealed. It is the process of creating, encrypting, sending, detecting, and reading a message without using a central messaging server. In a traditional messenger, messages usually pass through infrastructure controlled by the company that operates the app. In Sealed, the message flow is built around the user’s local device, encryption, and Algorand smart contracts. The goal is to make the user experience feel simple: write a message, send it, and let the recipient read it. The technical complexity stays under the hood. ### Local message creation When a user writes a message in Sealed, the message is first created locally inside the application. At this stage, the content exists only on the sender’s device. Sealed does not send the plain text message to a server for processing, routing, moderation, or storage. This is an important architectural rule: the readable version of the message should never leave the user’s device. Before any network interaction happens, the app prepares the message for encryption and delivery. ### Message encryption Before a message is sent, Sealed encrypts it on the sender’s device using the recipient’s wallet address. This means that the content is converted into unreadable data before it reaches any external infrastructure, and only the intended recipient should be able to decrypt it inside their own application. The blockchain does not receive a readable message. RPC infrastructure does not receive a readable message. Sealed as a project does not receive a readable message. For the user, this simply means that the message is protected automatically before it is delivered. ### Smart contract delivery Sealed does not send messages directly from one wallet to another by default. Instead, encrypted messages are sent through the Sealed smart contract on Algorand. This is a key part of the messaging architecture because direct wallet-to-wallet messaging could make it easier to see who is communicating with whom. By using a shared smart contract function, many users interact with the same public mechanism, which makes the delivery flow harder to interpret from the outside. The smart contract becomes the coordination layer for encrypted message delivery, not a server that can read or control the conversation. ### Message detection After a message is sent through the smart contract, the recipient’s application needs to detect that a message belongs to them. From the user’s perspective, this should feel like receiving a normal message. Under the hood, the app scans the relevant blockchain data and identifies encrypted messages that the user is able to open. The recipient’s device recognizes a message intended for it through an encrypted hint generated from the recipient’s wallet. This allows the recipient to detect their message without requiring the message to be addressed in a simple public way that exposes the recipient by default. Outside observers only see encrypted data moving through the public system. ### Message reading When the recipient’s app detects a message intended for them, the message is decrypted locally on the recipient’s device. This mirrors the sender side of the process: readable content stays inside the user’s application and is not exposed to external infrastructure. The recipient does not read the message from a Sealed server. They read it after their own device has successfully decrypted it. This keeps the message lifecycle consistent: plain text exists only on user devices, while everything outside the devices handles encrypted data. ### Message privacy Sealed messaging is designed to protect both content and context. Encryption protects the message content, while smart contract-based delivery helps avoid simple direct links between sender and recipient wallets. Every wallet uses the same smart contract function to send messages, which means that message delivery happens inside one shared flow rather than through visible direct wallet-to-wallet communication. As transaction volume grows, more users interact with the same function, making it increasingly difficult to reconstruct who communicated with whom and when. Message padding can also be used to reduce how much information is revealed by message size. In addition, when the sender uploads a message or the recipient retrieves messages, the devices use the official Algorand RPC with built-in OHTTP encryption. This masks the IP addresses of both devices from the RPC layer, so sending and receiving activity is not directly tied to the users’ network identity. These layers do not make every form of analysis impossible, but they make the communication model stronger than a simple encrypted message sent through a central server or directly between two visible wallets. ### Messaging architecture summary Messaging in Sealed starts on the sender’s device, where the message is created and encrypted locally. The encrypted message is then delivered through the Sealed smart contract on Algorand instead of a central messaging server or direct wallet-to-wallet transfer. The recipient’s app detects the message using an encrypted hint, decrypts it locally, and displays it to the user. This architecture keeps readable content on user devices, removes the need for a central message server, masks device IP addresses through OHTTP-protected RPC access, and makes message delivery harder to link from the outside. # Alias Chat Alias Chat is a separate conversation mode in Sealed built for stronger separation between a specific conversation and the user’s main wallet identity. It is not a public profile, not a nickname system, and not a standard wallet-to-wallet chat. It is a device-bound chat mode where both sides communicate through locally created aliases, shared hints, temporary wallets, and separate Alias Chat credits. The purpose of Alias Chat is to make the conversation harder to connect with the user’s main Sealed identity. Instead of displaying the recipient’s wallet address or nickname, the app shows a local alias chosen by the user. Under the hood, Sealed uses cryptographic information exchanged between both devices to recognize which encrypted messages belong to that Alias Chat. ### Contact setup Alias Chat can be started in two ways. The first method is a one-time invitation sent through the network. From the outside, this invitation looks like a normal Sealed message, so it does not clearly reveal that a special chat mode is being created. The second method is an offline QR code exchange, where both users scan codes from each other’s devices. One device shows a QR code, the other scans it, and then the same process happens in the opposite direction. The goal of this step is only to establish the first connection between the two devices. After this setup, both apps have the information they need to create the shared detection mechanism for the Alias Chat. ### Local alias In Alias Chat, the user does not see the other person as a wallet address or public nickname. Instead, the user creates a local alias for that conversation. This alias is only a label inside the user’s app and can be chosen freely by the user. The alias exists to make the conversation readable for the user without exposing the recipient’s real wallet identity in the interface. If someone opens the app, they see the chosen alias, not the other person’s wallet address. This is why the feature is called Alias Chat: the visible identity in the chat is local and user-defined. ### Shared hint After the initial setup, both devices create the same shared hint from the exchanged keys. This hint is used by the apps to recognize messages that belong to the Alias Chat. The shared hint replaces the need to show or use a visible recipient wallet address in the conversation interface. When the app scans incoming encrypted messages, it checks whether any of them match the Alias Chat hint. If there is a match, the app knows that the message belongs to that conversation. ### Alias Chat credits Alias Chat uses its own credit flow. From the main Sealed wallet, the user can exchange regular credits into Alias Chat credits. These credits are divided into packages of 50 messages. Each package works as a separate code, similar to a top-up code. These codes are stored locally on the device and are later used to fund Alias Chat messaging. This keeps the spending flow for Alias Chat separated from the main wallet used by the regular Sealed identity. ### Temporary wallet When an Alias Chat is started, the app creates a new local temporary wallet for that conversation. This wallet receives one package of Alias Chat credits and uses those credits to send messages within the Alias Chat. The temporary wallet exists only for this separated communication flow. It is not the user’s main Sealed wallet. When the package of credits runs out, the temporary wallet can be removed from the device and replaced with a new temporary wallet funded by a new Alias Chat code. ### Wallet rotation inside one conversation Alias Chat can continue even when the first temporary wallet is no longer used. When credits run out, the app can create another temporary wallet and fund it with another Alias Chat credit package. This means that one Alias Chat conversation does not need to rely on one long-lived wallet. Over time, the conversation can move through multiple temporary wallets, each funded by a separate credit code. This helps reduce the risk of building a long-term visible wallet trail for the conversation. ### Device-bound storage Alias Chat is bound to the device where it was created. The local alias, exchanged keys, shared hint, stored credit codes, temporary wallets, and conversation data are kept on that device. This is different from the main Sealed identity, which can be restored with a 24-word mnemonic phrase. Alias Chat is intentionally more isolated, so it does not use the same backup model. If the user loses the device or deletes the local Alias Chat data, the Alias Chat may be lost. ### Alias Chat architecture summary Alias Chat separates a specific conversation from the user’s main Sealed identity. Contact is established through a one-time network invitation or offline QR exchange. The visible identity is a local alias, message detection is based on a shared hint, and sending is handled by temporary wallets funded with Alias Chat credit packages. This design gives users a stronger separation layer for selected conversations, but it also comes with a clear trade-off: Alias Chat is device-bound and does not have the same recovery model as the main Sealed identity. # Peer-to-Peer Peer-to-Peer communication is an optional communication mode in Sealed. It allows two devices to exchange messages directly, without placing the encrypted message on the blockchain delivery layer. This mode is designed for specific situations where users want a more direct communication path. The default Sealed messaging flow uses Algorand smart contracts for delivery, but Peer-to-Peer gives users another option when both sides are online and willing to communicate directly. ### What Peer-to-Peer means in Sealed In Sealed, Peer-to-Peer means that two devices connect directly to exchange information between themselves. Instead of sending the encrypted message through the Sealed smart contract, the sender’s device communicates with the recipient’s device. For the user, this can feel similar to a direct secure chat session. The message is still protected by encryption, but the delivery path is different. The blockchain is not used as the message transport layer for that specific exchange. ### Why Peer-to-Peer exists Peer-to-Peer exists because some users may want to avoid placing sensitive communication on-chain, even in encrypted form. Sealed uses modern Post Quantum encryption, including ML-KEM, but some users may still be concerned about long-term risks such as “save now, decrypt later”, where encrypted data is stored today in the hope that future technology may be able to decrypt it. Peer-to-Peer gives users a way to exchange information directly between devices, so the message does not need to be written into the blockchain delivery flow. This does not replace the default Sealed messaging model. It adds another mode for situations where direct communication is preferred. ### Online availability requirement The main limitation of Peer-to-Peer communication is that both devices usually need to be online at the same time. In the default blockchain-based messaging flow, the sender can send a message even if the recipient is offline, because the recipient’s app can detect it later. In Peer-to-Peer mode, direct exchange requires both sides to be reachable during the communication session. This makes Peer-to-Peer less convenient for everyday messaging, especially when users are in different time zones, have unstable connections, or do not keep the app open. It is useful for direct sessions, but it is not as flexible as asynchronous delivery through the Sealed smart contract. ### IP address exposure Peer-to-Peer communication has a different privacy trade-off. Because devices communicate directly, each side may expose network-level information to the other side, including the IP address of the device or network being used. This is important for users to understand. Peer-to-Peer can reduce the amount of encrypted data placed on-chain, but it can increase exposure between the two communicating devices. For this reason, Peer-to-Peer is best used with trusted contacts or trusted devices, where both sides understand the trade-off. ### When to use Peer-to-Peer Peer-to-Peer should be treated as a special communication mode rather than the default experience. It can be useful when both users are online, when the conversation is highly sensitive, or when they want to avoid using the blockchain delivery layer for a specific exchange. For regular messaging, Sealed’s smart contract-based delivery is usually more practical because it supports asynchronous communication and does not require both users to be online at the same moment. ### Peer-to-Peer architecture summary Peer-to-Peer in Sealed allows two devices to exchange encrypted information directly. It avoids placing the encrypted message in the blockchain delivery flow, but it requires both devices to be online and may expose IP addresses between participants. This makes Peer-to-Peer a powerful optional mode for specific use cases, not a replacement for the default Sealed messaging architecture. # Credits Credits are the usage unit inside Sealed. They allow users to send messages, create or edit nicknames, use Alias Chat packages, and interact with Sealed features that require a transaction on the network. For a regular user, credits should feel similar to an app balance: the user receives credits once, and Sealed uses them in the background when an action needs to be processed. The purpose of credits is to make Sealed easier to use without forcing every messaging wallet to manually hold and manage ALGO. Instead of asking users to think about blockchain fees each time they send a message, Sealed turns usage into a simpler credit-based experience. ### Receiving credits Credits are obtained through the Sealed website. The website provides a simple interface where the user deposits ALGO into the credit smart contract. For every 10 ALGO deposit unit, the user receives a code that represents 500 credits. In practice, 500 credits equal 500 messages. The user can create one code or multiple codes at once by depositing a multiple of 10 ALGO. For example, a larger deposit can generate several separate codes, with each code representing the same fixed credit amount. This fixed-size model is important because it helps all credit codes look the same from the system’s perspective. ### Credit code A credit code is the bridge between the deposit and later usage inside the app. After the deposit is made, the user receives a code that can be activated in Sealed to unlock 500 credits. This code works similarly to a private voucher. It proves that a valid deposit was made, but it does not need to reveal which wallet made the original deposit when the credits are later activated in the app. The goal is to separate the wallet that deposits ALGO from the wallet that uses credits for messaging. ### Activating credits in the app Once the user has a credit code, they can enter or import it into the Sealed app. After activation, 500 credits become available for the user’s local Sealed identity and can be used for supported actions inside the application. From the user’s perspective, this should be simple: create a code on the website, activate it in the app, and start using Sealed. The app handles the technical details in the background, including credit activation, message sending, and transaction costs. ### Sponsored transaction costs One of the main benefits of credits is that they can include the cost of blockchain transactions. This means that the user’s messaging wallet does not need to hold ALGO directly in order to send messages or use basic network features. For the user, this removes a major source of friction. They do not need to manually calculate fees, keep small amounts of ALGO in every wallet, or understand how transaction costs work. Credits make the experience closer to using a normal app balance, while the system handles transaction costs in the background. ### Alias Chat credit packages Alias Chat uses a separate credit flow. From the main Sealed wallet, the user can convert regular credits into Alias Chat credits. These credits are divided into packages of 50 messages. Each package works as a separate code stored locally on the device. When an Alias Chat starts, the app creates a temporary local wallet and funds it with one of these packages. When the package runs out, the temporary wallet can be removed and replaced with a new one funded by another Alias Chat code. ### Credits architecture summary Credits are the internal usage balance of Sealed. Users create credit codes through the website by depositing ALGO into the credit smart contract. Each 10 ALGO code represents 500 credits, equal to 500 messages. The code can then be activated inside the app and used for messages, network actions, nickname creation or editing, and Alias Chat packages. This design makes Sealed easier for regular users because they do not need to manage blockchain fees manually. It also supports the privacy model by separating the deposit address from the wallet that later activates and uses credits. # Notifications Notifications in Sealed are optional and disabled by default. They are designed as a convenience layer for users who want to know when a new message may be waiting for them, without needing to manually open the app to check. When notifications are enabled, Sealed uses a separate notification flow built around a recipient tag, an open-source indexer, OHTTP-protected communication, and the standard push systems provided by Apple and Google. ### Scan Key When a user enables notifications, the Sealed app uses a key based on master-seed of wallet that is used only for finding messages that are coming for you and establishing the recipient-tag. This key is cannot decrypt any message it is only for notification matching. It is not directly tied to the wallet shown inside the app, and it is not meant to reveal the user’s Sealed identity. The scan key allows the notification system to recognize that a new message may be relevant for a specific device, without requiring the indexer to know the user’s wallet address in the app interface. ### OHTTP-protected registration After the recipient tag is generated, the app sends it to Sealed’s notification indexer through OHTTP encryption. OHTTP protects the network request, so the indexer receives the tag registration without directly learning the user’s IP address from the request. This is important because notification setup should not create a simple link between the device’s network identity and the user’s Sealed identity. ### Open-source notification indexer The notification indexer watches the blockchain for message events that match registered recipient tags. When it sees a matching event, it prepares a notification signal for the device. The indexer is operated by Sealed and is open source. It is the only additional infrastructure element in this flow that is not the app itself and not the blockchain. Because it is open source, its behavior can be inspected, reviewed, and audited. ### Push delivery When the indexer detects a matching event, it sends a push notification through Apple or Google notification systems, depending on the user’s device. The push notification is only an alert that something may have arrived. This allows Sealed to behave like a familiar mobile app while keeping the actual message handling inside the Sealed application. ### Opening the app After receiving a notification, the user opens Sealed. The app then connects to the official Algorand RPC through OHTTP encryption, checks the blockchain, finds the relevant encrypted message, and decrypts it locally on the device. This means the notification flow only helps the user know when to open the app. The actual message is retrieved and decrypted by Sealed after the app is opened. ### Metadata trade-off Notifications create a small privacy trade-off. The indexer can see that a registered recipient tag matched a blockchain event at a certain time, and Apple or Google can see that a push alert was delivered to the device. The recipient tag is not directly linked to the wallet in the app, and OHTTP helps protect the network request, but notifications still introduce timing-related metadata. This is why they are optional and disabled by default. Users who prefer convenience can enable them, while users who want to minimize metadata can leave them turned off. # Files, Photos # Groups # Decentralized storage # Layer 2 # Calling # Encryption Encryption is the main layer that protects the content of messages in Sealed. Its purpose is simple: before a message leaves the sender’s device, it is turned into unreadable data that only the intended recipient can open. Sealed uses encryption not only to hide what a message says, but also to reduce what can be learned around the message. This is why the encryption design combines message encryption, post-quantum protection, separate keys for each conversation, changing hints, Padmé-style padding. ### End-to-end message encryption Sealed uses end-to-end encryption based on **AES-GCM with an HKDF-derived key**. In simple terms, AES-GCM protects the message content, while HKDF helps create the encryption key used for that message from shared cryptographic material. For the user, this happens automatically. They write a message and press send. Before the message leaves the device, Sealed encrypts it locally. The readable version of the message is not sent to the blockchain, RPC infrastructure, notification systems, or any server. It becomes readable again only after the recipient’s device decrypts it locally. ### Post-quantum protection Sealed adds quantum-resistant protection through a hybrid approach: **X25519 + ML-KEM-512**. X25519 is a modern key exchange method widely used in secure communication, while ML-KEM-512 is a NIST-standardized post-quantum mechanism designed to protect against known quantum-computing attacks. The reason for combining both is long-term resilience. X25519 protects communication with a proven modern standard, while ML-KEM-512 adds protection against future risks, including “save now, decrypt later” scenarios where encrypted data is stored today in the hope that it can be decrypted years later. ### Separate keys for each conversation Each Sealed Alias Chat conversation uses its own separate set of keys. This means that one conversation is not protected by the same cryptographic material as every other conversation. This separation is important because it limits how much can be connected or affected at once. If a user has multiple conversations, each one has its own encryption context. A problem in one conversation should not automatically expose the cryptographic material of another conversation. ### Changing hint for every message Sealed uses hints to help the recipient’s app recognize which encrypted messages are intended for it. A hint is not the message content. It is only a detection marker that allows the app to find relevant encrypted messages inside the larger Sealed message flow. To reduce linkability, the hint changes with every message. This means that messages in the same conversation do not expose one permanent marker that can easily be followed over time. The recipient’s app can still recognize the messages, but outside observers have a harder time grouping them into one conversation. ### Padmé-style padding Sealed uses **Padmé-style padding** for every message. Padding changes the visible size of encrypted messages so that the original length of the plaintext is harder to guess. This matters because message size can reveal information even when the content is encrypted. Without padding, an observer may not know what a message says, but they could still notice whether it was very short, unusually long, or part of a recognizable pattern. Padmé-style padding reduces this kind of size-based analysis without forcing every message into one fixed size. ### Encryption summary Sealed protects messages with layered encryption. Message content is encrypted locally with AES-GCM using HKDF-derived keys, while hybrid X25519 + ML-KEM-512 adds post-quantum protection. Each conversation uses a separate key set, every message receives a changing hint, and Padmé-style padding reduces what can be learned from message size. When messages are sent or retrieved through blockchain infrastructure, OHTTP protects the user’s IP address from the RPC layer. Together, these mechanisms are designed to protect not only the message content, but also the surrounding signals that could otherwise make private communication easier to analyze. # Wallet top-up Wallet Top-Up in Sealed is designed to separate the wallet that provides ALGO from the wallet that later uses Sealed for communication. This matters because payment activity can become one of the easiest ways to identify a user. If the same wallet funds the account, sends messages, creates nicknames, and interacts with conversations, it becomes much easier to build a profile around that wallet. Sealed avoids this by using a credit code model. A user deposits ALGO into the credit smart contract, receives a code, and later activates that code inside the app from a different wallet. This creates separation between funding and usage. ### Separation between deposit and usage The main privacy goal of Wallet Top-Up is to avoid a direct public link between the deposit wallet and the messaging wallet. The deposit wallet is the wallet that provides ALGO to the smart contract. The messaging wallet is the wallet used later inside the Sealed app. In a simple system, these two actions could be connected easily: one wallet pays, the same wallet sends messages. In Sealed, the deposit creates a code, and the code can later be activated by a different wallet. This means the blockchain can show that a deposit happened and that a code was later activated, but it should not directly reveal that both actions belong to the same person. ### Fixed-size credit codes Each credit code has the same value: **10 ALGO equals 500 credits**, and 500 credits equal 500 messages. This fixed-size design is important for privacy because it prevents amount-based matching. If users could create codes for random amounts, it would be easier to connect a deposit with a later activation by comparing values. For example, a unique deposit amount could act like a fingerprint. By using the same standard size for every code, Sealed makes deposits look more uniform. Users who need more credits can create multiple standard codes instead of one unique large code. This keeps each code inside the same shared privacy set. ### Merkle tree privacy pool Sealed uses a Merkle tree-based privacy pool inspired by Tornado Cash. The idea is to place many identical deposit commitments into one shared structure. Later, a user can activate a valid code without publicly revealing which exact deposit created it. For a non-technical user, this can be understood like putting many identical sealed envelopes into one box. Later, someone proves they own one valid envelope without showing which exact person originally placed it there. This is what creates the separation between the deposit address and the activation address. The smart contract can verify that the code is valid, but the public chain does not need to show a simple one-to-one link between the original deposit wallet and the wallet that receives credits. ### Privacy depends on volume The privacy pool becomes stronger when more users participate. If only one person deposits and one person activates, the connection is easy to guess. If many users deposit the same fixed amount and many users activate codes over time, the link becomes much harder to reconstruct. This is called the anonymity set. The larger the group of possible deposits, the harder it is to identify which deposit belongs to which activation. In Sealed, more volume means stronger privacy for everyone using the credit system. ### Timing matters Timing is also important. If a user deposits ALGO and activates the code immediately, an observer may try to connect those two events based on timing. Even if the system does not reveal a direct link, the behavior itself can create a clue. Waiting longer before activating the code improves privacy because more deposits and activations can happen in between. The more time and activity between deposit and activation, the harder it becomes to make a confident connection. ### What this protects against Wallet Top-Up is designed to protect against simple payment-to-usage linking. It makes it harder for an outside observer to say: this wallet deposited ALGO, and that same person later used Sealed from this messaging wallet. It also helps protect against wallet profiling. The messaging wallet does not need to act like a normal funded crypto wallet, and the deposit wallet does not need to become the user’s communication identity. ### Wallet Top-Up summary Wallet Top-Up protects privacy by separating funding from communication. The user deposits a fixed 10 ALGO amount into the credit smart contract, receives a code worth 500 credits, and later activates that code inside the app from a messaging wallet. The privacy comes from several layers working together: fixed-size codes prevent amount-based matching, the Merkle tree privacy pool separates deposit and activation, higher volume increases the anonymity set, delayed activation reduces timing correlation, and credits remove the need to directly fund the messaging wallet with ALGO. # Blockchain interaction In Sealed, interaction with Algorand is protected by OHTTP. This matters because the app needs to communicate with blockchain infrastructure to send and retrieve encrypted messages, but the RPC provider should not directly see the user’s IP address. OHTTP adds a privacy layer between the user’s device and the RPC endpoint. It allows Sealed to use public blockchain infrastructure while reducing the network-level metadata created during normal app usage. ### What OHTTP is OHTTP stands for Oblivious HTTP. In simple terms, it is a way to send a request so that the service processing it does not directly know who originally sent it. In a regular connection, the service receiving a request can usually see both the request itself and the IP address of the device that sent it. With OHTTP, this information is separated. The RPC endpoint can process the request, but it does not directly receive the user’s IP address. ### Where Sealed uses OHTTP Sealed uses OHTTP when the app interacts with the official Algorand RPC. This applies to the blockchain operations needed for normal messaging, such as submitting encrypted message data and checking the chain for messages that may belong to the user. This protection is part of the app’s default connection flow. The user does not need to manually set up a VPN, proxy, custom node, or special network configuration. ### What OHTTP protects OHTTP protects the network identity of the device during RPC communication. The main thing it hides from the RPC layer is the user’s IP address. This is important because an IP address can reveal approximate location, internet provider, network type, and activity patterns. Without OHTTP, the RPC provider could potentially connect blockchain requests with the device or network that made them. ### What OHTTP does not hide OHTTP protects the connection between the user and the RPC layer, but it does not make public blockchain activity disappear. Transactions and encrypted message data that are placed on-chain remain visible as blockchain activity. This distinction is important. OHTTP protects the network path. Encryption protects the message content. The smart contract design helps reduce direct sender-recipient links. These are separate privacy layers that work together. ### User benefit For the user, the benefit is that Sealed can interact with Algorand without directly exposing the device’s IP address to the RPC provider. Sending and receiving messages still feels like using a normal app, while OHTTP works quietly in the background. # App security App security in Sealed focuses on one core principle: the device is the main security boundary. The app creates the user’s identity locally, stores sensitive data locally, and decrypts messages locally. Because of this, Sealed must protect access to the app, stored keys, local conversation data, and emergency situations where the user may need to remove access quickly. ### Access code After the wallet is created inside the app, the user creates a local access code. This code is used to unlock Sealed on that device. It is not a cloud password, not a server-side login, and not a recovery method. Its only role is to protect local access to the application. If the access code is entered incorrectly 5 times, the app resets itself. This protects the device against repeated guessing attempts. After a reset, the user needs the 24-word mnemonic phrase to restore the main Sealed identity. ### Termination code During the same setup flow, the user also creates a termination code. This code is entered on the same PIN screen as the normal access code, but it has the opposite effect: instead of opening the app, it silently wipes local Sealed data from the device. The termination code is designed for high-risk situations where a user may be forced to unlock the app. It does not erase anything from the blockchain, but it removes the local data needed to access conversations from that device. ### Hardware enclave Sealed uses the device’s hardware security layer to protect an AES wrapping key. This key is held inside the hardware enclave and is used to protect sensitive keys stored by the application. The AES wrapping key never leaves the enclave. It is not exported into normal app memory and is not sent to Sealed infrastructure. This gives the app a stronger local protection layer for key material. ### Encrypted private key storage The ed25519 private key is stored encrypted at rest using AES-256-GCM. This means the private key is not saved as plain readable data on the device. AES-256-GCM protects the stored key and helps detect unauthorized modification. The app only unlocks the key through the protected local flow when access to Sealed is allowed. ### Screenshot protection Sealed prevents screenshots inside the application. This helps reduce one common way of leaking sensitive information from a device, such as conversation screens, wallet-related screens, or recovery-related views. This protection cannot stop someone from taking a photo of the screen with another device, and it cannot control what another participant does with messages they receive. Its role is limited to blocking screenshots inside the operating system where the app can enforce it. ### Device risk Sealed reduces trust in central infrastructure, but it cannot remove the risk of a compromised device. If a device is already unlocked, infected, or controlled by an attacker, local data may be exposed despite the app’s protections. For this reason, device hygiene still matters. Users should keep their operating system updated, protect their screen lock, and store their 24-word mnemonic phrase safely. Sealed protects the app environment, but the device itself remains the final security boundary. # Audits # Data backup Data backup in Sealed is based on a local-first model. The app does not use a traditional cloud account where Sealed stores the user’s identity, messages, and recovery data. Instead, recovery depends on what the user controls locally and what can be reconstructed from blockchain-based encrypted data. This gives Sealed stronger privacy, because there is no central company backup containing user conversations or identity data. At the same time, it also means that backup works differently from normal web2 apps. There is no standard “forgot password” flow, and Sealed cannot recreate recovery material that the user has lost. ### Main identity recovery The main Sealed identity is backed up through the 24-word mnemonic phrase created during setup. This phrase is the recovery key for the user’s main identity and allows it to be restored on another device if the original device is lost, reset, or replaced. This is the most important backup element in Sealed. If the user keeps the mnemonic phrase safe, they can restore the main identity. If they lose it, Sealed cannot restore the identity through email, phone number, support request, or password reset. ### Recoverable blockchain data Some Sealed data can be recovered because it passed through the blockchain delivery flow in encrypted form. After restoring the main identity, the app can scan the blockchain, find relevant encrypted data, and decrypt what belongs to the restored identity. This is not the same as downloading a backup from a Sealed server. The blockchain provides access to encrypted delivery history, while the restored identity provides the ability to recognize and decrypt the data that belongs to the user. ### Device-bound data Not every part of Sealed is designed to be recoverable. Some data exists only on the device where it was created. This includes data that is intentionally separated from the main identity, such as Alias Chat information, local aliases, exchanged keys, shared hints, temporary wallets, and locally stored Alias Chat credit codes. This is a privacy trade-off. Device-bound data is harder to connect to the main identity, but it can also be lost if the device is lost, wiped, reset, or damaged. ### Wipe and reset consequences Sealed includes local wipe and reset mechanisms, such as the termination code and automatic reset after 5 incorrect access code attempts. These features are designed to protect the device in high-risk situations, but they also remove local data. After a wipe or reset, the main identity can be restored only with the 24-word mnemonic phrase. Device-bound data may not come back, because it was never meant to be recoverable through the main identity backup. ### User responsibility Because Sealed does not keep a central recovery copy, the user is responsible for protecting the mnemonic phrase. It should be stored safely, preferably offline and away from the device. The phrase should not be stored in screenshots, cloud notes, unencrypted files, or places that other apps or accounts may access. If someone else gets the phrase, they may be able to restore the identity. If the user loses it, Sealed cannot recreate it. ### Data Backup summary Data backup in Sealed has two categories: recoverable identity-based data and device-bound data. The 24-word mnemonic phrase restores the main identity and may allow the app to recover encrypted blockchain-based message data. Alias Chat and other device-bound information are intentionally local and may be lost with the device. This model gives Sealed stronger privacy and avoids central cloud backups, but it requires the user to protect their recovery phrase carefully. # Subscription model Sealed uses a subscription model to unlock additional app features and higher usage limits. Each tier gives users access to a different level of private communication tools, such as larger message allowances, encrypted storage, group creation, nickname setup, Alias Chat, audio calls, spam filtering, or business workspace features. Instead of treating every feature as a separate action, Sealed groups access into plans. A user activates a subscription and receives the features and limits included in that tier. Higher tiers are designed for users, teams, or organizations that need more communication capacity and more advanced tools inside the app. ### Subscription-based access A Sealed subscription defines what the user can access inside the app. Depending on the selected tier, the subscription can unlock message limits, group creation, nickname setup, encrypted storage, spam filtering, Alias Chat, audio calls, or business workspace tools. This gives Sealed a simple access structure. Users who need only essential premium features can choose a lower tier, while users who need more capacity or advanced privacy tools can move to a higher plan. ### ALGO-denominated plans Sealed subscriptions are denominated in ALGO. The planned tiers are Sealed+, Sealed Pro, and Sealed Business, with monthly and yearly options. Using ALGO fits the architecture of Sealed because the app uses Algorand as its blockchain layer. It also connects the subscription model with the underlying network costs related to message transactions, feature activation, and encrypted storage. ### Subscription codes Activating a subscription works similarly to the credit system. The user receives a code that can be activated inside the Sealed app. The difference is that a subscription code does more than add message credits. It also unlocks the features included in the selected plan. This keeps activation familiar for users while preserving the same privacy-oriented structure used by credits. The subscription can be activated in the app without turning the messaging wallet into a direct payment identity. ### Included messages and network costs Each subscription includes a monthly message allowance. These messages are designed to include the required network costs, so the user does not need to manually manage ALGO inside the messaging wallet for normal use. For the user, this means they can communicate within the limits of their plan without thinking about gas or transaction fees for every message. ### Lower cost per message at higher tiers Each higher subscription tier includes a larger monthly message allowance. This means the effective cost per message becomes lower as the user moves to a higher plan. This creates a clear upgrade logic. Smaller plans are suitable for lighter users, while higher tiers become more efficient for heavy users, teams, and organizations because they include more messages, more storage, and more advanced features at a lower average cost per message. ### Feature tiers Sealed’s subscription tiers are designed to match different levels of usage. Sealed+ is aimed at users who need private messaging with essential premium features. Sealed Pro is aimed at users who need higher limits and more advanced communication tools. Sealed Channel is aimed at organizations that need a closed communication workspace and configurable business features. The exact limits and feature sets can be presented separately in a pricing table, but the core idea is simple: higher tiers unlock higher usage limits, more storage, and more advanced tools. ### Encrypted storage retention Some subscription tiers include encrypted storage capacity for files and data. While a subscription is active, the user’s encrypted files remain available within the included storage limit. If a subscription ends, files remain available for a default retention period of 6 months. If the user renews the subscription, the files remain available for longer. This gives users time to restore access without immediately losing encrypted stored data after the subscription expires. ### Business subscriptions The Business tier is designed for companies, teams, and organizations. It can provide a closed workspace where employees connect their wallets, and the organization can manage communication rules, access, and internal structure. Sealed Channel subscriptions are also designed to support custom features. Since different organizations may need different tools, the Business tier has a starting price, while additional custom functionality can change the final cost. ### Subscription Model summary The Sealed subscription model gives users access to higher limits and additional features inside the app. Higher tiers unlock more communication capacity, more storage, and more advanced tools, while also lowering the effective cost per message. Subscription activation follows the same code-based structure as credits, helping preserve separation between payment activity and messaging identity. # Sealed + Sealed+ is the first subscription tier in Sealed. It is designed for users who want more than basic private messaging and need access to essential premium features inside the app. This plan gives users a larger monthly credit allowance, access to group creation, nickname setup, encrypted storage, and spam filtering. It is meant for regular users who want a private communication experience with enough capacity for everyday use. ### Plan price Sealed+ costs **50 ALGO per month** or **500 ALGO per year**. The yearly option gives users a lower effective monthly cost compared to paying month by month. This makes Sealed+ more efficient for users who expect to use the app continuously over a longer period. ### Credit allowance Sealed+ includes **5,000 credits per month**. Credits are used for actions inside Sealed, such as sending messages or interacting with features that require network activity. Instead of manually managing network fees or thinking about each blockchain transaction separately, the user receives a monthly credit package as part of the subscription. ### Included features Sealed+ unlocks the core premium features needed for a more complete Sealed experience. These include group creation, nickname setup, encrypted storage, and spam filtering. The purpose of this tier is to give users a stronger version of the app without moving into advanced features such as Alias Chat or audio calls, which are reserved for higher plans. ### Encrypted storage Sealed+ includes **15 GB of encrypted storage** for user files and data. The storage is designed for encrypted data, meaning that files should be protected before they are stored. Sealed provides storage capacity as part of the plan, while the privacy of the stored content depends on encryption rather than trust in a storage operator. ### Spam filter Sealed+ includes access to the spam filter. In Sealed, only users with an active subscription plan can set a nickname. If a user has a subscription, they can enable an option to receive regular conversations only from users who also have a nickname. Messages from users without a nickname are still received, but they appear in the spam section instead of becoming visible as a standard conversation by default. This gives users more control over who reaches their main conversation list, while still allowing them to review filtered messages if they choose to. ### Who Sealed+ is for Sealed+ is designed for users who want private messaging with essential premium tools. It is suitable for people who need more than a basic messenger, but do not yet need advanced privacy modes, high-volume communication, audio calls, or business workspace features. For many users, Sealed+ is the starting point for using Sealed as a daily private communication app. ### Sealed+ summary Sealed+ gives users **5,000 credits per month**, group creation, nickname setup, **15 GB of encrypted storage**, and spam filtering for **50 ALGO monthly** or **500 ALGO yearly**. It is the entry premium tier for users who want a fuller Sealed experience with practical limits and essential app features. # Sealed PRO Sealed Pro is the advanced subscription tier in Sealed. It is designed for users who need higher usage limits and access to stronger communication tools than those included in Sealed+. This plan expands the private messaging experience with more monthly credits, larger encrypted storage, Alias Chat, audio calls, and stronger spam filtering. It is meant for users who communicate more often, need stronger identity separation, or want access to more complete private communication features. ### Plan price Sealed Pro costs **100 ALGO per month** or **1,000 ALGO per year**. The yearly option gives users a lower effective monthly cost compared to paying month by month. It is designed for users who expect to use Sealed regularly over a longer period and want access to the full premium feature set. ### Credit allowance Sealed Pro includes **20,000 credits per month**. Credits are used for actions inside Sealed, such as sending messages or interacting with features that require network activity. Compared to Sealed+, Pro gives users a much larger monthly allowance, which lowers the effective cost per credit and makes the plan more efficient for heavier usage. ### Included features Sealed Pro includes the core premium features from Sealed+ and adds more advanced communication tools. The plan includes group creation, nickname setup, encrypted storage, spam filtering, Sealed+ user filtering, Alias Chat, and audio calls. The purpose of this tier is to give users access to the full personal communication experience inside Sealed. It is designed for people who need more than essential private messaging and want additional privacy and communication options. ### Encrypted storage Sealed Pro includes **50 GB of encrypted storage** for user files and data. This storage is intended for encrypted data, meaning files should be protected before they are stored. The larger storage limit makes Pro more suitable for users who want to keep more encrypted files, documents, or media inside the Sealed ecosystem. ### Spam filter Sealed Pro includes the standard spam filter and an additional Sealed+ user filter. In Sealed, only users with an active subscription plan can set a nickname. With the standard spam filter, a user can choose to receive regular conversations only from users who have a nickname. Messages from users without a nickname are still received, but they appear in the spam section instead of becoming visible as a standard conversation by default. Sealed Pro adds another level of filtering. Pro users can choose to receive regular conversations only from users with at least a Sealed+ subscription. This helps reduce low-quality or unwanted contact even further, while still allowing filtered messages to remain available in the spam section for review. ### Alias Chat Sealed Pro unlocks Alias Chat. Alias Chat is a separate conversation mode designed for stronger separation between a specific conversation and the user’s main Sealed identity. Instead of showing a wallet address or public nickname, the conversation can be handled through a local alias and a separate message detection flow. This is useful when a user wants to communicate without exposing their main Sealed identity inside that conversation. ### Audio calls Sealed Pro includes audio calls. Audio calls expand Sealed beyond text-based messaging and make the app more useful as a complete private communication tool. This feature is included in Pro for users who need direct voice communication inside the Sealed environment. ### Who Sealed Pro is for Sealed Pro is designed for users who want the full personal Sealed experience. It is suitable for people who need higher monthly limits, more encrypted storage, stronger spam filtering, Alias Chat, audio calls, and stronger tools for managing private communication. For users who treat Sealed as one of their main communication apps, Pro is the natural upgrade from Sealed+. ### Sealed Pro summary Sealed Pro gives users **20,000 credits per month**, group creation, nickname setup, **50 GB of encrypted storage**, spam filtering, Sealed+ user filtering, Alias Chat, and audio calls for **100 ALGO monthly** or **1,000 ALGO yearly**. It is the advanced personal tier for users who need higher capacity and access to Sealed’s stronger privacy and communication features. # Sealed Channel Sealed Channel is the organization-focused subscription tier in Sealed. It is designed for teams, companies, and institutions that need a private communication environment with higher limits, encrypted storage, internal workspace controls, and configurable business features. Unlike personal plans, Sealed Channel is not only about individual messaging. Its main purpose is to let an organization create a closed communication workspace where employees can use Sealed under company-defined rules. ### Plan price Sealed Business starts at **300 ALGO per month** or **3,000 ALGO per year**. This is the starting price for the base Channel plan. The final cost may increase depending on custom features, additional workspace requirements, storage needs, or organization-specific tools added later. ### Credit allowance Sealed Business includes **100,000 credits per month**. This higher allowance is designed for teams and organizations with larger communication volume. Compared to personal tiers, Channel gives more capacity and a lower effective cost per credit, making it more suitable for multi-user environments. ### Included features Sealed Channel includes the main features from personal premium tiers, but expands them for organizational use. The plan includes group creation, nickname setup, encrypted storage, spam filtering, Alias Chat, audio calls, and business workspace functionality. The purpose of this tier is to give organizations a private communication layer that can be adapted to internal needs instead of functioning only as a general public messenger. ### Encrypted storage Sealed Channel includes **1 TB of encrypted storage**. This storage is intended for encrypted company data, files, and communication-related content. It gives organizations enough capacity to use Sealed not only for messages, but also for storing encrypted materials connected to their workspace. ### Business workspace The core feature of Sealed Channel is the private business workspace. A company can create a closed environment where employees connect their wallets and communicate inside the organization. The workspace can be configured so that employees communicate only within the company environment. This makes it possible to disable contact with external users and keep communication focused on the organization’s internal structure. ### Master key model In Sealed Channel, the organization can operate with a master key model. This gives the employer or workspace administrator visibility and control over the business environment. This model is different from personal Sealed communication. In a personal plan, the user controls their own identity and conversations. In a business workspace, the company needs administrative access to organize the environment, manage internal data, and maintain control over company communication. ### Custom features Sealed Channel is designed to support custom features. Different companies may need different tools, workflows, access controls, compliance settings, or internal structures. Because these features are not one-size-fits-all, they are treated as additional configurable elements. Each custom feature can affect the final subscription cost, so the listed Business price should be understood as the base starting point. ### Who Sealed Channel is for Sealed Channel is designed for organizations that need a private, controlled communication environment rather than only individual encrypted messaging. It is suitable for teams that want encrypted internal communication, business-controlled access, larger storage capacity, higher credit limits, and the ability to adapt Sealed to company-specific needs. ### Sealed Channel summary Sealed Channel gives organizations **100,000 credits per month**, group creation, nickname setup, **1 TB of encrypted storage**, spam filtering, Alias Chat, audio calls, and a private business workspace for 5**00 ALGO monthly** or 5**,000 ALGO yearly** as a starting price. It is the organizational tier for teams and companies that need higher limits, internal controls, encrypted storage, and custom business features inside Sealed. # Untitled # Tokenomics SLD has a fixed total supply of **1,000,000,000 SLD**. The tokenomics of Sealed are designed to support long-term ecosystem growth, community participation, investor alignment, team execution, DAO governance, liquidity, and future strategic needs. The allocation is divided into several main groups, each with its own purpose and vesting schedule.The goal of this structure is to avoid excessive early unlocks, reward real users and builders, support long-term development, and give the DAO a meaningful role in the future of the ecosystem. ### Total supply The total supply of SLD is fixed at: **1,000,000,000 SLD** The allocation is divided into the following main categories: | Category | Allocation | Tokens | | -------------------- | ---------- | --------------------- | | Community & Airdrops | 30% | 300,000,000 SLD | | Investors | 20% | 200,000,000 SLD | | Team | 15% | 150,000,000 SLD | | DAO | 20% | 200,000,000 SLD | | Reserve | 10% | 100,000,000 SLD | | Liquidity | 5% | 50,000,000 SLD | | **Total** | **100%** | **1,000,000,000 SLD** | ### Launch valuation The planned initial TGE price for SLD in the first liquidity pool is **$0.025 per token**. With a fixed total supply of **1,000,000,000 SLD**, this implies a total fully diluted valuation of: **$25,000,000** The planned initial DEX liquidity is: **$700,000** This initial liquidity is intended to support early market creation and trading after TGE. ### Community & Airdrops The **Community & Airdrops** allocation represents **30% of the total supply**, equal to **300,000,000 SLD**. This category is designed to reward early users, active community members, builders, contributors, and real product usage. It is split into three separate pools: Early Users, Community Builders, and Real Users. #### Early Users The **Early Users** allocation represents **5% of the total supply**, equal to **50,000,000 SLD**. This pool is dedicated to users who participate in Sealed from the early stage until the launch of the final version of the messenger. It is designed as an airdrop for people who support and test the product before the final release. | Parameter | Value | | ------------------- | -------------- | | Allocation | 5% | | Tokens | 50,000,000 SLD | | Cliff | 1 month | | Vesting | 10% in month 2 | | Linear distribution | Months 3–26 | #### Community Builders The **Community Builders** allocation represents **5% of the total supply**, equal to **50,000,000 SLD**. This pool is intended for activities that help grow the ecosystem before and after launch. It can be used for KOLs, contests, early contributors, partnerships, marketing campaigns, and other community-building initiatives. | Parameter | Value | | ------------------- | -------------- | | Allocation | 5% | | Tokens | 50,000,000 SLD | | Cliff | 3 months | | Vesting | 10% in month 4 | | Linear distribution | Months 5–36 | #### Real Users The **Real Users** allocation represents **20% of the total supply**, equal to **200,000,000 SLD**. This is the main user airdrop pool. It is designed to reward real users from the launch of the final version of the messenger until TGE. Rewards can be based on product usage, activity, and social engagement. | Parameter | Value | | ------------------- | --------------- | | Allocation | 20% | | Tokens | 200,000,000 SLD | | Cliff | None | | Linear distribution | Months 1–50 | ### Investors The **Investors** allocation represents **20% of the total supply**, equal to **200,000,000 SLD**. This category is divided into four equal pools: Pre-seed, Seed, Private, and Presale. Each pool receives **5% of the total supply**, but with different cliff and vesting schedules. #### Pre-seed | Parameter | Value | | ------------------- | --------------- | | Allocation | 5% | | Tokens | 50,000,000 SLD | | Cliff | 12 months | | Vesting | 10% in month 13 | | Linear distribution | Months 14–36 | #### Seed | Parameter | Value | | ------------------- | --------------- | | Allocation | 5% | | Tokens | 50,000,000 SLD | | Cliff | 9 months | | Vesting | 10% in month 10 | | Linear distribution | Months 11–30 | #### Private | Parameter | Value | | ------------------- | -------------- | | Allocation | 5% | | Tokens | 50,000,000 SLD | | Cliff | 6 months | | Vesting | 10% in month 7 | | Linear distribution | Months 8–36 | #### Presale | Parameter | Value | | ------------------- | -------------- | | Allocation | 5% | | Tokens | 50,000,000 SLD | | Cliff | None | | Linear distribution | Months 1–25 | ### Team The **Team** allocation represents **15% of the total supply**, equal to **150,000,000 SLD**. This allocation is dedicated to team compensation and long-term project execution. The vesting schedule is designed to align the team with the long-term growth of Sealed. | Parameter | Value | | ------------------- | --------------- | | Allocation | 15% | | Tokens | 150,000,000 SLD | | Cliff | 12 months | | Linear distribution | Months 13–42 | ### DAO The **DAO** allocation represents **20% of the total supply**, equal to **200,000,000 SLD**. This allocation forms the DAO treasury. Half of the DAO allocation is intended to remain in permanent staking, while the other half can be used through DAO proposals. Community members can propose how DAO resources should be used, while the Sealed team keeps veto rights as a safety mechanism. | Parameter | Value | | ------------------- | ------------------------ | | Allocation | 20% | | Tokens | 200,000,000 SLD | | Cliff | None | | Linear distribution | Months 1–50 | | Special rule | 50% in permanent staking | ### Reserve The **Reserve** allocation represents **10% of the total supply**, equal to **100,000,000 SLD**. This pool is reserved for future project needs. It can be used for marketing, partnerships, community support, ecosystem growth, and other strategic initiatives. | Parameter | Value | | ------------------- | --------------- | | Allocation | 10% | | Tokens | 100,000,000 SLD | | Cliff | 1 month | | Linear distribution | Months 2–26 | ### Liquidity The **Liquidity** allocation represents **5% of the total supply**, equal to **50,000,000 SLD**. This allocation is intended for market making on centralized exchanges and initial liquidity provision on decentralized exchanges. The planned initial DEX liquidity is **$700,000**. After the DEX pair is created, liquidity is planned to be locked for one year. | Parameter | Value | | ------------------------------- | ------------------------------------------- | | Allocation | 5% | | Tokens | 50,000,000 SLD | | Initial TGE price | $0.025 per SLD | | Implied fully diluted valuation | $25,000,000 | | Initial DEX liquidity | $700,000 | | Purpose | CEX market making and initial DEX liquidity | | DEX liquidity lock | 1 year after pair creation | ### Tokenomics summary SLD tokenomics are built around a fixed supply of **1 billion tokens** and a planned TGE price of **$0.025 per SLD**, implying a fully diluted valuation of **$25 million**. The largest allocation is dedicated to community and airdrops, followed by DAO treasury, investors, team, reserve, and liquidity. The planned initial DEX liquidity is **$700,000**, with liquidity locked for one year after the DEX pair is created. The structure is designed to balance several goals: rewarding real users, supporting ecosystem growth, aligning investors and the team through vesting, giving the DAO meaningful resources, and providing liquidity for the market. The long vesting schedules across most categories are intended to reduce early supply pressure and support the long-term development of Sealed. # Utility SLD is the utility token of the Sealed ecosystem. Its main role is connected to staking, staking rewards, POWER, and optional in-app usage of earned rewards. The token is designed to reward long-term participation. Users who stake SLD can take part in the staking reward system, increase their POWER over time, and receive staking rewards generated by the protocol. ### Staking rewards SLD stakers receive a share of protocol revenue allocated to the staking pool. From the eligible revenue distributed by the protocol, **45% is assigned to stakers**. The staking reward smart contract works in **30-day reward intervals**. At the end of each 30-day interval, the contract calculates how much ALGO was generated for stakers during that period. That amount then becomes available for distribution to eligible stakers according to their staked SLD and POWER. This creates a clear reward cycle instead of irregular payouts. Users who stake SLD can claim their available ALGO rewards after the interval has been calculated. ### POWER multiplier POWER is the multiplier used in Sealed staking. It affects staking rewards. When a user starts staking SLD, their POWER begins at **1x**. Each day, POWER increases by **0.01x**, until it reaches a maximum of **4x**. This means that users gradually build stronger reward weight the longer they stay staked. A user with 1,000 SLD staked at 1x POWER has a lower effective reward weight than a user with 1,000 SLD staked at 4x POWER. In simple terms, POWER rewards time. The longer a user keeps SLD staked without unstaking, the stronger their position becomes in the reward system. ### POWER reset POWER resets when the user unstakes any amount of SLD. Even if the user removes only a small part of their staked tokens, the POWER multiplier returns to its starting point. This rule is designed to discourage short-term staking behavior. Users who constantly enter and exit staking do not keep the same long-term multiplier as users who remain staked continuously. Because POWER affects rewards, resetting it has a real impact on the user’s position in the staking system. ### Reward withdrawal options When a user earns staking rewards, they can choose how to receive or use them. One option is to claim rewards as ALGO to their wallet. This gives the user direct access to the value generated from staking. The alternative option is to use the reward value inside Sealed as credits or subscription access. This option is designed for users who actively use the app and prefer to convert their rewards into communication capacity instead of withdrawing ALGO. ### 10% discount for in-app usage If a user chooses to receive their staking reward value as Sealed credits or subscription access instead of withdrawing ALGO, they receive a **10% discount**. This means the same reward value gives the user more utility inside the Sealed app than it would if they withdrew ALGO and used it separately. The purpose of this discount is to encourage ecosystem circulation. Users who earn rewards can keep value inside Sealed, use the app more efficiently, and connect staking directly with product usage. ### Utility summary SLD utility is built mainly around staking rewards, POWER, and optional in-app use of earned rewards. Users who stake SLD can receive ALGO rewards from protocol revenue in 30-day intervals, grow their POWER over time, and optionally use rewards for Sealed credits or subscriptions with a 10% discount. Staking is the main utility of SLD because it connects tokenholders directly to protocol-generated rewards. # Buyback & Burn Buyback & Burn is an automated mechanism designed to reduce the circulating supply of SLD using real protocol revenue. Instead of relying on manual buybacks or occasional burn events, Sealed uses smart contracts to make the process systematic. When the protocol generates eligible revenue, a defined portion is routed to the Buyback & Burn contract. That contract uses ALGO to buy SLD from the market, and the purchased SLD is later sent to the burn contract. The goal is to make token burning directly connected to real usage of the Sealed protocol. ### Revenue-based burning The Buyback & Burn mechanism is funded from protocol revenue, not from new token emissions. This means SLD is burned only when Sealed generates eligible revenue through actual protocol activity. A defined share of this revenue is allocated to the Buyback & Burn contract. The contract receives ALGO, uses it to acquire SLD, and removes the purchased SLD from circulation. This creates a real-yield burn model: the stronger the protocol revenue, the more value can flow into SLD buybacks and burns. ### 30-day settlement cycle The Buyback & Burn mechanism uses a **30-day settlement cycle**. At the end of each 30-day period, the contract calculates the amount of ALGO allocated to Buyback & Burn from eligible protocol revenue. This 30-day amount becomes the budget for the next buyback cycle. Instead of spending it all at once, the contract spreads the buybacks across the following 30 days. This makes the mechanism easier to account for while still keeping market execution gradual. ### Five-minute buyback intervals Even though the settlement cycle is based on 30-day periods, buybacks are still executed in small, regular portions. The 30-day buyback budget is divided into 5-minute intervals across the cycle. The contract uses each portion to buy SLD from the market over time, instead of executing one large buyback. This creates steady buy pressure and reduces the risk of sudden market impact. ### Daily burning SLD purchased through the buyback mechanism is burned every 24 hours. This means buybacks happen continuously in small 5-minute portions, while burning happens once per day. The burn process removes the accumulated purchased SLD from circulation by sending it to the burn contract. This keeps the burn process frequent and transparent without requiring every small buyback to trigger a separate burn event. ### Smooth market impact The buyback amount is split into small, regular purchases to avoid sudden market impact. If a large 30-day buyback budget were used all at once, it could create a short-term price spike followed by unstable market behavior. By spreading purchases into 5-minute intervals, Sealed reduces the risk of a pump-and-dump effect and makes buyback pressure more gradual. This structure is designed to make the mechanism healthier and more predictable for the SLD market. ### Expired value and burns Unused value can also become eligible for the Buyback & Burn mechanism. If ALGO connected to a subscription is not claimed within one year, if subscription-based credits expire, or if individual credits expire after one year, that value can be classified as protocol revenue. Once it becomes revenue, the portion assigned to Buyback & Burn follows the same process: ALGO is routed to the contract, included in the 30-day settlement cycle, divided into 5-minute buyback portions, used to buy SLD, and the purchased SLD is burned every 24 hours. ### Buyback & Burn summary Sealed’s Buyback & Burn mechanism is automated, revenue-based, and executed through smart contracts. Eligible protocol revenue is settled every 30 days, routed to the Buyback & Burn contract, divided into 5-minute buyback portions, and used to buy SLD gradually over time. Purchased SLD is burned every 24 hours. This creates a real-yield-based burn model connected to protocol usage, while reducing sudden market impact through small, regular buybacks. # DAO The Sealed DAO is the community governance layer of the SLD token ecosystem. It is designed to give stakers a structured way to propose, discuss, and vote on how part of the ecosystem allocation should be used. The DAO is not limited to one predefined direction. Its purpose is to let the staking community decide what initiatives are worth supporting. Proposals may relate to Sealed, privacy, the Algorand ecosystem, tokenholder value, community growth, or other ideas that stakers believe are important. ### DAO allocation The DAO receives **20% of the total SLD token supply**. This allocation is divided into two parts. Half of the DAO allocation is placed in permanent staking, while the other half remains available for proposals and ecosystem spending. This structure gives the DAO both long-term alignment and usable capital. The permanently staked part supports the long-term staking and governance model, while the available part can be used to fund approved proposals. ### Proposal creation Community members who stake SLD can create proposals. A proposal can request funding for any purpose, as long as it follows the DAO rules and receives enough support from stakers. To create a proposal, the proposer must stake enough SLD to represent at least **10% of the proposal’s dollar value staked**. This means that larger proposals require the proposer to have more value staked. The goal is to make proposal creation open, but still require meaningful alignment from the person submitting the request. ### Proposal funding A proposal can request funding in **ALGO** or **SLD**. If the proposal requests SLD, the funds come from the non-staked part of the DAO allocation. This keeps the permanently staked DAO allocation untouched, while still giving the community an active pool for approved initiatives. Examples of possible proposals may include privacy-focused projects, Algorand ecosystem initiatives, community programs, additional staking rewards, or SLD buyback and burn actions. These are only examples. The final direction depends on what the staking community proposes and approves. ### Discussion period Every proposal enters a **one-week discussion period** before voting begins. During this period, stakers can review the proposal, ask questions, challenge assumptions, suggest changes, and decide whether they want to participate in the vote. To move from discussion to voting, at least **30% of stakers outside the DAO allocation** must declare that they want to vote on the proposal. This declaration step is important because it prevents proposals from moving forward without enough interest from the active staking community. A strong proposal should clearly explain what it requests, why it matters, how much funding is needed, who is responsible for execution, and what the expected outcome is. ### Voting period After the discussion period, an eligible proposal enters a **one-week voting period**. During this time, declared SLD stakers vote on whether the proposal should be approved. For a proposal to pass, at least **51% of voting power from participating voters must vote in favor**. If a staker did not declare participation during the discussion period and does not vote, they are treated as abstaining. If a staker declared participation but does not vote before the deadline, they are counted as voting against the proposal. This structure encourages voters to declare participation only when they actually intend to vote, while still allowing inactive or undecided stakers to abstain. ### Voting power Voting power in the Sealed DAO is based on two factors: the amount of SLD staked and the user’s **POWER** multiplier. A user who stakes more SLD has more base voting power. However, long-term staking is also rewarded through the POWER system. This means governance power is not based only on how many tokens someone holds, but also on how long they keep them staked. This design encourages long-term alignment instead of short-term voting behavior. ### POWER multiplier POWER is a staking multiplier used for both staking rewards and DAO voting power. When a user starts staking SLD, their POWER multiplier begins at **1x**. Each day, the multiplier increases by **0.01x**, until it reaches a maximum of **4x**. This means that users who keep their SLD staked for longer gradually gain more influence and higher staking reward weight. The longer a user remains committed, the stronger their POWER becomes. However, POWER resets if the user unstakes any amount of SLD. Even removing a small part of the stake resets the multiplier. This creates a strong incentive to remain staked continuously. ### Project veto rights The Sealed project keeps the right to veto proposals. This is a safety mechanism. DAO governance can support ecosystem growth, but it should not be able to harm the protocol, weaken privacy, misuse treasury resources, or force decisions that create legal, security, or operational risks. The Sealed project can also submit its own proposals. This allows the core team to request DAO support for initiatives that align with the project roadmap, ecosystem expansion, or strategic needs. ### DAO summary The Sealed DAO controls 20% of the total SLD supply, split between permanent staking and an active proposal pool. SLD stakers can create proposals, discuss them for one week, and move them to voting only if at least 30% of non-DAO stakers declare participation. To submit a proposal, a staker must hold at least 10% of the proposal’s dollar value in staked SLD. Voting lasts one week, and a proposal passes if at least 51% of participating voting power supports it. Voting power depends on both the amount of SLD staked and the POWER multiplier, which grows from 1x to 4x over time and resets when any SLD is unstaked. This model is designed to reward long-term commitment, give the community influence over DAO resources, and keep proposal creation open while still requiring alignment and active participation from stakers. # Compliance # Privacy Policy # Terms of service # regulamin # Staking terms # Subscription privacy policy # Risks annotations