Sealed - Decentralized Post-Quantum Communication - xGov Proposal 3534141276

[igor.m.sealed]

SEALED - DECENTRALIZED POST-QUANTUM COMMUNICATION

Amount Requested: 400,000 ALGO
Category: Mass Adoption/Real Utility
Type: Retroactive
Stage: Mainnet
Repository: https://github.com/sealed-channel/sealed
Download and social media: https://linktr.ee/sealedchannel

I. What is Sealed?
Sealed is a decentralized, post-quantum communication infrastructure built on Algorand that enables users to exchange encrypted messages without relying on centralized servers, phone numbers, emails, or traditional identity systems providing the real anonymity. By enabling encrypted messaging without centralized servers or user identity requirements, the project demonstrates how Algorand can be used as a foundation for secure, real-world communication infrastructure. We see the real solution for privacy violations in post quantum encryption that we can develop well on Algorand.

Sealed has been actively building presence within the Web3 ecosystem through participation in industry events, conferences and direct engagement with the crypto community. The project has been presented and discussed during major blockchain events, where Sealed was introduced to a broader audience of developers, investors and ecosystem participants, including:

• Next Block Expo (Warsaw, Poland)

• Crypto Community Conference (Łódź, Poland)

• ETH Warsaw (Katowice, Poland)

• Cashifam (Rzeszów, Poland)

  These events allowed the project to validate the concept, gather feedback and improve the solution. Sealed managed to establish early relationships within the industry and expand the team by blockchain industry experts who are already working on the development of current processes as well as working on the future aspects of the project such as ecosystem growth, monetization and business flow.

II. How is it profitable?
Sealed follows a hybrid monetization model combining low-cost usage, subscriptions and infrastructure-level integration.

At the core, Sealed uses a pay-per-message model, where users can send a limited number of messages for free (sponsored by the protocol), and continue usage beyond that limit at a low fixed cost (approximately $0.003 per message). This creates a scalable revenue stream directly tied to network usage. In addition, Sealed will introduce subscription tiers that provide access to advanced features such as group communication, higher message limits, desktop usage and premium privacy functionalities. This allows the product to capture value from more active users and professional use cases.

As the protocol evolves, Sealed is designed to expand into an infrastructure layer for third-party integrations, enabling wallets, dApps and businesses to use Sealed for private communication, notifications and authentication flows. These integrations can generate additional revenue through API access, enterprise plans or usage-based pricing.

This model ensures that monetization is aligned with real usage, while maintaining accessibility for new users through sponsored onboarding.

III. Technical Scope and development status of the project:
Sealed is live and in active development stage, with a working prototype of the core messaging functionality built on blockchain infrastructure. The application is already available in an early version on Google Play, allowing initial user testing and validation of the core concept, coming to Apple Store soon. The current focus is on transitioning from prototype to a production-ready mainnet version, improving scalability, usability and security of the protocol.

1. Core Cryptographic System (Implemented)
Sealed implements a production-ready end-to-end encryption system designed for decentralized environments:
1.1. Hybrid Key Exchange (Post-Quantum Ready)
Implemented combination of ML-KEM-512 (NIST-standard post-quantum KEM) and X25519 elliptic curve key exchange
→ ensures both current and future resistance against quantum attacks
1.2. Perfect Forward Secrecy (PFS)
Ephemeral keys are generated per message session
→ past communications remain secure even if long-term keys are compromised
1.3. Message Encryption Pipeline
Fully implemented pipeline:
1). Key agreement (hybrid ML-KEM + X25519)
2). Symmetric encryption of message content
3). Message padding (fixed-size obfuscation)
4). Transmission to blockchain layer
1.4. Message Padding Mechanism
All messages are padded to uniform size (1KB)
→ mitigates size-based metadata analysis attacks

2. Blockchain Messaging Layer (Implemented)
Sealed uses blockchain infrastructure as a transport and persistence layer:
2.1. On-Chain Message Broadcasting
Encrypted payloads are embedded into blockchain transactions (Algorand TestNet)**
2. 2. Decentralized Message Retrieval**
Clients can independently scan blockchain data via RPC (through privacy relay)
→ no reliance on centralized messaging servers
2.3. Self-Sovereign Identity Registration
Users register public keys on-chain by signing transactions
→ no email, phone number, or centralized identity required

