Source: Denglian Community
introduce
One of the major pain points that Web3 crypto users face is the lack of privacy. All transactions are visible on a public ledger and are increasingly associated with a clearly visible ENS name, which makes users less motivated to perform certain activities or causes them to perform those activities in a way that increases friction in the user experience. An example is simply moving funds from a hot wallet to a cold wallet or vice versa. A user may not want one wallet to be linked to another because they may not want their cold wallet balance to be visible. Currently, Ethereum addresses do not operate like private bank accounts because everyone can see your wallet and, increasingly, your social activity (SBT, proofs, activity on various dapps, etc.). Because of this, Vitalik calls privacy one of the three major technical transformations that Ethereum needs to go through in order to be useful to the average user.
Using existing privacy solutions, like Tornado Cash, the experience is less than ideal for several reasons. First: users will legitimately worry 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 skilled 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 toward privacy is not widespread, a web search found the following studies, which have broadly consistent results, indicating a clear need for transaction privacy.
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 indicated that 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).
Another interesting study from 2022, published in Frontiers , titled Political, economic, and governance attitudes of blockchain users , is more comprehensive and surveyed 3,710 crypto users. The results showed that about a quarter of respondents said privacy is the " most important feature in blockchain and cryptocurrency ."
In terms of overall attitudes towards privacy, Consensys released a study calledWeb3 and crypto global survey 2023 , in which 15,158 people from 15 countries were surveyed online on various web-related topics, not just crypto. The survey found that 83% of respondents believe that data privacy is important, while only 45% of respondents said they trust current Internet services to use their data and personal information.
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 transaction protocols
Railgun ’s usage numbers are impressive, with usage of the protocol appearing to grow steadily over time, reaching over $70M in total value locked (TVL) and $2B in transaction 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:
Umbra cumulative registrations (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 despite the contract address being technically listed on OFAC’s SDN list, it is still heavily used.
The chart below shows the TVL of Tornado Cash over time. We can observe that starting from the 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, corresponding to OFAC's inclusion 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 the sanctions, with TVL approaching $600 million. This strongly demonstrates the need for basic transaction privacy in Ethereum.
TVL (USD) Tornado Cash on Ethereum Mainnet — Source: Tornado Cash — DefiLlama
The Current State of Stealth Addresses
This research identified 4 main solutions currently in production 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: Confidential Meta Address Registration
Labyrinth and Railgun are based on the zerocash protocol (which zcash is also based on), which uses a protected pool where users deposit funds. Zerocash uses the concept of "tickets", which are basically cryptographic representations of value that enable private transactions. Each ticket consists of a hidden value, the owner's key, and a unique number (an invalidator), and zk-SNARKs are used to verify ownership without revealing the details, thereby transferring the value in the ticket. When a ticket is spent, its invalidator is revealed to prevent double spending, and a new ticket is created for the recipient, forming a UTXO system within the protected pool.
At a high level, the rationale behind stealth addresses is that a third party can send funds to an address that never existed, and the intended recipient can find and control that address (i.e. can subsequently spend those funds).
The erc-5564 standard specifies a mechanism whereby a recipient can publish a stealth meta address from which new Ethereum addresses can be derived. Anyone wishing to send funds to a recipient can generate new addresses from the stealth meta address and allow the recipient to learn of these 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 the concatenation of two compressed public keys, called the “spend key” and the “view key”. A stealth meta address uses the EIP-3770 chain-specific address format with the “st:” prefix added. 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 the funds to the new stealth address, typically through a singleton contract that listens for events on 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 private view key, and determines if they have the ability to spend the funds sent to the stealth address. If they do, 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 provides a clearer overview of the process:
Remember that this process is completely non-interactive, meaning there isn’t any direct communication between the sender and receiver, which means there is virtually no link between the sender and receiver that any third party can observe.
However, in order for this to work properly, the receiver must tell the sender their stealth address. One way to achieve this is to use the eip-6538 stealth meta address registry . This is a singleton contract that allows users to register a stealth meta address to a normal Ethereum address, which the sender can then look up. This allows the sender to resolve a normal address from ENS and then look up the associated stealth meta address from the registry.
This scheme breaks the link between the sender and the receiver, allowing them both to avoid the whole world knowing about their transactions. However, there are some caveats:
When the recipient goes to spend the 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 transfer chains remain intact and traceable, but they are only unlinked to the recipient in question (unless the recipient does something like send funds to a non-stealth address known to them). Note that this only works with 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 need to keep funds in the stealth address they were 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 this address, the recipient needs to provide some ETH to the address to pay for gas, which may cause the recipient to lose anonymity. This is a known issue with stealth addresses and one of the reasons why many implementations support eip-4337 and payers.
One 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 the 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 obviously not intended for them. By using view tags, 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 contract was deployed on the chain, which is very time consuming.
To solve this problem, users can choose to share a private viewing 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 (such as 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 tradeoffs, 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 preserve the traceability of the transaction, meaning the sender is visible to anyone who checks the transaction history of the stealth address. This means that if you receive funds at a stealth address, the person you decide to send those funds to will see where they came from. Additionally, the actual value transferred is visible. 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 following figures show 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 stealth address protocols across six main dimensions:
Complete end-to-end privacy (only the sender and receiver see payment information)
Forward secrecy. Funds received via a shielded transaction do not allow a second recipient to see the source of the funds
Follow the erc-5564 and erc-6538 standards
Implemented a scalable modular architecture, allowing integration with third-party dapps
Does the implementation provide an SDK that developers can use to integrate?
Does the solution provide compliance through some kind of de-anonymization support?
Does the design support obfuscation of the amount/value 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 the on-chain shielded address, while in Umbra**:** only ETH goes to the on-chain shielded address, and the tokens go to the central contract, and with Railgun and Labyrinth all transactions go to the core contract, not directly to the on-chain shielded address.
A Deep Dive into the Implementation of Stealth Addresses
Fluidkey
Fluidkey is an erc-5564 implementation that allows users to send, receive, exchange, 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 every time the user enters the app.
Fluidkey differs from other implementations in several ways. One of the differences is that users share their private viewing 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 shielded address. This only happens when funds funded from the shielded address are spent. The smart account is a 1/1 secure account that allows operations such as gas sponsorship, making it easier to manage various shielded addresses. For more information on this, you can check out their technical explanation .
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 been made public. They are based in Switzerland, and while they are subject to local law, the 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 capable of exporting their transactions, or sharing their viewing keys with third parties (such as accountants), which is particularly useful for businesses. It is worth noting that according to the ERC-5564 specification, the sharing of public keys is "all or nothing", meaning that it cannot reveal a single transaction in isolation. Additionally, as with all ERC-5564 implementations, traceability is not broken - only the association with the user is broken - which means that the transaction history of each stealth address is public to anyone with a viewing key. A lesser-known feature of Fluidkey is the ability to rotate viewing keys, which would allow users to use a new viewing key each month and only share viewing access with third parties for a specific month.
One benefit of the Fluidkey approach is that the stealth address itself is not generated by the sender, but rather is 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 they are the recipient of. 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. This 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 full self-custody, and they have open-sourced their hidden 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 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 calculate 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 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 stealth addresses. 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.
cost
Fluidkey is free to use and does not charge fees. When you want to spend funds, each address with funds incurs the cost of deploying a Safe contract. However, while relatively expensive on mainnet, on L2 this is actually negligible, typically less than 1 cent, even when combining multiple stealth addresses into a single transfer.
They can also do gas sponsorship via Safe deployment — they calculate the cost of gas and deduct it from the user’s balance, even if it’s one token — in which case the forwarder deploys Safe and transfers tokens 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 addresses. They then register this stealth meta address in the on-chain registry of their main wallet address. This is where the implementation differs from Fluidkey.
Umbra's implementation of erc-5564 is closest to the spec, as 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 typically use the Umbra app to do it. Basically, the Umbra app looks up a stealth meta address registered to an ENS name/wallet address and generates a stealth address. The recipient 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 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.
Forwarder
One of the issues with stealth addresses we mentioned earlier is that in order for the recipient to spend funds sent to a stealth address, the address needs to have ETH or other necessary gas tokens to pay for the transaction. On most networks, this is usually 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 may associate the address with the user's other addresses, thus losing privacy.
To get around this, Umbra uses a construct involving forwarders . 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 forwarder, which will transfer the funds from the smart contract on the user's behalf. The forwarder will deduct some tokens to cover the cost of gas fees, and will initially only support a certain amount of tokens.
cost
The Umbra contract also charges a small fee when transferring funds on a network with low transaction fees, in order to discourage spam. The rationale is that spam increases the cost of scanning transactions to identify relevant ones, so this is seen as an acceptable trade-off.
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 correct 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 contract 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 payers, 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 deanonymization", a complex solution that allows certain transactions to be deanonymized to specific authorized parties (i.e. legal agencies such as Interpol, etc.) while remaining transparent and open.
The core smart contracts used by Labyrinth include a multi-transaction and multi-asset pool, allowing users to trade multiple assets in a single transaction. To spend assets, users scan the network and obtain encrypted ticket data, decrypt the tickets, and filter out the assets they want to spend. Subsequently, users create a ZKP that includes the transaction and the signing key of 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 interact with Uniswap using Labyrinth, the user would construct a transaction that would use the conversion contract to call a swap operation on a Uniswap pool through Uniswap's proxy contract.
Labyrinth’s zkFi protocol uses “tickets” to track balances and transfers. A ticket is essentially a data structure that describes a certain amount of a certain asset and the address to which it belongs. Clients store the information needed to reconstruct the ticket and use this information to spend assets. Commitments to a ticket (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 ticket 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 where this note will be inserted.blinding: A random protection factor.rootAddress: The root address of the user with spending permissions.revoker: The public key peer of the selected 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 reality, the owner is calculated from the root address, the revoker, and a random protection factor, so to an outside observer the owner is actually a new address generated for each new transaction.
Protection Pool
What is particularly interesting about Labyrinth is that it is slightly different from traditional stealth address based protocols, the asset pool is actually a protection pool, which uses the concept of notes to create a shielded UTXO pool, thus providing forward secrecy for transactions. Recall that in the eip-5564 implementation, the object to which the user transfers funds will be able to see the source of those funds. In other words, Alice paid Bob with a stealth address, Bob paid Charlie, so Charlie can now see that Bob originally received these 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 within the protocol:
A user's balance in the protection pool is the sum of notes for the corresponding asset. In order to spend these notes, the user needs to reveal the "invalidation flags" 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 spent note. Multiple notes for the same asset can be merged, and multiple new notes can be created. The invalidation flag is 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 called a protection factor.
Recipients of shielded transaction transfers identify the transfer in the same way as eip-5564, as 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 addresses 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.
Research is currently 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 has relatively good performance, 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 packager. 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 an erc-4337 payer 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 really nice feature of Labyrinth is its modular architecture, which allows converter contracts to act as proxies 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 like Uniswap, Aave, Lido, etc.). These proxy " converter " contracts essentially implement a function that takes in an asset and outputs some asset, and the underlying logic exists in some third-party contract.
Compliance Solutions
Labyrinth ensures compliance and regulatory compliance through a framework called Selective De-anonymization (SeDe).
Recall that the note's data structure contains a field called "Revokers". A Revoker is the address of a specific entity that can initiate the deanonymization process. The user 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.
Reversers 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 Reverser 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 alone to reveal transaction data, and even if they collude, they cannot do anything without the revokers, and the revokers alone cannot do anything with 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, as 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 the note can calculate its invalidation flag, which is often generated based on the hash of the spending key and the index of the note in the Merkle tree.
Stealth 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 actually relayers that receive meta transactions from users and broadcast the actual transactions to the corresponding blockchain to pay gas fees on behalf of the user. User-to-broadcaster transactions are encrypted and communicated using the Waku protocol , protecting the anonymity of the end user.
Railgun uses 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 protects and unprotects tokens before and after interacting with external contracts, for example, unprotecting token A, exchanging token B on an AMM, and protecting 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 memory pool for Railgun. They are currently working with Umbra to research this issue and identify edge cases and how to solve them, see the Railgun v3 section below for more details.
cost
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 the RAIL governance token 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 core contracts (including 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 on Ethereum, Polygon, and Binance Chain have separate governance systems and tokens.
SDK and Cookbook
Railgun provides a comprehensive and well-documented SDK that wallet or DApp developers can use to build stealth address functionality through support for Railgun. Railgun also has a community-maintained cookbook that provides "recipes" that allow DApp developers to contribute modules to Railgun, enabling 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 exchange tokens.
RailGun v3
The next iteration of Railgun will see transaction costs drop by 50% to 60%. Other changes in version 3 are support for eip-4337 userops, implemented through a dedicated memory pool. 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 and plan 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, similar to WalletConnect, 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 this by using the state of a local copy of the chain from HardHat and injecting its own web3 provider into the DApp, with an RPC endpoint for the local HardHat version of the chain. This allows you to interact with the DApp contract as usual, recording transactions, which are then batched and snark proofs are created and sent to the Railgun contract on the actual chain. While this description is a bit simplistic, it conveys the general idea. This enables you to basically interact with almost any DApp (there may be some edge cases for DApps that require additional off-chain processing). It should be noted that saving the state of the chain locally is a resource-intensive operation, but once it is completed, you can use Railgun's hidden address to interact with the DApp without any difference from using a normal wallet.
in conclusion
There are some interesting proposals for implementing stealth addresses into 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 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 widespread 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 specifically to support eip-7503 (or if an L2 decides to add support to its EVM opcodes).
Aztec is probably the most sophisticated 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 the 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 aspect that verifies the legitimacy of individual funds through ZKP-based AML proofs and imposes limits on transaction amounts. Intmax is limited in providing privacy for transfers, and EVM smart contract operations do not have privacy. 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). Mainstream wallets may need to make several choices when providing support for stealth addresses. These choices include:
Will they provide opinionated support for a single implementation, or will they build and maintain some kind of comprehensive aggregator across multiple protocols? The latter is likely to be expensive to develop and maintain.
Will there be regulatory considerations and will a position need to be taken 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 because wallets show 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 DApps 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 when using eip-5506, but there will still be complexities and edge cases that may permeate the wallet's user experience.
There is also room for improvement in preventing poor user privacy hygiene, 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 had nothing to do with the protocol and were 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 can be used to deanonymize stealth address transactions, mostly based on not following best practices. However, these are all critical user experience 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 some pretty impressive progress and have found some very fixable challenges. I believe that mainstream wallets will find ways to provide support for stealth addresses and make it easy for users to use them with the normal level of privacy that users expect and deserve.
Thank you to all the teams that have invested 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!
