Umbra v2: Flexible, Interoperable, and More than Just Payments

Since its inception as a hackathon project in 2020, inspired by a tweet from Vitalik Buterin, Umbra has focused on one primary use case: privacy preserving payments. Even now, the main page of the Umbra App reads "Send Stealth Payments. Only the sender and recipient know who received funds."

In a certain sense, Umbra has succeeded in delivering on this use case. It has processed nearly $600 Million worth of assets, across hundreds of thousands of transactions, on five different EVM networks. With that said, the usage of crypto for payment rails has grown slowly relative to other areas. Perhaps this should be expected. Many solutions exist for fast and cheap payments outside the crypto world. Where crypto has grown the fastest is in areas that are inaccessible, or flat out don't exist, in the analog finance world.

For this reason, when we started brainstorming what Umbra v2 might look like, we knew we wanted something flexible. We absolutely want to continue supporting the payments use case, and supporting it well. But we also want Umbra to do more. In this post, we'll share our preliminary conception of an architecture that will support stealth payments even better than Umbra v1 does, but is also flexible enough to support many other use cases.

Standardized Interoperability at the Foundation

The foundation of Umbra v2 is the two ERC standards we've been focused on for the last several months, ERC-5564 and ERC-6538. These standards codify the basic functionality that any stealth address scheme on the EVM will need. These standards ensure a base level of interoperability between different stealth address implementations. This means that stealth address enabled apps and wallets will, at a minimum, be aware of the existence of other stealth transactions. Any app built on the standard can detect and surface stealth transactions from other apps to their users.

Interoperability is great for enabling different developers to permissionlessly explore their own use cases. A less obvious benefit of interoperability is that it bestows a level of modularity in the system. In Umbra v2, we intend to leverage that modularity extensively, allowing us to iterate and add use cases over time.

Even for the simple use case of payments, this interop-enabled modularity leads to a cleaner approach. Let's explore how.

In Umbra v1, we focused on two types of payments: those made in the base asset of the network (ETH) and those made in ERC20 tokens. To support this, we built one monolithic Umbra contract with code paths for each type of payment.

However, this monolithic design has some drawbacks. While it has served us well, it is inherently limited. How does one, for example, add support for other token standards, like ERC-1155? How does one add support for non-fungible tokens? How does one add support for new or emerging account abstraction layers, like ERC-4337 and/or ERC-3074. A monolithic design is not amenable to this kind of expansion and iteration.

In contrast, by using the ERC-5564 contract as the base for interoperability, Umbra v2 can support each of these use cases with a new, modular contract. These can be built and deployed by ScopeLift, or built by third parties and simply enabled in the Umbra app.

If a new token standard emerges, we can add support it with a modular contract built on top of ERC-5564. The same goes for assets with extended or unusual properties, like rebasing tokens or governance tokens. It also applies to account abstraction standards, smart wallet standards, and any number of other emerging trends in the ecosystem that might impact usage of stealth addresses for payments in some way. Each can be supported with an independently developed, modular smart contract, and enabled in Umbra v2 (or other stealth address aware apps) thanks to interoperability.

Even more exciting than this, though, is the fact that this applies to non-payment use cases of stealth addresses. Said use cases can be built as interoperable modules. In the rest of this post, we'll explore how Umbra v2 will aim to enable seamless, permissionless exploration of stealth addresses for payments and beyond.

Applying Stealth Addresses Broadly

If we were to describe what stealth addresses enable in the most generalized sense, we might say something like this:

1. User A creates a brand new address on behalf of User B called a stealth address. Even though User A created the stealth address, only User B has its private key.
2. User A grants some special privilege to User B's new stealth address.
3. User A broadcasts an encrypted announcement of the stealth address and privilege.
4. User B finds and decrypts the announcement.
5. User B exercises the new privilege that has been granted to the stealth address.
6. No one else knows the stealth address belongs to User B—it is not linked to User B's other accounts.

This is, essentially, an abstract user story for every stealth address use case. What can you build with stealth addresses? Any concrete use that can fit into this general form. We can see what this looks like by fleshing out the familiar payments use case:

