ENS Payment Privacy

🏛️ Public Goods General Discussion
#1

Receiving payments to human-readable addresses is part of the attraction and core value propositions of using ENS names as a universal web3 identity. Today, those payments are made to static addresses written into the text records associated with ENS names. Changes to those addresses are expensive and require an on-chain transaction and all current and past text records are in the immutable, historical record of the blockchain forever.

I would like to start a discussion with the community and get a temperature check on the idea of exploring alternatives to static payment addresses, such as allowing users to set an optional outside server (and creating the voluntary standards to support it) that would allow wallets that support the standard to resolve the server location from the ENS name and request payment addresses using existing HD wallet technology in order to provide greater payment privacy while using an ENS identity. Static payment addresses would remain for users not interested in the additional privacy features and could also be used as a fall-back in the event that no response was received from the payment server.

Note, I am not proposing that we discuss the technology behind the payment servers themselves, but assuming that such a tool was possible and that ENS provided the capability to resolve the connection details to them, I think it would really spur some innovation in that area. I also think that greater payment privacy is part of the long-term success of users and businesses adopting ENS names to be used as universal Web3 identities.

EDIT: This isn’t a claim that this would provide absolute protection of user privacy, it would just make it mostly infeasible for a casual observer to view a user’s payment history, but a malicious actor wanting to snoop could still do so.

2 Likes
#2

Are you talking about ZK rollups? If so implementing as an user option would foster a broader adoption of ENS. People want privacy options that are outside the current payment infrastructures. I believe this is the future. If this is what you are talking of?

1 Like
#3

No, I wasn’t thinking in that direction, but it sounds interesting and I’d like to learn more. I was talking about having a server address in the ENS text records that a wallet could ping to receive back a payment address.

That keeps the payment address between the payer and payee and doesn’t allow casual snoopers to just check a user’s payment address in the ENS records. The payment addresses would be kept out of the text record entirely if a user opted for this feature.

#4

The ability to set external url is part of CCIP read standard but that’s not designed for privacy purpose but rather for scalability purpose. I am not sure how this approach preserve privacy as people can trace the transaction histories between names unless you have proxy address between (as what most CEX does) or mix with multiple transactions (which is what Tornado does).

#5

It doesn’t guarantee absolute privacy, but it would require effort to snoop on a user’s payment history.

The process would be a (hypothetical) future compatible wallet using the developed standard resolving the payee server location from the ENS records. Then, the wallet pings the payee server to retrieve a payment address. The payee server, in theory, is running software that operates just like an HD wallet by returning the next available, unused payment address to the wallet in order to allow the payer’s wallet to complete the transaction.

In this scenario, the payer knows the address they sent a payment to, but they do not know any other address other payers have sent payments to. And any third party, casual observers would have no knowledge of anyone’s payments just by looking at the ENS record.

This could be foiled with a little effort by a malicious observer creating a bot that regularly pings the payment server listed in the ENS record, obtains next available address, and makes no payment but logs it instead. But this is a risk to be mitigated by the wallet software provider, not ENS.