Privacy on public blockchains has arrived. The harder problem has been making it work with the rest of the financial world. 

The choice has always been binary. Complete privacy meant complete isolation (secrecy), off-limits to regulated businesses and cut off from the financial system. But with full transparency it meant every balance and payment exposed, unworkable for most real financial activity.

STRK20 went live recently, ending that trade-off. This article is about the harder half of the design: compliance. A necessary design feature, because privacy that works for crypto has to work for the world crypto operates in.

The Need for Compliance

Privacy without compliance is a walled garden. When illicit funds can be hidden, laundered or moved without any path to investigation, exchanges, issuers and applications are forced to treat the entire system as a risk. Tokens get delisted, off-ramps get shut down, integrations get switched off. The privacy may be complete, but everything worth connecting to disappears and with it, the point of the product/network. 

Compliance also protects users directly. Without it, assets can be blocked by issuers or exchanges for commingling with illicit funds. That’s what happened with Tornado Cash and the fallout hit every user, including those willing to put up with the usability hurdles of a fully private system.

The only viable design, then, is one that maximizes confidentiality while enabling compliance. That’s the design principle STRK20 was built to meet: privacy that works for crypto.

The Risks of Alternative Approaches

  1. Opt-in viewing keys (used by some Zcash-style systems): If even one user doesn’t opt in, there is no compliance. From a regulator’s perspective, this is equivalent to having no compliance at all.
  2. Proofs of Innocence (Railgun / 0xBow, championed by Vitalik): Users get screened at deposit and must prove at withdrawal that their funds came from a clean address. The problem: a bad actor deposits, waits an hour for screening to clear, withdraws with a clean proof, and five hours later their address is flagged—but the funds are already gone. The model only works if funds are flagged while still inside the pool, and flagging is rarely that fast. No regulator has endorsed this as sufficient, though it is considered the current “state of the art” in the absence of a better solution.
  3. Canton-style Network of Distributed Ledgers: An enterprise-grade system that functions as a SWIFT equivalent for corporations—trusted, gated, and centrally operated. Good for institutions transferring funds between themselves, but not Web3-compatible. It doesn’t give users access to the richness of a public DeFi ecosystem. It competes in the institutional domain, not in the blockchain space.

Starknet’s Solution

At a high level, Starknet’s solution screens users on deposits, and then introduces a viewing key that can be used to decrypt transaction histories in response to lawful requests. The initial screen attempts to prevent bad actors from entering the pool, while the viewer key enables targeted disclosure after transactions have occurred. The solution is based directly on “Haze and Daze: Compliant Privacy Mixers,”  a paper co-authored by StarkWare PhD developer Maya Dotan, and adds a number of important components. 

Each user must create a viewer key in order to deposit into the pool and generate a proof that this was done correctly. Without this proof, a wallet cannot interact with the privacy pool. Viewer keys are then encrypted to a master key.

The master key is held inside a dual-enclave TEE operated by Financial Privacy Inc, also known as FPI. The company specializes in secure custody of audit keys, and was founded by the team behind QEDIT, a pioneer in zero-knowledge cryptography for enterprises. FPI’s architecture was recently cited in a February 2026 research note from the Royal United Services Institute, the UK defense and security think tank, as a practical model for privacy-enhancing technology in regulated finance.

The master key is also backed by a 3 out of 4 multisig contract with two signatories from StarkWare and two signatories from FPI. Finally, as a redundancy measure, another 7 out of 12 multisig backup for the master key is controlled by the Starknet Security Council. The Starknet Security Council also has upgrade capabilities for the smart contract that controls the privacy pool. Any changes to the compliance model requires 7 out of 12 signatures from the Starknet Security Council.

A viewer key is designed to disclose only the information strictly necessary to respond to a legitimate lawful request, while all other information remains private. Unlike other solutions, viewer keys in the STRK20 privacy pool support scoped disclosure of specific information, rather than exposing all information automatically associated with a key. For instance, if law enforcement requires disclosure of a specific counterparty transfer during a defined window, FPI reencrypts that one transfer inside the enclave to the appropriate authority, and nothing else.

What amounts to a lawful request? This is a request, order, or demand: (i) that is issued by a court, regulator, competent law-enforcement agency or governmental agency; (ii) where such body must be acting within its jurisdiction and lawful powers; (iii) which is properly authenticated and made through an official channel by an identified, authorised representative of that body; and (d) where the legal basis for the request has been identified & verified. Financial Privacy Inc operates the legal review processes for this determination.

For more technical and operational details, check out the Starknet privacy whitepaper.