3. Device-Side Security Architecture (Implemented)
3.1. Local Key Ownership (Self-Custody)
Private keys are generated and stored exclusively on user devices
→ no key material is transmitted or stored externally
3.2. Secure Storage Integration
Platform-native secure storage:
1). iOS Keychain
2). Android Keystore
3.3. Local Encrypted Database
SQLite-based local storage for messages and metadata
→ enables offline access and decryption
3.4. Offline Decryption Capability
Messages are decrypted locally without network interaction

4. Privacy Infrastructure Layer (Implemented)
4.1. OHTTP Relay Integration
All network requests are routed through Oblivious HTTP relay
→ hides client IP from blockchain nodes and indexer services
4.2. Tor Routing Support
Additional anonymization layer via Tor network
→ protects against network-level tracking
4.3. Alias-Based Communication (Anonymous Channels)
Users can communicate through alias wallets / channels
→ prevents direct linkage between primary identities

5. Indexer & Notification System (Implemented – Optional Layer)
5.1. Privacy-Preserving Indexer
Dedicated indexer processes blockchain events to detect incoming messages
5.2. Push Notification System
Firebase/APNs integration for real-time notifications
5.3. Limited Trust Model
Indexer:
1). cannot decrypt messages
2). only processes metadata required for notification delivery

6. Cross-Platform Application Layer (Implemented)
6.1. Flutter-Based Multi-Platform App
1). iOS (full support)
2). Android (full support)
3). Desktop/Web (development-ready)
6.2. Wallet Management System
1). BIP39 mnemonic generation & recovery
2). On-chain identity registration
6.3. Messaging Interface
1). Send / receive encrypted messages
2). Alias chat support

7. Testing & Validation (Implemented)
7.1. Unit tests for cryptographic services
7.2. Integration test for real message transmission
7.3. End-to-end flow validation:
encryption → blockchain → retrieval → decryption

8. Security Model (Defined & Implemented)
Sealed includes a defined threat model covering:
8.1. Protected:
1). Message content (end-to-end encrypted)
2). Sender/receiver linkage (via alias system)
3). IP address (via OHTTP + Tor)

8.2. Partially Mitigated:
Timing analysis (reduced via padding and relay routing)

8.3. Assumptions:
1). User device security
2). Blockchain integrity (Algorand consensus)
3). Optional indexer availability

IV. Our upcoming deployments:
-Smart contract-based communication layer
We are introducing a dedicated smart contract that allows Sealed messages to be reliably recognized and processed on-chain. This creates a structured and scalable communication protocol on Algorand.
-Private indexer for encrypted messages
We are building a custom private onion-based indexer that enables real time detection and retrieval of encrypted messages while maintaining a serverless and privacy-preserving architecture.
-QR-based onboarding and interaction
Instead of manually entering wallet addresses or private keys, users will be able to connect and communicate using QR codes, significantly improving usability and onboarding for non-technical users.
-Offline key exchange for Alias Chat
We are implementing an offline key exchange mechanism that allows users to establish highly private communication channels without exposing or linking their primary wallet identities.
-Emergency security layer (key deletion & access protection)
We are introducing an emergency mechanism that allows users to instantly delete keys, alias chats and access credentials using a dedicated code. This feature is designed for high-risk environments and increases user control over sensitive data.
-Group communication functionality
Sealed will support private group chats, expanding the protocol from 1:1 communication to broader use cases such as communities, teams and organizations.
-Desktop application with secure key handling
We are developing a desktop version of Sealed, including the ability to securely import or scan private keys, enabling more advanced and professional use cases.
-Sponsored messaging model (freemium layer)
Users will be able to send a limited number of messages per day for free, with transaction fees sponsored by the protocol. Beyond the free limit, messages will be available at a low fixed cost (~$0.003 per message).
This approach removes initial friction and allows onboarding of users without requiring upfront crypto balances.

V. Funding Request
The requested funding reflects the scope and maturity of the Sealed project, which has already moved beyond the concept stage and into a working prototype with a fully implemented core architecture.

This proposal represents the first phase of a broader development roadmap, with future milestones planned based on adoption and ecosystem integration. At this stage, Sealed is not starting from zero - the core cryptographic system, blockchain messaging layer, privacy infrastructure and application framework have already been developed and validated. The funding is therefore not intended to initiate development, but to complete the transition from a functional prototype to a production-ready, scalable communication infrastructure on Algorand. The funding will support the implementation of a sponsored messaging model, which plays a key role in user acquisition. By covering initial transaction costs, Sealed removes one of the main barriers to entry in blockchain applications and enables onboarding of non-crypto-native users into the Algorand ecosystem.

