Security at Offline Protocol
Offline Protocol is built for environments where trust cannot depend on a reachable server: defense, public safety, payments, and critical infrastructure. Encryption, identity, and a serverless architecture are the default path, not add-ons.
Last updated
Every session is end-to-end encrypted with MLS (RFC 9420). Identities are Ed25519 keypairs whose private keys never leave the device. There is no server in the path, so there is no central store to breach and no single point of failure. Relays forward ciphertext they cannot read. Telemetry is opt-in and emits nothing until your app installs a sink.
Encrypted end to end, on the device
Traffic is encrypted end to end with Messaging Layer Security, the IETF group-messaging standard. Encryption is the default path, not an option you enable.
Every device carries an Ed25519 keypair. Messages are signed and sessions are keyed to identities that verify without any authority to phone.
Private keys are generated and held on the device and are never transmitted. A relay, a peer, or an operator never handles your keys.
Nodes forwarding traffic for the mesh route by envelope, not content. Only session members can decrypt, so relay duty exposes nothing.
Because keys are held on the device and sessions are keyed to OfflineID identities, the security boundary is the session, not the infrastructure. A relay that carries your traffic across the mesh only ever handles ciphertext. There is no vantage point, at a relay, a gateway, or a server, from which the plaintext is visible.
Trust that does not depend on a server
OfflineID is a self-sovereign identity built on Ed25519. Two devices verify each other directly, with no certificate authority to query and no registry to reach. In a jammed or disconnected environment, authentication still completes, because it never needed the network in the first place.
Pairing follows trust-on-first-use: the first verified exchange between two devices establishes the relationship, and subsequent contact confirms the same key. Rotation and revocation are anchored on-chain, so when an identity must be retired, the update propagates across the mesh as nodes touch the internet, without a central server issuing it.
Field observations can be signed at capture, making records tamper-evident end to end. More than 300,000 OfflineIDs have been issued across the network. See how offline identity verification works for the full model.
No server, no single point of failure
A conventional system concentrates risk: one server holds the data, brokers the identities, and routes the messages, so one breach or one outage compromises everything attached to it. Offline Protocol removes the center. Routing, identity, and service discovery all run device to device, so there is no central store to exfiltrate and no chokepoint whose loss silences the fleet.
Telemetry follows the same principle. The protocol emits nothing until your application installs a sink. There is no background beacon, no default phone-home, and no data leaving the device unless you wire it to. When you do install a sink, it carries protocol events on a single stream that you control.
This is a deliberate posture for buyers who cannot accept a third-party dependency in the trust path. The platform gives you transport, identity, and coordination without asking you to route sensitive traffic through anyone else's infrastructure.
Operating under adverse conditions
Jamming and shutdown
When one transport is jammed or an internet link drops, DORS fails over to another radio sub-second. The mesh degrades path by path rather than going dark, and coverage is the fleet itself, not a tower.
Lost links and moving nodes
Multi-hop routing with acknowledgment, retry, and deduplication means a message reroutes around a node that leaves. Delivery is confirmed, not assumed, with an 8-hop TTL bounding every route.
Fully offline operation
Identity verification, routing, and service discovery all run with zero connectivity. There is no server whose loss takes the network down, and no lookup that must succeed for two devices to trust each other.
Offline Protocol is a connectivity, identity, and coordination layer. It does not replace your organization's own operational security, endpoint hardening, or key-custody policy. It gives you a transport and trust model that assumes the network can fail and keeps working when it does.
If you believe you have found a security vulnerability, we want to hear from you. Report it privately to [email protected] or through the contact page. Include the affected component, reproduction steps, and any impact you have assessed.
We follow coordinated disclosure. We will acknowledge your report, investigate, agree a remediation timeline with you, and credit researchers who report responsibly. Please give us reasonable time to ship a fix before disclosing publicly.
Security FAQ
Is Offline Protocol end-to-end encrypted?
Yes. Every session is encrypted with MLS (RFC 9420), the IETF standard for group messaging security. Only the members of a session hold the keys to decrypt its traffic, and those keys never leave the device that generated them.
What can a relay node see?
Ciphertext only. Relays forward MLS-encrypted payloads without the keys to open them. They route by envelope metadata, not content, so a device relaying traffic for others cannot read it.
Does the protocol send anything to a server?
No. There is no server in the path. Identity verification, routing, and service discovery all happen device to device. Telemetry is opt-in and emits nothing until your application installs a sink, so the protocol is silent by default.
How are identities verified with no connectivity?
OfflineID uses Ed25519 keypairs that verify device to device with no lookup, no certificate authority, and no round-trip. Pairing follows trust-on-first-use, and rotation and revocation are anchored on-chain so updates propagate whenever any node touches the internet.
What happens if a device is lost or a key is compromised?
The identity can be rotated or revoked. Because rotation and revocation are anchored on-chain, the update propagates across the mesh as nodes reconnect, so a compromised or lost credential can be retired without a central server.
How do I report a security issue?
Email [email protected] or use the contact page. We follow coordinated disclosure: we acknowledge reports, work with you on a fix and a timeline, and credit researchers who report responsibly. Please do not disclose publicly until a fix is available.
