End-to-End Encryption vs Non-Custodial Architecture: Different Things

End-to-end encryption and non-custodial architecture are both privacy-relevant properties, and they are sometimes conflated. The conflation matters because the properties address different threats and protect different things. This post is about the actual distinction, why it matters, and how the two compose.

What End-to-End Encryption Actually Means

The technical definition.

Encryption keys are held only by the endpoints. The sender and recipient hold the keys; no intermediary does.

Content is encrypted in transit and at rest at intermediaries. A server handling the message sees only ciphertext. The server cannot decrypt the content because it does not have the keys.

Decryption happens at the recipient. The recipient’s client decrypts the message after receiving it.

Common implementations. Signal Protocol (used by Signal, WhatsApp, Element). PGP / GPG (used by various email tools). Apple iMessage. ProtonMail (PGP-based, with key management abstraction).

What it protects against. Compromise of the intermediate infrastructure. If the server is breached, the attacker sees only ciphertext. If the service operator is malicious, they cannot read content.

What it does not protect against. Compromise of the endpoints (sender or recipient device, account credentials). Side-channel attacks (metadata, timing). Attacks that capture the content before encryption or after decryption.

E2EE is a strong property when implemented correctly. It addresses a specific threat: the intermediary as adversary.

What Non-Custodial Architecture Actually Means

The other definition.

The service does not hold user assets. Funds, tokens, credentials, or other sensitive items are held by the user, not by the service.

The service may facilitate operations on user assets. Through user-authorized actions, the service can route payments, validate transactions, etc. But the assets themselves stay with the user.

Common implementations in crypto. Lightning wallets that store keys on-device. Self-custody wallets like Wallet of Satoshi (custodial), Phoenix (non-custodial). Cashu wallets that hold user tokens locally.

Common implementations beyond crypto. Password managers using local encryption (Bitwarden self-host, KeePass). Some “client-side” SaaS where data stays in the browser.

What it protects against. Service operator becoming a custodian or custodian of malice. Service insolvency or seizure affecting user assets. Service compromise leading to direct asset theft.

What it does not protect against. Loss or theft of the user’s own keys. Failure of the user-controlled infrastructure (lost device, forgotten password). Misconfiguration by the user.

Non-custodial is a strong property when the user maintains control. It addresses a different threat: the service as custodian-of-trust.

Why They Are Different

The threats they address are distinct.

E2EE threat model. Service operator could read your content if they wanted. E2EE prevents this. The threat is information disclosure.

Non-custodial threat model. Service operator could withhold or steal your assets. Non-custodial prevents this. The threat is asset loss or seizure.

A service can be E2EE without being non-custodial. Example: a messaging service that uses E2EE for messages but holds your account credentials. Compromise of the service still steals your account; messages remain confidential but the account is at risk.

A service can be non-custodial without being E2EE. Example: a non-custodial Lightning wallet that does not encrypt local backups. The wallet is non-custodial (you hold keys); the local data is not E2EE protected against device compromise.

A service can be neither. Most consumer SaaS. Custodial of credentials and content; not E2EE.

A service can be both. Some privacy-aware tools combine E2EE for content with non-custodial architecture for assets. This is the strongest privacy posture but also the most complex to implement.

The distinction matters because the privacy claim depends on which property the service has, not on which property the user assumes.

What Email Tools Typically Do

The landscape.

Standard email (Gmail, Outlook). Custodial of content (server stores plaintext or operator-encrypted). Custodial of credentials. Not E2EE.

ProtonMail. Mostly E2EE (with caveats around mail to non-Proton recipients, where E2EE breaks down). Custodial of credentials and account state.

Tutanota. Similar to Proton. E2EE for in-network mail; not for cross-network. Custodial of account.

Self-hosted email. Variable. Can be E2EE if the user runs PGP. Often custodial of the email content at rest unless local encryption is configured.

Apple Mail with Advanced Data Protection. Custodial by default (iCloud servers see content). With ADP enabled, content is encrypted such that Apple cannot decrypt. Closer to E2EE but with caveats.

The dominant pattern in email is custodial-of-content with TLS in transit. E2EE for email is niche; non-custodial for email content is rarer still.

What Rythm Does

The privacy posture.

Non-custodial for payments. Cashu tokens are never stored. Rythm receives an email, parses for the token, melts the token to the user’s Lightning address in memory. The user’s wallet receives the sats. Rythm is never in custody of funds.

Ephemeral processing for content. Rythm processes email content in memory during the cover-charge check. Content is not persisted on Rythm’s infrastructure. The provider (Gmail or Outlook) holds the email; Rythm reads it through OAuth, processes the relevant fields, and releases the memory.

Not E2EE for email content. Rythm is not an end-to-end encrypted email tool. Email arrives at Gmail or Outlook in their standard form (TLS in transit, custodial at rest). Rythm reads the content through OAuth-authorized API access.

Confidentiality through ephemerality. Rythm does not hold email content. Content is processed and released. This is not the same as E2EE; the provider still holds the content. But Rythm itself is not adding a custodial layer.

The user’s content custody is determined by the provider. If the user wants E2EE for email content, they need an E2EE email service (Proton, Tutanota, etc.) underneath. Rythm operates on top of whichever provider the user chose.

Why This Matters for Choosing Tools

The framework.

If your threat model is “the service operator might read my content,” you need E2EE. Use a Proton-class provider for email content. The provider is the layer at which E2EE matters; Rythm is a layer on top.

If your threat model is “the service might hold or seize my funds,” you need non-custodial. Use non-custodial Lightning wallets. Use Rythm for email payments because Rythm is non-custodial.

If your threat model is both, you need both layers. A Proton-class email provider plus non-custodial wallets plus a non-custodial layer (Rythm) on top.

If your threat model is just volume reduction, neither E2EE nor non-custodial is the primary concern. Any reputable inbox protection tool can address volume; the privacy properties are secondary to the volume reduction.

The right tool depends on which threats matter to you. Tools claiming “privacy” without specifying which property are providing weaker information than users typically assume.

What This Means for Privacy-Aware Users

The realistic stack.

Email content layer. Choose a provider whose stance matches your threat model. Standard providers (Gmail, Outlook) are custodial of content. E2EE providers (Proton, Tutanota) are E2EE for in-network mail.

Inbox filtering layer. Rythm operates here. Non-custodial for payments. Ephemeral for content processing. Composes with whichever email provider you chose.

Wallet layer. Choose a non-custodial Lightning wallet. The cover charge payments arrive here.

Identity layer. Hardware-key MFA on the email account. Reauth for sensitive operations.

The stack is layered. Each layer addresses a specific threat. The combination is stronger than any single tool.

A Specific Honest Note

E2EE and non-custodial address different threats. They are sometimes conflated, especially in marketing copy that uses “privacy” as an umbrella term. The distinction matters when choosing tools because users seeking one property might mistakenly assume another tool provides it.

For Rythm specifically: non-custodial for payments, ephemeral for content. Not E2EE for email content (the provider is the relevant layer for that). The combination works for most users seeking inbox protection without giving custody of funds or persistent access to email content. For users with stronger E2EE requirements, layering Rythm on top of an E2EE email provider is the right approach when Rythm supports those providers (currently Gmail and Outlook).

For the related guides, see what non-custodial means in 2026, the non-custodial email stack, why most privacy-first email tools are not actually private, and why ProtonMail doesn’t solve the spam problem. For the broader frame, see non-custodial architecture and what is a non-custodial email service. Rythm is $1.65 per month, cancel anytime.