Overall, this funding enables Sealed to bridge the gap between a working prototype and a fully usable, production-ready system, significantly increasing its potential for adoption and long-term impact within the Algorand ecosystem.

VI. Team Overview
Igor Makowiecki - CEO
Responsible for overall strategy, execution and ecosystem positioning. Leads business development, partnerships and coordination between technical and non-technical teams. Ensures alignment between product development and real market demand, as well as integration with the broader Algorand ecosystem.

Dominik Stępień - CTO
Leads the technical architecture and implementation of Sealed. Responsible for blockchain integration, cryptographic systems, infrastructure design and delivery of core protocol components, including the transition to mainnet and implementation of smart contract-based communication.

Igor Kamrowski - Product Owner
Oversees product development and feature prioritization. Ensures that complex technical components are translated into usable product features, focusing on user experience, onboarding and real-world usability.

Sebastian Seliga - Chief Ecosystem Officer
Responsible for ecosystem expansion, strategic partnerships and collaboration with Web3 stakeholders. Focuses on integrating Sealed within the broader blockchain landscape and driving adoption through partnerships and community engagement.

Grzegorz Pisula - Head of Marketing
Leads go-to-market strategy, user acquisition and communication. Responsible for positioning Sealed as a privacy-first infrastructure project and driving awareness through content, community building and industry presence.

Grzegorz Pawlica - Head of Design
Responsible for product design, UI/UX and visual identity. Ensures that Sealed remains accessible and intuitive despite the underlying technical complexity, which is critical for onboarding non-technical users.

Thank you for your attention,
Sealed Team

[Atsoc1993]

A heavily vibe-coded, “stateless” (this was probably misconstrued with a logic sig somewhere through prompting) Pyteal contract whose methods’ only validations are asserts that the length of public key passed in as in arg is 32 bytes (and some other arbitrary length assertions)

It’s cool that you guys are putting things on-chain for your already existing mobile app (presumably with inception / primary support on an EVM chain until meeting with DevRel at an event), but how long have you “supported” Algorand on your app and what metrics do you have to support that? If you have on-chain metrics can you please point to the application ID’s from which you obtained them on mainnet?

I personally don’t think integrating Algorand into your existing app costs 400,000 Algo, but if the adoption from the Algorand community is there (not just tweets) it would make sense.

There is no real benefit to the chain’s metrics by submitting these transactions on testnet either. You charge 0.003 cents per message but don’t transmit them on chain and avoid fees through testnet, I think that should be reconsidered personally as it’s taking advantage of infrastructure intended as a testing environment as infrastructure for your communications app.

I don’t see any quantum-secure logic (like supporting falcon accounts), can you point me to this? Or if the messages are encrypted and quantum secure but the accounts are not that kind of defeats the purpose no?

Just some initial thoughts, but this smells a little fishy to me personally.

Edit: Also there are indicators that funding would trigger a transition plan for proactive work and I believe this violates the xGov policy.

Edit edit: Apologies for the EVM assumption, I see your project originates from Solana where you are in production on Solana Devnet for current communications, would it be safe to assume you will be in production on Algorand in Testnet as well?

[igor.m.sealed]

Hey, thanks for the feedback, at the beginning we are so sorry for your bad experience, We suppose that’s because our latest iOS version still is not available on either App Store or Testflight, only the Android one has the latest version and it will be updated on TestFlight in 2-3 days.

The requested amount does not fund migration to Algorand. The app is well developed at this point, completely on Algo. Initially the app was planned to be built on Solana, however we decided on change due to Algo’s post quantum development, which gives us the big advantage in encrypting and keeping up the security of the app.

We do not charge any fees on testnet, before mainnet you can use it freely using testnet ALGO. Falcon is used for encryption of messages. We are about to finish development of top-up smart contract that makes you able to fund app’s wallet anonymously and after that we are going to migrate to mainnet.

You are welcome to join our discord, we can also discuss there!

[Atsoc1993]

I am not sure about the remark about a bad experience, I have not tried the app personally but I am on iOS, not Android.

There are still some points unaddressed if you don’t mind rereading my comment, eg; why Pyteal was used and the lack of proper assertions for sending messages* or why this isn’t necessary?

