Decentralization Milestones
XMTP is migrating to our decentralized network. We are doing this with millions of users and billions of messages already on the network, so we want to make sure the transition is smooth and the network is ready to handle everyone.
---
config:
theme: 'dark'
---
timeline
title Decentralization Migration
section Testnet
Testnet Relaunch (December, 2025) : ✅ XMTP mainnet chain launched
: ✅ All smart contracts deployed to testnet
: ✅ 3 nodes (one from XMTP Labs) deployed
: XMTP production data pre-seeded
: Pre-seed complete and message publishing enabled
: ✅ Testing gateway service deployed
: Testnet funding portal live
: Feature complete decentralization ready SDKs released
Testnet Validation (January, 2026) : xmtp.chat has a testnet mode
: Convos TestFlight build connected to testnet
: xmtp-qa-tools performance suite running against testnet
: Testnet load testing begins
section Mainnet
Mainnet Prepare : ✅ 1.0 smart contracts deployed on XMTP mainnet
: ✅ 1 XMTP Labs node deployed on mainnet
: XMTP production data pre-seeded
: Mainnet funding portal live
: All major XMTP clients migrated to a 2.x SDK version
: All major XMTP clients have a funded gateway linked to their app
Mainnet Launch : Pre-seed complete and message publishing enabled
: V3 backend begins sending "migration enabled" errors
: All 2.x compatible clients begin talking to Mainnet
: Nodes begin receiving USDC messaging fees
: 6 global nodes added to mainnet
The rollout of the decentralized network is happening over four distinct phases.
Testnet Relaunch
While we have been running a testnet of the decentralized network for over a year, this is a clean-slate launch of a new network using the latest smart contracts and xmtpd code.
This network will be pre-seeded with all non-expired messages from the XMTP V3 network (the network used by all apps today) to create a realistic storage footprint.
The latest versions of XMTP’s iOS, Android, React Native, and Node SDKs will be compatible with this testnet and able to send and receive messages. Applications will be able to run a Gateway Service to subsidize messaging fees on behalf of their users.
Validation Criteria
This phase will be deemed complete when:
- All integration tests pass across XMTP SDKs when pointed at the testnet network using a gateway
- The pre-seed is complete up to the predefined snapshot date
- The testnet funding portal is live, so that application developers can fund their account
Testnet Validation
With a realistic dataset and a complete set of clients, we now need to make sure that the network is able to satisfy the needs of apps currently using XMTP.
We are looking to validate that the network provides acceptable levels of latency, throughput, and reliability to be a suitable replacement for XMTP’s current network.
Validation Criteria
We cannot move on to the next phase of rollout until the following evaluations have passed:
All latency SLAs are met
We already have automated tools measuring the performance of XMTP V3 that have been extended to support testnet. These are end-to-end client metrics for common operations. While the environment is synthetic (the nodes are in the same data center as the client), it gives us a good performance baseline.
| Single Operation Metrics | Target (p95) | XMTP V3 |
|---|---|---|
| Sync a group | <100ms | ~100ms |
| Send message to group - members can see the message (including stream) | <400ms | ~250ms |
| Create a group with 100 members | <2.5s | ~4s |
| Register a single new identity on the network | <1.5s | ~350ms |
| Add a new member to a 10 person group | <1.5s | ~250ms |
| Add a new member to a 250 person group | <1.5s | ~750ms |
| Group rename (10 member group) | <1.5s | ~100ms |
All throughput SLAs are met
The XMTP network is growing. Today we see about 2 million new messages per day. We need to be sure that we can handle the current network throughput and expected growth.
| Metric | Target |
|---|---|
| Offchain messages originated per second (burst) | 1000 |
| Onchain messages originated per second (burst) | 50 |
| Sustained daily throughput with 3 nodes | 10,000,000 messages |
All reliability SLAs are met
| Metric | Target |
|---|---|
| Node reliability (Client can read or write to the decentralized network without error) | 99.99% |
| Fork test suite | 0% fork rate |
| Integration test pass rate over 5 runs | 100% |
Does it feel good in a real app?
While some of the latency targets above are slower than the V3 network, our hypothesis is that the slowdowns in these particular operations are too small to be noticeable to the majority of users. We need to validate that hypothesis by using real applications connected to the testnet. We will do this by working with our partners to have testnet versions of xmtp.chat, Convos, Coinbase Wallet, and World and seeing how they feel compared to the V3 network.
Many app developers have their own instrumentation and metrics that we can use to compare the real-world performance of testnet with V3.
Mainnet Preparation
Once all validations from testnet have been satisfied we will start a 60 day migration clock. At the end of these 60 days all XMTP apps need to be migrated to a mainnet compatible XMTP SDK and connected to a funded gateway. The mainnet-compatible SDK version will still connect to the V3 network until the cutover date, but will be configured and prepared to talk to mainnet after the cutover.
In this phase we will deploy the mainnet nodes and smart contracts and begin migrating data from V3 production to mainnet.
Validation criteria
To move forward with the final launch
- Pre-seed/data migration has caught up with present and is streaming all new messages from V3 → mainnet
- All validations from previous stages remain green
Mainnet Launch
The launch of mainnet is a hard cutover. At a predefined time V3 network will begin sending a specific error code to clients telling them to switch over to mainnet. Clients will then exclusively communicate with nodes on the mainnet network and all writes will go through the application’s configured gateway.
App developers should expect up to 30 minutes of downtime where the network is unavailable during this migration.