Two Products — Two Protocols
The SELA Protocols
One mission—Breach-Nullification—delivered by two distinct protocols: the SELA Protocol for personal digital identity, and MPC-SQL for organizational database security through Emet.
One mission—Breach-Nullification—delivered by two distinct protocols: the SELA Protocol for personal digital identity, and MPC-SQL for organizational database security through Emet.
Traditional cybersecurity focuses on preventing breaches—building higher walls, stronger firewalls, more complex encryption around centralized data stores. This approach has a 100% failure rate over sufficient time.
SELA takes a fundamentally different approach: make breaches irrelevant. If the server never stores readable personal data, there is nothing meaningful to steal. The SELA Server acts strictly as a "Blind Relay" and "encrypted vault."
Even in the event of a complete server compromise, no readable user data is exposed. The attacker finds only encrypted blobs that require the user's private key—which exists only on the user's device.
SELA solves the breach crisis from both sides: individuals protect their identity with the SELA Ecosystem, and organizations protect their databases with Emet. Each product runs on its own protocol, purpose-built for its side of the problem.
A self-custody identity protocol. Your credentials live encrypted on your own device, verified through Zero-Knowledge Proofs and anchored on the Polygon blockchain. Hybrid encryption (ECIES + AES-256-GCM) means the server only ever stores blobs it cannot read. Recovery through your BIP39 seed phrase or MPC-based threshold recovery.
A database security protocol built on Multi-Party Computation. Sensitive columns are encrypted with keys mathematically split across independent parties—no single party can ever decrypt alone. Split-brain storage and zero-knowledge mathematical shredding keep cloud databases completely blind to plaintext PII.
Inside the SELA Protocol—the identity side—each layer serves a distinct purpose in the trust chain, from blockchain anchoring to encrypted storage to business logic.
The immutable trust anchor. Every verification event in SELA produces an on-chain hash—the audit trail. Public key management and verification logging happen here. No PII is ever written to Layer 1. Only cryptographic hashes that prove events occurred without revealing any personal data.
The self-custody storage layer of the ecosystem. Credentials and documents are encrypted at rest on the user's device—hardware-backed by the Secure Enclave or Android Keystore and gated by biometrics. For recovery, data is wrapped with a random AES-256-GCM key that only the user's private key can unlock: the server stores an opaque blob it cannot decrypt, and the user restores access with their seed phrase or MPC-based threshold recovery.
The business logic that powers SELA Link and SELA Connect. Two verification modes: Proof (ZKP)—confirms a fact without sharing data (e.g., "Over 18" returns True, no dates shared). Doc (Restricted Sharing)—for regulatory KYC where seeing the ID is mandatory: a time-limited, view-only document link with no download, and a temporary key discarded after the session.
Before any request reaches the user's device, SELA Server validates the requesting organization—only active, verified partners can initiate a verification flow. Anything else is blocked at the server level, so users are never bothered by spam.
SELA Link agents can call and email users without ever seeing their real contact details. The server bridges calls via Click-to-Dial and relays email with DID-based masking—neither side sees the other's number or address.
The SELA Server is the Blind Relay of the ecosystem—the back-office and router that orchestrates every verification handshake while remaining Zero-Knowledge regarding PII. It never sees, stores, or processes personal data in readable form.
Stores only AES-256-GCM encrypted blobs for SELA Vault recovery. It cannot decrypt any stored data—only the user's private key, which never leaves the device, can unlock the vault.
Anchors every verification event on the Polygon blockchain as a cryptographic hash. Creates an immutable, regulator-ready audit trail without ever exposing content.
Approves or declines SELA Link and SELA Connect requests based on partner status. Only active, verified organizations can initiate verification flows.
Manages DID-based masking for phone calls and emails. Bridges communication between organizations and users without ever exposing the real contact details of either party.
The SELA Protocol uses ECIES (Elliptic Curve Integrated Encryption Scheme) for vault operations. Each document is encrypted with a unique AES-256-GCM key, then that key is encrypted with the user's public key derived from their seed phrase. Emet extends the same zero-knowledge principle to databases with MPC-SQL, where decryption keys are split across independent parties.
Military-grade symmetric encryption for document payload
Asymmetric encryption of the AES key with user's public key
12-word mnemonic or MPC-based threshold recovery to restore keys
Column-level database keys mathematically split—no single party can decrypt alone
