Privacy on public blockchains has always existed onchain in fragments.

We have had mixers and stealth address protocols that offer momentary relief from transparency, but never a system that makes privacy persistent, expressive, and usable by default. What Umbra represents is not an incremental improvement on those tools, but a structural shift in how private financial activity can exist on a public blockchain.

This piece is an attempt to explain why Umbra is foundational to modern onchain privacy. I will walk through the limitations of previous privacy systems, how Umbra builds on decades of cryptographic progress, and why its architecture enables something we have not seen before: a fully expressive financial system operating on encrypted shared state.

Just as importantly, this is not an abstract cryptography essay. Umbra is a product-first protocol. Many of the hardest privacy problems are not purely cryptographic, but behavioral and experiential. Umbra is the first privacy system I have seen that treats anonymity sets, user behavior, and UX as first-class design constraints rather than afterthoughts.

Finally, Umbra is also distinct in how it is owned. Rather than treating the token as a peripheral incentive, Umbra was launched through MetaDAO as an ownership coin. This means Umbra is not only a private financial system, but one whose long-term direction and economic policy are governed by aligned incentives rather than discretionary control.

The result is not just stronger privacy guarantees, but a defensible moat.

@UmbraPrivacy

is a privacy protocol for private transfers, swaps, and onchain yield generation. It's a a shielded layer on

@Solana

, enabling onchain activity to occur within a private, persistent environment.

Umbra is accessed primarily through the Umbra Wallet, which serves as the main user-facing interface to this private environment. At the same time, Umbra is built as an open protocol, with an SDK that allows wallets and applications to integrate private transfers, swaps, and balances directly into their own products.

Under the hood, Umbra leverages a combination of cryptographic techniques, specifically client-side zero-knowledge proofs (ZKPs) and multi-party computation (MPC). This design enables a level of expressiveness and functionality that alternative solutions don’t have. It is the first financial layer to operate on encrypted shared state.

Let me explain in more depth why Umbra uses a dual cryptographic architecture.

Umbra uses client-side zero-knowledge proofs, generated locally on the user’s device, for private transfers and swaps. Through its Mixer Pool, these proofs cryptographically sever the link between deposits and withdrawals, providing anonymity.

Because proofs are generated locally, the witness data (the sensitive inputs) never leaves the user’s device. This avoids entire classes of server-side leakage present in prover networks or centralized relayers.

This is the gold standard for trust-minimized private transfers, and it works particularly well with minimal computational demand for this exact use-case.

However, Umbra is not simply a mixer like Tornado Cash. If it were, zero-knowledge proofs alone would suffice. ZK is quite limited when it comes to privacy, and this is where Umbra goes further.

As the saying goes: all roads lead to MPC.

Multi-party computation (MPC) is a cryptographic technique that dates back to the 1980s. For decades, it remained largely theoretical. Only recently has it become practical at scale.

MPC does exactly what the name suggests: it allows multiple parties to compute jointly on data without any party ever seeing the underlying data. The data is split into secret shares and distributed among participants. Each party performs computation on its secret share, and together they produce a result without revealing the inputs at any point.

This distinction matters because zero-knowledge proofs and MPC solve fundamentally different problems. Zero-knowledge proofs allow something to be proven privately. MPC allows computation to be performed directly on encrypted data.

Crucially, MPC enables something blockchains have never had before: encrypted shared state.

A useful way to understand this shift is through the evolution of blockchains:

• Bitcoin introduced public isolated state.

• Ethereum introduced public shared state.

• Zcash introduced encrypted isolated state.

• Arcium introduces encrypted shared state.

The same programmability Ethereum introduced to blockchains from Bitcoin, is the same programmability Arcium provides to existing blockchains from Zcash.

Umbra will be the first protocol to get this power into their hands.

Umbra uses

@Arcium

's MPC to enable fully confidential balances, implemented as

Encrypted Token Accounts

(ETAs). This is a fundamental departure from earlier privacy tools, which are limited to breaking the link between deposit and withdrawal addresses while still exposing balances and transfer amounts.

ETAs replace standard SPL Associated Token Accounts (ATAs), allowing funds to be claimed into internal balances without revealing amounts, and keeping subsequent balances and transfers encrypted by default through Arcium’s MPC infrastructure.

The result is not only anonymity at the point of entry and exit, but persistent confidentiality throughout onchain activity. Umbra both severs the link between sender and receiver and hides balances and transfer amounts, eliminating a major source of onchain correlation that mixers leave exposed.

There is also a practical performance implication to this design. In UTXO-based shielded systems like Zcash, a user’s balance is fragmented across many notes. Over time, this slows and increases the cost of transactions as the wallet must scan, aggregate, and spend an increasing number of UTXOs.

Umbra avoids this entirely. Confidential balances are continuously aggregated into Encrypted Token Accounts, preserving a single coherent balance rather than a growing set of fragments. Shielded transfers remain fast and predictable regardless of how long a user has been active.

Furthermore, MPC makes Umbra inherently extensible. Because it operates on encrypted shared state, Umbra can support any future use case that requires shared state, without sacrificing privacy.

This distinction is critical. Traditional blockchains operate on a shared state. Privacy protocols, until now, have largely been forced into isolated state, which made common financial operations impossible to perform privately.

By introducing encrypted shared state, MPC allows Umbra to scale privacy beyond simple transfers and into a fully expressive, high-performance financial system.

From a cryptographic standpoint, Umbra is privacy-maximized. Transfers, swaps, balances, and any future financial operation on Umbra are cryptographically private by default.

