Local litepaper copy saved as: research/crypto/whitepapers/xmtp-litepaper.md
Key takeaways from primary sources
XMTP is no longer best framed as simple wallet-to-wallet messaging. The key architectural move is the portable inbox: inbox IDs stay stable while identities and installations can change around them.
The current protocol stack is explicitly MLS-based. The docs center MLS for confidentiality, forward secrecy, post-compromise security, and group messaging efficiency, which gives XMTP a much clearer security model than older “sign a wallet message and encrypt some payload” approaches.
Consent is a first-class protocol mechanism. XMTP says allow/block preferences live on the network and sync across apps, which means spam control is not just a client-side UX decision but part of the shared messaging substrate.
XMTP’s identity model is worth retaining because it separates a stable message destination from wallet identity. One inbox can map to multiple identities and multiple installations, with a recovery identity retaining special authority.
The decentralization materials show that XMTP’s current network is still meaningfully permissioned. Phase 1 uses Security Council-approved nodes, message fees paid by apps, a gateway layer for payer wallets, and a phased path toward staking and slashing.
The decentralized-network story is therefore real but incomplete. Practical authority currently still sits partly with the council, the appchain / metadata layer, gateway operators, and the app developers who fund network fees.
XMTP is especially useful as a comparison class because it bundles protocol-level identity continuity, cross-app consent, and fee-funded delivery in one stack instead of leaving those functions to separate wallets, transports, and client products.
Specific source signals worth retaining
protocol/overview: cleanest summary of XMTP as a combination of authentication service, delivery service, identity layer, topics, cursors, and intents.
protocol/security: strongest source for MLS security properties, sender-hiding claims, welcome-message protection, and quantum-resistance framing.
protocol/identity: clearest articulation of inbox IDs, multiple identities, multiple installations, and recovery authority.
xmtp.org/consent: shows that cross-app portable consent is a deliberate product and protocol surface, not incidental client behavior.
xmtp.org/decentralization: best current source for how node eligibility, Security Council oversight, fees, gateways, and later staking are supposed to work.
Litepaper + libxmtp README: useful for historical and implementation framing, especially around portable inbox ambition, conditional deliverability, and the live code surface.
Why this entry belongs in the corpus
XMTP earns a place because it makes a distinct mechanism legible: portable encrypted messaging where identity continuity, spam control, and app funding are embedded in the protocol layer itself.
It is a strong comparison class for Push because both address wallet-native communication, but XMTP puts much more weight on portable inbox identity and network-level consent.
It is a strong comparison class for Waku, Nym, and HOPR because XMTP sits higher in the stack: less about anonymous relay topology and more about shared inbox semantics, app interoperability, and policy surfaces above transport.
The reusable insight is that once inbox continuity and consent are pushed into the network itself, authority shifts toward identity-linking rules, recovery roles, gateway defaults, operator admission, and fee-payer infrastructure—not just to whoever runs the user-facing app.
Whitepaper / docs status
XMTP has a substantial public-draft litepaper and current live docs.
For this pass, the live docs were the clearest source for current architecture and security properties, while the litepaper was best for historical framing and the portable-inbox / conditional-deliverability vision.
Local litepaper path: research/crypto/whitepapers/xmtp-litepaper.md