It might be helpful to adjust your readme’s to reflect that, if I’m understanding correctly, you plan to go to mainnet, and that Solana is no longer supported / planned to be supported — your readme says that Algorand Testnet is your “primary chain” and your legacy chain is Solana Devnet:

I appreciate you clarifying that the funds are for existing developments but if you don’t mind me asking again do you have metrics for community usage? How many messages have been sent on-chain so far from unique Algorand users.

Edit: The Pyteal usage in itself is just a poor indicator of being in touch with current AVM developments, it doesn’t help with my confidence in the competence to execute the integration well, especially with so many resources and friendly developers willing to provide guidance. It feels rushed =\

[Atsoc1993]

You have a prod key exposed in your repo as well….

[Allan]

The wallet mnemonic is not imported from the .env file; it is directly in the deployment code in two files. I know it is only on the testnet, but be careful.

[joe-p]

I posted my concerns with a simillar protocol here: Open-Sourcing AVM Email: Joining Encrypted Communications with Defi: 3524536010 - #26 by joe-p

Much of what I said there also applies here as well. Feel free to quote anything I’ve said in that thread to continue the discussion here.

Also side note, @igor.m.sealed seems to have been caught by the auto mod. I don’t think I have perms to fix but I’m trying to get a hold of someone that does

[uhudo]

Thanks for the proposal and your innovation in encrypted communications!

I agree with the comments of @Atsoc1993 on the use of PyTEAL, and the big question regarding the product’s adoption, including whether that is on Algorand testnet or mainnet. @joe-p also raises excellent points and it would be great if the proposal addressed them.

The proposal also talks about a functional prototype, not a finished product, thus makes it sound as if it is proactive, which is against the xGov program T&Cs.

IMO the proposal should be submitted at a more mature stage of the project (with tangible usage metrics) and/or with a (much) reduced ask, rewritten in an up-to-date framework and a polished repo based on which the community can learn and build upon. The proposal should also make it clearer what it already delivered vs. plans for the future.

[igor.m.sealed]

Hey guys, apologies for late reply, our account got banned.

Addressing the PyTEAL comment - We initially focused strongly on the client side of the app. We’re currently planning out new smart contract allowing users to anonymously top-up their accounts on main-net. Which will be fully implemented in TypeScript.

When it comes to current state of development as testnet, our plan is to gather community feedback in order to find potential vulnerabilities, or ideas how to improve it. But we will switch to mainnet slightly before the voting phase begin.

As of the metrics of the adoption - Sealed has been released in the testnet version not so long ago, with no app ID included, so besides downloads (only few) there is no way to realistically track metrics like users (via wallets) or amount of messages (transaction volume), but after switching to mainnet we want to build and publicly track adoption metrics with a help from Algorand community, so the app is mature enough for voting phase.

Our proposal will soon reflect clearly for which features it applies.

We don’t think much of what you said @joe-p in following proposal applies for us as well (if you think different please provide appropriate questions here) the only similarity we can see is a concern about potential future decryption of messages stored on public blockchain. We use PQ ML-KEM for encryption of each message. Moreover, a feature that partly solves this problem is smart contract that will give you ability to anonymously top-up the in-app wallet, this way you stay anonymous as both receiver and sender of particular message unless someone opens the app on your own device. The SC will be live in the next app version too.

We hope that clarifies all of your concerns, we are open to answer any question regarding Sealed. Stay tune for future updates.

[Atsoc1993]

@igor.m.sealed

We’re currently planning out new smart contract allowing users to anonymously top-up their accounts on main-net. Which will be fully implemented in TealScript

What was the architectural decision behind using Tealscript and not Typescript?

[igor.m.sealed]

@Atsoc1993 Typescript of course, our bad with the typo

[emg110]

Hey @igor.m.sealed ,
Along with all facts other brought to your attention I need to add these too:
1- Having arbitrary data on chain is something I never agree with and liked since in case of success it will just render chain less and less usable for everyone if full archival is needed and in terms of fast catchup even. So I personally think of storing chat messages onchain a bad idea.
2- Given product status and the fact that you are new to ecosystem and also the fact that product does not even started to be used on testnet and also the code quality which renderes it not that re0usable as white label or code to re-use, the ask is very high and I would like to ask you to ellaborate a little about on which basis you cam up with the numbers.
3- Please descibe the values this product and code brings to Algorand and what attracts average users to get onboarded to Algorand using this and also when all of those promised roadmap items are planned to land.
4- Please ellaborate on which confirmations, recommendations, traction or audits this code base has already. some mentions and numbers will help everyone to know the credibility of work at this stage, IMHO

