Privacy on Ethereum Layer 2: How Bermuda Enables Stealth Addresses
Layer 2 networks face a fundamental tradeoff: privacy or composability. Bermuda solves this by implementing privacy at the protocol layer through stealth addresses and confidential balances, allowing transactions to remain private while users interact seamlessly with public smart contracts. Unlike privacy-first sidechains that isolate private activity, Bermuda uses zero-knowledge proofs to bridge private execution with a transparent settlement layer that includes retroactive compliance. Instead of watching everyone upfront, the protocol screens funds at entry. If funds are later identified as illicit, the system can withdraw the right to anonymization during the exit process, linking the withdrawal back to the initial deposit to ensure accountability..
Privacy is a core property of cash. If every transaction is visible to everyone, surveillance becomes default. Yet on Ethereum Layer 2s, transparency is the norm. Users can track account balances, transaction history, and on-chain activity in real time.
The challenge: adding privacy breaks composability. Most privacy solutions (like privacy pools or isolated rollups) create walled gardens where private users cannot interact with public dApps, DEXs, or lending protocols without reverting to transparent exits.
Traditional approaches fail because they separate private and public execution into different layers. When you want to privately swap on a DEX, you must first unshield your funds (revealing your identity), execute the swap transparently, and reshield. Each step leaks metadata.
Bermuda takes a different approach: integrate privacy as a native property of the rollup itself, not as a sidecar or wrapper.
A stealth address is a one-time receiving address derived from a permanent public key. Instead of reusing a single address (which reveals all transactions tied to you), every deposit generates a new address that only you can recognize.
The mechanism:
- 1Ephemeral Public Key: A sender generates an ephemeral key pair for each transaction.
- 2Shared Secret Derivation: The sender's ephemeral public key is combined with your permanent public key using Diffie-Hellman key exchange.
- 3Stealth Address Generation: A one-time address is derived from this shared secret. Only you (holding the corresponding private key) can recognize and spend funds sent to this address.
- 4Encrypted Metadata: The ephemeral public key is published on-chain, but the link between the stealth address and your identity remains private.
To observers, every stealth address appears unrelated. Even if Alice sends you 1 ETH ten times, each transaction uses a different receiving address. An external analyst cannot correlate these transactions to a single entity.
Stealth addresses hide the receiver. Confidential balances hide the amount.
On a standard L2, a balance update appears in the state tree as account_X: 5 ETH → 7 ETH. Anyone monitoring state can infer transaction size.
Confidential balances work differently:
- Balances are encrypted using a public key held only by the account owner.
- When you spend funds, you generate a zero-knowledge proof that:
- You own the encrypted balance being spent.
- The balance is sufficient (without revealing the actual amount).
- The transaction does not create a net increase in supply (no double-spending).
- The rollup verifies the proof without decrypting the balance.
This is computationally expensive (proof generation takes milliseconds), but on an L2 where transactions are batched and submitted once per block, the overhead is manageable.
The critical design choice: Bermuda allows private accounts to interact directly with public smart contracts.
Example: You hold 100 GUSD in a private stealth account. You want to swap 10 GUSD for ETH on the Orvex DEX.
Without composability, you would:
- 1Unshield the 10 GUSD (revealing your identity).
- 2Swap on Orvex (public).
- 3Reshield the ETH (expensive, requires a new ZK proof).
With native composability:
- 1You prove (off-chain) that you hold sufficient GUSD in a private account using a ZK proof that includes a commitment to the swap parameters.
- 2The proof includes a reference to the Orvex contract call (encoded as a constraint).
- 3The rollup atomically executes the swap on Orvex while transferring the private GUSD to a new stealth address you control.
- 4To the DEX, this appears as a normal swap from a temporary transparent account. The DEX has no visibility into the fact that the funds came from a private account.
Privacy is maintained end-to-end because:
- The sender never reveals their stealth address publicly.
- The amount is hidden in a confidential commitment.
- The swap is linked to the private execution through a ZK proof, not through visible account state.
On a gasless L2, funding execution through native yield creates a new privacy challenge: how do you pay the sequencer or prover without revealing your identity?
Bermuda solves this by separating authentication from funding:
- Authentication: Your private account proves ownership of assets and intent to transact using ZK proofs (off-chain, no gas).
- Funding: A separate funding mechanism (from the network's yield pool or a relayer) covers proof verification and L2 execution costs.
A relayer submits the private transaction on your behalf. The relayer receives a payment routed through an unlinkable channel (e.g., a fee attached to a future transaction, or withdrawn from a confidential balance). The relayer never sees the transaction contents; only the rollup verifies the ZK proof.
This preserves privacy while maintaining the gasless property.
Privacy at protocol layer comes with costs:
- Proof Generation Latency: ZK proofs for confidential balances take 50-500ms to generate, depending on the circuit complexity. Batch submissions mitigate this.
- Proof Size: A confidential balance proof is 100-200 bytes, larger than a simple signature. This increases rollup calldata.
- Withdrawal Complexity: Exiting a private account to Ethereum L1 requires a privacy-preserving bridge proof, which is non-standard and longer than transparent exits.
- Flexible Disclosure: Unlike systems where privacy is an all-or-nothing state, users can manage both public and private balances within the same interface. A native 'Private Mode' toggle allows for selective privacy, meaning users only shield specific assets or transactions when needed. Status Network's Bermuda layer allows users to choose: operate a transparent account for public DeFi, or a private account for personal transactions.
These constraints are acceptable for private-by-default use cases (payments, personal finance, gaming) but not for financial primitives requiring transparency (lending collateral, DAO governance).
Status Network's Bermuda layer allows users to choose: operate a transparent account for public DeFi, or a private account for personal transactions. Karma governance and gasless transactions work seamlessly across both.
A privacy solution that isolates users defeats the purpose. If you're the only person using private addresses on an L2, you stand out. Privacy requires liquidity and activity, many users operating private accounts simultaneously.
Composability ensures that private accounts are not second-class citizens. You can:
- Swap on the native DEX without unshielding.
- Earn yield in GUSD privately.
- Participate in liquidity mining without revealing your identity.
- Bridge to other L2s through privacy-preserving relayers.
This makes private accounts economically attractive, driving adoption and improving the anonymity set for all users.
Can a stealth address recipient see who sent them funds?
No. The ephemeral public key is published, but deriving the sender's identity from it requires solving the discrete logarithm problem (computationally infeasible). The sender can optionally include an encrypted metadata payload for personal record-keeping, but this is not broadcast.
Do ZK proofs for confidential balances require special hardware?
No. Proof generation is handled locally, even in constrained environments like mobile devices or browser extensions. Bermuda has implemented client-side proving within a sandbox, such as a MetaMask Snap, ensuring that private keys never leave the user's device while generating ZK proofs.
What happens if someone exceeds their Karma quota while using a private account?
RLN (Rate Limiting Nullifiers) still apply. The private account accumulates a quota violation record linked to an anonymous credential, not a public address. Exceeding the quota triggers premium gas fees, applied to the next on-chain interaction, without deanonymizing the user.
Can private accounts interact with smart contracts that require EIP-2771 meta-transactions?
Yes, but with a caveat. The contract must be adapted to accept ZK commitments instead of transparent addresses. Status Network's private relay pattern handles this automatically for integrated apps, but older contracts require an adapter.
Are private balances truly private from the sequencer?
Yes, because the sequencer only sees encrypted commitments, not plaintext balances. The sequencer receives a ZK proof and a transaction hash; it cannot decrypt the balance even if it tries. However, the sequencer can observe transaction frequency from an account (timing analysis). Users concerned about this should batch transactions or use a privacy-preserving proxy.
How do I prove ownership of a private account to a counterparty off-chain?
You can generate a zero-knowledge proof of balance at a specific block height, signed by your private key, without revealing the balance itself. The counterparty verifies the proof locally. This is useful for credit applications, collateral negotiations, or fraud prevention.
Does Bermuda work on Ethereum L1, or only on Status Network L2?
Bermuda is designed as an L2 privacy layer. L1 implementations exist (e.g., Tornado Cash, but with different trade-offs). Status Network's Bermuda is optimized for L2 composability and gasless transactions, which are difficult to achieve on L1 due to gas costs and block time constraints.
What if someone accidentally sends funds to a stealth address they don't control?
This is rare because stealth addresses are derived from the recipient's public key, not chosen arbitrarily. If a mistake occurs, the funds are permanently unrecoverable because no one holds the private key to the stealth address. Users should test with small amounts first.