Great proposal — glad to see more conversations around making ERC20 assets privacy-capable.
Our team has been building privacy infrastructure on Base for several months, and we’ve actually fully implemented and deployed a wrapping-based privacy system similar to what’s being proposed here.
(ZeroLayer is currently live on Base Sepolia and supports wrapping ETH and any ERC20 into private assets.)
After building, deploying, and testing this model, we found several important insights that may be useful for this discussion:
- Wrap-based privacy works, but creates real UX fragmentation
Users end up managing two representations of the same token:
public ERC20
private wrapped version
Even with a smooth UI, users often get confused about:
“Which balance do I actually have?”
“Where is my real supply stored?”
This creates friction for adoption.
- Supply is still “split” between two contracts
Even with correct supply invariants, the model inherently creates:
ERC20 public supply
wrapped private supply
This complicates accounting and increases the surface for implementation mistakes.
- DeFi composability becomes indirect
The wrapped form cannot be used directly inside DeFi unless integrations explicitly add support for it.
This pushes additional work to every DeFi protocol instead of giving them a unified standard.
- These issues eventually motivated us to explore a unified (“dual-mode”) token model
After deploying the wrap approach and observing user feedback, we came to the conclusion that privacy should ideally live inside the token standard itself, not as a wrapper contract.
This led us to draft a proposal for a Dual-Mode Fungible Token, where a single token natively supports:
a public mode (ERC20)
a private mode (ZK commitments)
seamless switching between the two
consistent total supply tracking
Our draft is here for anyone interested in the comparison:
- Wrap-based privacy and dual-mode privacy can coexist
I believe the wrap model is extremely valuable especially for existing tokens that cannot upgrade.
Dual-mode tokens, on the other hand, benefit new tokens that can launch with native privacy built-in.
Both approaches are valid and useful, depending on the context.
Just wanted to share our practical learnings from having a live wrap-privacy implementation — hope this helps the discussion move forward.
Happy to collaborate or share deeper technical details if helpful.