Privacy UX Is Part of the Security Model

At EthCC 2026, I gave a talk called Keeping Your Users' Private Parts Private. This blog post is the summary of it, but here is a link to watch.

In short, Ethereum privacy is no longer blocked by cryptography. We have moved a meaningful distance from "impossible" to "possible." The next barrier is usability and many things could be done today.

Privacy tools do not fail like normal apps

Normally, when making onchain transactions, mistakes usually create visible failure. Something errors, the transaction reverts, the error is visible and the user knows something went wrong.

When making a private transaction today, using any of the existing privacy protocols, your transaction will not revert and you will receive that green checkmark. The interface looks fine. Funds arrive. However, there is no feedback loop on privacy. User's privacy could be gone, no second chance. That difference matters. A flow can work technically and still expose the user.

This is why privacy UX cannot be treated just as cosmetic polish. Privacy adds a second layer of correctness beyond transaction success. It has to be treated as part of the security model.

The data is not kind to wishful thinking

The August 31, 2023, paper Anonymity Analysis of the Umbra Stealth Address Scheme on Ethereum showed how practical privacy collapses under ordinary user behavior.

In short, half of the Umbra users were deanonymized. Not even due to a very sophisticated behavior analysis, but rather the dominant failure mode was address reuse. A normal user behavior recreated linkages that the system was supposed to avoid.

That is the part builders should sit with for a moment. The failure was not "the math was broken." It wasn't a documentation issue. It was a product design and policy issue.

Another such research, Clustering Deposit and Withdrawal Activity in Tornado Cash: A Cross-Chain Analysis, was based on Tornado Cash, a system that has even less room for error. The researchers were successful in deanonymizing up to 35% Tornado Cash transactions.

Privacy success needs different metrics

If privacy-preserving flows have different failure modes, they also need different success criteria. Today, many teams still implicitly evaluate privacy flows with the wrong question: "Did the transaction work?", That is necessary, but it is not sufficient.

A better evaluation looks more like this:

• Did the user preserve identity separation?
  • e.g., A private withdrawal into a public ENS-linked wallet may be technically successful and privacy-failing at the same time.
• Did the flow reduce or increase linkability?
  • e.g., Recreating obvious patterns through timing or doing the same amounts all over again will lead to failure of this criterion.
• Did the user understand what remained visible?
  • e.g., Criterion checks if privacy state was shown continuously so the user doesn't leave with the wrong mental model.

The product has to protect the intended boundary, not just execute the protocol action.

Builders need to stop designing from protocol surfaces

Stop thinking: "How do I present protocol actions?" and exposing smart contract functionality through just a UI button.

That leads to interfaces built around terms and jargon like stealth addresses, shielding, relayers, reveal phases, etc. Those may be technically correct, but they are not how users think about the job.

Builders should start from intent instead, for example:

• Send a transaction privately
• Receive recurring payments privately
• Separate work and personal wallets

That change sounds small, but it pushes the whole product experience. It changes onboarding, defaults, warnings, routing and what counts as a dangerous action. It affects how you set up default settings and maximize privacy, while also reducing the number of clicks a user has to make.

Safe behavior should be the default

Privacy should not depend on perfect discipline.

We already accept this principle in security. Wallets try to prevent bad approvals and exposure of private keys. Privacy needs the same treatment. Known privacy-breaking actions should be treated as policy violations.

That means things like:

• blocking reuse of an address or merging identity with a public account
• warning repeated transactions into the same destination
• avoiding asking each transaction who should relay the transaction

Add privacy review, not just transaction review

Transaction confirmations used to be scary. But we got better at transaction reviews. We now have in our wallets certain security checks and dry-run simulations. The same could be applied to private transactions.

A confirmation screen could include a privacy section that tells the user:

• What becomes public
• What new linkage risk is created
• Who can still observe relevant metadata

Not only "Will this succeed?" but "How does this change the user's privacy state?"

The threat model does not stop at the chain

It's not only UX. Privacy boundaries are often described too narrowly. Onchain privacy is only one layer. Frontends, RPC providers, relayers and other infrastructure can still observe metadata. Some systems rely on off-chain or semi-trusted components that users rarely include in their own threat models.

A privacy product should not hide that. It should explain it plainly.

If a product has additional dependencies involved in user behavior, that information belongs in the visible interface, not only in the docs.

Privacy by default is the future

The long-term goal is not to turn every Ethereum user into a privacy expert. It is to make privacy feel like today's HTTPS protocol, to which we are very accustomed.

Secure internet browsing (https://) is built into the default path. It's mostly invisible when it works and clear when the boundary changes. It's also unusual when you access an insecure HTTP connection.

You get warned for non-encrypted communication. Transactions should be seen the same way. A user can always opt-out but private mode is the default and privacy becomes normal.

But first, if we want to have functional private transactions, then we should do what we can today and build for the majority of users and use cases. The safe path has to become the easy path.