Cryptography alone, however, does not guarantee privacy when interacting with any mixer or shielded pool. Execution inside the pool is private by design, but deposits and withdrawals occur at the boundary between public and private state. At that boundary, observers can attempt to correlate entries and exits by analyzing onchain activity derived from the smart contract, using timing, amounts, and behavioral patterns.

In practice, the privacy guarantees users retain when exiting the pool depend on two additional factors: the size of the anonymity set and user behavior.

Umbra is uniquely positioned to excel on both dimensions.

Before explaining why Umbra is well positioned to grow a large anonymity set, it is important to clarify what is meant by the anonymity set in this context. At a basic level, the anonymity set represents the number of plausible participants a given transaction could be associated with.

In practice, the quality of that anonymity is shaped by several factors: the size of the pool, the level of ongoing transaction activity, and the amount of time funds remain within the shielded environment. Larger pools increase the number of plausible senders, while higher transaction frequency and sustained activity make individual flows harder to isolate.

Time also plays a critical role. When funds remain shielded for longer periods and participate in repeated shielded activity, timing-based correlation weakens. Privacy therefore compounds over time, not because the anonymity set grows automatically, but because individual transactions become increasingly indistinguishable from the surrounding activity.

Anonymity set ≈ shielded pool size, volume, time in pool, total number of shielded transactions.

Umbra is going live with their Private Beta this week with weekly cohorts of over 100 users and a conservative deposit cap of $500. These constraints are intentional and temporary. When Umbra enters public mainnet in February, these limits will be lifted, allowing broader participation and deposits. How the anonymity set evolves under these conditions will be worth observing.

The Umbra Wallet is a user-facing wallet built on top of the Umbra SDK. This naturally encourages funds at rest within the shielded environment, rather than an app with transient deposits and withdrawals.

At the same time, the Umbra SDK allows any application to integrate privacy with just a few lines of code. A neobank could add private transfers, swaps and balances directly into its app, letting users move and swap funds internally without leaking balances or counterparties, and without forcing them to exit to an external privacy tool. From the user’s perspective, the neobank simply becomes a private payments and settlement layer by default.

The same applies to wallets. By integrating Umbra, a wallet can support private transfers, swaps, and balance management natively, turning it from a transparent account viewer into a self-custodial private finance interface where activity remains shielded unless the user chooses otherwise.

More broadly, transfers, swaps, and balances are foundational primitives of onchain finance. By providing privacy at this level, Umbra does not need application-specific integrations to be useful. Any system built around value movement, exchange, or accounting can inherit privacy by design through the SDK.

Every integration feeds into the same unified shielded pool. Liquidity is shared, activity compounds, and each new use case increases both pool size and transaction frequency, directly strengthening the anonymity set for everyone.

When it comes to tokens, listings are permissioned and determined by the Umbra team. However, any token can be supported on Umbra. Each token builds its own anonymity set, with one pool per token. In the case of using the Umbra SDK, projects integrate already existing token pools.

Users can also earn yield on shielded assets, for example by holding yield-bearing stablecoins or liquid staking tokens (LSTs). This creates an incentive to keep these assets shielded for longer periods, allowing privacy to compound over time rather than being episodic.

Unlike alternative privacy protocols that require users to permanently unshield funds in order to trade, Umbra preserves privacy across the swap lifecycle by separating execution from identity and balance exposure.

Swaps are executed publicly via existing liquidity venues such as Jupiter, while Umbra ensures that the user’s identity, balances, and intent remain confidential. From the user’s confidential balance, funds are withdrawn anonymously into a stealth pool, claimed by an ephemeral address, swapped via Jupiter, and then deposited back into the confidential balance.

These ephemeral addresses are not random or disposable in a way that risks fund loss. They are derived deterministically from the user’s master seed and a derivation path. The master seed itself is generated from a signature, meaning that even if an ephemeral keypair is dropped locally, it can always be re-derived and recovered.

To an observer monitoring the user’s address, this appears only as a hidden deposit into the stealth pool followed by a hidden withdrawal. To an observer monitoring Jupiter, the swap amounts are visible, but there is no linkage to the user, their balances, or their broader financial activity.

From the user’s perspective, the entire flow is abstracted into a single action. Privacy is preserved not by hiding the existence of swaps, but by breaking the link between who traded, what they hold, and how they trade.

Users can execute swaps without ever leaving the shielded environment. There is no operational reason to unshield funds to access liquidity or functionality. Privacy is not a temporary state; it is the default.

Taken together, these dynamics highlight an important distinction between single-purpose and multi-purpose shielded pools:

Single-purpose shielded pools support only one operation: transfers. Users deposit, wait, and withdraw. Privacy is episodic and short-lived.

Multi-purpose shielded pools support many operations: transfers, swaps, yield, and composable financial logic. Funds move, fragment, recombine, and persist inside the shielded environment over time.

Umbra is a multi-purpose shielded pool. It is not designed for single-purpose privacy, but for continuous private financial activity. Funds are not only deposited and withdrawn in one-to-one fashion. They are naturally split into smaller transactions, reused, swapped, and held over time without ever needing to exit the shielded pool.

This persistence is critical. Umbra enables a persistent private state, rather than a temporary one. And it is precisely this persistence, combined with product quality and composability, that allows the anonymity set to grow meaningfully and sustainably.

Although Umbra cryptographically breaks the link between deposits and withdrawals and keeps activity within the shielded pool private by default, correlation risk can re-emerge if a user chooses to unshield their funds.

At that boundary, observers may analyze public entry and exit transactions using blockchain explorers or forensic tools such as Metasleuth or Chainalysis, looking for timing, amount, and behavioral patterns that could plausibly link a deposit to a later withdrawal.

