Hello,
If your wallet is public, your life is public. People can watch your balances, your trades, your positions, your timing, then say it’s “just data.”That’s why privacy keeps coming back as a narrative.
The issue is that “privacy” is not one feature. It’s five different problems.
This piece is to help you understand what you’re asking for the next time you tweet, ‘We need privacy’.
When people mention privacy, they often mean very different things:
Intent privacy: observers shouldn’t see your trade before it lands
Value privacy: your salary, net worth, or trade size shouldn’t be easily observable
State privacy: positions, liquidation thresholds, vault states, and inventory shouldn’t be public by default
Execution privacy: strategies shouldn’t be inferable from which paths you trigger and how.
Graph privacy: observers shouldn’t be able to map who you pay, donate to, or coordinate with.
Many “privacy protocols” address one or two of these, while leaking the rest. Most leaks occur at the peripheries: wallets, Remote Procedure Calls (RPCs) - the bridges between wallets and blockchains, relayers, bridges between blockchains, exchanges, and human predictability.
That’s the frame that makes the landscape legible: separate the surface you want to protect, then look at the tool that protects that surface.
Intent Privacy
On many chains, a transaction doesn’t go straight from your wallet into a block.
Instead, it first sits in a public waiting room called the mempool, where pending transactions are visible before they are included. If you can see pending swaps, you can react to them. This creates the opening for Maximum Extractable Value (MEV) bots. These bots are automated systems that monitor blockchain mempools at high speed to find and exploit profitable transaction opportunities, such as arbitrage, liquidations, and sandwich attacks.
For example, a bot could spot your swap, buy right before you do, causing the price to move against you, and then sell right after you to capture the difference. You still complete your trade, but at a worse execution price.
Intent privacy addresses this specific ~12-second window.
The goal is to keep transaction details hidden until it’s too late for random observers to respond.
Private Transaction Delivery
The most practical approach to ensure the privacy of a transaction delivery is to change its path.
Your wallet still creates a normal signed transaction. The difference lies in where it gets sent. Instead of broadcasting it to the public mempool, the transaction is submitted to a private endpoint that forwards it to block builders. These builders assemble candidate blocks by ordering transactions. A validator then publishes one of those blocks.
This is what systems like Flashbots Protect offer: a route that keeps your transaction out of the public mempool until it’s included in a block.
Flashbots is also working on a concept called Single Unifying Auction for Value Expression, or SUAVE, which frames the problem as “order flow as its own system.” The idea is to collect user intents in a private environment, run an auction to determine who executes them, and then settle the outcomes on Ethereum and other chains.
While still evolving, this approach sets a clear direction: privacy should be applied before the transaction ever touches a public mempool.
Why this works is also why it has a trade-off.
It works because public bots never get the early look. The trade-off is that the private pipeline and the builders do get that early look. You’re shrinking the audience, not removing early visibility entirely.
Encrypted Mempools
Encrypted mempools aim to provide stronger privacy by ensuring no one can see your transaction before it is included in a block.
Instead of broadcasting a readable transaction, the network sees an encrypted blob. Observers can tell that something was submitted, but they can’t tell what it does.
Decryption happens only after the order is locked in. One common design uses threshold decryption, where decryption is split across a committee (The Shutter Network calls them Keypers). Each committee member holds a share.
When it is time to reveal the contents, sufficient shares are published to reconstruct the decryption key, allowing the transaction to be executed.
This method eliminates the “problem of the private pipeline being able to read everything early, but it introduces new assumptions: the committee must be online, and must not collude.
Intent privacy ends when the block is published. After inclusion, the chain reveals what it always has unless you pair it with on-chain privacy for values, state, or execution.
Value Privacy
Value privacy answers a simple question: Can I send money without the whole world seeing how much I sent?
On a normal public chain, the answer is no. Every transaction literally publishes the amount. That’s how everyone verifies balances.
Shielded systems change this by separating two things:
the amount (kept private)
the proof that the rules were followed (remains public)
Under the hood, the system stores your money as private records. You can think of them as encrypted receipts. Each receipt represents some amount, but only the owner knows what’s inside.
When you spend:
You prove you own a valid receipt
You prove you haven’t spent it before
You create new receipts for the recipient (and change)
You publish a proof that the total going out equals the total coming in
The chain checks the proof. If the proof is valid, the transaction is accepted, but the hidden amount remains unknown. This is the core design behind Zcash shielded transfers, a classic example of value privacy in production.
Penumbra uses the same general concept in a multi-asset shielded pool, where all value resides within a private pool and transfers occur via proofs rather than visible amounts.
But this type of privacy has limitations.
Even with perfect math, privacy can still fail.
The leaks usually stem from user behaviour:
If you deposit a very unusual amount and later withdraw the exact same amount, observers can guess it’s the same person.
If you enter and exit the private pool within minutes, the timing becomes a clue.
If only a handful of people are using the private pool, the anonymity set is small.
If you immediately move funds to a known exchange account, you reconnect your identity.
So, value privacy hides the number inside the system, but it does not automatically hide the patterns surrounding the system.
Graph Privacy
Graph privacy focuses on relationships. Even if you hide the amounts, a public ledger can still reveal patterns: who you send to, who you receive from, how often, and in what amounts. Over time, this network map can be more revealing than balances.
Most graph privacy approaches fall into two categories:
The first is pooled unlinkability. This is the “mixing” idea. A lot of users send funds into the same pool, and later withdraw them in a way that doesn’t publicly tie the withdrawal to a specific deposit. The chain still shows deposits and withdrawals.
Privacy comes from ambiguity. Observers can see the deposits and withdrawals, but they can’t reliably match a specific withdrawal to a specific deposit. Each withdrawal could plausibly belong to many participants. This is the core mechanism behind mixer-style systems like Tornado Cash.
The larger the pool, the less certain an observer is about any single link.
If the pool is busy and many people deposit the same amounts, you blend into the crowd. If the pool is small, the crowd collapses, and the graph starts to reappear through timing and amounts.
Another way to break the graph is to stop reusing the same receiving address.
If every payment goes to one public address, your inbound history becomes a permanent public feed. Anyone can cluster those payments and treat them as belonging to the same person.
Stealth addresses can change that pattern. Instead of a single visible destination, each payment lands at a new address that looks unrelated to the last one.
The sender generates a one-time address for that payment, and only the intended recipient can access it. To outside observers, it appears as money going to unrelated addresses.
This doesn’t hide the amount or the sender. It solves a narrower problem by preventing outsiders from linking all inbound payments to the same identity.
ERC-5564 standardises this pattern for Ethereum. It doesn’t hide the sender or the amount; it stops “all payments to Alice” from being obvious.
Graph privacy still leaks through behaviour. If you withdraw from a pool and immediately bridge to the same place every time, you create a new linkage point.
If you exit and immediately touch a KYC exchange, identity snaps back. If you keep the same timing habits, the graph becomes guessable again. These systems break direct links; they don’t erase your footprint.
State Privacy
State privacy seeks to address a DeFi-specific problem. Your balances, positions, liquidation thresholds, vault composition, and inventory should not be readable by anyone with a block explorer.
This matters because “public state” turns into a strategy leak. If your position is visible, other actors can predict how you’ll behave, when you’ll get liquidated, and what you’re likely to do next. Even worse, they can target you. A wallet with a visible liquidation line is basically a public scoreboard.
So what does state privacy change under the hood?
In a normal chain, the state is the thing everyone agrees on, and everyone can read. A lending protocol maps an address to position details. A vault maps an address to shares and debt. That’s what indexers and bots scrape.
Private-state systems stop writing those details in plaintext. They replace “public state keyed by your address” with “private state represented as hidden records,” and force updates to come with a proof that the update followed the rules.
Here’s the simplest way to picture it:
You still perform actions like “deposit collateral,” “borrow,” “rebalance,” or “swap.”
The chain still has to enforce constraints like ‘you cannot borrow beyond what your collateral allows’; ‘you cannot create value out of thin air’; and ‘you cannot spend the same private balance twice’.
But the chain enforces these constraints by verifying a proof, not by reading your position.
That’s why state privacy and ZK proofs often travel together. You need something that says “this update is valid” while keeping the underlying numbers private.
A useful concrete example is Aztec. The design centres on private execution on the client-side, with the network validating proofs and commitments. That lets a position exist without being stored as a readable table on-chain. You can do DeFi-like actions, while the public chain only sees proof-verified state transitions, not your raw position.
Where does state privacy leak? Mostly at the edges, again.
If you have a private position but periodically exit to a public DEX, the size and timing of those exits can reconstruct your behaviour. If you bridge in and out in predictable patterns, you create a linkage.
If you rely on public keepers for things like liquidations, your “private” position still needs some interface to the outside world, and that interface can leak.
Also, state privacy is hard to make composable. Public DeFi is like Lego because everyone can read everything. Private DeFi has to answer “How do two contracts interact when neither can see the other’s internals?”
The more complex the composition, the more careful the design needs to be.
State privacy is where privacy stops being about “hide a transfer” and becomes about “hide an ongoing financial posture,” and that’s why it’s harder, more useful, and more fragile at the boundaries.
Execution Privacy
This type of privacy goes one level deeper. It hides not only balances or positions but also how the computation happened. This matters for auctions, matching, solver logic, liquidation strategies, private order types, and anything where the strategy becomes exploitable once it’s visible.
There are two common approaches:
One uses Trusted Execution Environments (TEEs), where contracts execute within a hardware enclave, inputs are decrypted within the enclave, outputs are encrypted, and attestation verifies that the correct code ran.
Secret Network and Oasis Sapphire are examples of systems that use this approach to get private execution with lower proofing overhead. The trade is hardware trust and side-channel risk classes.
The other approach uses ZK proofs for private execution, where the system produces evidence that a program ran correctly without revealing the private inputs that drove the execution.
This approach is conceptually clean, typically heavier on tooling and performance, and tends to be rolled out gradually through limited scopes before it becomes general.
Execution privacy is weak in the same areas as every other type of privacy: timing, boundary interactions, and the access layer.
RPC: Tackling the Place Privacy
Even if your on-chain privacy is perfect, if your wallet uses Infura or Alchemy, that RPC provider can see your IP address, which addresses you control (because you queried their balances), what contracts you interact with, and your timing patterns.
In 2022, ConsenSys publicly acknowledged that MetaMask’s default RPC (Infura) collects IP addresses and wallet addresses. This is why protocol privacy often fails in practice: the access layer reveals everything before the cryptography gets a chance to work.
So, privacy is context-shaped. Different contexts shape privacy designs in different ways.
Trading mostly needs intent privacy. Payments need value and recipient-side graph privacy. DeFi wants state privacy. Bridges multiply correlation points. Institutions want confidentiality with a path to verification and accountability.
So, the question ‘Which privacy model wins?’ is usually the wrong one.
A more accurate question is: Which surface are you protecting? What assumptions are you making? And where does the information still leak when the user touches the real world?
That’s all for today.
P.S.: Thanks to Nitanshu, Joel and Kunal for helping with their input.
Token Dispatch is a daily crypto newsletter handpicked and crafted with love by human bots. If you want to reach out to 200,000+ subscriber community of the Token Dispatch, you can explore the partnership opportunities with us 🙌
📩 Fill out this form to submit your details and book a meeting with us directly.
Disclaimer: The views expressed in this article belong to the author, Yash Chandak, and not Token Dispatch.
 | A guest post by
|