Layer 2 rollups have become the dominant scaling solution for Ethereum. Privacy rollups — L2s that additionally encrypt transaction data — are frequently presented as the path to private Ethereum transactions. This is partially true and importantly incomplete. There is a structural gap between L2 privacy and L1 privacy that affects every rollup design, and it stems from how rollups work fundamentally.
How Rollups Work
A rollup executes transactions off-chain, in batches, then posts a summary to the L1. For optimistic rollups, that summary is the transaction data itself (so L1 can verify correctness if challenged). For ZK rollups, the summary is a validity proof that mathematically proves the batch was computed correctly, without posting the individual transaction details.
The key mechanism: rollup state lives on the L1. Deposits come in through an L1 bridge contract. Withdrawals exit through that same contract. Proof submissions (for ZK rollups) are L1 transactions. Every meaningful interaction with the rollup's settlement layer is a visible L1 event.
What L1 Can Always See
Even the most privacy-optimized L2 rollup cannot prevent the following from being visible on L1:
- Deposits. When you bridge funds from Ethereum to a privacy L2, you call the bridge contract from your Ethereum address. That transaction is public. Your Ethereum address, the amount, and the timing are all visible. This is the entry into the private system, and it is fully exposed.
- Withdrawals. When you withdraw funds from the L2 back to Ethereum, the bridge contract releases funds to an Ethereum address. The receiving address, amount, and timing are visible. This is the exit from the private system, and it too is fully exposed.
- Proof submissions. For ZK rollups, the proof submitter posts a transaction to L1 for each batch. This reveals which L2 is active, how frequently batches are produced, and sometimes batch-level metadata like transaction count.
- Bridge contract interactions. Any direct interaction with the bridge contract — emergency withdrawals, governance actions, parameter updates — is an L1 transaction with a visible caller address.
The Exit Timing Attack
The deposit and withdrawal visibility creates a specific deanonymization vector called the exit timing attack. Even if all activity within the L2 is perfectly private, an observer watching the L1 bridge contract can infer behavior from timing correlations.
The simplest version: you deposit 10 ETH into a privacy L2 from address A. Several days later, address B withdraws exactly 10 ETH from the same rollup. Even without any on-chain link between A and B, the matching amount and temporal proximity is a strong statistical signal. With more data — the distribution of deposits and withdrawals, timing patterns, amount clustering — analysts can reconstruct behavioral patterns even from the L1 perimeter alone.
This is not a flaw that can be fixed within the L2 design. It is an inherent consequence of using a public settlement layer. The L1 always sees the boundary conditions of the L2 system.
Sequencer Centralization as a Privacy Attack Surface
Most current L2 rollups use a centralized or semi-centralized sequencer — a single operator that orders and batches L2 transactions. This creates a privacy risk that is often understated: the sequencer sees every L2 transaction in plaintext before it is committed to a batch. The sequencer knows the sender, receiver, and amount of every transaction on the L2.
For a "privacy L2," this means the entity running the sequencer has full visibility into the activity that users believe is private. This is structurally similar to using an end-to-end encrypted messaging app where the server operator can still read all messages before encryption. The privacy guarantee exists at the public observer level but not at the sequencer level.
Decentralized sequencing mitigates but does not eliminate this: a decentralized sequencer set distributes the trust assumption across more parties, but each sequencer participant still sees the full transaction. Encrypted mempools (transactions encrypted until they are included in a block) are a research-stage solution that addresses sequencer-level visibility, but are not yet deployed in any production L2.
What "Private L2" Actually Claims vs What It Delivers
When a privacy L2 claims its transactions are private, the claim is typically: "observers on the L1 cannot read the transaction data from within the L2 batches." This is true for the calldata content. It does not mean:
- Your deposit or withdrawal is hidden from L1 observers.
- The sequencer cannot see your transactions.
- Timing and amount analysis of bridge activity cannot link entry and exit addresses.
- The volume and frequency of your L2 activity is hidden.
These are significant caveats. A privacy L2 provides meaningful protection against one class of adversary (someone reading Ethereum calldata) while leaving substantial exposure against other adversaries (the sequencer, sophisticated timing analysts, and anyone monitoring the bridge contract).
Why Native L1 Privacy Is Structurally Different
A privacy-native L1 does not have a settlement layer that publishes the boundary conditions of its privacy system. Every transaction in the privacy pool is settled on the privacy chain itself — there is no L1 bridge, no cross-chain deposit, no external settlement layer watching the entry and exit points.
The validator set verifies transaction validity using ZK proofs, but the validators see only the proof, not the private data. The consensus mechanism is the same mechanism that enforces privacy — not a separate overlay system. This is what "privacy at the consensus layer" means: privacy is not an application running on top of a transparent chain, it is the fundamental operating mode of the chain itself.
What Sanect's Approach Changes
Sanect settles transactions on its own chain. The shielded pool is native to the L1 — there is no bridge to Ethereum, no external settlement layer, no cross-chain deposit that reveals your entry point to an Ethereum observer. All transaction validation, including ZK proof verification, happens within Sanect's own validator set using UltraHonk proofs generated from custom Noir circuits via Barretenberg.
The remaining exposure points are the public EVM layer (which coexists with the shielded pool for explicit public transactions) and the entry and exit from the shielded pool to the public EVM layer. These are analogous to the L1 bridge problem, but confined entirely within the Sanect chain — not exposed to an external public settlement layer. The anonymity set for shielded transactions is the full Sanect shielded pool, not constrained by the activity visible on Ethereum.
L2 privacy is real but bounded. L1 privacy removes the settlement layer problem. The difference matters most for high-value activity where sophisticated timing and behavioral analysis is a realistic threat model.