As of today, XMTP is now a fully quantum-resistant decentralized messaging protocol. This means, any developer, anywhere in the world can leverage XMTP to provide their users with private, decentralized, & quantum-resistant messaging.

Quantum computers are an existential threat to much of today’s cryptography. Everything from TLS to Bitcoin to secure messaging protocols like XMTP run under the assumption that the Elliptic Curve Discrete Logarithm Problem is computationally intractable. Deriving a private key from a strong public key on a conventional computer would take longer than the life of the universe, so we can all feel safe using them for encryption.

Since the ‘90s, we’ve known that quantum computers have the potential to exponentially speed up this process: with enough qubits, the same problems could be solved in hours. The algorithms required to do this are decades old - we are just waiting for a quantum computer powerful enough to use them effectively. Breaking a 256-bit elliptic curve private key could take as little as a few thousand “logical qubits.” Nothing like that exists today, and we don’t know when scientists will make the required breakthroughs to get there, but we’ve seen signs that it’s time to get serious about the threat. In the past few years, Google has announced their Willow quantum processor, IBM announced Heron, and Microsoft has shown off Marjorana. If these breakthroughs continue, a working quantum computer with thousands of logical qubits may become a reality in the next 10 years.

Fortunately, there are things that we can do today to protect our users against future quantum breakthroughs.

Not all threats from quantum computers have equal urgency. Zooko published an excellent thread last year on how ZCash is thinking about quantum risks, and many of the same principles apply to XMTP. We need to think about the risks from active and passive attackers very differently.

• Passive Attacker. Someone silently listening to messages on the XMTP network and using a quantum computer to decrypt the contents. The threat from a passive attacker is removing the confidentiality from otherwise private communications.

• Active Attacker. Someone capable of using a quantum computer to assist in writing or modifying messages on the XMTP network. Active attackers may be able to impersonate users on the network, read confidential messages, and modify the parameters of group chats.

The threats from active attackers are serious, but we have much more time to deal with them. Note that the active attacker needs a working quantum-computer at the time of their attack. So long as the network has rolled out protections against the threat before a sufficiently powerful quantum computer is online, everyone is safe. Whether we beat that quantum computer by a week, a year, or a decade doesn’t matter.

This is not the case for passive attackers. We know well-funded actors are already archiving interesting ciphertext today, waiting for the technology to advance to the point that they can decrypt it. This is typically referred to as “Harvest Now, Decrypt Later” (HNDL) and we should address it as soon as possible.

While Quantum computers capable of breaking cryptography are still theoretical, the cryptography community has designed protocols that are resistant against quantum computers (even with thousands of logical qubits). NIST has been working for the last 8 years to standardize a suite of algorithms that protect against both quantum and conventional threats.

In the last year, both Signal and Apple have released updates to their messaging protocol to protect against passive attackers using these algorithms. Both implementations take a hybrid approach - which combines conventional and post-quantum encryption - so as not to “put all your eggs in one basket” with relatively new cryptography. Cryptographic algorithms become trustworthy by being used for decades without anyone finding a shortcut or back door to break them.

Our partners at Cryspen have been working on a post-quantum version of OpenMLS, and have implemented hybrid ciphersuites that can be dropped in to replace all conventional cryptography with post-quantum algorithms.

One challenge with going “all in” on post-quantum ciphersuites is the size of the keys and payloads. In a decentralized network like XMTP, every extra byte increases the cost to Payers on the network. Some payloads may grow by 5-10X with a hybrid approach.

Ideally, XMTP would get to post-quantum protection without needing to bloat payload sizes across the network.

Apple included this very helpful rubric for levels of quantum protection. To protect against passive attackers today, we need to get XMTP from Level 1 to Level 2. Implementing the full OpenMLS ciphersuite would put us somewhere between Level 3 and the “Future” state. Protecting against active attackers requires us to make our way into the “Future” column, which would include post-quantum signatures.

Thanks to the design of MLS, we don’t need to replace our traditional cryptography everywhere to keep messages safe from passive attackers.

Quantum computers do not give the same advantages to decrypting symmetrically encrypted payloads as they do to asymmetric encryption.

With a quantum computer, private keys using traditional algorithms can be derived from public keys by taking advantage of Shor's Algorithm, but the best attack against symmetric keys in 30+ years of research is Grover's Algorithm. Shor's algorithm provides an exponential speed-up, whereas Grover's provides a quadratic speed-up (or less).

That makes Shor's algorithm devastating to 256-bit public keys, while XMTP’s symmetric encryption keys remain safe against Grover's algorithm. This difference greatly limits the scope of what is required to get XMTP post-quantum protection against passive attackers.

