The XMTP chain is a layer two EVM blockchain that uses an onchain DID workflow for XMTP messaging identity and blockchain transactions for message metadata transport (i.e., message-metadata transactions). This model is intended to provide a censorship and spam resistant platform for secure messaging.
Proposal
An open source privacy gateway for developers that exposes an interface to the XMTP chain mainnet.
Motivation
Like other EVM networks, the XMTP chain message-metadata transactions are open and transparent and require a valid signature and sufficient gas for network inclusion. Blockchain transparency violates XMTP’s privacy requirements by allowing third parties to associate transaction senders with messaging activity, and per message signatures and fees are an unworkable user experience for a messaging application. A solution is needed that provides users with sender anonymity and a seamless way to construct, sign, fund, and send blockchain message-metadata transactions.
Open source XMTP chain privacy gateway
XMTP Labs will develop an open source privacy gateway for mainnet v1. The gateway’s main purpose is to break the linkage between message sender and blockchain transaction (i.e., sender anonymity). Developers interface with the gateway by passing it encrypted message metadata that carries instructions for metadata delivery and message content retrieval. The gateway constructs a blockchain transaction that includes the encrypted message metadata, and signs, funds, and sends the transaction to the blockchain from its own account.
Have the gateway pay for the message sending fees.
Have the gateway hide the message sender identity.
The 2nd goal is not the goal of the bulk-sender, which would have high-throughput.
Both goals should be aligned with the free-tier deployed gateway.
Note that we’re saying here “message sending fees”, but it really applies to the entire XMTP chain usage, including DID registration, invites and messaging.
I believe we should consider renaming the gateway to better reflect its functionality, as “blockchain gateway” or another blockchain-related name might be more appropriate. The end-to-end encryption (E2EE) we’ve implemented confines privacy operations to the client side, specifically within libxmtp. The gateway’s current setup neither enhances nor compromises privacy, which is by design.
It’s important to note that the gateway’s ability to obscure the sender’s address by wrapping on-chain transactions doesn’t truly enhance privacy. Users can simply use a burner Ethereum account for transactions, which is unrelated to their main Ethereum account used in the inbox app. And the actual message is not signed by Ethereum keys.
Furthermore, labeling it a “privacy gateway” could mislead developers into thinking they need to rely on this gateway for privacy features, which isn’t the case.
Blockchain Gateway seems reasonable. But, if the user wants sender anonymity for the EOA they associated their messaging keys to, they will need to use a gateway.
That EOA doesn’t have to be the same EOA they use to send tx on chain, they can create a burner wallet for the sender anonymity and that doesn’t require using the gateway.
