Source: Denglian Community

Introduction

A major pain point faced by Web3 encryption users is the lack of privacy. All transactions are visible on the public ledger and are increasingly tied to a clearly visible ENS name, which makes users less motivated to perform certain activities or causes them to perform them in a way that adds friction to the user experience these activities. 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 as they may not want their cold wallet balances to be seen. Currently, Ethereum addresses do not operate like private bank accounts, as everyone can see your wallet and, increasingly, your social activities (SBT, proofs, activity on various dapps, etc.) will be seen. Because of this, Vitalik calls privacy one of the three major technological transformations that Ethereum needs to undergo in order to be useful to ordinary users.

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. Secondly, the user experience of 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 a private bank account, but in a way that is easy to understand. Additionally, innovation around stealth addresses means we can do this in a way that is compliant with anti-money laundering regulations across multiple jurisdictions.

User demand for privacy

While research on Web and Web3 user attitudes toward privacy is not extensive, a web search uncovered the following studies with broadly consistent results indicating a clear need for transactional privacy.

A survey conducted in 2022, published by Simin Ghesmati et al. in a paper titled User-perceived privacy in blockchain, stated that “Half of respondents stated that transaction privacy is very important to them. Important”. While this research 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, was more comprehensive and surveyed a total of 3,710 crypto users. The results show that about a quarter of respondents said privacy is the "most important feature in blockchain and cryptocurrencies".

In terms of overall attitudes towards privacy, Consensys released a study called Web3 and crypto global survey 2023, which surveyed 15,158 people from 15 People conducted online surveys covering a variety of topics related to the web, not just encryption. The survey found that 83% of respondents believe data privacy is important, while only 45% said they trust current internet services with 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 "The desire for anonymity/privacy" as a Reasons why they invest in cryptocurrencies.

Adoption of Stealth Trading Protocol

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

TVL (USD) Railgun on the Ethereum mainnet — Source: Railgun — DefiLlama

Umbra usage has also steadily increased (the number of people registering stealth addresses to their ENS), as of November 2024 approaching 77,000 people:

Umbra cumulative registration number (across 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 although the contract address is technically OFAC-Listed SDN list, but it is still heavily used.

The chart below shows Tornado Cash's TVL over time. We can observe that starting from the peak around October 2021, the first major decline in TVL coincides with the overall sell-off in the crypto market, and the second major decline occurs in August 2022, which coincides with OFACAdding Tornado Cash to the SDN List, the third major drop corresponds to OFAC's re-designation in November 2022. However, since then, despite the sanctions, Tornado Cash usage has grown steadily, with TVL approaching $600 million. This is strong evidence of the need for basic transaction privacy in Ethereum.

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

Current status of stealth addresses

This study identified 4 currently produced on the EVM chain The main solutions are:

Fluidkey

Umbra

Labyrinth

Railgun

Fluidkey and Umbra Based on Ethereum standards, these standards are:

ERC-5564: Stealth Address Protocol

ERC-6538: Stealth Meta-Address Registration

Labyrinth and Railgun is based on the zerocash protocol (which zcash is also based on), which uses a protected pool into which users deposit funds. Zerocash uses the concept of “notes”, which are basically cryptographic representations of value, enabling private transactions. Each note includes a hidden value, the owner key, and a unique number (an invalidator) that uses zk-SNARKs to verify ownership without revealing the details, thereby transferring the value in the note. When a note is spent, its invalidator is revealed to prevent double spending, while a new note is created for the recipient, forming a UTXO system within a protected pool.

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 the funds ).

The erc-5564 standard specifies a mechanism whereby a recipient can publish a cryptographic meta-address from which a new Ethereum address can be derived. Anyone wishing to send funds to a recipient can generate a new address from the cryptic meta-address and allow the recipient to learn about the 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 a "spend key" and a "view key." Stealth metaaddresses use the EIP-3770 chain-specific address format with the "st:" prefix added. Here is a secretExample of address:

st:eth:0x036ffa94a70a5b9608aca693e12da815fe0295f3739c7b22b0284c6d85c464ba4a02c0521b 6fe31714b2ca0efa159402574355b754e0b50406b0b5fb33128eec3507

To simplify, this stealth address can be compared to a regular Ethereum address (and therefore also ENS) connection, making it easier to send funds to the owner of a stealth address. To send funds, the sender parses the above address and uses the EIP-5564 standard to create a temporary public key from which the stealth address is derived. The sender sends funds to the new stealth address, typically through a singleton contract where all stealth address receivers listen for events. The contract emits an "announce" event that receivers can subscribe to. Whenever an announcement event is sent, the recipient checks the temporary public key in the announcement, combines it with their viewing private key, and determines whether 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 corresponding funds and add it to the user's displayed balance. To actually spend those funds, they can sign a transaction using their private spending key.

The following diagram provides a clearer overview of the entire process:

Please note Live, this process is completely non-interactive, which means 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 a third party.

However, in order for this to work properly, the recipient must inform the sender of 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 that can be looked up by the sender. This allows the sender to resolve the normal address from ENS and then look up the associated stealth meta-address from the registry.

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

When the recipient goes to spend the funds, the person they are transferring the funds to will see that the funds came from the original sender (i.e., they can see the address to which the funds were transferred and who before funds were sent to this address). This means that the transfer chain remains intact and traceable, but they are only tied 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 combining them into one under the 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 derived 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 is one of the reasons why many implementations support eip-4337 and payers.

One disadvantage of the stealth address scheme is that the recipient needs to monitor the blockchain for announcement events and check each announcement to determine whether they have received funds. This is obviously an unrealistic 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 the shared secret that can be used to quickly discard transactions that were clearly not intended for them. Performance on desktop isn't that bad by using the View tab, but it might be more noticeable on mobile. The only time the performance degradation is really noticeable is if the wallet is recovering, in which case the wallet needs to scan every address since the on-chain contract was deployed, which is very time-consuming.