If you look at all the payloads on the XMTP network, the only place we share group secrets through public key cryptography is in MLS Key Packages. We use those Key Packages to encrypt Welcome messages, which are used to add members to a group.

If a quantum computer can decrypt a Welcome, they have access to the full set of leaf nodes for conversation participants. They can then decrypt all messages in the current epoch and evade post-compromise security by breaking other participants' public keys as the epochs move forward.

But if the quantum computer cannot decrypt Welcomes, the rest of the payloads on the XMTP network are useless to a passive attacker. They don't have access to the leaf node public keys to break. That means they can’t read any of your messages.

XMTP already adds an extra encryption layer for Welcome messages above and beyond what is specified by MLS in order to protect some metadata we consider sensitive in our threat model. If we were to replace that extra encryption step with quantum-resistant HPKE encryption, we could protect Welcomes without impacting any other payloads on the network.

The steps required to do this are outlined here, and we expect to roll this change out in the coming weeks. The change will be non-breaking: clients who have post-quantum keys in their key packages will have their Welcome messages protected by post-quantum encryption, and older clients will not. Once all clients have upgraded to an SDK version that supports post-quantum protection, we can remove the legacy key package encryption altogether.

We expect this change to add 1.5KB to each Key Package and to increase the size of each encrypted Welcome message by approximately 50%. The highest volume payload types on the XMTP network (application messages and commits) would be unaffected by the change.

We brought in Cryspen to help model some of the security properties of this new architecture, and the informal analysis confirms that the new version of XMTP offers HNDL Forward Secrecy.

As we’ve outlined above, XMTP has a bit more time to protect ourselves against active attackers. We only need to be ready before quantum computers enter the chat. We expect that with time, we will see improvements in the payload sizes for hybrid encryption schemes, and researchers may develop algorithms that offer even stronger protection.

To protect against an active attacker with a quantum computer, we would need to replace the ciphersuites used everywhere with a post-quantum alternative.

This would impact:

• Key Packages

• The inner payload in an XMTP double-encrypted Welcome

• Leaf nodes in the MLS tree, and the epoch secret from the root of the tree

• All MLS commits and proposals

• Signatures used for authentication of Key Packages and PrivateMessages

To prepare for a fully quantum-resistant version of MLS, we would like to allow developers to explore and play with these features in test environments. In 2026, we will begin allowing developers to enable post-quantum clients and to create groups that enforce post-quantum encryption. We can continue to iterate and learn from these experiments before we need to make post-quantum encryption the default in the network.

We expect that, over time, the data storage costs in the network will decrease and make the costs of the hybrid payloads less prohibitive for senders. There’s no reward for being 10 years early here, so we might as well wait for the best possible algorithms.

XMTP was built on the belief that private communication must not depend on trust in any single party, including us. We encrypt everything and distribute it across a geographically and organizationally diverse network of nodes—meaning:

• No single point of compromise. XMTP encrypts everything and distributes it across a geographically and organizationally diverse group of nodes. No individual or entity has unilateral power to undermine privacy.

• No illusion that encryption alone is enough. Even perfect encryption fails if other risks—centralized storage, subpoenas, identity leaks—aren’t addressed. XMTP removes those vectors entirely, forcing the ecosystem to advance real, end-to-end privacy through cryptography.

• No need to trust the network operator. XMTP’s design ensures that privacy is guaranteed by protocol, not by promises.

We believe this architecture aligns with the highest privacy standards demanded by the most privacy-conscious organizations and individuals.

We have rigorously designed XMTP to obfuscate and minimize metadata:

• No message content or sender-recipient pairs are exposed: All content and conversations are fully encrypted.

• Decentralized nodes: Data is distributed across multiple independent nodes, eliminating centralized surveillance risks.

• Public discipline: Encryption of all public data is mandatory—XMTP’s open system enforces this discipline transparently.

Below is a table listing core metadata properties typically at risk on centralized servers

While many messaging protocols claim strong encryption by securing message contents, protecting all conversation metadata requires many more layers of obfuscation and encryption that very few protocols can offer.

As with everything in XMTP, this change will be released in the open. XMTP client code, servers, and data are available to the public. You can read a more detailed security analysis of the feature here.

We fundamentally believe that the most private network is the one where nothing is hidden.

This openness allows security researchers and the developer community to test every part of the project and prove our privacy model is sound with each release.

Every other major messaging platform keeps its data locked up on private servers. That means the first time their cryptography will be truly tested is when those servers get hacked. It means when they get subpoenaed, they can’t—or won’t—tell you what they handed over, and you have no way to verify what was collected in the first place.

You shouldn’t trust them, and you shouldn’t trust us. Trust the math.

Many thanks to Jesse Pollack, Franziskus Kiefer, Joseph Bonneau, Rohan Mahy, and Charles Guillemet for reviewing this post.