It is no question today that privacy on Ethereum is still one of the largest remaining challenges. Several attempts have been made to enable different kinds of privacy, including network layer privacy, confidential token transfers, and private smart contracts. Surprisingly, however, we still lack a truly usable solution for one of the seemingly most simple problems—receiving payments anonymously. Today, we outline the problem space of anonymous payments, how stealth addresses help solve the issue, and what outstanding UX problems remain. This is part one of a two-part blog post, where we outline the current state of anonymous payments in this first post, and discuss Nocturne’s approach more in the second post.

Alice wants to pay Bob 1000 DAI without revealing to the public that Bob is the receiver. Alice also wants to do so in a manner that requires no interaction with Bob beforehand. For the above, we would need a system where Alice can generate multiple addresses or identifiers that Bob owns but that the rest of the world doesn’t know belong to Bob.

In short, a stealth address system is exactly the above: a system (either at the Ethereum account level or within a smart contract) that allows for the generation of many unlinkable “one-time addresses”.

EIP-5564 outlines a standard for generating stealth externally owned accounts (EOAs) in a non-interactive manner. In short, a recipient owns a spending and viewing key, both standard Ethereum private keys. The combination of the two keys’ public keys comprises a stealth “meta address.” A sender can use the meta address to non-interactively derive a shared secret with the recipient. Using this shared secret, the sender will generate a fresh Ethereum address that the recipient can exclusively derive the private key for. The sender will then transfer funds to the fresh Ethereum address, with the recipient detecting the transfer and deriving the address’s corresponding private key to take control of the received funds.

The full details of the EIP are here. In short, EIP-5564 is a strong step towards an out-of-the-box, compatible way to receive funds anonymously.

While EIP-5564 provides an EOA-level stealth address system, there are several usability drawbacks that make practical usage difficult.

The most immediate drawback of EOA-level stealth addresses is the fact that all movement of assets to and from the stealth address is publicly traceable. When the recipient wants to move the received assets, they need to be extremely careful not to link the received funds to their main wallet address. Transferring any funds from the stealth address to their main wallet (directly or indirectly) would immediately create a visible link between the stealth address, the user’s main wallet, and any other stealth addresses that become linked to the main wallet. Keeping separation between different EOAs is quite difficult in practice.

Another related challenge is paying transaction fees with newly funded stealth addresses that have an ETH balance of 0. You can’t just fund the stealth address with ETH from your main wallet because that would create a link. You could use EIP-4337 bundlers to relay your transaction but this only works when the stealth address has acceptable ERC-20 gas tokens to compensate the bundler. If you have neither ETH nor valid gas tokens, your funds are nearly stuck.

What’s needed is a stealth address system that allows a stealth address owner to move funds without revealing what stealth address the funds are coming from. This way, received funds can be moved or gas funds provided without creating public links.

As described above, the core problem with relying on just stealth EOAs for payment anonymity is that moving funds to and from stealth addresses opens up room for creating accidental links between addresses. At Nocturne, we’ve spent considerable time on this problem. In the next week, we will be sharing more about our protocol design and how it expands on the concepts in this first blog post to create a more usable and effective payments solution. Stay tuned.

It is no question today that privacy on Ethereum is still one of the largest remaining challenges. Several attempts have been made to enable different kinds of privacy, including network layer privacy, confidential token transfers, and private smart contracts. Surprisingly, however, we still lack a truly usable solution for one of the seemingly most simple problems—receiving payments anonymously. Today, we outline the problem space of anonymous payments, how stealth addresses help solve the issue, and what outstanding UX problems remain. This is part one of a two-part blog post, where we outline the current state of anonymous payments in this first post, and discuss Nocturne’s approach more in the second post.

Alice wants to pay Bob 1000 DAI without revealing to the public that Bob is the receiver. Alice also wants to do so in a manner that requires no interaction with Bob beforehand. For the above, we would need a system where Alice can generate multiple addresses or identifiers that Bob owns but that the rest of the world doesn’t know belong to Bob.

In short, a stealth address system is exactly the above: a system (either at the Ethereum account level or within a smart contract) that allows for the generation of many unlinkable “one-time addresses”.

EIP-5564 outlines a standard for generating stealth externally owned accounts (EOAs) in a non-interactive manner. In short, a recipient owns a spending and viewing key, both standard Ethereum private keys. The combination of the two keys’ public keys comprises a stealth “meta address.” A sender can use the meta address to non-interactively derive a shared secret with the recipient. Using this shared secret, the sender will generate a fresh Ethereum address that the recipient can exclusively derive the private key for. The sender will then transfer funds to the fresh Ethereum address, with the recipient detecting the transfer and deriving the address’s corresponding private key to take control of the received funds.

The full details of the EIP are here. In short, EIP-5564 is a strong step towards an out-of-the-box, compatible way to receive funds anonymously.

While EIP-5564 provides an EOA-level stealth address system, there are several usability drawbacks that make practical usage difficult.

The most immediate drawback of EOA-level stealth addresses is the fact that all movement of assets to and from the stealth address is publicly traceable. When the recipient wants to move the received assets, they need to be extremely careful not to link the received funds to their main wallet address. Transferring any funds from the stealth address to their main wallet (directly or indirectly) would immediately create a visible link between the stealth address, the user’s main wallet, and any other stealth addresses that become linked to the main wallet. Keeping separation between different EOAs is quite difficult in practice.

Another related challenge is paying transaction fees with newly funded stealth addresses that have an ETH balance of 0. You can’t just fund the stealth address with ETH from your main wallet because that would create a link. You could use EIP-4337 bundlers to relay your transaction but this only works when the stealth address has acceptable ERC-20 gas tokens to compensate the bundler. If you have neither ETH nor valid gas tokens, your funds are nearly stuck.

What’s needed is a stealth address system that allows a stealth address owner to move funds without revealing what stealth address the funds are coming from. This way, received funds can be moved or gas funds provided without creating public links.

As described above, the core problem with relying on just stealth EOAs for payment anonymity is that moving funds to and from stealth addresses opens up room for creating accidental links between addresses. At Nocturne, we’ve spent considerable time on this problem. In the next week, we will be sharing more about our protocol design and how it expands on the concepts in this first blog post to create a more usable and effective payments solution. Stay tuned.