To resolve this issue, users can choose to share private viewing keys with a trusted third party. This third-party service monitors various networks and notifies users when they receive funds. Of course, this comes with a trade-off: while third parties can't actually spend users' funds (they don't have a private spending key), they can see all funds sent to a specific recipient, which means users need 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

We can compare the four stealth address implementations explored in this article in a number of ways. All implementations have subtle differences and trade-offs, but probably the most important takeaways are around 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 not responsible for any inspection Hidden address transaction history is visible to anyone. This means that if you receive funds at a hidden address, the person you decide to send those funds to will see where they came from.In addition, the actual value transferred is also visible. Railgun and Labyrinth hide the sender and the value being sent, but at the cost of it all happening within a single contract rather than as a normal transaction to a normal Ethereum address.

The following figure shows how the protocols we discuss in this article compare to each other along these two important dimensions of comparison.

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

Complete end-to-end privacy (sender only and the recipient sees the payment information)

Forward secrecy. Funds received through hidden transactions do not allow the second recipient to see the source of the funds

Follows the erc-5564 and erc-6538 standards

Implements a scalable modular architecture, Allow 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 additional nuances and distinctions in more detail. Each implementation has interesting nuances that may or may not have an impact on your use case.

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

Deep dive into the stealth address implementation Fluidkey

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

Users interact with Fluidkey through its web user interface. When they first log in using the wallet, they sign a key generation message from which their viewing and spending 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 difference is that users share their private viewing key with Fluidkey (actually a BIP-32 derived node). This enables Fluidkey to generate stealth addresses for users and notify them when they receive payments to those addressesuser. However, this also means that Fluidkey has the ability to view a user’s incoming transactions and balances, which is a trade-off. However, Fluidkey remains completely 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 the cloaked address are used. A smart account is a 1/1 secure account that allows for operations such as gas sponsorship, making it easier to manage various stealth addresses. For more information on this, check out their technical note.

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

Users are also fully able to export their transactions or share their viewing keys with third parties (such as accountants), which is especially useful for businesses. It is worth noting that according to the erc-5564 specification, the sharing of public keys is "all-or-none," meaning that it cannot be revealed on its own for a single transaction in isolation. Additionally, as with all erc-5564 implementations, traceability is not broken—just correlation to the user—meaning that the transaction history of each stealth address is public to anyone with the 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 for a specific month with third parties.

One benefit of the Fluidkey approach is that the stealth address itself is not generated by the sender, but rather pseudo-randomly generated by Fluidkey each time it queries ENS. This is faster because users do not have to scan through announcement events to identify transactions for which they are the recipient. This also means that the sender does not need a stealth address wallet to generate a stealth address for the recipient - they can simply send funds like any other address. This also means there are no registration contracts involved, which is unique to Fluidkey’s design and a major advantage.

It’s worth mentioning that Fluidkey is committed to fully self-custody, and they have open sourced their stealth account toolkit library and, in the unlikely event that Fluidkey disappears overnight, will be able to There are several independently developed recovery interfaces available, meaning funds are never locked or stuck.

Address Abstraction

By using smart contract accounts, Fluidkey can automatically abstract and manage variousa hidden address. This means that if you want to transfer a specific amount to a specific recipient from your balance in various stealth addresses, Fluidkey can automatically calculate the address combination to transfer the funds, handle all gas fees and contract deployment, all It happens 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 an ENS name unique to Fluidkey. These static names come in two forms: username.fkey.id and username.fkey.eth, one being a URL to the web interface for sending funds to someone, and the other being a standard ENS name that can be used with a wallet.

ENS settings use the ENS offchain resolver (also known as erc-3668: CCIP Read) to return stealth addresses. Each time the offline 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, since the resulting 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 requires a fee to deploy a Safe contract. However, while relatively expensive on mainnet, this is practically trivial on L2, typically less than 1 cent, even when combining multiple stealth addresses into a single transfer.

They can also do gas sponsorship through Safe deployment - they calculate the cost of gas and deduct it from the user's balance, even if it is a token - in this case, the forwarder deploys Safe and transfer tokens on behalf of users.

Umbra Cash

Umbra is eip-5564 + eip6538 implemented by Scopelift. When a user logs into the Umbra app, they go through a setup phase where they sign a message from which a spend and view key and corresponding stealth meta-address are derived. They then register this stealth meta-address into 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 specification, as they do not have access to the user's keys. While this means that Umbra (or anyone else) cannot see the user's funds, it does mean that in order to receive the funds, the sender must have aerc-5564 compliant wallets (or Umbra apps) to generate their stealth meta-addresses.

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

Forwarder

One of the problems with stealth addresses we mentioned before is that in order for the recipient to spend funds sent to the stealth address, the address needs to have ETH or other necessary gas tokens to pay transaction fees. On most networks, this is usually not a problem if the stealth address initially received ETH. However, if a stealth address receives erc-20 tokens or NFTs, the act of gassing the address with ETH may associate that address with the user's other addresses, thereby losing privacy.

To get around this problem, 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 stealth address. Users can spend funds sent to their stealth address by sending a meta-transaction (from the Umbra app) to Umbra's forwarder, who will transfer funds from the smart contract on the user's behalf. Reposters will deduct some tokens to cover the cost of gas fees, and only a certain number of tokens will be supported initially.

Fees

Umbra contracts also charge a small fee when moving funds on the low transaction fee network to curb spam. The rationale is that spam increases the cost of scanning transactions to identify relevant transactions, 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 registration contract has an interesting design. The deployment method uses create2 and the standard create2 deployer, and the smart contract address is the same on any network. This means that if a contract exists on a given network, the client can ensure that it is the correct contract. Clients can be configured to add networks and anyone can deploy to any network. They have normalized the bytecode so that the contract has no owner, which allows anyPeople can deploy registration and announcement contracts on any chain without permission.

Umbra v2

Scopelift is currently developing 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 a "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 such as Interpol, etc.) while maintaining transparency 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. In order to spend assets, users scan the network and obtain encrypted ticket data, decrypt the tickets, and filter out the assets they want to spend. Users then create a ZKP that includes the transaction and the signing key for the note associated with the transaction they want to spend.

Part of the Labyrinth core contract includes a transformation 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 a 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. The client stores the information needed to reconstruct the ticket and uses this information to spend the asset. The commitment to the note (a hash of the asset ID, owner, and value) is stored in an on-chain Merkle tree. In fact, Labyrinth uses two Merkle trees, one for tickets and one for root addresses.

The note data structure contains the following content:

assetId: the asset represented by this noteidentifier (ETH, WBTC, MATIC, etc.).

value: The value or amount represented by the note.

leafIndex: The leaf node index of the promise Merkle tree into which this note will be inserted.

blinding: A random protection factor.

rootAddress: The root address of the user with spending permissions.

revoker: The public key point of the selected revoker.

You will notice that the above data structure does not contain any reference to the owner of the asset, which is strange because the commitments recorded in the note Merkle tree are assets Hash of ID, value and owner. In reality, the owner is calculated from the root address, the undoer, and a random protection factor, so to an outside observer the owner is actually a new address generated with 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 that uses notes. The concept creates a pool of shielded UTXOs, providing forward secrecy for transactions. Recall that in the eip-5564 implementation, the recipients of user transfers will be able to see the source of those funds. In other words, Alice pays Bob with the stealth address, and Bob pays 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 protective 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 one of the notes for the corresponding asset. and. In order to spend these notes, the user needs to reveal the "invalidity flag" of those notes. The invalid ID is uniquely associated with a note, and once the note is spent, the invalid ID 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 invalid identifier 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 called the protection factor.

Receivers of stealth transaction transfers identify the transfer in the same way as eip-5564, in that they listen to events emitted from the core contract and determine the stealth address from which they will be able to send funds, and log it locally these addresses. The speed of identifying incoming funds is also improved by leveraging view tags and asynchronous local caching and synchronization of notes throughout the application lifecycle.

Research is currently underway to speed up the process of discovery receiving funding, check out this proposal from Aztec: Request for Proposals: Note Discovery Protocol — Aztec.

In terms of spending funds, users must also generate a zk proof, unlike the erc-6654 implementation which is basically a normal Ethereum address. Generating the proof requires a compatible wallet and performs relatively well, taking around 20 seconds or so on a mid-range Android device.

Packagers and Converters

Labyrinth offers some nice features that address some of the pain points in stealth trading. Transactions sent to the Labyrinth core contract are sent as user operations through the erc-4337 packager. This setup allows notes to be spent without the need for ETH or gas tokens from 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 with 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, which allows converter contracts to act as proxies for third-party decentralized applications. This not only allows users to move funds using stealth transactions, but also interacts with third-party decentralized applications such as DEXs like Uniswap, Aave, Lido, etc. These proxy "Converter" contracts essentially implement a function that receives an input of a certain asset and outputs some assets. The basic logic exists in a third-party contract.

Compliance Solutions

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

Recall that the note's data structure contains a field called "undone by". 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. Revocators are not solely responsible for identifying potentially illegal or inappropriate activity but may respond to requests from law enforcement agencies.

Undoers do not have the sole ability to directly de-anonymize transactions, but they are responsible for initiating de-anonymization requests. These requests are posted publicly to the Guardian, a board of entities that oversees privacy and compliance. Guardians must vote whether to allow deanonymizing transactions. If guardians can reach a quorum and vote in favor, revokers can decrypt the transaction data, thereby convertingRelated transactions are linked to previous transactions until the transaction chain is fully de-anonymized.

This system creates a series of checks and balances, because guardians cannot decide to reveal transaction data alone, and even if they collude, they cannot do anything without undoers, and undoers alone cannot Guardians do everything by majority vote.

Railgun

RAILGUN is a stealth 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, forming a UTXO set, i.e. by creating new notes for other recipients expenditure. This means that only the owner of a note can compute its invalidation ID, which is often generated based on a hash of the spending key and the note's index in the Merkle tree.

Cryptic meta-addresses in Railgun use a "0zk" prefix, similar to eip-5564, which is a combination of the public view key and the public spend key. However, Railgun uses the Ed25519 key 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 a user's meta-transactions and broadcast the actual transactions to the corresponding blockchain on behalf of the user Pay the gas fee. User-to-broadcaster transactions are encrypted and communicated 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 achieves this through the AdaptRelay contract, which secures and unprotects tokens before and after interacting with external contracts, for example, unprotecting token A, exchanging tokens on some AMM Token B, protect 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 study this issue and identify edge cases and how to resolve them, more details in the Railgun v3 section below.

Fees

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

Governance

Railgun has a governance system that allows submission of any form of proposal. Changes to any core contract (including financial 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 through support for Railgun. Railgun also has a community-maintained cookbook that provides "recipes" that allow DApp developers to provide modules for Railgun, enabling users to interact with their DApps using Railgun. For example, a developer could write a recipe for a DEX that allows users with a token balance in Railgun to privately exchange 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, via dedicated memory pools. Additionally, v3 will support intent-based architecture, allowing solvers to compete for best execution, although the details are still very high-level as of this writing. They are currently working with CowSwap and plan to use front and back 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, There is no need for these DApps to explicitly provide integration with Railgun through custom modules.

Railgun Connect is a browser extension that actually uses the state of the HardHat local copy chain and injects its own web3 provider into the DApp, with RPC endpoints for the local HardHat version chain. This allows you to interact with the DApp contract as usual, record the transaction, and thenBatch it and create a snark proof and send it to the Railgun contract on the actual chain. Although this description is somewhat simplistic, it conveys the general idea. This enables you to interact with basically 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 completed, you can use Railgun's stealth address to interact with DApps without any difference from 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 encapsulates a normal erc-20 contract and encrypts all balances. Transfers and approvals occur in an encrypted state using fully homomorphic encryption. Inco relies on precompilation that currently only exists on its own network, but may be moved 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, possibly because it requires An update to the EVM, without which it would really only be implemented at the token level, using the erc-20 design that specifically supports eip-7503 (or if a certain L2 decides to add support for its EVM opcodes).

Aztec may be the most sophisticated privacy technology out there, but it requires users to bridge 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, Aztec may have a unique value proposition and become a very valuable L2 as DApps and users migrate to a platform that offers privacy by default.

Similarly, Intmax is a privacy-centric Ethereum L2 (based on Plasma design), which also has a compliance regulatory aspect, verifying the legality of personal funds based on AML proof through ZKP, and Limits are imposed on transaction amounts. Intmax has limitations in providing privacy for transfers, while 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 choicesIncluding:

Will they provide advisory support for a single implementation, or will they build and maintain some kind of comprehensive aggregator across multiple protocols? The latter can be costly to develop and maintain.

Are there regulatory considerations and will a position need to be taken on the scope and mechanisms of selective de-anonymization (as in the case of Labyrinth)?

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

Stealth addresses complicate existing integrations with block detectors such as Etherscan. For example, the "View on Detector" button will not work for stealth meta addresses because wallets display aggregate balances. This problem may also exist in transfers. These edge cases need to be seriously considered.

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

There is also room for improvement in preventing poor user privacy hygiene, please see this article: "Anonymity Analysis of the Umbra Stealth Address Scheme on Ethereum", the author successfully conducted 48.5% of invisible transactions on the Ethereum mainnet Deanonymize. The heuristics they use have nothing to do with the protocol and more about privacy hygiene, such as users sending funds to a cloaked address they control and then sending those funds back to the original sending address, mistakenly believing that traceability has 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 critical user experience issues that need to be addressed.

Overall, I am quite optimistic about stealth addresses and privacy in Ethereum. I think we've made pretty impressive progress and identified some very fixable challenges. I believe that mainstream wallets will find ways to provide support for stealth addresses so that users can easily use these addresses with the normal level of privacy that users expect and deserve.

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