1. Alice creates a stealth address for Bob
2. Alice sends funds to Bob's stealth address
3. Alice sends an encrypted announcement of her payment to Bob
4. Bob decrypts the announcement and sees his payment
5. Bob moves the funds from his stealth address to an exchange
6. No one else knows Alice paid Bob

Many other use cases can also fit into this mold. Let's imagine, for example, that an NFT project wanted to perform an onchain vote amongst its holders on an important decision on the project's roadmap in a privacy preserving way. Here's what that looks like using the stealth address rubric:

1. Project leaders create stealth addresses for all NFT holders
2. Each holder's stealth address is granted an onchain vote
3. Project leaders send encrypted announcements to each holder
4. Each NFT holder is notified of their right to vote
5. Holders sign messages with their stealth addresses to cast onchain votes
6. Votes are aggregated onchain without the identity of each voter being revealed

We imagine that many other use cases can be built in this framework. Stealth DAO voting, stealth public goods funding (think Gitcoin Grants or RetroPGF), and stealth encrypted onchain messaging are just a few examples.

More importantly, we hope to design Umbra v2 in such a way that 3rd party developers can permissionlessly add use cases that fit into the stealth address framework, and see them exposed and actionable in the Umbra app. Let's explore how this might work.

Enabling Third-Party Stealth Apps

As discussed, the key functionality of a stealth address is to allow one party to create a new address on another party's behalf and imbue it with special privileges. Umbra v1 focused on providing a user interface for the payments use case: moving or withdrawing funds received by the stealth address. While we expect payments to remain a primary use case, we believe many others are possible and want to enable them permissionlessly.

But how can a single app enable this in a flexible manner? The frontend needed for an onchain vote is completely different from the one needed for an onchain payment, and both are different from an onchain chat app.

Even if we support all those use cases well, what happens when a 3rd party dev comes up with some ingenious use for stealth addresses we had not yet considered? We don't want to be in the position of choosing which stealth address use cases succeed or fail.

Rather than building all use cases into a single app, Umbra v2 will serve as a hub where users discover stealth addresses spawned on their behalf, then hop to the appropriate third-party app in the context of their stealth address. To get a sense of how this might work, let's revisit the example of an NFT project allowing holders to vote onchain to about the project's future.

1. The team generates a stealth address for each holder of their NFT.
2. The team creates a simple web app, using the web3 toolchain they're used to, that allows each stealth address to vote onchain.
3. The team sends a transaction for each stealth address through Umbra v2, which forwards it through the ERC-5564 contracts. The metadata of the transaction includes context about the onchain vote and the dapp where the user can cast their vote.
4. Each NFT owner logs into Umbra, where they see the transaction sent by the team along with context about the vote and a link to participate.
5. Each NFT owner clicks the link, and is taken to the voting dapp built by the team. They are automatically connected with the stealth address that received the transaction.
6. Each NFT owner casts their vote.

As demonstrated by this example, the Umbra app does not need to provide a built in interface to enable the onchain voting use case. Instead, Umbra provides the team with the tools they need to build the use case themselves. For users, Umbra's app becomes the place from which they receive stealth transactions, then hop to the context where they can wield the special privilege that stealth address has.

In summary, our hope with Umbra v2 is not just to create some cool features on top of stealth addresses. Instead, we hope to create a framework on top of which third party devs can easily add stealth address enabled privacy to the use cases they design, all in an interoperable way thanks to the nearly-finalized ERC standards. By doing this, we hope to enable a wave of innovative, permissionless experimentation with stealth address use cases.

Status and Next Steps

With both stealth address ERCs nearing finalization, we are drawing close to the end of ScopeLift's 6 month stealth address work stream funded by the Ethereum Foundation. Prototyping Umbra v2 remains the last large task on our plate.

In the month ahead, we will deploy the ERC contracts to major EVM mainnets, roll out the production ready SDK, and share more work on our plans for Umbra v2.

We'll also, of course, continue to maintain and upgrade Umbra v1, adding improvements and features, like we did recently when we added support for Base.

We want to once again thank the Ethereum Foundation, and the whole community, for their continued support of stealth addresses and Umbra. While it's a difficult time to be doing so, we believe building privacy tools remains extremely important. We hope you're as excited about the potential for stealth addresses as we are. There's work to be done, so we press on!