A Pragmatic Approach to Private ETH Transfers via XMTP

[davincibot1495.eth]

Problem

Blockchain technology is built on transparency, but many users desire the ability to transact privately while maintaining the integrity and security of decentralized networks. Ethereum, in its current state, does not natively support private transactions. This lack of privacy can be a barrier to adoption for users who prioritize confidentiality in financial transactions.

Goal

The objective of this proposal is to outline a hybrid on-chain/off-chain system that enables private transactions on Ethereum. By leveraging zero-knowledge proofs and decentralized encrypted messaging, this system provides an effective means of conducting private transfers without requiring specialized wallet infrastructure.

Proposal

To illustrate the system, consider the scenario where Alice wants to privately send 1 ETH to Bob:

1. Alice Initiates the Transfer: Alice accesses a front-end application connected to her Ethereum wallet and initiates a private transfer of 1 ETH.
2. Deposit into Privacy-Preserving Smart Contract: Under the hood, the front end deposits 1 ETH into a smart contract that utilizes zero-knowledge proofs, such as Tornado Cash on Ethereum L1 or Veil.cash on Base L2.
3. Secret Generation: The deposit contract generates a unique secret, which serves as a withdrawal key for Bob.
4. Secure Communication via XMTP: The front end transmits this secret from Alice to Bob using XMTP, a decentralized, end-to-end encrypted messaging protocol.
5. Notification to Bob: Bob receives a notification through the front end that 1 ETH is available for withdrawal.
6. Bob Claims the Funds: Bob initiates a claim through the front end, which executes a withdrawal from the deposit contract using the secret received via XMTP.
7. Front End Submits Secret to the Deposit Contract: The front end interacts with the deposit contract, which verifies the provided secret to authorize the withdrawal.
8. Deposit Contract Releases Funds: Upon successful verification of the secret, the deposit contract releases 1 ETH directly to Bob’s wallet.

Benefits

• Seamless Integration with Existing Wallets: The system can leverage Coinbase Wallet’s integration with XMTP, reducing friction for users.
• Multi-Layer Compatibility: The approach works on both Ethereum L1 and Base L2, ensuring broader accessibility.
• AML/KYC Compliance on Base L2: Veil.cash’s verified deposit pools enable optional compliance for regulatory adherence.
• No Specialized Wallets Required: Unlike solutions such as Railgun, this system operates with standard Ethereum wallets.

Limitations

• Fixed Denomination Deposits: Privacy-preserving deposit contracts such as Tornado Cash and Veil.cash generally require transactions to occur in predefined denominations (e.g., 0.01 ETH, 0.1 ETH, 1 ETH, etc.). This constraint could reduce flexibility for users who need to transact in arbitrary amounts.
• Token Holding Requirements: Some privacy-preserving deposit contracts, like Veil.cash, require users to hold a certain amount of their token to utilize the service.

[shanemac]

Thanks so much for this idea @davincibot1495.eth - we care so deeply about privacy and have discussed this a few times but never really made it happen in reality.

I wonder how the community could build a prototype with ZK proofs and Coinbase Messaging to show how this could be possible.

Be great to know what @nick and @Fabri think of this.

[nick]

Love this idea. Absolutely nothing stopping someone from building this on top of XMTP today

[tantodefi]

innovations on the original tornado cash ZK circuits now allow privacy-enabled withdrawals/deposits of variable amounts (aka privacy pools / shielded pools).

This could be fun to hack together sometime, I’ll add it to my list.

[Maivar]

Great proposal! Using XMTP to automate the delivery of withdrawal secrets is a smart way to solve the UX friction typically found in privacy protocols.

It’s a solid architecture that bridges the gap between complex ZK-proofs and standard wallets. I especially like the focus on Base L2 for better compliance and lower fees.

Quick question: How do you envision Bob handling the gas fees for the withdrawal if he’s using a fresh, ‘clean’ wallet? Would a relayer be used to keep the link completely broken?

[tantodefi]

Your correct @Maivar - in most privacy protocols live today there is a centralized relayer that handles this.

We’ve actually built the first privacy-preserving paymaster (based on erc4337) to try to combat this emerging centralization standard in standard in privacy protocols - it is currently live on testnet at https://testnet.prepaidgas.xyz/

The idea is that dapps can integrate this paymaster that is configurable by users with coupons (think giftcards for gas) that can then be redeemed to facilitate private withdrawals

From outside perspective you will be able to see that someone used the prepaidgas paymaster to pay for gas but you will not be able to determine which user as all gas deposits are held in the paymaster contract and only accessible/redeemable by their coupon.

I think if we combine this with the new EIL framework to make it go crosschain - this can be really good solution.

would love your thoughts and feedback!

[chizzy7569]

This is actually a good idea