production hybrid I2I + I2U
Shielding
Enable confidential transfers by shielding balances, sender, and receiver, while still allowing regulators and auditors to verify via selective disclosure (viewing keys, proofs). The logic generalizes beyond ERC-20 to any transferable asset.
CR
Medium
Censorship Resistance
O
Partial
Open Source
P
Full
Privacy
S
Medium
Security
CROPS context
I2I
Between institutions, both counterparties have legal recourse and KYC-aligned identities. A shielded pool can be permissioned to institutional participants once the anonymity set is large enough to preserve unlinkability within the set. Shielding hides positions from competitors while viewing keys cover audit.
I2U
User is asymmetric to the operator. The shielded pool's CR must not depend on an operator who can block withdrawals. Forced withdrawal is required to make the privacy guarantee meaningful; without it, CR is effectively `low`.
Works best when
You need confidential transfer amounts and counterparties.
Selective disclosure or auditing is required.
Avoid when
Transparency is mandated by design.
Intent
Enable confidential transfers by shielding balances, sender, and receiver, while still allowing regulators and auditors to verify via selective disclosure (viewing keys, proofs). The logic generalizes beyond ERC-20 to any transferable asset.
Components
- Shielded pool contract stores commitments, the nullifier set, and a ZK verifier. Deployable on L1 or a shielded L2.
- Hash-based commitments (e.g. Poseidon) hide note contents; notes represent spendable state.
- Nullifier set prevents double-spends by tracking spent notes.
- Prover and verifier, with circuit logic authored in a DSL (Noir, Circom, Halo2, Gnark, etc.); the prover runs client-side.
- Wallet/KMS manages shielded keys and optional viewing keys.
- Relayer/paymaster (optional) for gas abstraction.
- Stealth addresses (optional, ERC-5564) for recipient unlinkability.
Protocol
1
[user] Deposit assets into the shielded pool contract. 2
[contract] Store the commitment submitted by the user in the commitment set. 3
[user] Construct a shielded transfer: generate a zero-knowledge proof that (a) nullifiers for spent notes are not already in the nullifier set, (b) commitments for spent notes are members of the commitment set, (c) the sum of output note amounts does not exceed the sum of input note amounts, and (d) the sender owns the spending keys. 4
[relayer] Submit the shielded transaction for gas abstraction (optional). 5
[contract] Verify the proof, add new commitments, and add spent nullifiers. 6
[auditor] Verify a specific transfer via the recipient's viewing key. 7
[user] Withdraw by proving ownership of notes and burning them. Guarantees & threat model
Guarantees:
- Hides amounts, sender, and receiver from non-participants within the anonymity set.
- Enables scoped disclosures to auditors via viewing keys.
- Anchors state on the underlying chain (L1 or L2) for integrity.
Threat model:
- Soundness of the zero-knowledge proof system.
- Non-censoring sequencer or validator set on shielded L2s.
- Non-compromised relayer and paymaster. The relayer sees raw transaction data (nullifier, commitment, proof) and can link user IPs to shielded activity even though the contents stay hidden. A colluding paymaster can selectively censor.
- Network-layer metadata (timing, gas payer, IP) is out of scope for the shielding layer; combine with network-level anonymity to cover it.
Trade-offs
- Cost and latency of zero-knowledge proofs (prover time, calldata/blobspace).
- Metadata leakage at the network layer.
- Gas abstraction is mandatory in practice: paying gas from the user's own EOA links the exit address back to the entry, breaking entry-to-exit unlinkability. A relayer or paymaster is required to break that link.
- Monotonic state growth: commitments accumulate indefinitely, so pool state bloats and proof costs drift up over time.
Post-quantum
high risk Vector: EC-based commitments (Groth16, PLONK/KZG) broken by CRQC; HNDL risk high for encrypted notes.
Mitigation: STARK-based shielded pools with hash commitments. See Post-Quantum Threats.
Example
- A user shields stablecoins into the pool, transfers them privately to a recipient, and the regulator later verifies the transfer via the recipient's viewing key.
Open-source implementations