In the first part of this two-part blog post, we introduced the problem of anonymous payments, EIP-5564, and some of the outstanding UX challenges with stealth EOAs. To recap, in order to pay someone without revealing them as the recipient, we need a system that enables the generation of many unlinkable “one-time addresses” belonging to the recipient. EIP-5564 enables exactly this, where the stealth addresses are Ethereum EOAs. The core problem with using EOAs as stealth addresses, however, is that sending funds to and from these public addresses creates visible links. This makes moving the anonymously received assets or funding the stealth addresses for gas fees quite difficult in practice. 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 can be provided without creating any links.

Nocturne mitigates the problems described above by combining a “contract-internal” stealth address system with a shielded pool.

For starters, a contract-internal stealth address scheme means that instead of owning multiple ephemeral Ethereum addresses, a user owns several “internal” addresses within the Nocturne contract. The addresses themselves are not Ethereum addresses but rather identifiers specific to the Nocturne protocol. The exact details of the cryptography of the stealth address scheme can be found in our docs. The main benefit of using an address scheme separate from Ethereum accounts is that we have more flexibility with how we can represent and update user accounts (more details in the coming paragraphs).

Now, what is a shielded pool? A shielded pool is a protocol enabling the accounting and spending of funds without revealing their owners. Users deposit funds into a shielded pool, producing a “note” in return that represents the users’ claim to their funds. The main fields on a note are the token address, the amount of tokens the note contains, and an “identifier” (address) for the owner. To spend the funds contained in the note, the user must prove in zero-knowledge that they have the key corresponding to the owner field in the note. For more details, see the preliminaries section of our docs.

Combining the previous two concepts, Nocturne is a shielded pool where note owners are Nocturne stealth addresses (see diagram above). A sender can deposit funds into the Nocturne pool, listing the Nocturne stealth address of the recipient as the owner of the note that will be produced. The recipient will then notice the newly produced note and can then spend the funds by proving note ownership in zero-knowledge.

Moreover, Nocturne has a built-in gas payments mechanism that allows the user to use tokens across any of their stealth addresses to pay relayers for gas, all while concealing the links between the stealth addresses.

The benefits of a shielded pool paired with an internal stealth address system are twofold.

1. Users can still transfer the anonymous funds back to their main wallet address without creating a direct link, as note ownership is proved in zero-knowledge.

2. Users can easily pay gas fees through the built-in gas payment mechanism using funds from any of their stealth addresses.

Combined, these two benefits eliminate liquidity fragmentation between addresses and greatly reduce the chance of linking together addresses (externally-owned or contract-internal). This way, less savvy users can easily transact with received funds and maintain privacy with minimal mental or technical overhead.

Payment privacy has been an old yet unsolved problem. While stealth EOAs (such as in EIP-5564) are a major step forward in improving on-chain privacy, they are not without their challenges. Combining an effective stealth addresses scheme with a shielded pool offers a low-friction solution for payment privacy.

We’re currently on testnet getting feedback on our private vault UI. We’re excited to share more updates as we approach mainnet.

In the first part of this two-part blog post, we introduced the problem of anonymous payments, EIP-5564, and some of the outstanding UX challenges with stealth EOAs. To recap, in order to pay someone without revealing them as the recipient, we need a system that enables the generation of many unlinkable “one-time addresses” belonging to the recipient. EIP-5564 enables exactly this, where the stealth addresses are Ethereum EOAs. The core problem with using EOAs as stealth addresses, however, is that sending funds to and from these public addresses creates visible links. This makes moving the anonymously received assets or funding the stealth addresses for gas fees quite difficult in practice. 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 can be provided without creating any links.

Nocturne mitigates the problems described above by combining a “contract-internal” stealth address system with a shielded pool.

For starters, a contract-internal stealth address scheme means that instead of owning multiple ephemeral Ethereum addresses, a user owns several “internal” addresses within the Nocturne contract. The addresses themselves are not Ethereum addresses but rather identifiers specific to the Nocturne protocol. The exact details of the cryptography of the stealth address scheme can be found in our docs. The main benefit of using an address scheme separate from Ethereum accounts is that we have more flexibility with how we can represent and update user accounts (more details in the coming paragraphs).

Now, what is a shielded pool? A shielded pool is a protocol enabling the accounting and spending of funds without revealing their owners. Users deposit funds into a shielded pool, producing a “note” in return that represents the users’ claim to their funds. The main fields on a note are the token address, the amount of tokens the note contains, and an “identifier” (address) for the owner. To spend the funds contained in the note, the user must prove in zero-knowledge that they have the key corresponding to the owner field in the note. For more details, see the preliminaries section of our docs.

Combining the previous two concepts, Nocturne is a shielded pool where note owners are Nocturne stealth addresses (see diagram above). A sender can deposit funds into the Nocturne pool, listing the Nocturne stealth address of the recipient as the owner of the note that will be produced. The recipient will then notice the newly produced note and can then spend the funds by proving note ownership in zero-knowledge.

Moreover, Nocturne has a built-in gas payments mechanism that allows the user to use tokens across any of their stealth addresses to pay relayers for gas, all while concealing the links between the stealth addresses.

The benefits of a shielded pool paired with an internal stealth address system are twofold.

1. Users can still transfer the anonymous funds back to their main wallet address without creating a direct link, as note ownership is proved in zero-knowledge.

2. Users can easily pay gas fees through the built-in gas payment mechanism using funds from any of their stealth addresses.

Combined, these two benefits eliminate liquidity fragmentation between addresses and greatly reduce the chance of linking together addresses (externally-owned or contract-internal). This way, less savvy users can easily transact with received funds and maintain privacy with minimal mental or technical overhead.

Payment privacy has been an old yet unsolved problem. While stealth EOAs (such as in EIP-5564) are a major step forward in improving on-chain privacy, they are not without their challenges. Combining an effective stealth addresses scheme with a shielded pool offers a low-friction solution for payment privacy.

We’re currently on testnet getting feedback on our private vault UI. We’re excited to share more updates as we approach mainnet.