Most privacy failures are not the result of broken cryptography, but of user behavior that creates distinguishable patterns at the point of exit. This is the same class of risk seen when unshielding Zcash to a transparent address.

In the majority of privacy tools, these risks are poorly communicated and insufficiently supported by product design. Below are some of the most common behavioral mistakes, and how Umbra is designed to minimize them in case of exit.

Using assets or pools with a small anonymity set materially weakens privacy guarantees. The same applies to depositing or withdrawing unusually large amounts in relatively small pools, where activity fails to blend into common patterns. Privacy improves when transactions are indistinguishable from many others.

Umbra surfaces this risk directly in the product by treating the anonymity set as a first-class metric. Assets with sufficiently large anonymity sets are marked with a golden checkmark, allowing users to transact with confidence, while assets without this indicator signal weaker anonymity sets and require greater caution from users.

Rapidly shielding funds from a public balance and then unshielding back to a public balance within a short time window creates strong temporal correlation. This behavior weakens the user’s effective anonymity within the set and is one of the most reliable ways to deanonymize individual activity at the boundary between public and private state.

In Umbra, rapid activity within the shielded environment does not introduce this threat. Transfers, swaps, and movements between confidential balances remain fully shielded and unlinkable. Correlation risk exists only when rapidly transitioning between public and private state.

To mitigate this, Umbra introduces Anonymity Level, allowing users to specify a delay window before funds are unshielded, giving the anonymity set time to grow before the transaction goes through.

Shielding and unshielding the exact same amount can be a source of correlation when crossing the public–private boundary in systems without fixed denominations. When users move funds from a public balance into the shielded pool and then back out again with identical, unique amounts, observers can attempt to link entry and exit points.

Within Umbra’s shielded environment, however, exact-amount symmetry is not exposed. Transfers between confidential balances occur via Encrypted Token Accounts, where amounts and flows remain hidden, meaning identical values alone are insufficient to trace behavior once funds remain inside the pool. Correlation risk primarily arises from identical entry to or exit from public state, not from activity within the shielded environment itself.

As an additional precaution when exiting to a public state, users may choose to withdraw a different amount than they originally deposited. For example, depositing 500 USDC and later withdrawing an arbitrary, non-identical amount further weakens value-based correlation at the public boundary. This is not required for privacy within Umbra’s shielded environment, but can provide extra protection when unshielding to public balances.

Anyone who has interacted with Tornado Cash is familiar with the severe friction it introduces when engaging with onchain applications. Users are automatically classified as high risk and blocked from interacting with a wide range of apps and protocols. One example is Hyperliquid, which restricts access for addresses associated with Tornado Cash.

This occurs because Tornado Cash allows users to mix funds with anyone in the pool. While this includes well-meaning users, it can also include sanctioned entities such as the DPRK, as well as other fraudulent or illicit actors and terrorist organizations. As a result, many applications choose to apply broad restrictions rather than assume that all participants are benign.

Compliance is a complex topic. Although privacy is commonly viewed as a fundamental right, current enforcement practices often lead to broad labeling and access restrictions that impose substantial friction on regular users.

Against this backdrop, it is useful to outline how Umbra handles compliance-related considerations in practice.

Proactive screening against sanctions and risk databases

This is the industry standard for modern privacy applications. Umbra uses

@range_org

for screening wallet addresses against sanctioned entities and risk databases. Addresses that exceed established risk thresholds are prevented from entering the shielded pool, with funds returned automatically.

Selective Disclosure with Viewing Keys

This allows users to selectively share visibility into their transaction history and balances without giving up control over their funds. Users can generate viewing keys that grant read-only access to selected transaction history, balances, or specific timeframes, and these keys cannot be used to transfer or spend assets. Disclosure is entirely opt-in and granular, meaning a user can choose exactly what data is shared and with whom.

Privacy is the power to selectively reveal oneself to the world.

Umbra conducted its token sale on @MetaDAOProject, marking MetaDAO’s largest ICO to date and the largest ICO in Solana’s history, with $155M in total commitments. Of this amount, $3M was accepted, with the remaining capital refunded on a pro-rata basis.

MetaDAO structures team unlocks around a pay-for-performance model in which allocations become available only as the token sustainably appreciates beyond its launch price. This design prevents early extraction, aligns founders with token holders, and ensures team compensation is earned through long-term execution and real value creation rather than the mere passage of time.

In line with MetaDAO’s model, token unlocks follow a structured schedule. For Umbra, unlocks can only begin 18 months after the token sale conclusion and are gated by post-launch price milestones at 2×, 4×, 8×, 16×, and 32×.

Umbra is governed via futarchy on MetaDAO. Any participant can submit a proposal and trade on its outcome through prediction markets, with decisions resolved based on expected impact rather than traditional token voting. For ownership coins, futarchy effectively functions as a market-driven board of directors, with outcomes that are contractually binding on the company.

In practice, futarchy is used for high-impact, strategic decisions, most notably treasury allocation and major commitments. Day-to-day operations and internal execution remain the responsibility of the team, allowing the company to move quickly without introducing unnecessary bureaucratic overhead.

MetaDAO’s model gives token holders genuine ownership and decision-making power over the business, ensuring that the most consequential decisions are governed by markets rather than a centralized team.

A common counter-argument you may hear is that you need to leave Solana entirely to get meaningful privacy. This view reflects the historical role of dedicated privacy blockchains, which pioneered many of the strongest privacy guarantees in the space and come with their own distinct trade-offs and benefits that are outside the scope of this discussion.

