Privacy in Ethereum - Stealth Address

Source: Denglian Community

Introduction

A major pain point faced by Web3 crypto users is the lack of privacy. All transactions are visible on the public ledger and are increasingly associated with a clearly visible ENS name, which makes users lack motivation to perform certain activities or causes them to perform these activities in a way that increases friction in the user experience. An example is simply transferring funds from a hot wallet to a cold wallet or vice versa. Users may not want one wallet to be connected to another because they may not want their cold wallet balance to be seen. Currently, Ethereum addresses do not operate like private bank accounts, because everyone can see your wallet, and increasingly, your social activities (SBT, proofs, activities on various dapps, etc.) are also visible. It’s for this reason that Vitalik calls privacy one of the three major technical transitions that Ethereum needs to go through in order to be useful to the average user.

With existing privacy solutions, like Tornado Cash, the experience is less than ideal for a few reasons. First: users have legitimate concerns about their addresses being blacklisted on centralized exchanges or other platforms. Second, interacting with services like Tornado Cash is not user-friendly and is really only suitable for highly sophisticated users.

Stealth addresses provide users with a level of privacy similar to what they take for granted in their private bank accounts, and do so in an easy to understand way. Furthermore, innovation around stealth addresses means we can do this in a way that complies with anti-money laundering regulations in multiple jurisdictions.

User Demand for Privacy

While research on network and Web3 user attitudes towards privacy is not extensive, a web search found the following studies with broadly consistent results, indicating a clear demand for transaction privacy.

1. A survey conducted in 2022, published in a paper titled User-perceived privacy in blockchain by Simin Ghesmati et al., noted that “half of respondents said transaction privacy is very important to them”. While this study is more relevant to Bitcoin, Ethereum users may have similar attitudes. However, the sample size of this study was relatively small (14 participants).

2. Another interesting study comes from 2022, published in Frontiers, titled Political, economic, and governance attitudes of blockchain users, which is more comprehensive and surveyed 3,710 crypto users. The results showed that about a quarter of the respondents said that privacy is the "most important feature of blockchain and cryptocurrency."

1. In terms of overall attitudes towards privacy, Consensys released a study called Web3 and crypto global survey 2023, in which 15,158 people from 15 countries were surveyed online on various topics related to the web, not just encryption. The survey found that 83% of respondents believed that data privacy was important, while only 45% said they trusted current Internet services to use their data and personal information.

2. A survey conducted by the UK Financial Services Compensation Scheme, published in April 2023, highlighted that 9% of respondents cited "desire for anonymity/privacy" as their reason for investing in cryptocurrencies.

Adoption of Confidential Trading Protocols

Railgun’s usage statistics are impressive, with usage of the protocol appearing to grow steadily over time, reaching over $70M in total value locked (TVL) and $2B in trading volume as of November 2024.

TVL (USD) Railgun on Ethereum Mainnet — Source: Railgun — DefiLlama

Umbra has also seen a steady increase in usage (number of people registering stealth addresses to their ENS), approaching 77,000 as of November 2024:

TVL (USD) Railgun on Ethereum Mainnet — Source: Railgun — DefiLlama

Umbra has also seen a steady increase in usage (number of people registering stealth addresses to their ENS), approaching 77,000 as of November 2024:

Umbra Cumulative Signups (Cross-Chain) — Source: dune.com

If we look at the most widely known (and now unfortunately infamous) privacy protocol in Ethereum, Tornado Cash, we can see that it continues to see heavy usage despite the contract address being technically listed on OFAC’s SDN list.

The chart below shows Tornado Cash’s TVL over time. We can observe that from its peak around October 2021, the first major drop in TVL coincided with the overall sell-off in the crypto market, the second major drop occurred in August 2022, coinciding with OFAC’s listing of Tornado Cash on the SDN list, and the third major drop corresponded to OFAC’s redesignation in November 2022. However, since then, Tornado Cash’s usage has continued to grow steadily despite sanctions, with a TVL approaching $600M. This is a strong demonstration of the need for fundamental transaction privacy in Ethereum.

