Works best when
- Strong privacy is required beyond value-hiding, including identity unlinkability and programmable access controls.
- Institutions want to embed compliance hooks (view keys, audit proofs) directly into the execution environment.
Avoid when
- A conservative, battle-tested L1 deployment path is required today.
- Only minimal value privacy is needed and bridging overhead is unjustified.
I2I vs I2U — context differences
Institution to institution
I2IInstitutions can absorb bridging friction and centralized-sequencer risk as known operational costs. The primary value is programmable private state: confidential contract logic, private balances with DvP hooks, and selective disclosure integrated at the protocol level. Both counterparties share a legal framework, so temporary sequencer centralization is a liveness concern, not an existential one.
Institution to end user
I2UEnd users face asymmetric exposure to the sequencer. A centralized sequencer can unilaterally exclude user transactions; without forced withdrawal via the L1 bridge, user funds can be stranded. Permissionless sequencer selection and forced-exit guarantees are prerequisites before this pattern is safe for user-facing deployments.
Post-quantum exposure
Risk · high- Vector
- EC-based proof systems (Groth16, PLONK/KZG) dominate privacy rollup stacks and are broken by CRQC. FHE-based L2s depend on lattice hardness and are PQ-leaning, but the surrounding bridge and signature schemes are typically classical.
- Mitigation
- STARK-based rollups with hash commitments for PQ-secure proofs; hybrid PQ-secure bridges for cross-layer messages.
Visibility
| Actor | Sees |
|---|---|
| Counterparty |
|
| Chain |
|
| Regulator |
|
| Public |
|
Components
- Privacy rollup execution layer: either a ZK rollup that commits to state via ZK proofs of valid transitions, or an FHE rollup that computes on encrypted state.
- L1 bridge contracts: deposit, withdraw, and forced-exit paths that anchor the rollup to Ethereum.
- Client-side or coprocessor prover: generates ZK proofs for private state transitions, or orchestrates FHE computation.
- Viewing key and disclosure infrastructure: off-chain key management and attestation services for regulator access.
- Sequencer or block builder: collects and orders transactions for the rollup; centralized on most deployments today.
Shielded note logic on the rollup is described in pattern-shielding; disclosure flows in pattern-regulatory-disclosure-keys-proofs.
Protocol
- user Bridge assets from L1 to the privacy L2 via a deposit contract.
- contract Assets are converted to private notes or encrypted balances on the L2.
- user Execute transactions privately within the L2 (amounts, senders, receivers shielded within the rollup).
- prover Generate ZK proofs (or FHE state-transition proofs) for valid state transitions.
- sequencer Order and aggregate transitions; post the proof and state root to L1.
- contract Optionally couple settlement with an on-chain DvP or PvP contract for atomic cross-asset flows.
- regulator Access transaction details via viewing keys or disclosure proofs as required.
- user Exit to L1 by submitting a withdrawal proof of valid state ownership.
Guarantees & threat model
Guarantees:
- Private transactions: amounts, sender, and receiver are shielded within the L2.
- Private state: balances and contract state are stored as encrypted commitments or notes.
- Interoperability with L1 state: rollup state roots anchor on L1, enabling bridging and settlement with L1 assets.
- Programmable compliance: viewing keys, selective disclosure, and audit proofs can be embedded in contract logic.
Threat model:
- Bridge soundness. An exploited bridge can inflate or steal assets on L1.
- Proof system or FHE scheme soundness. Breaks here allow unauthorized state transitions.
- Sequencer liveness and honesty. A centralized or censoring sequencer can exclude transactions until the L1 forced-exit path is exercised.
- Viewing key custody. A compromised viewing key exposes the history protected under it.
- Non-standardized regulator interfaces. Each deployment rolls its own compliance hooks, creating fragmentation risk for supervisors.
Trade-offs
- Maturity risks. Most privacy L2s are early-stage with limited production deployments.
- Migration and bridging overhead. Assets and apps must move from L1 or other L2s, adding friction and new trust surfaces.
- New attack surfaces. Viewing key compromise, bridge exploits, and sequencer censorship.
- Regulatory auditability uncertain. Selective disclosure is possible, but no standardized frameworks exist yet for regulator access or compliance proofs.
- Sequencer centralization. Most privacy L2 sequencers are currently centralized and can censor until decentralized sequencing is implemented.
Example
- Bond issuance and secondary trading on native shielded notes.
- An FHE-based L2 running a private credit risk model where inputs remain encrypted end-to-end and only the final attestation is revealed to the counterparty.