With a persistent private state in a shielded pool on Solana, you get the same category of privacy guarantee that people associate with systems like Zcash. Zcash has transparent and shielded addresses. You can think of Solana and Umbra the same way: Solana is the transparent environment, Umbra is the shielded environment.

As with any privacy system, what ultimately matters is the size and quality of the anonymity set. While other systems may have large anonymity sets today, Umbra’s focus is on growing this set as soon as it goes live.

Importantly, Umbra does not require users to buy into a separate privacy coin to get privacy. Users can retain exposure to the assets they already hold, such as stablecoins or SOL, while making those balances private within Umbra.

This leads to a key point: Umbra is not “a feature” or a wallet add-on. It is a sovereign privacy domain on Solana, with its own shielded pools, its own private state, and its own internal economy. That makes it closer to a private financial system operating on top of Solana than a privacy tool that users briefly interact with and leave.

This positions Umbra’s token less as a speculative asset and more as long-term ownership over private economic activity. Through futarchy and protocol governance, token holders have direct influence over treasury allocation and economic policy, tying the token’s value to sustained usage rather than short-term narratives.

Through this ownership, token holders can propose and vote on decisions such as revenue sharing or dividend-like distributions sourced from protocol revenue. If approved, holders participate in protocol fees. As long as blockchains are used, there is persistent demand for private financial activity, and Umbra is designed to capture that demand through ownership of a productive private economy rather than through mandatory usage of a single privacy asset.

If privacy applications have historically suffered from one flaw beyond limited expressiveness, it is product quality. While cryptographic innovation has advanced rapidly, many privacy tools have failed to translate those capabilities into usable, accessible products. Poor UX and high operational complexity have significantly limited who can realistically benefit from privacy onchain.

Umbra takes a different approach. It is built as a product-first privacy system, with design choices that explicitly account for user behavior as a source of privacy risk. Rather than assuming perfect operational discipline, the wallet is designed to help users preserve privacy by default through clear affordances, safety mechanisms, and thoughtful UX. This focus on product quality is rare in the crypto privacy space and materially expands access to privacy beyond expert users.

The Umbra Wallet is designed with the assumption that real-world threats and constraints matter as much as cryptography. Beyond private transfers, swaps, encrypted balances, yield, and other features mentioned earlier in this article, the wallet includes features that address coercion, usability, and long-term recoverability without compromising the underlying privacy model.

One example is Distress Mode, a coercion-resistance feature intended for physical threat scenarios such as wrench attacks. By entering a decoy password, users can unlock a limited view of the wallet containing a predefined, low-value balance, while the primary wallet, balances, and private activity remain hidden. This allows users to comply under duress without exposing their full financial state.

Umbra also removes several forms of friction that commonly lead to privacy leakage. All transactions in the wallet are gas abstracted, meaning users do not need to hold native SOL to perform transfers or swaps. This is enabled through integrated relayer support, allowing gasless private transactions where fees are deducted directly from encrypted balances and relayers are reimbursed automatically. As a result, users can transact from fresh addresses without pre-funding them, eliminating a common onchain linkability vector.

Account recovery and custody are handled with the same emphasis on resilience. Umbra integrates social recovery, allowing users to regain access to their wallet through a configurable set of trusted guardians. A threshold of approvals can securely transfer control to a new key without granting guardians access to funds, removing the single point of failure inherent in seed-phrase–only recovery while preserving self-custody.

For users with higher security requirements, Umbra also supports hardware wallets, including Ledger and Keystone, with additional support for Trezor and Solflare Shield planned. This allows users to combine hardware-backed key storage with Umbra’s privacy guarantees, rather than choosing between the two.

Finally, Umbra includes an in-app browser that allows users to connect directly to supported applications from within the wallet while operating in Public Mode. Private Mode support will be enabled as integrations and partnerships mature, enabling seamless interaction with applications while maintaining privacy guarantees end to end.

Umbra is a wallet across iOS, Android, and web, as well as an SDK that can be integrated by any application seeking private transfers, swaps, and yield. It is designed as an environment users live in, not a pool they briefly pass through.

It is also the first privacy protocol to operate on encrypted shared state. That one distinction is what makes everything else possible: composable private execution, confidential balances, and a system that can expand into new financial primitives without sacrificing privacy.

Umbra does not treat anonymity as a vague promise. It treats it as a measurable outcome. A multi-purpose shielded pool compounds privacy because funds stay shielded, move repeatedly, fragment, recombine, and accumulate history inside the private domain. Integrations feed into the same unified pool, increasing both pool size and transaction frequency, which is what grows the anonymity set in practice.

And Umbra does not assume perfect users. It is built around the reality that most privacy failures come from behavior. Encrypted balances minimize amount-based correlation. Anonymity set visibility is surfaced as a first-class metric. The product actively tells users when an anonymity set is good instead of letting them unknowingly transact into deanonymization.

It also brings properties that traditional privacy protocols never had. Swaps execute within a shielded environment, balances remain confidential, and the system is built with a level of product focus never before seen in crypto privacy. At the same time, it acknowledges real-world compliance constraints without compromising the privacy thesis. Through proactive screening and selective disclosure via viewing keys, users can choose when to reveal information, rather than being forced into full transparency.

Umbra is not a mixer. It is not a single feature. It is a private financial layer for Solana that finally makes privacy persistent, expressive, and usable.

Protec!

Signed, Privacy GCR.

For a complementary perspective on Umbra, I recommend reading Umbra: Private DeFi’s Foyer

For a higher-level exploration of cryptography and MPC in crypto, see my article Crypto's New Whitespace

If you are new to MPC, An Introduction to Multiparty Computation is a good place to start.

If you want to dive deeper into Umbra, I recommend reading their docs.