TVL (USD) Tornado Cash on Ethereum Mainnet — Source: Tornado Cash — DefiLlama

Current Status of Stealth Addresses

This study identified 4 major solutions currently being produced on the EVM chain, which are:

• Fluidkey

• Umbra

• Labyrinth

• Railgun

Fluidkey and Umbra are based on Ethereum standards, which are:

• ERC-5564: Stealth Address Protocol

• ERC-6538: Stealth Meta Address Registry

Labyrinth and Railgun are based on

At a high level, the basic principle of stealth addresses is that a third party can send funds to an address that never existed, and the intended recipient can find and control the address (i.e. can subsequently spend those funds).

The ERC-5564 standard specifies a mechanism for recipients to publish a stealth meta address from which new Ethereum addresses can be derived. Anyone who wishes to send funds to a recipient can generate a new address from a stealth meta address and allow the recipient to learn of those funds without any direct communication. All stealth address implementations are based on this basic premise.

How Stealth Addresses Work

A stealth meta address is essentially a concatenation of two compressed public keys, called a "spend key" and a "view key". A stealth meta address uses the EIP-3770 chain-specific address format with an "st:" prefix. Here is an example of a stealth address:

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

To simplify, this stealth address can be associated with a normal Ethereum address (and therefore ENS), making it easier to send funds to the stealth address owner. To send funds, the sender resolves the above address and creates a temporary public key using the EIP-5564 standard from which the stealth address is derived. The sender sends funds to the new stealth address, typically through a singleton contract that listens for events for all stealth address recipients. This contract emits an "announce" event, which recipients can subscribe to. Whenever an announce event is emitted, the recipient checks the temporary public key in the announcement, combines it with their view private key, and determines if they have the ability to spend the funds sent to the stealth address. If so, the wallet/client they are using will remember the stealth address and the corresponding funds, and add them to the user's displayed balance. To actually spend these funds, they can sign a transaction using their private spend key.

The following diagram outlines the whole process more clearly:

Remember that this process is completely non-interactive, meaning there is no direct communication between the sender and the receiver, which means there is actually no link between the sender and the receiver that can be observed by any third party.

However, in order for this to work, the receiver must tell the sender their stealth address. One way to achieve this is to use the eip-6538 Confidential Meta Address Registry. This is a singleton contract that allows users to register a confidential meta address to a normal Ethereum address, which can be looked up by senders. This allows senders to resolve a normal address from ENS, and then look up the associated confidential meta address from the registry.

This scheme breaks the link between sender and receiver, allowing them both to avoid the whole world knowing about their transactions. However, there are some caveats:

• When the receiver goes to spend funds, the person they transferred the funds to will see that those funds came from the original sender (i.e., they can see the address the funds were transferred to and who previously sent funds to that address). This means that the chains of transfers remain intact and traceable, but they are only unlinked to the relevant receiver (unless the receiver does something like send funds to a non-confidential address known to them). Note that this only applies to the erc-5564 implementation, not Railgun or Labyrinth.

• Another side effect of the above issue is that, in order to maintain optimal privacy, users may want to keep funds in the stealth addresses they originally sent to until they actually need them, rather than consolidating them under a single address. This represents the additional overhead of remembering addresses, and subsequently spending funds on those addresses, since the amount you wish to transfer needs to be sourced from a combination of funds from multiple other addresses.

• In order to transfer funds from that address, the recipient needs to provide that address with some ETH to pay for gas, which can potentially make the recipient lose anonymity. This is a known issue with stealth addresses, and one of the reasons many implementations support eip-4337 and payers.

• A downside to the stealth address scheme is that the recipient needs to monitor the blockchain for announcement events, and check each one to determine if they have received funds. This is obviously an impractical overhead for most users, especially when receiving funds from multiple networks. To make this process more efficient, the standard specifies a "view tag", which is a truncated hash derived from a shared secret that can be used to quickly discard transactions that were clearly not intended for them. By using a view tag, performance on a desktop isn't that bad, but it may be more noticeable on a mobile device. The only time the performance hit is really noticeable is if the wallet is being restored, in which case the wallet needs to scan every address since the on-chain contract was deployed, which is very time-consuming.

