One mission—Breach-Nullification—delivered by two distinct products: the SELA Protocol for personal digital identity, and the Emet zero-trust database security layer for protected organizational data.
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 protects personal identity through a self-custody protocol. Emet protects configured database fields through an inline zero-trust wire proxy. Their architectures are distinct and purpose-built for different sides 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 uses your BIP39 seed phrase or approved threshold recovery.
An inline PostgreSQL-wire proxy that encrypts selected sensitive fields with AES-256-GCM before write commit. The database stores authenticated ciphertext for protected columns, while authorized reads are decrypted transparently for the application.
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 approved 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 is a separate inline database wire proxy that applies AES-256-GCM to configured sensitive fields before they are committed to storage.
Military-grade symmetric encryption for document payload
Asymmetric encryption of the AES key with user's public key
12-word mnemonic or an approved threshold recovery policy to restore access
Selective AES-256-GCM encryption protects configured fields before database write commit
