Privacy design
The shielded bridge
How value crosses between Base and shh while staying private: a deposit on Base arrives as a spendable shielded note on the L3, and a shielded burn proof on the L3 authorizes an unlock back on Base.
The shielded bridge is what lets funds enter the privacy set directly, rather than landing as a transparent balance first. It is bidirectional and unit-tested in both directions.
Deposit — Base → shh
Locking the denomination/amount on Base emits a message via the OP Stack messenger. On the L3, the ShieldedBridge inserts the resulting commitment directly into the shielded set — so bridged funds arrive as a spendable note, not a transparent balance.
Withdrawal — shh → Base
Withdrawal reverses it: a shielded burn proof on the L3 authorizes an unlock on Base. The spend is bound to the bridge as recipient, and the actual L2 → L1 ETH transfer goes through the canonical L2StandardBridge.
| Direction | On the source side | On the destination side |
|---|---|---|
| Deposit | Lock on Base; OP portal message | ShieldedBridge inserts commitment into the shielded set |
| Withdraw | Shielded burn proof on L3 (bridge = recipient) | Canonical L2StandardBridge releases ETH on Base |
Why it's safe
- Deposit spoofing is prevented by accepting only the aliased L1 bridge address.
- Withdraw spoofing is prevented because the burn proof binds the bridge as recipient, then the authenticated L2→L1 path does the transfer.
- Both directions are covered by the contracts test suite.
Deployment
The bridge is deployed by a role-based script (deployShieldedBridge.ts) parameterised by BRIDGE_SIDE=l1|l2. Wiring it to a live OP portal address depends on a booted devnet — see the Roadmap, Phase 4.