[igor.m.sealed]

Hey, @emg110

1. The only arbitrary data stored on-chain are certain wallet’s usernames and push notification tokens. It makes it more convenient while searching a different app user to start a conversation with and to receive in-app push notification (if decided) when you receive a message. The content of each message is put it transaction’s note field.

2. It is not about current state of development like we pointed out in our latest reply, but mainnet ready-to-use app that we plan to launch soon. We also plan to delay voting phase as long as needed to finish development and possess appropriate and trackable success metrics. We think that when the development for this phase is done, it will reflect our proposal’s value.

3. We consider quite broad utility for both current and not yet associated Algorand users. Trustless, open source and censorship resistant messanger has wide application potential in business, regime countries, entities, governments or overall privacy between two people. Major advantages for Algorand we notice are:

- impact on transaction volume, each message sent is an individual transaction that generates fee;

- Onboarding new user - we aim to create as smooth web2 user flow as possible, he’ll be able to top-up in-app balance via credit card and won’t notice crypto anymore even though the app constantly operate on-chain. This creates constant inflow of funds to Algorand and generates another wave of transctions.

- Mainnet app with anonymous top-up of in-app wallet, simple messages, nickname setup and Alias Chat with offline exchange of keys between devices will be ready soon (we want this part to be delivered by the voting stage). After that we plan to deliver next utilities like sending files/photos, phone calls, Desktop app within next months depdending on development difficulty. Later on we plan to focus on creating trustless business enviornment making you able to manage tasks, store data and have team talks. Everything encrypted, decentalized and web2 friendly.

4. The code is obviously still in development. Like mentioned in our latest answear, we plan to Begin publically tracking adoption data right after launching mainnet, and slightly before beginning voting phase.

[emg110]

Thank you, much better now but regarding your answer to 1 I need to remind you: no matter where you keep that message , in a box or in a txn note , it will be forever part of the chain and one successful messaging app can harm chain reliability and make node keeping more and more resource demanding. for an app with 100000 active users and 20 message per each per day in 240 characters averge will be ~14.5 GB monthly and 175 GB yearly. Now consider several other apps do store arbitrary data on chain as well! Node running and indexers will become so resource thristy and fast catch-up becomes so time consuming that chain may render not feasible to host unless for big enterprises. see the bad chain of effects.
I know everyone can build as they see fir and put as much data as they want on chain and it is not my place to set any rules but as a builder I have warned against such practices in the past and will continue to do so as well.

Just a note: Also keeping messages in notes means that no large message or content can be sent in your messaging system unless exotic methods like byte chunking is applied which makes rendering content slow and much harder to track.

The last part of my comment: The privacy of your system will depend for ever to that encryption algorithm you choose to withhold against all advances in tech since chain history is forever so the only advantage sealed is introducing, privacy is largely vulnerable to technology advancements without any remedy. Which PostQuantum encryption method did you use for sealed?

[vidhyanand]

Problem is with adoption. It would have been great if you have launched the product, waited for three months and applied for the grant. xGovs tend to vote positively if there is adoption.

[igor.m.sealed]

Hey @emg110 we recognise the future problem of storing data on chain and obvious solution is to switch messagin layer to our own L2, when it become a real one. Still we’ll keep Algorand mainnet as settlement and reputaion layer. We’ll also provide an option to converse P2P, if you trust receiver too, if both devices are online in the same time, the device will be using P2P automatically if user prefers to, we switched to smart contract as a way of sending an receiving, but padding is possible and you can keep up to 300 signs in one tx, also we will be keeping the message in a Smart Contract event ABI log field instead of standard note field.. In the future files and photos will be available to be send P2P only. We use ML-KEM algorithm.

[emg110]

As I myself have a WIP P2P communication project at hand I went through the R&D and knew about shortcomings and thats why I suggested what I used for myself and strategies I choosed and found useful and therefore recommended here as well.
Wish you the best of luck and I’m glad it was a little humble help.

[emg110]

You can defer the submission to after when you solved these issues or revise the ask to meet the current delivery

[cusma]

Hi @igor.m.sealed, can you explain why a blockchain is needed at all and why specifically Algorand?