Partnerships & interoperability
Last updated: August 2026
SELF is a privacy-first platform built around a sovereign client: key derivation, decryption, and validation run in the user’s browser. For protected content, the server stores ciphertext and routes traffic, while the keys required to read it remain in the browser. Operational services handle the account, routing, and external mail data needed to deliver the product.
If you are exploring a technical or commercial partnership with SELF, this page describes how we work with external projects without compromising that architecture.
Our approach
We don’t integrate at the infrastructure layer. We interoperate at the client layer, with encrypted payloads, explicit user opt-in, and verifiable execution where compute is involved.
For technical interoperability, partners are optional capabilities the user turns on, not shared backends or merged trust domains. The same principle applies across AI, messaging, vault, mail, and chain: full privacy inside SELF, pragmatic bridges outside when the user chooses.
Commercial partnerships follow a different shape: contract and DPA, without opening product integration or user data paths. Many inquiries need both kinds of relationship; some need only one.
This boundary is central to the product. Our goal is one clear compatibility philosophy with a small set of well-defined patterns that partners can understand and adopt.
Trust boundaries
SELF scopes every partnership discussion across three trust zones:
| Zone | What it covers | Partner access |
|---|---|---|
| Sovereign (Zone 0) | Recovery phrase, vault decryption, validator keys, consensus, block building and voting | Never |
| Operator (Zone 1) | EU hosting, mail routing, WebRTC signaling, rate limits, billing | Commercial contract / DPA only, not a product integration surface |
| Opt-in partner (Zone 2) | Attested compute, cross-chain tools, external AI or agents, scoped identity handoff | User consent + ciphertext (or client-side-only interaction) |
Partnerships never involve Zone 0. They may use Zone 1, Zone 2, or both:
- Zone 1 is for commercial and operator relationships only (contract, DPA). White-label deals and supplier agreements typically start here. It is not a technical product integration surface.
- Zone 2 is where proposed technical interoperability patterns are scoped (user consent, ciphertext, client-side adapters, encrypted job queues).
When someone asks to “integrate” a product or workload, that always means Zone 2. Zone 1 alone is fine for commercial partnerships that do not touch user data paths.
For technical integration, name workloads in Zone 2, with attestation if you run compute on user data. For commercial-only partnerships, Zone 1 may be sufficient on its own.
How interoperability works
The Zone 2 designs below are proposed reference partnership patterns for scoping future integrations. They are not delivered SELF App features. Each proposed pattern follows the same rules:
- No server-side decryption of user content for partner features
- No hosted validators, block builders, or privileged chain roles
- User-initiated actions only
- Ciphertext in and ciphertext out, or interaction that stays entirely in the browser
Compatible partnerships fall into two groups by zone:
- Zone 2: three technical patterns (below), for anything that touches user data or product interop
- Zone 1: two commercial paths (below), for branded deployments, Constellation onboarding, and supplier agreements; optional Zone 2 add-ons when confidential compute or client-side interop is needed
Proposed reference technical patterns (Zone 2)
1. SELF Interop Profile (proposed reference pattern)
The proposed SELF Interop Profile would specify what partners may do without touching SELF core. A partnership following this reference pattern would implement the profile without merging codebases or sharing databases.
The proposed profile would cover consent requirements, ciphertext formats, attestation expectations for compute partners, and explicit out-of-scope items. A future verification process could list partners as verified compatible once they meet a published bar.
Suited to: protocol teams, infrastructure vendors, and generic “integration” requests.
2. Client capsules (proposed reference pattern)
Under this proposed pattern, partners would ship a browser-side module (for example WASM) that the SELF PWA could load when the user enables it. SELF core, including vault, messenger, and validator, would stay unchanged. The capsule would encrypt locally, talk to the partner from the client, and decrypt locally.
Suited to: AI and agent stacks, cross-chain wallets, MCP-style tools, interactive confidential compute.
Proposed partner-token pattern for SELF Wallet: A protocol with its own token could interoperate through a client capsule in SELF Wallet. The user would opt in; signing and key material would stay in the browser; SELF would not hold partner assets or merge another protocol’s token into Celestial core. Display, send, and receive flows would run client-side against the partner network. Listing or distribution of any token would remain the partner’s regulatory responsibility.
3. Encrypted job queue (proposed reference pattern)
A proposed reference pattern for asynchronous attested compute:
- The client encrypts the job and parameters
- The encrypted blob is uploaded (same object-storage model as SELF Vault)
- The partner pulls the job and runs it in isolated or attested compute
- The partner returns an encrypted result blob
- The client decrypts the result
In this proposed design, the API would see job identifiers and blob pointers and would not receive plaintext prompts, payloads, or outputs.
Suited to: confidential inference, GPU and batch AI, TEE and attested compute providers.
The proposed capsules and job queue share the same reference trust model: capsules for interactive flows and the job queue for asynchronous workloads.
Commercial paths (Zone 1)
These paths start with commercial and operator agreements (Zone 1). They may add Zone 2 patterns later if the deal includes user-facing interop or confidential compute.
Constellation partnership
Instead of embedding a partner inside SELF App, enterprises and protocols can launch their own Constellation, a sovereign chain on the SELF platform with their rules, tokenomics, and compliance model. SELF App remains the flagship consumer Constellation; inter-chain bridges connect neighbours when ready.
Suited to: other L1 and protocol teams, “build on your stack” inquiries, enterprise chains.
Learn more: About SELF (Constellation architecture) · SELF App Constellation
White-label (delivered capability)
Organizations can deploy a branded messenger and productivity suite on SELF’s EU stack, with end-to-end encryption where the product already supports it. This white-label capability is delivered today.
A confidential compute tier is a proposed reference partnership pattern for workloads that would use attested third-party suppliers and require isolation from other users and the platform operator. It is not a delivered SELF App or white-label feature.
Suited to: regulated industries, enterprise deployments, TEE vendors as suppliers to a branded product (not as a replacement for SELF’s core fleet).
What we don’t do
The following are out of scope for partnership and will not be offered as integrations:
- Hosting validators or performing block building on behalf of users
- Shared user databases, identity lakes, or cross-tenant analytics
- Server-side decryption to power partner features
- Plaintext webhooks or pipelines for AI, analytics, or monitoring
- Replacing SELF’s core EU compute and storage fleet with a partner’s platform
If your proposal requires any of the above, it conflicts with SELF’s sovereign-client architecture.
Choosing a path
| Your goal | Zone | Typical path |
|---|---|---|
| Publish a protocol or standard alongside SELF | 2 | Proposed Interop Profile + future compatible listing |
| Add AI, agents, wallets, or interactive tools for SELF users | 2 | Proposed client capsule pattern |
| Expose your protocol token inside SELF Wallet (user opt-in, non-custodial) | 2 | Proposed client capsule pattern in Wallet |
| Run confidential or GPU compute on user jobs | 2 | Proposed encrypted job queue pattern + attestation |
| Reach SELF users without deep coupling | 2 | E2E messenger channels + scoped identity handoff |
| Launch your own sovereign chain | 1 | Constellation partnership |
| Ship a branded product to your customers | 1 (opt. 2) | Delivered white-label capability; proposed confidential tier where scoped |
| Combined technical + commercial deal | 1 + 2 | Zone 1 agreement plus one proposed Zone 2 reference pattern |
Zone 1 alone is enough for commercial-only deals. Zone 2 is required when the proposal touches user data, client-side interop, or attested compute. Combined proposals can pair a Zone 1 commercial path with one proposed Zone 2 reference pattern and, where useful, the proposed Interop Profile.
Precedent: mail interoperability
SELF Mail is end-to-end encrypted inside the app. External mail still works through standard protocols, but SELF does not decrypt user mail on the server to make third-party features easier. Partner interoperability follows the same hybrid: maximum privacy inside, user-controlled bridges outside.
Getting started
- Read this page and confirm whether your inquiry is Zone 1 (commercial only), Zone 2 (technical interop), or both.
- Describe the proposal: for Zone 1, the commercial model (white-label, Constellation, supplier role); for Zone 2, the workload, what the user opts into, what stays encrypted, and whether you need attested compute.
- Pick a pattern from the tables above (commercial path, technical pattern, or both).
- Contact us through SELF App Settings → Contact Us with your zone(s), proposed pattern, and a short summary.
We review every inquiry against the proposed Interop Profile principles. Zone 2 pilots are scoped narrowly: one named workload, explicit user consent, ciphertext or client-side-only data paths. Zone 1 pilots are scoped as commercial agreements without product integration unless Zone 2 is also in scope.
Related documentation
- About SELF, ecosystem overview and Constellation architecture
- SELF App Constellation, Proof-of-AI and browser validation
- SELF App, privacy-first product overview
- Security & privacy, zero-knowledge architecture
This page describes SELF’s partnership philosophy and compatibility model. It is not a commitment to build any specific integration or to onboard any particular partner.