Base2.0
Privacy as a native layer
Created on 14th March 2026
•
Base2.0
Privacy as a native layer
The problem Base2.0 solves
In today's Ethereum ecosystem, privacy is an afterthought. Users must discover privacy tools, manually deposit into shielded pools, and navigate complex UX. 99.9% of users never bother. Existing solutions like RAILGUN are powerful but require users to actively seek them out — like convincing everyone to install Signal when they already have a messaging app built in.
What ShadowBase does differently
We forked Base itself (the OP Stack chain) and made privacy a native, chain-level feature. Every wallet on our chain has a built-in private sub-account. Users opt-in with a single toggle. Once enabled, incoming funds are automatically shielded — no extra steps, no special wallets, no learning curve.
The sender doesn't even need to know privacy exists. Alice sends ETH to Bob's address like a normal transaction. The chain itself handles the rest.
How it works
Bob toggles "Auto-Shield" ON in his wallet — a single on-chain transaction to the PrivacyRouter system contract
Alice sends 1 ETH to Bob — a completely normal transaction, Alice knows nothing about privacy
The EVM itself intercepts the transfer — our custom Go precompile in op-geth checks Bob's privacy rules
ETH is automatically routed to the Shielded Pool — Bob's public balance stays 0, his private balance shows 1 ETH
The block explorer shows: Alice → PrivacyRouter [SHIELDED], 1 ETH — Bob's address appears nowhere
Key capabilities
Auto-shielding at the EVM level — a custom precompile (Go, in op-geth) intercepts every value transfer and checks the recipient's privacy rules. This is NOT a smart contract hack — it's a protocol-level hook
Configurable privacy rules — users set min amount thresholds, token whitelists, sender whitelists via the PrivacyRouter system contract at 0x4200...0069
Full ZK privacy — forked RAILGUN's battle-tested Groth16 circuits and Solidity contracts for the ShieldedPool (Poseidon Merkle tree, encrypted UTXO commitments, nullifier tracking)
Cross-chain privacy bridge — bridge shielded funds from Base to RAILGUN on Ethereum Sepolia using OP Stack's native CrossDomainMessenger. Same commitment scheme = full compatibility
Recipient metadata privacy — RPC-level + message-level transaction rewriting ensures Bob's address never appears in any explorer or wallet query
Zero disruption for public users — addresses default to PUBLIC mode. The chain behaves exactly like Base unless you opt in
The analogy
RAILGUN is like Signal — a great privacy app, but you have to convince everyone to install it. We made end-to-end encryption the default in every phone's messaging system. Same cryptography, fundamentally different impact.
Challenges we ran into
- Transaction Recipient Privacy Leak
The bug: When Alice sends ETH to Bob (auto-shield ON), the on-chain transaction envelope still recorded to: Bob because Alice's signature commits to Bob's address. Any raw block reader could see who the recipient was, defeating the entire purpose.
How we fixed it: We implemented a multi-layer privacy fix:
Message-level rewriting in state_transition.go — before the EVM executes, we rewrite msg.To from Bob's address to PrivacyRouter and encode routeShield(bob) as calldata. The EVM never sees Bob.
RPC-level masking in api.go — newRPCTransaction() detects AutoShielded event logs in receipts and overrides the to field. Every explorer, wallet, and indexer sees PrivacyRouter, not Bob.
Transfer hook guard — the Transfer() function in evm.go detects when PrivacyRouter is the recipient and skips the auto-shield check (avoiding infinite recursion), while correctly routing ETH to the ShieldedPool.
2. RAILGUN Commitment Scheme Compatibility
The challenge: For the cross-chain bridge to work, the commitment scheme on our Base fork must be byte-for-byte identical to RAILGUN on Ethereum Sepolia. Different hash parameters, Merkle tree depth, or commitment structure would break bridge transfers.
How we solved it: We wrote 25 dedicated Foundry verification tests (CommitmentSchemeVerification.t.sol) comparing our ShieldedPool's Poseidon hash parameters, SNARK_SCALAR_FIELD, ZERO_VALUE, tree depth, and commitment structure (PoseidonT4(npk, tokenID, value)) against RAILGUN Sepolia's live contract (0xecfcf3b4...3fea). We also ran cast call against live Sepolia to verify all 28 verification key fields (alpha1, beta2, gamma2, delta2, IC points) match exactly.
- Predeploy Genesis Injection
The challenge: OP Stack predeploys are deployed at genesis — they must exist in the genesis state before the first block. But the standard op-chain-ops genesis generation doesn't support custom contracts.
How we solved it: We built Python scripts (inject-genesis-bytecode.py, patch_genesis_bridge.py, patch_genesis_bridge_storage.py) that extract compiled bytecodes and inject them at the reserved 0x4200... addresses in genesis.json, including initialized storage slots for the PrivacyBridge (l1Companion address, admin, pause state).
- Native ETH Shielding
The challenge: RAILGUN contracts are designed for ERC-20 tokens (using safeTransferFrom), not native ETH. Our auto-shield intercepts plain ETH transfers — but the ShieldedPool doesn't natively handle msg.value.
How we solved it: We adapted the ShieldedPool to accept native ETH via shieldETH() and claimAutoShield() functions, with the precompile writing pending shield balances to a special storage mapping. Recipients later claim their shielded funds, which triggers commitment insertion into the Merkle tree.
Tracks Applied (3)
Privacy
Privacy
Base
BEST Overall Project
Technologies used
Cheer Project
Cheering for a project means supporting a project you like with as little as 0.0025 ETH. Right now, you can Cheer using ETH on Arbitrum, Optimism and Base.