Privacy on public blockchains has always existed onchain in fragments.

We have had mixers and stealth address protocols that offer momentary relief from transparency, but never a system that makes privacy persistent, expressive, and usable by default. What Umbra represents is not an incremental improvement on those tools, but a structural shift in how private financial activity can exist on a public blockchain.

This piece is an attempt to explain why Umbra is foundational to modern onchain privacy. I will walk through the limitations of previous privacy systems, how Umbra builds on decades of cryptographic progress, and why its architecture enables something we have not seen before: a fully expressive financial system operating on encrypted shared state.

Just as importantly, this is not an abstract cryptography essay. Umbra is a product-first protocol. Many of the hardest privacy problems are not purely cryptographic, but behavioral and experiential. Umbra is the first privacy system I have seen that treats anonymity sets, user behavior, and UX as first-class design constraints rather than afterthoughts.

Finally, Umbra is also distinct in how it is owned. Rather than treating the token as a peripheral incentive, Umbra was launched through MetaDAO as an ownership coin. This means Umbra is not only a private financial system, but one whose long-term direction and economic policy are governed by aligned incentives rather than discretionary control.

The result is not just stronger privacy guarantees, but a defensible moat.

@UmbraPrivacy

is a privacy protocol for private transfers, swaps, and onchain yield generation. It's a a shielded layer on

@Solana

, enabling onchain activity to occur within a private, persistent environment.

Umbra is accessed primarily through the Umbra Wallet, which serves as the main user-facing interface to this private environment. At the same time, Umbra is built as an open protocol, with an SDK that allows wallets and applications to integrate private transfers, swaps, and balances directly into their own products.

Under the hood, Umbra leverages a combination of cryptographic techniques, specifically client-side zero-knowledge proofs (ZKPs) and multi-party computation (MPC). This design enables a level of expressiveness and functionality that alternative solutions don’t have. It is the first financial layer to operate on encrypted shared state.

Let me explain in more depth why Umbra uses a dual cryptographic architecture.

Umbra uses client-side zero-knowledge proofs, generated locally on the user’s device, for private transfers and swaps. Through its Mixer Pool, these proofs cryptographically sever the link between deposits and withdrawals, providing anonymity.

Because proofs are generated locally, the witness data (the sensitive inputs) never leaves the user’s device. This avoids entire classes of server-side leakage present in prover networks or centralized relayers.

This is the gold standard for trust-minimized private transfers, and it works particularly well with minimal computational demand for this exact use-case.

However, Umbra is not simply a mixer like Tornado Cash. If it were, zero-knowledge proofs alone would suffice. ZK is quite limited when it comes to privacy, and this is where Umbra goes further.

As the saying goes: all roads lead to MPC.

Multi-party computation (MPC) is a cryptographic technique that dates back to the 1980s. For decades, it remained largely theoretical. Only recently has it become practical at scale.

MPC does exactly what the name suggests: it allows multiple parties to compute jointly on data without any party ever seeing the underlying data. The data is split into secret shares and distributed among participants. Each party performs computation on its secret share, and together they produce a result without revealing the inputs at any point.

This distinction matters because zero-knowledge proofs and MPC solve fundamentally different problems. Zero-knowledge proofs allow something to be proven privately. MPC allows computation to be performed directly on encrypted data.

Crucially, MPC enables something blockchains have never had before: encrypted shared state.

A useful way to understand this shift is through the evolution of blockchains:

• Bitcoin introduced public isolated state.

• Ethereum introduced public shared state.

• Zcash introduced encrypted isolated state.

• Arcium introduces encrypted shared state.

The same programmability Ethereum introduced to blockchains from Bitcoin, is the same programmability Arcium provides to existing blockchains from Zcash.

Umbra will be the first protocol to get this power into their hands.

Umbra uses

@Arcium

's MPC to enable fully confidential balances, implemented as

Encrypted Token Accounts

(ETAs). This is a fundamental departure from earlier privacy tools, which are limited to breaking the link between deposit and withdrawal addresses while still exposing balances and transfer amounts.

ETAs replace standard SPL Associated Token Accounts (ATAs), allowing funds to be claimed into internal balances without revealing amounts, and keeping subsequent balances and transfers encrypted by default through Arcium’s MPC infrastructure.

The result is not only anonymity at the point of entry and exit, but persistent confidentiality throughout onchain activity. Umbra both severs the link between sender and receiver and hides balances and transfer amounts, eliminating a major source of onchain correlation that mixers leave exposed.

There is also a practical performance implication to this design. In UTXO-based shielded systems like Zcash, a user’s balance is fragmented across many notes. Over time, this slows and increases the cost of transactions as the wallet must scan, aggregate, and spend an increasing number of UTXOs.

Umbra avoids this entirely. Confidential balances are continuously aggregated into Encrypted Token Accounts, preserving a single coherent balance rather than a growing set of fragments. Shielded transfers remain fast and predictable regardless of how long a user has been active.

Furthermore, MPC makes Umbra inherently extensible. Because it operates on encrypted shared state, Umbra can support any future use case that requires shared state, without sacrificing privacy.

This distinction is critical. Traditional blockchains operate on a shared state. Privacy protocols, until now, have largely been forced into isolated state, which made common financial operations impossible to perform privately.

By introducing encrypted shared state, MPC allows Umbra to scale privacy beyond simple transfers and into a fully expressive, high-performance financial system.

From a cryptographic standpoint, Umbra is privacy-maximized. Transfers, swaps, balances, and any future financial operation on Umbra are cryptographically private by default.

