Version 2.0 — Approved for Development
The SELA Protocol
The constitution of digital identity. A set of established rules and procedures designed to provide Breach-Nullification across every interaction in the ecosystem.
The constitution of digital identity. A set of established rules and procedures designed to provide Breach-Nullification across every interaction in the ecosystem.
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.
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.
Allows users to recover their documents if they lose their device, without trusting the server. Data is encrypted with a random AES-256-GCM key, then the AES key is encrypted with the user's public key. The server stores the encrypted blob—it cannot decrypt it. Recovery requires the user's 12/24-word seed phrase to regenerate their private key.
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, generates a signed URL valid for 5 minutes with no download or right-click, temporary key discarded after session.
Before any request reaches the user's app, the SELA Server validates the requesting organization. Is it active and paid? If not, the request is blocked at the server level. Users are never bothered by spam.
SELA Link agents can call users without seeing their phone numbers. The server bridges calls via Click-to-Dial—neither side sees the other's real number. Same applies to email relay with DID-based masking.
Every request from SELA App includes an OS-level Integrity Token (Play Integrity / DeviceCheck). The server verifies this token before processing any vault upload or verification response—ensuring the client is trusted.
The SELA Server is the back-office and router. It is Zero-Knowledge regarding PII—it never sees, stores, or processes personal data in readable form.
Stores only AES-256-GCM encrypted blobs for user recovery. Cannot decrypt any stored data—only the user's private key can unlock the vault.
Logs requests and transactions on-chain via Polygon. Creates an immutable, verifiable trail of every verification event without exposing content.
Approves or declines SELA Link requests based on partner status. Ensures only active, verified organizations can initiate verification flows.
Manages DID-based masking for phone calls and emails. Bridges communication without ever exposing real contact details of either party.
SELA 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 ECDSA public key derived from their seed phrase.
Military-grade symmetric encryption for document payload
Asymmetric encryption of the AES key with user's public key
12-word mnemonic for deterministic key recovery
100,000 iterations with SHA-256 for settlement operations
