Skip to content

Encryption and Delivery

Why MLS

One-to-one end-to-end encryption was solved long ago by the Signal approach (double ratchet). Groups are the hard part. Applying the 1:1 approach to a group of N means maintaining a crypto session per pair of members, and the cost explodes.

MLS (Messaging Layer Security, RFC 9420) is an IETF standard in which the whole group shares a single group key through a tree structure, and only the necessary parts are refreshed when membership changes.

A group's crypto state advances in epochs. Adding a member, removing one, or rotating keys emits a commit message that opens a new epoch. Two properties come out of this structure; knowing the names is enough.

Property Meaning
forward secrecy Even if the current key leaks, past messages stay unreadable
post-compromise security After a compromise, security returns from the next epoch onward

How XMTP uses MLS

Three things to remember.

  • Every conversation is a group. A 1:1 DM is internally a two-member group, so there is a single code path. That is why DMs and groups go through the same adapter in Umul.
  • There is no separate authentication server. The identity verification MLS requires is handled directly by the Inbox system.
  • Key encapsulation for a new member's invitation (Welcome) uses a quantum-resistant hybrid KEM (XWING). This guards against harvest-now, decrypt-later attacks with a future quantum computer.

The implementation, libxmtp, went through a security assessment by NCC Group (completed 2024-12), and the report is public.

Envelopes and subscription addresses

The packaging unit for encrypted data travelling the network is the envelope; the routing address is the topic.

Envelope In plain terms Where it goes
Group Message A conversation message Conversation topic (g-<conversation ID>)
Welcome Message The entry pass handed to a new member Recipient device topic (w-<device ID>)
Key Package The business card you publish in advance so others can invite you Network storage
Identity Update A record of identity changes (adding/revoking wallets and devices) Stored permanently on the network

A client subscribes to its own conversation topics and its own device topic and receives new envelopes there. Even when sender and receiver are attached to different nodes, replication between nodes bridges them.

sequenceDiagram
  autonumber
  participant B as Bob (sender, on node 1)
  participant N1 as Node 1
  participant N2 as Node 2
  participant A1 as Alice phone (on node 2)
  participant A2 as Alice laptop

  Note over A1: Key Package published in advance
  B->>N1: look up Alice's Key Package
  B->>B: create a 2-member MLS group (a DM is a group too)
  B->>N1: publish Welcome (w-Alice-phone topic)
  N1-->>N2: replicate copy
  N2-->>A1: receive Welcome, obtain the group secret
  B->>N1: publish Group Message (g-conversation topic)
  N1-->>N2: replicate copy (messages survive a node failure)
  N2-->>A1: receive on the subscribed topic, decrypt
  N2-->>A2: Alice's other device receives it too

What matters is that you must publish a Key Package in advance for anyone to invite you. Even if the peer is offline, the sender can read their card and deliver the entry pass to their device topic.

On-chain or node storage

XMTP does not put everything on chain. The split is identity and group composition on chain, message contents on nodes.

Path Envelope Where it lands
New user registration Identity Update IdentityUpdateBroadcaster contract
Group composition change Group Message (MLS commit/proposal) GroupMessageBroadcaster contract
Group setup Key Package, Welcome Node storage
Message exchange Group Message (ordinary) Node storage

This runs in the same direction as Umul's evidence design. Umul likewise keeps conversation plaintext off chain and publishes only hashes and signatures (see the Evidence Contract Guide).

Where the network stands

The protocol stays as is while the network carrying it moves from company operation to a node network (xmtpd). As of 2026-07:

  • The decentralized testnet first ran 2025-02, was reset to the current configuration in 2025-12, and finished migrating existing messages on 2026-02-25
  • Mainnet was targeted for 2026-03, but there was no live announcement as of this survey
  • Fees are paid by the app, not the user. Fund the app-side payer wallet with USDC and it costs roughly $5 per 100,000 messages
  • Mainnet starts permissioned with seven curated node operators, and no token has been issued. Tokens circulating under an XMTP ticker are unrelated to any official announcement

The node implementation xmtpd is still experimental. Its own README states that it "is not the node software that currently makes up the XMTP network." The on-chain/node split above reflects that target implementation and may change.

Honest limits

  • Metadata is not hidden. Contents are encrypted, but nodes can see message timing, size, and query patterns (per IP), and the recipient of a Welcome is not concealed. The official security documentation states this limit itself.
  • It is still centralized. The initial seven nodes are curated, and governance starts from XMTP Labs leadership. Decentralization is a roadmap item, not the present state.
  • The economic model is unproven. Fees only start flowing after mainnet, and whether $5 per 100,000 messages holds up in the market is still unknown.