Cryptography alone, however, does not guarantee privacy when interacting with any mixer or shielded pool. Execution inside the pool is private by design, but deposits and withdrawals occur at the boundary between public and private state. At that boundary, observers can attempt to correlate entries and exits by analyzing onchain activity derived from the smart contract, using timing, amounts, and behavioral patterns.

In practice, the privacy guarantees users retain when exiting the pool depend on two additional factors: the size of the anonymity set and user behavior.

Umbra is uniquely positioned to excel on both dimensions.

Before explaining why Umbra is well positioned to grow a large anonymity set, it is important to clarify what is meant by the anonymity set in this context. At a basic level, the anonymity set represents the number of plausible participants a given transaction could be associated with.

In practice, the quality of that anonymity is shaped by several factors: the size of the pool, the level of ongoing transaction activity, and the amount of time funds remain within the shielded environment. Larger pools increase the number of plausible senders, while higher transaction frequency and sustained activity make individual flows harder to isolate.

Time also plays a critical role. When funds remain shielded for longer periods and participate in repeated shielded activity, timing-based correlation weakens. Privacy therefore compounds over time, not because the anonymity set grows automatically, but because individual transactions become increasingly indistinguishable from the surrounding activity.

Anonymity set ≈ shielded pool size, volume, time in pool, total number of shielded transactions.

Umbra is going live with their Private Beta this week with weekly cohorts of over 100 users and a conservative deposit cap of $500. These constraints are intentional and temporary. When Umbra enters public mainnet in February, these limits will be lifted, allowing broader participation and deposits. How the anonymity set evolves under these conditions will be worth observing.

The Umbra Wallet is a user-facing wallet built on top of the Umbra SDK. This naturally encourages funds at rest within the shielded environment, rather than an app with transient deposits and withdrawals.

At the same time, the Umbra SDK allows any application to integrate privacy with just a few lines of code. A neobank could add private transfers, swaps and balances directly into its app, letting users move and swap funds internally without leaking balances or counterparties, and without forcing them to exit to an external privacy tool. From the user’s perspective, the neobank simply becomes a private payments and settlement layer by default.

The same applies to wallets. By integrating Umbra, a wallet can support private transfers, swaps, and balance management natively, turning it from a transparent account viewer into a self-custodial private finance interface where activity remains shielded unless the user chooses otherwise.

More broadly, transfers, swaps, and balances are foundational primitives of onchain finance. By providing privacy at this level, Umbra does not need application-specific integrations to be useful. Any system built around value movement, exchange, or accounting can inherit privacy by design through the SDK.

Every integration feeds into the same unified shielded pool. Liquidity is shared, activity compounds, and each new use case increases both pool size and transaction frequency, directly strengthening the anonymity set for everyone.

When it comes to tokens, listings are permissioned and determined by the Umbra team. However, any token can be supported on Umbra. Each token builds its own anonymity set, with one pool per token. In the case of using the Umbra SDK, projects integrate already existing token pools.

Users can also earn yield on shielded assets, for example by holding yield-bearing stablecoins or liquid staking tokens (LSTs). This creates an incentive to keep these assets shielded for longer periods, allowing privacy to compound over time rather than being episodic.

Unlike alternative privacy protocols that require users to permanently unshield funds in order to trade, Umbra preserves privacy across the swap lifecycle by separating execution from identity and balance exposure.

Swaps are executed publicly via existing liquidity venues such as Jupiter, while Umbra ensures that the user’s identity, balances, and intent remain confidential. From the user’s confidential balance, funds are withdrawn anonymously into a stealth pool, claimed by an ephemeral address, swapped via Jupiter, and then deposited back into the confidential balance.

These ephemeral addresses are not random or disposable in a way that risks fund loss. They are derived deterministically from the user’s master seed and a derivation path. The master seed itself is generated from a signature, meaning that even if an ephemeral keypair is dropped locally, it can always be re-derived and recovered.

To an observer monitoring the user’s address, this appears only as a hidden deposit into the stealth pool followed by a hidden withdrawal. To an observer monitoring Jupiter, the swap amounts are visible, but there is no linkage to the user, their balances, or their broader financial activity.

From the user’s perspective, the entire flow is abstracted into a single action. Privacy is preserved not by hiding the existence of swaps, but by breaking the link between who traded, what they hold, and how they trade.

Users can execute swaps without ever leaving the shielded environment. There is no operational reason to unshield funds to access liquidity or functionality. Privacy is not a temporary state; it is the default.

Taken together, these dynamics highlight an important distinction between single-purpose and multi-purpose shielded pools:

Single-purpose shielded pools support only one operation: transfers. Users deposit, wait, and withdraw. Privacy is episodic and short-lived.

Multi-purpose shielded pools support many operations: transfers, swaps, yield, and composable financial logic. Funds move, fragment, recombine, and persist inside the shielded environment over time.

Umbra is a multi-purpose shielded pool. It is not designed for single-purpose privacy, but for continuous private financial activity. Funds are not only deposited and withdrawn in one-to-one fashion. They are naturally split into smaller transactions, reused, swapped, and held over time without ever needing to exit the shielded pool.

This persistence is critical. Umbra enables a persistent private state, rather than a temporary one. And it is precisely this persistence, combined with product quality and composability, that allows the anonymity set to grow meaningfully and sustainably.

Although Umbra cryptographically breaks the link between deposits and withdrawals and keeps activity within the shielded pool private by default, correlation risk can re-emerge if a user chooses to unshield their funds.

At that boundary, observers may analyze public entry and exit transactions using blockchain explorers or forensic tools such as Metasleuth or Chainalysis, looking for timing, amount, and behavioral patterns that could plausibly link a deposit to a later withdrawal.