• To address this, users can choose to share a private view key with a trusted third party. This third-party service can monitor various networks and notify users when they receive funds. Of course, this comes with a trade-off: while the third party can't actually spend the user's funds (they don't have the private spend key), they can see all funds sent to a specific recipient, which means the user needs to trust their privacy. Fluidkey does this by default.

• The standard stealth address protocol, ERC-5564, is designed to facilitate privacy-preserving transfers, however, non-financial use cases (like calling arbitrary smart contract functions) require more engineering and are often implementation-specific.

Comparison Matrix

There are a number of ways we can compare the four stealth address implementations explored in this article. All implementations have subtle differences and trade-offs, but perhaps the most important takeaways are about traceability and obfuscation of value.

While both Fluidkey and Umbra allow funds to be transferred to a standard Ethereum address while breaking any link to the recipient’s identity, they still retain the traceability of the transaction, meaning the sender is visible to anyone who inspects the stealth address’ transaction history. This means that if you receive funds at a stealth address, whoever you decide to send those funds to will see where they came from. Additionally, the actual value transferred is visible as well. Railgun and Labyrinth hide the sender as well as the value being sent, but at the expense of having it all happen within a single contract, rather than as a normal transaction to a normal Ethereum address.

The figure below shows how the protocols we discussed in this article compare to each other on these two important comparison dimensions.

To explore these differences in more detail, here is a comparison matrix of the four major shielded address protocols on six major dimensions:

1. Full end-to-end privacy (only the sender and receiver see the payment information)

2. Forward secrecy. Funds received via shielded transactions do not allow the second recipient to see the source of the funds

3. Adherence to the ERC-5564 and ERC-6538 standards

4. Implements an extensible, modular architecture that allows for integration with third-party dapps

5. Does the implementation provide an SDK that developers can use to integrate?

6. Does the solution provide compliance through some kind of de-anonymization support?

7. Does the design support obfuscation of the amounts/values ​​transferred?

The following sections capture some of the other nuances and distinctions in more detail. Each implementation has interesting nuances that may or may not impact your use case.

For example: In Fluidkey: all transactions go directly to a hidden address on-chain, while in Umbra**:** only ETH goes to a hidden address on-chain, and tokens go to a central contract, and with Railgun and Labyrinth all transactions go to the core contract, not directly to a hidden address on-chain.

A Deep Dive into the Implementation of Stealth Addresses

Fluidkey

Fluidkey is an implementation of erc-5564 that allows users to send, receive, swap, and bridge ETH and erc-20 tokens. At the time of writing, Fluidkey has been deployed on Base, Optimism, Arbitrum, Polygon, Gnosis, and the Ethereum mainnet.

Users interact with Fluidkey through its web UI. When they first log in with the wallet, they sign a key generation message from which their view and spend keys are derived. These same keys are regenerated in the same way each time the user enters the app.

Fluidkey differs from other implementations in a few ways. One of the differences is that users share their private view key (actually a BIP-32 derivation node) with Fluidkey. This enables Fluidkey to generate stealth addresses for users and notify users when they receive payments to those addresses. However, this also means that Fluidkey has the ability to view users' incoming transactions and balances, which is a trade-off. However, Fluidkey still maintains full self-custody.

Another interesting aspect of Fluidkey's design is that it deploys a smart contract account for each new stealth address. This will only happen if funds funded from a stealth address are spent. A Smart Account is a 1/1 secure account that allows for actions such as gas sponsorship, making it easier to manage various stealth addresses. More information on this can be found in their Technical Walkthrough.

While Fluidkey does retain visibility into user accounts, which could potentially be an advantage in terms of compliance, the exact framework for how Fluidkey will handle potential future law enforcement requests has not yet been made public. They are based in Switzerland, and while they are subject to local laws, data protection laws are very clear and strong - there must be a very clear reason to share data, and the matter is subject to court review (See this article for an excellent overview of Swiss privacy law).

Users are also fully able to export their transactions, or share their viewing keys with third parties such as accountants, which is particularly useful for businesses. It is worth noting that, per the ERC-5564 specification, the sharing of a public key is “all or nothing”, meaning it cannot reveal a single transaction in isolation. Additionally, as with all ERC-5564 implementations, traceability is not broken – only the association to the user is broken – meaning the transaction history of each stealth address is public to anyone with a view key. A lesser known feature of Fluidkey is the ability to rotate view keys, which would allow a user to use a new view key each month and only share view access with third parties for a particular month.

One benefit of the Fluidkey approach is that the stealth addresses themselves are not generated by the sender, but are instead pseudo-randomly generated by Fluidkey each time it queries ENS. This is faster because users don’t have to scan through announcement events to identify transactions where they are the recipient. It also means that senders don’t need a stealth address wallet to generate a stealth address for the recipient – ​​they can just send funds like any other address. It also means there is no registry contract involved, which is unique to the Fluidkey design and a major advantage.

It’s worth mentioning that Fluidkey is committed to being completely self-custodial, and they’ve open-sourced their shielded account toolkit library, and in the unlikely event that Fluidkey disappears overnight, there are several independently developed recovery interfaces available, meaning funds can never be locked or stuck.

Address Abstraction

By using smart contract accounts, Fluidkey can automatically abstract away the management of individual shielded addresses. This means that if you want to transfer a specific amount from your balances in various shielded addresses to a specific recipient, Fluidkey can automatically figure out the combination of addresses to transfer the funds, handling all the gas fees and contract deployment, all in the background. Fluidkey also allows users to have some control over which addresses are combined through a cool feature called Tags, which allows users to tag addresses into different categories.

ENS Resolution

Fluidkey requires users to create ENS names that are unique to Fluidkey. These static names come in two forms: username.fkey.id and username.fkey.eth, one is a URL pointing to a web interface for sending funds to someone, and the other is a standard ENS name that can be used with a wallet.

The ENS setup uses the ENS offchain resolver (also known as erc-3668: CCIP Read) to return the stealth address. Each time the offchain resolver is queried, it generates and returns a new stealth address for the corresponding ENS name. This is a great feature because it allows users to have a single human-readable ENS name while still retaining the privacy of the stealth address, as the generated stealth address cannot be traced back to the ENS name.

Fees

Fluidkey is free to use and there are no fees. When you want to spend funds, each address with funds in it incurs the cost of deploying a Safe contract. However, while relatively expensive on mainnet, on L2 this is actually negligible, typically under 1 cent, even when combining multiple stealth addresses into a single transfer.

They can also do gas sponsorship with Safe deployments - they calculate the gas fee and deduct it from the user's balance, even if it's one token - in which case the forwarder deploys the Safe and transfers the token on the user's behalf.

Umbra Cash

Umbra is Scopelift's implementation of eip-5564 + eip6538. When a user logs into the Umbra app, they go through a setup phase where they sign a message from which they derive their spend and view keys and corresponding stealth meta address. They then register this stealth meta address in the on-chain registry of their primary wallet address. This is where the implementation differs from Fluidkey.

Umbra's implementation of ERC-5564 is closest to the spec in that they do not have access to the user's keys. While this means that Umbra (or anyone else) cannot see a user's funds, it does mean that in order to receive funds, the sender must have an ERC-5564 compatible wallet (or the Umbra app) to generate their stealth meta address.

When someone wants to send funds to a user, they will typically use the Umbra app to do so. Basically, the Umbra app looks for a stealth meta address registered to an ENS name/wallet address and generates a stealth address. Recipients can log into the Umbra app and scan for any funds sent to a stealth address belonging to them since the last time they logged in. Thanks to some clever caching, this seems to take only 10-15 seconds for a weekly scan, although users will also have the option to specify a block range to narrow the scan. Umbra v2 will include the use of view tags, which will speed up the process even further.

Forwarders

One of the issues with stealth addresses we mentioned earlier is that in order for a recipient to spend funds sent to a stealth address, that address needs to have ETH or other necessary gas tokens in place to pay for the transaction. On most networks, this is generally not a problem if the stealth address originally received ETH. However, if the stealth address receives an erc-20 token or NFT, the act of gassing the address with ETH could potentially associate that address with the user's other addresses, resulting in a loss of privacy.

To get around this, Umbra uses a construct involving relays. When any non-ETH asset is sent to an Umbra user, it is actually sent to a special contract, rather than directly to a shielded address. Users can spend funds sent to their shielded address by sending a meta transaction (from the Umbra app) to Umbra's relay, which will transfer the funds from the smart contract on the user's behalf. Relays will deduct some tokens to cover the cost of gas fees, and will only support a certain amount of tokens initially.

Fees

Umbra contracts also charge a small fee when transferring funds on networks with low transaction fees, in order to disincentivize spam. The rationale is that spam would increase the cost of scanning transactions to identify relevant ones, so this is seen as an acceptable tradeoff.

Supported Networks

Umbra is currently deployed on the Ethereum mainnet, as well as Optimism, Polygon, Gnosis Chain, and Arbitrum.

The Umbra registry contract has an interesting design. The deployment method uses create2 and the standard create2 deployer, the smart contract address is the same on any network. This means that if the contract exists on a given network, the client can be sure that this is the right contract. The client can be configured to add networks, and anyone can deploy to any network. They have normalized the bytecode, and contracts have no owners, which allows anyone to deploy registry and announcement contracts permissionlessly on any chain.

Umbra v2

Scopelift is currently working on version 2 of Umbra, which introduces a new modular architecture that allows the core contracts to be extended to support new token standards or non-payment use cases. Using this new architecture, third-party developers can build modules for any type of token standard, such as erc-1155, erc-7621, support for erc-4337 payees, or anything else you can think of. Currently, the Umbra core contract supports two scenarios, one for ETH and the other for erc-20. V2 will support many different scenarios.

Labyrinth

Labyrinth is a protocol that is not based on eip-5564 + eip6538, but uses zero-knowledge proofs to add anonymity and privacy to transactions. Labyrinth's white paper describes it as "zkFi" middleware: "zkFi provides a packaged solution that acts as a privacy middleware with built-in compliance". Built-in compliance refers to Labyrinth’s “selective de-anonymization,” a sophisticated solution that allows certain transactions to be de-anonymized to specific authorized parties (i.e. legal agencies like Interpol, etc.) while remaining transparent and open.

The core smart contracts used by Labyrinth include a multi-trading and multi-asset pool that allows users to trade multiple assets in a single transaction. To spend assets, users scan the network and obtain encrypted ticket data, decrypt the ticket, and filter out the assets they want to spend. Subsequently, the user creates a ZKP that includes the transaction and the signing key for the ticket associated with the transaction they want to spend.

Part of the Labyrinth core contracts includes a conversion contract that interfaces with modular proxy contracts, which are basically proxies for external contracts. So, for example: if a user wanted to use Labyrinth to interact with Uniswap, the user would construct a transaction that would use the conversion contract to call a swap operation on the Uniswap pool through Uniswap’s proxy contract.

Labyrinth’s zkFi protocol uses “tickets” to track balances and transfers. A note is essentially a data structure that describes a certain amount of an asset and the address to which it belongs. Clients store the information needed to reconstruct the note and use this information to spend assets. Commitments to a note (a hash of the asset ID, owner, and value) are stored in an on-chain Merkle tree. In fact, Labyrinth uses two Merkle trees, one for the note and one for the root address.

The note data structure contains the following:

• assetId: The identifier of the asset this note represents (ETH, WBTC, MATIC, etc.).

• value: The value or amount the note represents.

• leafIndex: The leaf node index of the commitment Merkle tree that this note will be inserted into.

• blinding: A random protection factor.

• rootAddress: The root address of the user with spending authority.

• revoker: The public key point of the chosen revoker.

You’ll notice that the above data structure does not contain any reference to the owner of the asset, which is odd since the commitment recorded in the note Merkle tree is a hash of the asset ID, value, and owner. In fact, the owner is calculated from the root address, the revoker, and the random protection factor, so to an outside observer the owner is actually a new address generated for each new transaction.

Protection Pool

What’s particularly interesting about Labyrinth is that it’s a bit different from traditional stealth address based protocols, the asset pool is actually a protection pool, which leverages the concept of notes to create a kind of shielded UTXO pool, providing forward secrecy for transactions. Recall that in the eip-5564 implementation, the people to whom users transfer funds will be able to see the source of those funds. In other words, Alice pays Bob from a stealth address, who pays Charlie, so Charlie can now see that Bob originally received those funds from Alice, and so on. This is not the case with Labyrinth’s protection pool.

To understand how this protection pool works, we need to look at how funds are transferred inside the protocol:

A user’s balance in the protection pool is the sum of notes for the corresponding assets. In order to spend these notes, the user needs to reveal the “invalidation flag” of those notes. The invalidation flag is uniquely associated with a note, and once the note is spent, the invalidation flag is marked to prevent double spending, and a new note is created based on the already spent note. Multiple notes for the same asset can be merged, and multiple new notes can be created. The invalidation flag is simply the hash of (?,?,?), where ? is the index of the note’s commitment in the note’s Merkle tree, ? is the commitment, and ? is a random element also known as a protection factor.

The recipient of a shielded transaction transfer identifies the transfer in the same way as eip-5564, in that they listen to events emitted from the core contract and determine the shielded addresses from which they will be able to send funds, and record these locally. The speed of identifying incoming funds has also been improved by leveraging view tags and asynchronously caching and syncing notes locally during the application lifecycle.

There is research underway to speed up the process of discovering received funds, take a look at this proposal from Aztec: Request for Proposals: Note Discovery Protocol — Aztec.

In terms of spending funds, users must also generate a zk proof, which is different from the erc-6654 implementation which is basically a normal ethereum address. Generating the proof requires a compatible wallet and performance is relatively good, taking about 20 seconds on a mid-range Android device.

Packagers and Converters

Labyrinth offers some nice features that solve some of the pain points in confidential transactions. Transactions sent to the Labyrinth core contract are sent as user actions through an erc-4337 packer. This setup allows notes to be spent without the need for ETH or gas tokens for the transaction, as users can leverage erc-4337 payers to pay for gas for them, adding an extra layer of privacy. The only exception is the initial deposit, which is not submitted as a user action. Another benefit of using erc-4337 payers is the ability to pay for gas through the assets being transferred, even if they are erc-20 tokens, so Labyrinth exposes a gas price oracle API.

Another very nice feature of Labyrinth is its modular architecture, allowing the converter contract to act as a proxy for third-party decentralized applications. This not only allows users to transfer funds using confidential transactions, but also interact with third-party decentralized applications (e.g. DEXs such as Uniswap, Aave, Lido, etc.). These proxy "converter" contracts essentially implement a function that takes in an input of some asset and outputs some asset, with the underlying logic residing in some third-party contract.

Compliance Solution

Labyrinth ensures compliance and regulatory compliance through a framework called Selective Deanonymization (SeDe).

Recall that the data structure of a note contains a field called "revokers". Revokers are the addresses of specific entities that can initiate the deanonymization process. Users must select at least one revoker from a predefined list. Revokers are not solely responsible for identifying potentially illegal or inappropriate activity, but can respond to requests from law enforcement agencies.

Revokers do not have the individual ability to directly deanonymize transactions, but they are responsible for initiating deanonymization requests. These requests are publicly posted to the Guardians, a committee of entities that oversee privacy and compliance. The Guardians must decide by voting whether to allow the deanonymization transaction. If the guardians can reach a quorum and vote in favor, the revoker can decrypt the transaction data, thereby linking the transaction in question to previous transactions until the chain of transactions is fully deanonymized.

This system creates a series of checks and balances, as the guardians cannot decide to reveal transaction data alone, and even if they collude, they cannot do anything without the revokers, and the revokers alone cannot do anything without a majority vote of the guardians.

Railgun

RAILGUN is a confidential transaction privacy system deployed on Ethereum, Binance Smart Chain, Polygon, and Arbitrum. The protocol is similar to Labyrinth in some ways, in that it is based on notes, which are stored as commitments in a Merkle tree to form a UTXO set, which is spent by creating new notes for other recipients. This means that only the owner of a note can compute its invalidation flag, which is generated from a hash of the spend key and the index of the note in the Merkle tree.

Secret meta addresses in Railgun use a prefix of "0zk", similar to eip-5564, which is a combination of a public view key and a public spend key. However, Railgun uses Ed25519 keys on the BabyJubJub curve instead of ECDSA and secp256k1. Just like eip-5564, users scan all emitted events in the Railgun contract and use their view key to determine which events represent transfers to their wallet.

Railgun uses a network of Broadcasters, which are essentially relayers that receive meta transactions from users and broadcast the actual transactions to the corresponding blockchain, paying gas fees on behalf of the user. User-to-Broadcaster transactions are encrypted and communicate using the Waku protocol, protecting the anonymity of the end user.

Railgun has a modular architecture that allows it to interact with external smart contracts, providing functionality beyond simple transfers. It does this through the AdaptRelay contract, which shields and unshields tokens before and after interacting with external contracts, e.g., unshields token A, swaps token B on some AMM, shields token B back to the original owner.

In version 3, Railgun plans to leverage eip-4337 and support traditional meta transactions. They hope to enable independent solvers to participate as broadcasters by maintaining a dedicated eip-4337 userop mempool for Railgun. They are currently working with Umbra to research this and identify edge cases and how to solve them, see the Railgun v3 section below for more details.

Fees

The Railgun protocol charges a 0.25% fee on deposits and withdrawals. These fees are sent to the DAO treasury, which is paid out to stakers of RAIL governance tokens over time. In addition to the 0.25% deposit and withdrawal fees, broadcasters typically charge their own fees, which are typically around 10% of the gas fees of the actual on-chain transactions.

Governance

Railgun has a governance system that allows for proposals of any kind to be submitted, and any changes to the core contracts (including the treasury and governance contracts) must go through a DAO proposal before they can be made. Unusually, different instances of Railgun have their own governance. For example, Railgun has separate governance systems and tokens on Ethereum, Polygon, and Binance Chain.

SDK and Cookbook

Railgun provides a comprehensive and well-documented SDK that wallet or DApp developers can use to build stealth address functionality with support for Railgun. Railgun also has a community-maintained cookbook that provides "recipes" that allow DApp developers to contribute modules to Railgun that enable users to interact with their DApps using Railgun. For example, a developer could write a recipe for a DEX that enables users with token balances in Railgun to privately swap tokens.

RailGun v3

The next iteration of Railgun will reduce transaction costs by 50% to 60%. Other changes in version 3 are support for eip-4337 userops, implemented via a dedicated mempool. Additionally, v3 will support an intent-based architecture, allowing solvers to compete for best execution, although the details are still very high-level as of writing. They are currently working with CowSwap, planning to use pre- and post-hooks to allow solvers to access funds.

Railgun Connect

Arguably the most interesting change in the proposal is a tool called Railgun Connect, which is similar to WalletConnect and allows 0zk addresses to connect to most frontends for private use, without requiring those DApps to explicitly provide integration with Railgun via a custom module.

Railgun Connect is a browser extension that actually does what it does by using HardHat to replicate the state of the chain locally, and injecting its own web3 provider into DApps, with an RPC endpoint for the local HardHat version of the chain. This allows you to interact with the DApp contract as normal, record the transaction, then batch it and create a snark proof, and send it to the Railgun contract on the actual chain. While this description is a bit simplistic, it conveys the general idea. This allows you to basically interact with almost any DApp (there may be some edge cases for DApps that require additional off-chain processing). It is important to note that saving the state of the chain locally is a resource-intensive operation, but once it is completed, you can interact with the DApp using Railgun's stealth addresses, which is no different than using a normal wallet.

Conclusion

There are currently some interesting proposals for establishing stealth addresses in the Ethereum protocol. For example, Inco uses the concept of an erc-20 "wrapper" that wraps a normal erc-20 contract and encrypts all balances. Transfers and approvals are all done in an encrypted state using fully homomorphic encryption. Inco relies on precompiles that currently only exist on its own network, but may move to Ethereum in the future.

There is another proposal called EIP-7503: Zero-Knowledge Wormholes, which is based on a design called "proof of burn", although this proposal does not seem to have gained much traction, perhaps because it requires an update to the EVM, and without this update, it can only really be implemented at the token level, using an erc-20 design that specifically supports eip-7503 (or if an L2 decides to add support to their EVM opcodes).

Aztec is perhaps the most complex privacy technology currently available, but requires users to bridge their funds to Aztec in order to use it, which may not be acceptable to most users. However, if demand for basic transaction privacy grows among Ethereum users, then Aztec may have a unique value proposition and become a very valuable L2 as DApps and users migrate to a platform that provides privacy by default.

Similarly, Intmax is a privacy-centric Ethereum L2 (based on the Plasma design) that also has a compliance and regulatory aspect, verifying the legitimacy of individual funds through ZKP-based AML proofs and imposing limits on transaction amounts. Intmax has limitations in providing privacy for transfers, and EVM smart contract operations are not private. However, unlike Aztec, smart contracts can be written in Solidity, which some developers may prefer (depending on the use case).

Wallet Support

While we are seeing increased adoption of stealth address protocols, which is a positive sign, there are still many challenges. The most important challenge is that they are not fully supported in mainstream Ethereum wallets (at least not yet). Major wallets may need to make several choices when providing support for stealth addresses. These choices include:

• Will they provide opt-in support for a single implementation, or will they build and maintain some kind of comprehensive aggregator across multiple protocols? The latter may be costly in terms of development and maintenance.

• Will there be regulatory considerations that require taking a position on the scope and mechanisms of selective de-anonymization (such as in the case of Labyrinth)?

• Stealth addresses require an on-chain component, via a registry contract (except for Fluidkey), which means that every EVM network must be explicitly supported by a wallet (although Umbra's design facilitates permissionless deployment of registries).

• Stealth addresses complicate existing integrations with block explorers such as Etherscan. For example, the "View on explorer" button will not work for stealth meta addresses, as the wallet displays aggregated balances. This issue may also exist for transfers. These edge cases need to be carefully considered.

• Depending on the underlying implementation, users will only be able to effectively use stealth addresses with a specific set of DApps, namely those that are supported by the underlying protocol. A modular stealth address architecture will make this possible. However, not all DApps will be supported, and users will need to be informed in some way. This is relatively easy with eip-5506, but there will still be complications and edge cases that may seep into the wallet's user experience.

There is also room for improvement in preventing poor privacy hygiene for users, see this paper: "Anonymity Analysis of the Umbra Stealth Address Scheme on Ethereum", where the authors successfully deanonymized 48.5% of stealth transactions on Ethereum mainnet. The heuristics they used were less about the protocol and more about privacy hygiene, such as users sending funds to a stealth address they controlled and then sending those funds back to the original sending address, mistakenly believing that traceability had been broken. Overall, the authors identified 6 different heuristics that could be used to deanonymize stealth address transactions, mostly based on not following best practices. However, these are all critical UX issues that need to be addressed.

Overall, I am quite bullish on stealth addresses and privacy in Ethereum in general. I think we have made pretty impressive progress and found some very fixable challenges. I’m confident that mainstream wallets will find ways to provide support for stealth addresses, making them easily usable with the normal level of privacy that users expect and deserve.

Thank you to all the teams that have invested their time and hard work in researching and building stealth address infrastructure, including the four protocols I mentioned in this post. Their efforts and tenacity will have a huge impact on Ethereum!