Hop is built so the network carries your messages without being able to read them. This is how that works in practice, and what we do and don't hold.
Hop Privacy Policy · Effective date: September 4, 2026
Under applicable privacy frameworks including the General Data Protection Regulation (GDPR) and California Consumer Privacy Act (CCPA):
Every message payload is encrypted to the destination's key (X25519 + ChaCha20-Poly1305) before it leaves your device. Relays, including our hosted backbone, carry ciphertext they cannot read. Only the recipient can open it. We never see, store, or process the contents of your messages.
A node is an Ed25519 keypair; its public key is its address. There is no required account, phone number, or email at the protocol layer. Human-readable names and contacts are an application concern, kept by the app, not part of the network.
When you use the optional cloud backbone, it stores sealed bundles (ciphertext) and their routing envelope so a message can wait for an offline recipient and bridge across regions. Held messages in the message spool are evicted on their lifetime/TTL and purged upon verified delivery. The backbone relays what it's given; it does not decrypt it.
In addition to transient message spools, relay instances persistently store session and device metadata in Google Cloud Firestore under relays/{node}/kv. This metadata includes base58 device public keys and timestamps of connected devices, used for active connection tracking, peer routing, and network rate limiting. While payload contents remain strictly encrypted and inaccessible, these session records persist across connections to enable reliable store-and-forward routing.
Billing is metered on the sealed envelope, counts and bytes, never content: active devices, data carried, internet egress, and mailbox storage. Active-device counts use pseudonymous addresses, deduplicated within a billing period and not linked to any personal identity. We never open a payload to meter it.
The hosted backbone's durable store is a single database in one Google Cloud multi-region, currently the United States. Relays in other regions read and write that same store, so backbone-held sealed bundles and their routing envelope rest under US residency wherever the relay carrying them runs. We do not offer regional pinning or a per-user home region today, and we will not claim to until it ships.
If that placement does not work for you, the protocol does not require our backbone: run peer-to-peer with no backbone at all, or operate your own in the jurisdiction you need (see Self-hosting below).
Our public marketing website loads client-side icon fonts from Font Awesome (Fonticons, Inc.). When your browser requests these resources, Fonticons, Inc. may receive your client IP address and standard HTTP request headers. No message contents, cryptographic keys, or application payloads are ever transmitted to Fonticons. Developer console payments and billing subscriptions are administered through Stripe, Inc.
The Hosted Services and developer tools are strictly intended for developers and commercial organizations. They are not directed to, and we do not knowingly collect personal information from, children under 13 years of age (or under 16 in the European Economic Area or United Kingdom), in compliance with the Children's Online Privacy Protection Act (COPPA) and applicable European data protection legislation. If we become aware that a child under 13 has provided personal data to us, we will take immediate steps to delete such information.
You can run the SDK fully peer-to-peer with no backbone at all, or operate your own private backbone, in which case the data never touches our infrastructure and these backbone practices are yours to set.
Depending on your jurisdiction (including the EEA, UK, and California), you may have rights to access, correct, port, or request deletion of personal information we hold about you as a Data Controller. Held bundles in our relay spool are transient, purged immediately upon verified delivery or evicted automatically upon TTL expiration. Persistent relay connection records and device public keys and timestamps in relays/{node}/kv are maintained under strict IAM access controls for network operation and rate limiting, governed by automatic TTL retention policies (session state expires after 30 days, carrier streams after 24 hours, seen bundle identifiers after 7 days, and default transient KV rows after 30 days; financial ledger records and telemetry deduplication markers are exempt from TTL and have no automated expiry).
Questions about data handling or privacy rights: privacy@hopme.sh.