Privacy That Works for Crypto
Earlier this year, the Ethereum Foundation’s Privacy and Scaling Explorations team published findings from a long stretch of user research on private transfers. The report was not a ranking of privacy systems, but it surfaced recurring blockers: fragmented anonymity sets, weak DeFi composability, poor wallet support, disclosure complexity, and cost.
The full piece is worth reading, but the picture it paints is clear. Privacy in crypto has become separate from public networks. It lives in fragmented environments with siloed anonymity sets, different wallets, and limited DeFi composability. Truthfully, privacy products sit at a distance from how people actually use crypto.
These are not bugs in any specific product. They are the recurring downstream effects of one architectural pattern: building privacy as a separate environment that users have to travel to.
STRK20 takes the opposite bet. Privacy should be a property of the assets and wallets people already use, not a place they have to go.
The pattern in the research
The pattern matters because these problems compound. Anonymity sets were bounded by whoever happened to be inside a given private environment at a given time. Liquidity was forced to split between a public version of an asset and a wrapped, shielded version somewhere else. Wallets struggled to expose private flows in ways that felt native, so users were pushed into specialist interfaces with separate mental models. Composability with the rest of DeFi was weak enough that a private action usually ended a user’s session rather than continuing it.
The reason these symptoms keep recurring is that they share a cause. When privacy is built as a parallel environment, every interaction with it requires a context switch, the anonymity set is structurally smaller than the asset it shadows, liquidity splits, and integration becomes a second stack rather than a first-class one. The cryptography inside those environments can be excellent, but location still matters.
What STRK20 does differently
STRK20 is the privacy capability going live on Starknet in June. The system is built on a canonical privacy pool that holds encrypted notes rather than transparent balances. Wallets construct private transactions off chain, an operator generates the proof, and the Starknet sequencer verifies it before updating the pool’s state. From the outside, observers see only encrypted notes and nullifiers; sender, receiver, and amount are hidden onchain. Each transaction is designed to finalize in one to three seconds at under ten cents.
The architectural choice that matters most for positioning is that STRK20 is not a separate network. It is a property applied to any ERC-20 asset on Starknet, enabled from the wallet a user already has and connected to the same DeFi environment public transactions already use. Privacy stops being somewhere a user goes and starts being something an asset can do, which changes the shape of every problem the PSE research identified.
The swap problem: privacy that survives execution
One of the clearest patterns in the PSE research was how quickly privacy breaks down when users try to do more than hold or transfer privately. In many designs, using an asset in DeFi still means moving between private and public states: unshield, execute, then reshield. Each transition between public and private opens a window where intent becomes visible and others can react, leaking the privacy the user came for in the first place.
STRK20 collapses that sequence into a single atomic action that constructs and settles the swap against public AMMs on Starknet, with no intermediate public state for anyone to observe or front-run. The result is private execution against shared, public liquidity, the combination most isolated privacy environments cannot produce.
This is also why STRK20 does not require a parallel DeFi stack. Private and public assets coexist in the same ecosystem and interact through the same protocols.
The wallet problem: opt-in from the app you already use
PSE identified lack of native wallet support as one of the recurring blockers. Wallets often could not surface private flows in a way that felt native, so users were pushed into separate apps with separate mental models, and most never came back.
STRK20 is built as a wallet-native capability. Users opt in from within the wallet they already use and transact through the same flows they already know, while the cryptographic work happens behind the interface. Proofs are generated at the operator level so users do not have to run heavy local proving software, and a paymaster covers gas so transactions do not have to be funded from an identifiable public account. Spending authorization still requires the user’s own signature, which means delegating proof generation never delegates custody.
The integration problem: an SDK, not a second stack
Another recurring finding was that privacy remains hard for developers to integrate into normal application flows.
For developers working with STRK20, the integration story is an SDK rather than a parallel runtime. Note discovery, proof generation, note merge and split, transfer construction, and viewing-key management are abstracted into wallet-side primitives, and existing ERC-20 issuer controls and asset policies continue to apply. Integrating privacy does not require rewriting an application or rebuilding its liquidity model.
A team that has to learn a new runtime, new token standards, and new liquidity venues will usually not start; a team that can support a new property on assets it already handles is much more likely to ship.
The compliance problem: disclosure that works under real conditions
Operational and compliance friction was one of the clearest blockers in the PSE research. The issue is not only whether activity can stay private from the public, but whether relevant information can be disclosed under legitimate process when required.
Many systems only solve part of this. Some rely on users voluntarily sharing viewing keys. Others can prove a specific deposit-withdrawal link, but not activity through the pool. Proof-of-innocence models can also have a timing gap if funds move before they are flagged.
STRK20 is designed with disclosure built in from the start. Each user has a viewing key relating to their private history – the viewing key is held by an independent audit firm. Pursuant to lawful requests, a specific user’s activity can be reviewed through a threshold-controlled process without exposing the broader pool.
For institutions, this is the difference between privacy that is technically possible and confidentiality that can be used operationally.
The shift: privacy where crypto happens
The reframe STRK20 offers is consequential without being complicated. Privacy is not its own ecosystem; it is a property that an asset, a wallet, and an application can have. Once it is located that way, the recurring problems in the PSE research stop being independent failures and start to look like symptoms of putting privacy in the wrong place.
None of this would be possible without the cryptographic and systems work the privacy research community has produced over the past several years. The deployment pattern, though, is the part that has to change. Privacy that works for crypto is not another sealed environment beside the public one. It is privacy inside the assets, wallets, and applications people already use.
Source: https://pse.dev/blog/private-transfers-engineering-user-research
Disclaimer:
This content is for informational purposes only and should not be construed as investment, legal, or financial advice. It does not constitute an offer to sell or solicitation to buy and is not an endorsement of any product. Participation involves risk. Users should do their own research and/or consult with qualified professional advisors before making any decisions.
Participation in strk20s will involve screening at points of entry and exit and complete privacy cannot be guaranteed since certain activity may be visible through a viewing key (where required for regulatory purposes).