Most privacy failures are not the result of broken cryptography, but of user behavior that creates distinguishable patterns at the point of exit. This is the same class of risk seen when unshielding Zcash to a transparent address.

In the majority of privacy tools, these risks are poorly communicated and insufficiently supported by product design. Below are some of the most common behavioral mistakes, and how Umbra is designed to minimize them in case of exit.

Using assets or pools with a small anonymity set materially weakens privacy guarantees. The same applies to depositing or withdrawing unusually large amounts in relatively small pools, where activity fails to blend into common patterns. Privacy improves when transactions are indistinguishable from many others.

Umbra surfaces this risk directly in the product by treating the anonymity set as a first-class metric. Assets with sufficiently large anonymity sets are marked with a golden checkmark, allowing users to transact with confidence, while assets without this indicator signal weaker anonymity sets and require greater caution from users.

Rapidly shielding funds from a public balance and then unshielding back to a public balance within a short time window creates strong temporal correlation. This behavior weakens the user’s effective anonymity within the set and is one of the most reliable ways to deanonymize individual activity at the boundary between public and private state.

In Umbra, rapid activity within the shielded environment does not introduce this threat. Transfers, swaps, and movements between confidential balances remain fully shielded and unlinkable. Correlation risk exists only when rapidly transitioning between public and private state.

To mitigate this, Umbra introduces Anonymity Level, allowing users to specify a delay window before funds are unshielded, giving the anonymity set time to grow before the transaction goes through.

Shielding and unshielding the exact same amount can be a source of correlation when crossing the public–private boundary in systems without fixed denominations. When users move funds from a public balance into the shielded pool and then back out again with identical, unique amounts, observers can attempt to link entry and exit points.

Within Umbra’s shielded environment, however, exact-amount symmetry is not exposed. Transfers between confidential balances occur via Encrypted Token Accounts, where amounts and flows remain hidden, meaning identical values alone are insufficient to trace behavior once funds remain inside the pool. Correlation risk primarily arises from identical entry to or exit from public state, not from activity within the shielded environment itself.

As an additional precaution when exiting to a public state, users may choose to withdraw a different amount than they originally deposited. For example, depositing 500 USDC and later withdrawing an arbitrary, non-identical amount further weakens value-based correlation at the public boundary. This is not required for privacy within Umbra’s shielded environment, but can provide extra protection when unshielding to public balances.

Anyone who has interacted with Tornado Cash is familiar with the severe friction it introduces when engaging with onchain applications. Users are automatically classified as high risk and blocked from interacting with a wide range of apps and protocols. One example is Hyperliquid, which restricts access for addresses associated with Tornado Cash.

This occurs because Tornado Cash allows users to mix funds with anyone in the pool. While this includes well-meaning users, it can also include sanctioned entities such as the DPRK, as well as other fraudulent or illicit actors and terrorist organizations. As a result, many applications choose to apply broad restrictions rather than assume that all participants are benign.

Compliance is a complex topic. Although privacy is commonly viewed as a fundamental right, current enforcement practices often lead to broad labeling and access restrictions that impose substantial friction on regular users.

Against this backdrop, it is useful to outline how Umbra handles compliance-related considerations in practice.

Proactive screening against sanctions and risk databases

This is the industry standard for modern privacy applications. Umbra uses

@range_org

for screening wallet addresses against sanctioned entities and risk databases. Addresses that exceed established risk thresholds are prevented from entering the shielded pool, with funds returned automatically.

Selective Disclosure with Viewing Keys

This allows users to selectively share visibility into their transaction history and balances without giving up control over their funds. Users can generate viewing keys that grant read-only access to selected transaction history, balances, or specific timeframes, and these keys cannot be used to transfer or spend assets. Disclosure is entirely opt-in and granular, meaning a user can choose exactly what data is shared and with whom.

Privacy is the power to selectively reveal oneself to the world.

Umbra conducted its token sale on @MetaDAOProject, marking MetaDAO’s largest ICO to date and the largest ICO in Solana’s history, with $155M in total commitments. Of this amount, $3M was accepted, with the remaining capital refunded on a pro-rata basis.

MetaDAO structures team unlocks around a pay-for-performance model in which allocations become available only as the token sustainably appreciates beyond its launch price. This design prevents early extraction, aligns founders with token holders, and ensures team compensation is earned through long-term execution and real value creation rather than the mere passage of time.

In line with MetaDAO’s model, token unlocks follow a structured schedule. For Umbra, unlocks can only begin 18 months after the token sale conclusion and are gated by post-launch price milestones at 2×, 4×, 8×, 16×, and 32×.

Umbra is governed via futarchy on MetaDAO. Any participant can submit a proposal and trade on its outcome through prediction markets, with decisions resolved based on expected impact rather than traditional token voting. For ownership coins, futarchy effectively functions as a market-driven board of directors, with outcomes that are contractually binding on the company.

In practice, futarchy is used for high-impact, strategic decisions, most notably treasury allocation and major commitments. Day-to-day operations and internal execution remain the responsibility of the team, allowing the company to move quickly without introducing unnecessary bureaucratic overhead.

MetaDAO’s model gives token holders genuine ownership and decision-making power over the business, ensuring that the most consequential decisions are governed by markets rather than a centralized team.

A common counter-argument you may hear is that you need to leave Solana entirely to get meaningful privacy. This view reflects the historical role of dedicated privacy blockchains, which pioneered many of the strongest privacy guarantees in the space and come with their own distinct trade-offs and benefits that are outside the scope of this discussion.

