The Problem: Cross-Chain Identity Spoofing
As XMTP expands toward full cross-chain messaging support, it introduces a massive vector for address-spoofing and phishing attacks. Malicious actors routinely deploy smart contracts or generate EOAs with identical addresses on different EVM/non-EVM chains using CREATE2 or vanity address generators (matching the first and last few characters).
If the protocol lacks strict, cryptographic chain-origin validation at the UI/client level, users can easily be tricked into interacting with a malicious clone account on a different network, thinking they are messaging a verified counterparty.
Proposal: Cryptographic Origin Enforcement
- Chain-Specific Identity Binding: Bind XMTP identity keys strictly to the specific Chain ID where the address was originally verified.
- Visual Disambiguation: Force client SDKs to explicitly flag messages if the sender’s address matches a known contact but originates from an unexpected or unverified chain.
- Cross-Chain State Proofs: Implement light cryptographic proofs to verify that an address on Chain B actually owns the corresponding identity state on Chain A before allowing direct inbox access.
Bottom Line:
We cannot just bridge messages and hope users notice the chain difference. Without strict origin verification, cross-chain support is a goldmine for targeted phishing.