Author：BitPush
Author: Yash Chandak
Original title: Stop Saying ‘We Need Privacy’
Compiled and edited by: BitpushNews
If your wallet is public, your life is public. People can stare at your balance, your trades, your positions, and your entry points, and then casually say it's "just data." That's why...privacy"It always manages to return as a timeless narrative."
The problem is that "privacy" is not a single function. It is actually five distinct issues.
This article is written to help you understand what you're actually asking for the next time you tweet "We need privacy".
When people talk about privacy, they often mean something completely different:
Intent privacy: Observers should not be able to see your transaction before it is completed.
Value privacy: Your salary, net worth, or transaction size should not be easily observable.
State privacy: Positions, liquidation thresholds, vault status, and inventory should not be disclosed by default.
Execution privacy: Your policies should not be inferred from which paths you trigger and how you trigger them.
Graph privacy: Observers should not be able to map who you pay, who you donate to, or who you collaborate with.
Many "privacy agreements" only address one or two issues, while exposing the rest. Most leaks occur at the edge: wallets, remote procedure calls (RPCs, the bridge between wallets and the blockchain), relayers, cross-chain bridges, exchanges, and the predictability of human behavior.
This is a framework that clarifies the industry landscape: first identify the surface you want to protect, and then find the tools to protect that surface.
Intent on privacy
On many blockchains, transactions don't go directly from your wallet into the block. Instead, they first sit in a public waiting room called a "mempool," where pending transactions are visible before being packaged. If you can see pending swaps, you can react to them. This creates opportunities for Maximum Extractable Value (MEV) bots. These bots are high-speed, automated systems that monitor the blockchain mempool to find and exploit profitable trading opportunities such as arbitrage, liquidation, and sandwich attacks.
For example, a bot could detect your exchange request, buy in before you do, causing the price to fluctuate against you, and then immediately sell after you to profit from the difference. You complete the transaction, but the price you received is worse.
Intended privacy addresses this specific 12-second window problem. Its goal is to hide transaction details until the observer has no time to react.
Private transaction delivery
The most practical way to ensure transaction delivery privacy is to change its path. Your wallet still creates a normal signed transaction. The difference is where it is sent. Instead of being broadcast to a public mempool, the transaction is submitted to a private endpoint, which forwards it to block builders. These builders assemble candidate blocks by ordering the transactions, and finally, validators publish one of the blocks.
This is the solution offered by systems like Flashbots Protect: a route that keeps your transactions away from the public mempool before they enter the block.
Flashbots is also researching a concept called SUAVE (Single Unified Auction of Value Expression), which defines the problem as "the order flow itself is a system." The idea is to collect user intent in a private environment, run an auction to determine who will execute, and then settle the results on Ethereum and other chains.
Although still evolving, this approach sets a clear direction: privacy should be applied before transactions access the public mempool.
This approach works because it involves trade-offs. It works because public bots can never see ahead. The trade-off is that private channels and builders can indeed see ahead. You're just narrowing down the audience, not eliminating advance visibility entirely.
Encrypted memory pool
Cryptographic memory pools are designed to provide stronger privacy, ensuring that no one (including the builder) can see a transaction before it is included in a block.
What the network sees is not a readable transaction, but a large, encrypted binary blob. Observers can see that something has been committed, but cannot know the specific content.
Decryption only occurs after an order has been locked. A common design uses threshold decryption, where decryption authority is distributed among a committee (called Keypers by Shutter Network). Each committee member holds a fragment. When the contents need to be revealed, the decryption key is reconstructed by releasing a sufficient number of fragments, allowing the transaction to execute.
This approach eliminates the problem of "private channels having access to everything in advance," but it introduces new assumptions: the committee must be online and must not collude.
Intended privacy ends when a block is published. Unless you combine it with on-chain value, state, or execution privacy, the information contained within the block will still be exposed as usual.
Value Privacy
Value Privacy answers a simple question: Can I transfer money without letting the whole world know how much I'm sending?
On a normal public blockchain, the answer is no. Each transaction directly publishes its amount, which is also how everyone verifies their balance.
“Shielded systems” change this by separating two things:
Amount (Keep confidential)
Proof of compliance with the rules (keep it public)
At its core, the system stores your funds as a private record. You can think of them as encrypted receipts. Each receipt represents a certain amount, but only the owner knows how much is in it.
When you make a purchase:
You can prove that you have a valid receipt.
You prove you haven't spent it before.
You create a new receipt for the recipient (and give yourself change).
You issue a certificate proving that the total amount transferred out equals the total amount transferred in.
The blockchain is responsible for verifying this proof. If the proof is valid, the transaction is accepted, but the hidden amount remains unknown to the outside world. This is the core design behind Zcash's shielded transfers and a classic example of value privacy in a production environment. Penumbra uses the same general concept in its multi-asset shielded pools, where all value resides in a private pool, and transfers are made through proof rather than through the visible amount.
However, this kind of privacy also has limitations. Even with perfect mathematics, privacy can still fail. Leaks usually stem from user behavior:
If you deposit a very specific amount and then later withdraw the exact same amount, an observer can guess that it's the same person.
If you enter and exit the private pool within a few minutes, the timing becomes a clue.
If only a few people are using a private pool, the anonymity set will be very small.
If you immediately transfer the funds to a known exchange account, you reconnect your identity.
Therefore, value privacy hides the numbers inside the system, but it does not automatically hide the behavioral patterns surrounding the system.
Graph Privacy
Graph privacy focuses on relationships. Even if you hide the amounts, the public ledger can still reveal patterns: who you send to, who you receive from, how frequently, and the size of the amounts. Over time, this network map may reveal more information than just the balance.
Most graph privacy methods fall into two categories:
The first type is pooled unlinkability. This is the idea behind "coin mixing." A large number of users send funds to the same pool and then withdraw them in a way that makes it impossible to publicly link withdrawals to specific deposits. Deposits and withdrawals still appear on the blockchain.
Privacy stems from ambiguity. Observers can see deposits and withdrawals, but cannot reliably match them. Each withdrawal could logically belong to many participants. This is the core mechanism of mixer systems like Tornado Cash. The larger the pool of funds, the lower the certainty an observer has regarding any single link.
If the pool is busy and many people deposit the same amount, you will disappear into the crowd. If the pool is small, the crowd will collapse, and the graph will reappear over time and with different amounts of money deposited.
Another way to disrupt the payment map is to stop using the same payment address repeatedly.
If every payment is sent to a public address, your payment history becomes a permanent public subscription source. Anyone can cluster these payments and assume they belong to the same person.
Stealth addresses can alter this pattern. Instead of being sent to a single, visible destination, each payment lands at a new address that appears unrelated to the previous one. The sender generates a one-time address for the payment, accessible only to the intended recipient. To an external observer, this appears as if funds are flowing to unrelated addresses.
This doesn't hide the amount or the sender. It solves a more narrowly defined problem by preventing outsiders from linking all payments to the same identity. This is the model standardized for Ethereum by ERC-5564. It doesn't hide the sender or the amount, but it makes "all the money paid to Alice" less obvious.
Graph privacy can still be compromised through behavior. If you withdraw funds from a pool and immediately bridge to the same place each time, you create a new link. If you log out and immediately contact an exchange that requires KYC (Know Your Customer), your identity is instantly reclaimed. If you maintain the same timing habits, the graph becomes predictable. These systems break direct links, but they don't erase your footprints.
Status privacy
State privacy aims to solve problems unique to DeFi. Your balance, positions, liquidation thresholds, vault composition, and inventory should not be readable by anyone with a block explorer.
This is important because "public visibility" becomes a strategy leak. If your positions are visible, other participants can predict your behavior, when you'll be liquidated, and what you might do next. Worse, they can target you. A wallet with visible liquidation lines is essentially a public scoreboard.
So what changes does state privacy actually make at the underlying level?
In a normal blockchain, state is something that everyone agrees on and can read. Lending protocols map addresses to position details. Vaults map addresses to shares and liabilities. This is what indexers and bots crawl.
Private state systems stop writing these details in plaintext. They replace "public state indexed by your address" with "private state represented by hidden records" and mandate that state updates must be accompanied by proof that the update follows the rules.
Here is the simplest way to understand it:
You can still perform operations such as "deposit collateral", "borrow", "rebalance", or "exchange".
The chain must still enforce constraints such as "you cannot borrow more than the collateral allows", "you cannot create value out of thin air", and "you cannot double spend the same private balance".
But the chain enforces these constraints by verifying proofs, not by reading your position.
This is why state privacy and zero-knowledge proofs (ZK proofs) are often inseparable. You need something that declares "this update is valid" while keeping the underlying digital information private.
A concrete example is Aztec. Its design centers on private execution by the client, with the network responsible for verifying proofs and commitments. This allows positions to exist without needing to be stored on-chain as readable tables. You can perform DeFi-like operations, and the public chain only sees the proven state transitions, not your original positions.
Where is state privacy being leaked? Primarily at the margins.
If you have a private position but regularly exit to a public decentralized exchange (DEX), the size and timing of these exits can reconstruct your behavior. If you enter and exit cross-chain bridges in a predictable pattern, you are creating links. If you rely on public keepers for liquidation, your "private" position still needs to establish some kind of interface with the outside world, and that interface may leak information.
Furthermore, state privacy makes composability difficult to achieve. Public DeFi is like Lego because everyone can read everything. Private DeFi must answer: "How do two contracts interact when neither can see the other's internal workings?" The more complex the composability, the more careful the design needs to be.
State privacy is where privacy evolves from "hiding a single transaction" to "hiding a continuous financial gesture," which is why it is harder to achieve, more useful, but also more prone to crumbling at the boundaries.
Enforcing privacy
This type of privacy goes a step further. It hides not only the balance or position, but also how the computation takes place. This is crucial for auctions, matching, solver logic, liquidation strategies, private order types, and any scenario where the strategy could be exploited once it becomes visible.
There are two common methods:
One approach uses Trusted Execution Environments (TEEs). Contracts execute within a hardware enclave; inputs are decrypted within the enclave, outputs are encrypted, and attestation verifies that the executed code is correct. Secret Network and Oasis Sapphire are examples of using this method to obtain private execution with lower proof overhead. The trade-off lies in the trust in the hardware and the risk of side-channel attacks.
Another approach is to use ZK proofs for private execution. The system generates proof that the program is running correctly, but does not reveal the private inputs that drive the execution. This approach is conceptually pure, but it usually has extremely high requirements for tools and performance, and is often rolled out in a limited scope before becoming widespread.
Enforcing privacy is weak in the same areas as other privacy types: timing, boundary interactions, and access layers.
RPC: Addressing Where Privacy Happens
Even if your on-chain privacy is perfect, if your wallet uses Infura or Alchemy, the RPC provider can see your IP address, the addresses you control (because you query their balances), which contracts you interact with, and your time patterns.
In 2022, ConsenSys publicly admitted that MetaMask's default RPC (Infura) collects IP addresses and wallet addresses. This is why protocol privacy often fails in practice: the access layer leaks everything before encryption even has a chance to work.
Therefore, privacy is shaped by context. Different contexts shape privacy design in different ways.
Transactions primarily require intent privacy. Payments require value privacy and graph privacy on the recipient's side. DeFi craves state privacy. Cross-chain bridges increase the number of points of connection. Institutions want to maintain confidentiality while having paths to verification and accountability.
Therefore, the question "Which privacy model will win?" is usually wrong.
A more precise question is: Which surface are you protecting? What assumptions are you making? And where else might information be leaked when users interact with the real world?