With a persistent private state in a shielded pool on Solana, you get the same category of privacy guarantee that people associate with systems like Zcash. Zcash has transparent and shielded addresses. You can think of Solana and Umbra the same way: Solana is the transparent environment, Umbra is the shielded environment.

As with any privacy system, what ultimately matters is the size and quality of the anonymity set. While other systems may have large anonymity sets today, Umbra’s focus is on growing this set as soon as it goes live.

Importantly, Umbra does not require users to buy into a separate privacy coin to get privacy. Users can retain exposure to the assets they already hold, such as stablecoins or SOL, while making those balances private within Umbra.

This leads to a key point: Umbra is not “a feature” or a wallet add-on. It is a sovereign privacy domain on Solana, with its own shielded pools, its own private state, and its own internal economy. That makes it closer to a private financial system operating on top of Solana than a privacy tool that users briefly interact with and leave.

This positions Umbra’s token less as a speculative asset and more as long-term ownership over private economic activity. Through futarchy and protocol governance, token holders have direct influence over treasury allocation and economic policy, tying the token’s value to sustained usage rather than short-term narratives.

Through this ownership, token holders can propose and vote on decisions such as revenue sharing or dividend-like distributions sourced from protocol revenue. If approved, holders participate in protocol fees. As long as blockchains are used, there is persistent demand for private financial activity, and Umbra is designed to capture that demand through ownership of a productive private economy rather than through mandatory usage of a single privacy asset.

If privacy applications have historically suffered from one flaw beyond limited expressiveness, it is product quality. While cryptographic innovation has advanced rapidly, many privacy tools have failed to translate those capabilities into usable, accessible products. Poor UX and high operational complexity have significantly limited who can realistically benefit from privacy onchain.

Umbra takes a different approach. It is built as a product-first privacy system, with design choices that explicitly account for user behavior as a source of privacy risk. Rather than assuming perfect operational discipline, the wallet is designed to help users preserve privacy by default through clear affordances, safety mechanisms, and thoughtful UX. This focus on product quality is rare in the crypto privacy space and materially expands access to privacy beyond expert users.

The Umbra Wallet is designed with the assumption that real-world threats and constraints matter as much as cryptography. Beyond private transfers, swaps, encrypted balances, yield, and other features mentioned earlier in this article, the wallet includes features that address coercion, usability, and long-term recoverability without compromising the underlying privacy model.

One example is Distress Mode, a coercion-resistance feature intended for physical threat scenarios such as wrench attacks. By entering a decoy password, users can unlock a limited view of the wallet containing a predefined, low-value balance, while the primary wallet, balances, and private activity remain hidden. This allows users to comply under duress without exposing their full financial state.

Umbra also removes several forms of friction that commonly lead to privacy leakage. All transactions in the wallet are gas abstracted, meaning users do not need to hold native SOL to perform transfers or swaps. This is enabled through integrated relayer support, allowing gasless private transactions where fees are deducted directly from encrypted balances and relayers are reimbursed automatically. As a result, users can transact from fresh addresses without pre-funding them, eliminating a common onchain linkability vector.

Account recovery and custody are handled with the same emphasis on resilience. Umbra integrates social recovery, allowing users to regain access to their wallet through a configurable set of trusted guardians. A threshold of approvals can securely transfer control to a new key without granting guardians access to funds, removing the single point of failure inherent in seed-phrase–only recovery while preserving self-custody.

For users with higher security requirements, Umbra also supports hardware wallets, including Ledger and Keystone, with additional support for Trezor and Solflare Shield planned. This allows users to combine hardware-backed key storage with Umbra’s privacy guarantees, rather than choosing between the two.

Finally, Umbra includes an in-app browser that allows users to connect directly to supported applications from within the wallet while operating in Public Mode. Private Mode support will be enabled as integrations and partnerships mature, enabling seamless interaction with applications while maintaining privacy guarantees end to end.

Umbra is a wallet across iOS, Android, and web, as well as an SDK that can be integrated by any application seeking private transfers, swaps, and yield. It is designed as an environment users live in, not a pool they briefly pass through.

It is also the first privacy protocol to operate on encrypted shared state. That one distinction is what makes everything else possible: composable private execution, confidential balances, and a system that can expand into new financial primitives without sacrificing privacy.

Umbra does not treat anonymity as a vague promise. It treats it as a measurable outcome. A multi-purpose shielded pool compounds privacy because funds stay shielded, move repeatedly, fragment, recombine, and accumulate history inside the private domain. Integrations feed into the same unified pool, increasing both pool size and transaction frequency, which is what grows the anonymity set in practice.

And Umbra does not assume perfect users. It is built around the reality that most privacy failures come from behavior. Encrypted balances minimize amount-based correlation. Anonymity set visibility is surfaced as a first-class metric. The product actively tells users when an anonymity set is good instead of letting them unknowingly transact into deanonymization.

It also brings properties that traditional privacy protocols never had. Swaps execute within a shielded environment, balances remain confidential, and the system is built with a level of product focus never before seen in crypto privacy. At the same time, it acknowledges real-world compliance constraints without compromising the privacy thesis. Through proactive screening and selective disclosure via viewing keys, users can choose when to reveal information, rather than being forced into full transparency.

Umbra is not a mixer. It is not a single feature. It is a private financial layer for Solana that finally makes privacy persistent, expressive, and usable.

Protec!

Signed, Privacy GCR.

For a complementary perspective on Umbra, I recommend reading Umbra: Private DeFi’s Foyer

For a higher-level exploration of cryptography and MPC in crypto, see my article Crypto's New Whitespace

If you are new to MPC, An Introduction to Multiparty Computation is a good place to start.

If you want to dive deeper into Umbra, I recommend reading their docs.