About
FAQs & architecture
XMTP messaging security
Can XMTP read user messages?
No, messages are encrypted end-to-end. Only participants in a conversation have the keys to decrypt the messages in it. Your app cannot decrypt messages either.
How does XMTP's encryption compare to Signal or WhatsApp?
XMTP provides the same security properties (forward secrecy and post-compromise security) as Signal and WhatsApp, using the newer, more efficient MLS protocol.
Can others see who users are messaging with?
No. Message recipients are encrypted, so even network nodes cannot see who is messaging whom. Nodes can only see timing and size of encrypted messages.
What happens if a user loses access to their wallet?
They'll need to start new conversations from their new wallet. Messages sent to their old wallet address can't be decrypted without access to that wallet.
Are group messages as secure as direct messages?
Yes, MLS provides the same security properties for both group and direct messages. In fact, MLS is particularly efficient for group messaging.
What if a user suspects their wallet is compromised?
Due to forward secrecy, even if someone gains access to their wallet, they can't read their past messages. They should start using a new wallet immediately — this ensures attackers won't be able to read future messages either.
How does encryption work across different XMTP apps?
All XMTP apps use the same MLS protocol, ensuring consistent encryption across the ecosystem regardless of which app users choose.
What BlocChat decentralises vs centralises
Decentralised
- All message content — E2E encrypted via XMTP network (peer-to-peer MLS protocol, no server reads messages)
- Wallet authentication — WalletConnect; identity lives on-chain, no custodial accounts
- ENS resolution — on-chain lookups, no intermediary
- Payments — ETH/USDC transfers execute on Base L2, settled on-chain
- Group encryption & membership — XMTP MLS handles key distribution and group state
- Read receipts — stored in XMTP consent/metadata layer per-conversation
- Token gating verification — checks on-chain balances (even though rules are stored centrally)
- Minting (when live) — contract deployment on Base via user's wallet
- Installation management — XMTP identity keys, managed client-side
- Payments — execution is on-chain (decentralised)
Centralised
Rust backend + PostgreSQL + AWS
- User profiles — usernames, display names, avatars, bios stored in DB
- Profile search — queries your backend, not a decentralised registry
- Typing indicators — entirely backend-powered (in-memory store on EC2)
- Payment history — transaction records logged to your DB (on-chain data exists independently, but the app reads from your API)
- Token gate rules — the gate configurations (which tokens, thresholds, operators) are stored in your DB
- Shop/marketplace data — shop items, prices, images all in PostgreSQL
- Public group registry — the public_groups table that powers Discover
- Group metadata edits — while XMTP holds some group metadata, our backend supplements it
Hybrid
- Group discovery — public group registry is centralised, but the actual group join/membership is XMTP (decentralised)
- Token gating — balance checks are on-chain, rule storage is the only DB entry here