SEALED — ZAMA DEVELOPER PROGRAM APPLICATION
(Startup Track) @Jan @alex
QUICK RECAP
Sealed is a protocol that lets organizations with sensitive data (hospitals, banks, law firms, research labs) get AI trained on that data without the raw data ever being exposed to anyone — not the model provider, not the compute network, not Sealed itself. Zama’s FHE stack is the core enabling piece: it’s what makes “train on data you can never see” actually possible.
WHY ZAMA SPECIFICALLY
Homomorphic encryption is the only piece of this that can’t be substituted. Everything else (compute marketplace, storage) has multiple viable providers — Zama’s TFHE-rs / Concrete ML / fhEVM is the one dependency the whole protocol is built around, since it’s what lets computation run on encrypted data without ever decrypting it.
ARCHITECTURE — THE REAL COMPONENT MAPPING
-
Data Owner encrypts the raw data client-side using Zama’s TFHE-rs / Concrete ML. The decryption key never leaves the Data Owner’s side.
-
Ciphertext is deployed as a compute workload on Akash (via an SDL manifest, matched through Akash’s Provider Marketplace to a GPU-equipped Provider) — decentralized compute chosen for cost, not exclusivity; this layer is swappable.
-
A dedicated Bittensor Subnet handles the AI work: Miners train/run models directly on the ciphertext using Zama’s fhEVM-compatible execution, never decrypting it; Validators score the quality of the encrypted output through Bittensor’s Yuma Consensus.
-
Encrypted datasets and model checkpoints persist via Filecoin storage deals.
-
The encrypted result returns to the Data Owner, who holds the only decryption key and decrypts locally.
Flow: Data Owner → [TFHE-rs/Concrete ML encryption] → Akash compute lease → Bittensor Subnet (Miners train, Validators score via Yuma Consensus) → Filecoin storage → back to Data Owner → local decryption.
WHY NOW
Every piece above already exists and is live today, including Zama’s own stack. The gap is that nobody has wired them together specifically for regulated data — that’s the opening, and it’s Zama’s FHE tooling that makes it viable rather than theoretical.
HONEST LIMITATION
FHE computation is still slow. This is a “regulated industries, narrow high-value tasks” play first (healthcare diagnostics AI, legal-tech document analysis, financial fraud detection), not a mass-market or frontier-LLM-training play yet — a limitation the Zama team will recognize better than most.
TARGET VERTICALS
Primary: healthcare, legal, financial services (fraud detection).
Also under consideration: fire brigades/emergency services, agricultural chemical businesses, and other crypto/Web3 projects as early technical partners.
STAGE & ASK
Early-stage: the architecture is worked out and every dependency it needs is already live, but there’s no capital or built prototype behind it yet. Applying to the Startup Track for support building an initial proof of concept on Zama’s stack — a working demo of one narrow use case (e.g. encrypted fraud-detection scoring) rather than the full protocol at once.
TEAM
Two-person team, already collaborating on projects together: Tristan (backend) and Jocelyn (frontend) — a working split, not a rigid boundary.
Looking for some honest direction and input. Also for some technical collaborators for ground up builds such as this project and others to come. Im front end mostly “the ideas guy” and would love someone with a little patience and openness to teaching small parts. Any curious/interested parties, funding or anything useful towards deployment be it stages through to completion will be taken in full consideration.
Cheers J
