Partnerships & interoperability
Last updated: June 2026
SELF is a privacy-first platform built around a sovereign client: keys, decryption, and validation run in the user’s browser. The server stores encrypted blobs and routes traffic; it does not hold user secrets or participate in consensus on a partner’s behalf.
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 enquiries need both kinds of relationship; some need only one.
This is not a limitation; it is the product. Our goal is one clear compatibility philosophy with a small set of well-defined patterns, rather than a custom integration negotiation for every enquiry.
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 technical interoperability lives (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
All partner-facing technical patterns share 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
Technical patterns (Zone 2)
1. SELF Interop Profile
A published specification of what partners may do without touching SELF core. Partnership means “we implement the profile,” not merging codebases or sharing databases.
The profile covers consent requirements, ciphertext formats, attestation expectations for compute partners, and explicit out-of-scope items. Partners can be listed as verified compatible once they meet the published bar.
Suited to: protocol teams, infrastructure vendors, and generic “integration” requests.
2. Client capsules
Partners ship a browser-side module (for example WASM) that the SELF PWA loads when the user enables it. SELF core, including vault, messenger, and validator, stays unchanged. The capsule encrypts locally, talks to the partner from the client, and decrypts locally.
Suited to: AI and agent stacks, cross-chain wallets, MCP-style tools, interactive confidential compute.
Partner tokens in SELF Wallet: A protocol with its own token can interoperate through a client capsule in SELF Wallet, not a server-side or custodial integration. The user opts in; signing and key material stay in the browser; SELF does not hold partner assets or merge another protocol’s token into SELF Chain core. Display, send, and receive flows run client-side against the partner network, the same trust model as other wallet adapters. Listing or distribution of any token remains the partner’s regulatory responsibility.
3. Encrypted job queue
A generic 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
The API only ever sees job identifiers and blob pointers, never plaintext prompts, payloads, or outputs.
Suited to: confidential inference, GPU and batch AI, TEE and attested compute providers.
Capsules and the job queue use the same trust model; capsules for interactive flows, the job queue for async 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” enquiries, enterprise chains.
Learn more: About SELF (Constellation architecture) · SELF Chain
White-label
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. An optional confidential compute tier, powered by attested third-party suppliers, can be offered for workloads that must remain hidden from the platform operator, not only from other users.
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 | Interop Profile + verified compatible listing |
| Add AI, agents, wallets, or interactive tools for SELF users | 2 | Client capsule |
| Expose your protocol token inside SELF Wallet (user opt-in, non-custodial) | 2 | Client capsule in Wallet |
| Run confidential or GPU compute on user jobs | 2 | Encrypted job queue + 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) | White-label; add confidential tier if compute must stay off-operator |
| Combined technical + commercial deal | 1 + 2 | Zone 1 agreement plus one Zone 2 pattern (e.g. white-label + job queue) |
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. Most combined deals pair a Zone 1 commercial path with one Zone 2 pattern and, where useful, a published 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 enquiry 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 via email with your zone(s), proposed pattern, and a short summary.
We review every enquiry against the 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 Chain, Proof-of-AI, browser validators, enterprise chains
- 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.