Privacy and Compliance Aren’t Enemies

The most-private financial instrument in the world is also the most regulated. The framing of these two as adversaries is a category error inherited from a pre-cryptographic era. Anyone telling you ot

I want to start with a number.

There are roughly $2.3T in U.S. paper currency in active circulation. Not in vaults — in circulation, in wallets and registers and shoeboxes and under mattresses, moving from hand to hand without a counterparty record at any of the transitions. That instrument is the most-private financial instrument the modern American economy has produced. It is also one of the most regulated. The Bank Secrecy Act applies to cash. The Currency Transaction Reporting threshold applies to cash. Suspicious Activity Reports apply to cash. AML works against cash. It works well enough that the bulk of cash movement that should be reported is reported, and the bulk of laundering attempts that depend on cash get caught.

Read that sentence again. The most private instrument in the system is also the instrument compliance was first written for, and the system runs.

So when somebody tells you privacy and compliance are at war — that you have to pick one, that crypto’s privacy properties are inherently incompatible with regulatory oversight, that any system with default privacy is by construction a money-laundering machine — they are telling you something cash falsifies on its face every day, in every state, in every retail transaction, in every cash-deposit ticket walked into a teller window with a reasonable explanation.

The framing is wrong. This post is about why, and about what regulators actually object to (it isn’t privacy), and about what zero-knowledge cryptography lets you build that no prior generation of financial technology could.

What’s on the table

• U.S. paper currency in circulation: ~$2.3T, the most-private instrument in the system, the same system AML works in

• FATF Recommendation 16 (the “Travel Rule”): originator and beneficiary information transmitted with transfers above a threshold. Designed for wires. Specified before ZK existed

• FinCEN guidance on CVCs (convertible virtual currencies): focuses on Money Service Business obligations, source-of-funds attestation, sanctions screening. Almost none of it requires identity revelation when ZK can prove the underlying property

• StableZK’s view-key model: every account holder can issue a scoped view key to a third party (auditor, accountant, regulator with cause). The view key reveals exactly the slice of state the holder authorized. No master key exists

• ZK compliance attestations in StableZK: source-of-funds proof, sanctions-screening proof, jurisdiction-of-residence proof, tax-basis computation, large-transfer reporting. Each is a proof that the property holds without revealing what underlies the proof

• The migration path: Phase 1 Groth16 (production today, not quantum-resistant), Phase 3 STARK / lattice (the destination, quantum-resistant). Compliance attestations move with the migration

❦ ❦ ❦

The problem

The framing of privacy versus compliance as adversaries got baked into financial regulation in the pre-cryptographic era because, in that era, it was true.

Before zero-knowledge proofs, the only way to verify a property of a transaction was to see the transaction. The only way to verify that the originator wasn’t on a sanctions list was to know who the originator was. The only way to verify that the funds had a legitimate source was to see the chain of custody. Privacy and verification were fundamentally at odds because verification meant disclosure. Compliance regimes inherited that constraint because they had no other option. The regimes are not stupid. They were built against the cryptography of their time.

Cash got carved out of the worst of this through a different route. Cash is not infinitely divisible by counterparty record because nobody asks you for the counterparty record. The implicit deal is: we accept lower auditability per transaction in exchange for the friction of physical handling, which makes large-scale laundering operationally hard. That deal worked because cash has bandwidth limits. You cannot move $50M in suitcases without somebody noticing the suitcases. The compliance regime around cash is structured to catch the suitcases, not the singles.

Crypto’s first generation broke that deal in both directions. It removed the bandwidth limits — you can move $50M in a transaction with no physical correlate at all — and it also removed the privacy, because the public ledger is a counterparty record by default. So compliance regimes responded the way they were trained: more disclosure, harder identity gates, KYC at every on-ramp, off-ramp, and venue. The result is a system where users have neither cash’s privacy nor banking’s regulatory clarity. The worst of both worlds, by design, because the framing assumed those properties were a tradeoff.

Then zero-knowledge proofs arrived in production and the assumption stopped holding.

Here’s the part I want you to read precisely.

A zero-knowledge proof of a property does not require revealing the underlying state. Every regulatory ask that previously required disclosure can be reformulated as a property to be proved. Are you on the sanctions list is a property. Did your funds come from a non-sanctioned source is a property. Is your aggregate annual transfer below the reporting threshold is a property. Are you a tax resident of a jurisdiction that requires you to file is a property. Every one of these can be proved cryptographically without the holder revealing identity, transaction history, counterparty list, or balance.

Which means the compliance regime can ask the same questions it has always asked — and get the same answers — without the disclosure that previously came as the price of the answer.

That is the whole insight. The compliance regime is unchanged. The disclosure surface collapses.

What regulators actually object to

I worked for a bank regulator. I have spent a lot of time in rooms with other bank regulators. The thing I will tell you, having sat in those rooms, is that regulators do not object to privacy.

What regulators object to is the inability to enforce the law when there is probable cause. They object to designs where, when the warrant arrives, the records do not exist. They object to designs where their tools — sanctions enforcement, AML enforcement, tax enforcement, court orders — cannot reach the relevant slice of state because no slice exists or because the slice cannot be authoritatively produced.

This is a different objection from “we want to see everyone’s transactions all the time.” It is an objection that says: for the small fraction of cases where lawful enforcement is warranted, the system has to be able to produce what’s needed. The number of cases where this kicks in is small. The default state of every other holder is privacy.

This is exactly the deal cash already operates under. Walk into a bank, deposit five thousand dollars in cash with a reasonable explanation, and the bank will accept the deposit, generate a CTR if applicable, and otherwise leave you alone. Get convicted of money laundering and the IRS can subpoena the bank’s records of your deposit. The deal is default privacy with selective disclosure on cause. It has worked for a hundred years.

The deal does not require a master key. It does not require everyone’s transactions visible to everyone all the time. It does not require KYC on every micropayment. It requires that the system be capable of producing the right answer for the small fraction of cases where the law has cause. That is satisfiable cryptographically without recreating any of the disclosure surface that gave the prior framing its teeth.

The decision

StableZK ships a four-part regulatory architecture. None of it requires a master key. None of it requires identity revelation by default. All of it satisfies the compliance asks that actual financial regulators have actually made.

One. The view-key model. Every account holder can issue a scoped view key to a third party. The scope is set by the holder: a specific time range, a specific counterparty, a specific category of transaction. The view key reveals exactly the slice of state the holder authorized and nothing more. There is no master key. There is no protocol-level admin who can read accounts. The third party — auditor, accountant, regulator with a warrant — gets exactly what they were supposed to get and exactly nothing else. Selective disclosure with the holder in the loop.

Two. ZK compliance attestations. A holder can prove a property of their account without revealing the account. I am not on the OFAC sanctions list, proved against the published list, with no identity revelation. My funds were sourced from non-sanctioned counterparties, proved across the chain of custody, with no counterparty revelation. My aggregate transfers this year are below the FATCA threshold, proved against the holder’s history, with no balance revelation. The protocol ships a library of attestation circuits for the obvious regulatory asks. New asks are additive. The pattern is composable.

Three. The warrant model. When a court order with cause arrives at a regulated counterparty (an exchange, a custody desk, a fund), the counterparty’s compliance team uses its existing access to the account holders it serves to produce the slice the warrant requires. This is the same model banks already operate. StableZK does not introduce a new disclosure surface; it permits the existing one to operate cryptographically. The regulator does not need a master key on the protocol because the regulator already has subpoena power over the regulated counterparty.

Four. Suspicious-activity attestation. Regulated counterparties operating on StableZK can produce SAR-equivalent reports — large-transfer flags, structuring detection, sanctioned-counterparty proximity — using ZK attestations from the holder’s account, with the counterparty as the recipient of the disclosure. Same regulatory output. Different disclosure surface. The counterparty sees what they need. The protocol sees nothing.

The four pieces compose. A regulated exchange operating on StableZK can do its KYC at onboarding (off-protocol), accept ZK attestations from the holder during operation (on-protocol), produce SARs and CTRs for the regulator (off-protocol), and respond to warrants with scoped view keys against the holder’s account (on-protocol). Every regulatory output the existing system produces is producible. The protocol is not visible to the regulator and does not need to be.

What this looks like under the post-quantum decision

Compliance attestations are the place where the post-quantum migration matters most, and most quietly.

A regulator who accepts a ZK attestation today is accepting the cryptographic claim that the underlying property held at the time the proof was generated. If the proof system gets broken — by a quantum capability or any other classical break — the attestation becomes retroactively unsound. Every “I was not on the sanctions list” proof in the chain history becomes a proof of nothing in particular.

This is the worst kind of cryptographic failure to inherit. Compliance attestations are exactly the artifacts whose value depends on long-term integrity. A bank’s records have to be auditable for years after the transaction. A SAR has to be defensible if the case goes to court a decade later. A tax-basis computation has to hold up to an audit five years out. The proofs have to outlive the proof system.

The path is the one Post 1 named. Phase 1 Groth16 in production today, with the acknowledged property that those proofs are not quantum-resistant. Phase 2 hybrid hash-based commitments alongside, buying integrity through the migration. Phase 3 STARK or lattice-based ZK end-to-end, quantum-resistant, with proofs that survive cryptographic regime change.

The cookbook chapter on the regulatory perimeter has the migration table. There is a recipe for re-attestation under primitive change — proofs generated under Phase 1 can be replayed under Phase 3 against the same underlying state, producing fresh proofs whose cryptographic integrity outlasts the original system. That recipe is non-trivial. It is also necessary. Without it, the compliance attestations have a shelf life. With it, they don’t.

What this isn’t

This is not a claim that ZK compliance is easier than the prior regime. It is harder. The circuits are non-trivial. The libraries are immature. The integration burden on regulated counterparties is real. There is real implementation work between we have ZK proofs and the FinCEN examiner accepts them as a substitute for transaction-level disclosure. Some of that work is technical. Most of it is institutional — getting the regulator’s tooling, training, and procedural confidence to a place where the proofs are accepted as sufficient. That is not a one-year project.

It is also not a claim that ZK compliance is complete. There are regulatory asks that don’t reduce cleanly to a property of a single account. Coordinated structuring across multiple accounts, for example, is a pattern that requires comparison across holders. The view-key model handles this through the regulated counterparty layer rather than at the protocol layer. That is a deliberate choice. The protocol’s job is not to be the regulator. The protocol’s job is to be a place a regulated counterparty can operate without the protocol itself becoming the disclosure surface.

It is not a claim that this satisfies every jurisdiction. The cookbook is explicit: the regulatory framework is a design, not a legal opinion. Specific jurisdictional implementations will be developed in collaboration with counsel in each relevant venue. What I will say is that the design is built to be implementable in jurisdictions that take regulator effectiveness seriously, and that the regulators I have spent time with — U.S. and otherwise — recognize the difference between privacy and opacity. They want privacy. They will not accept opacity. The design gives the first and rejects the second.

See also

• Post 1 — Inside the Quantum Window. Why the proof system has to migrate.

• Post 3 — Make the Waterfall Immutable Or Don’t Bother. Why “no master key” is structural, not a marketing line.

• Post 5 — The False Binaries. The pattern this is one instance of.

• Cookbook Ch. 6 — The Regulatory Perimeter. The full architecture, the per-jurisdiction notes, the FAQ for examiners.

Closer

I’m not selling a token in this series. The protocol token (SZK) exists in the design and there is no allocation being raised against the run of these posts. If that changes I will tell you, in plain text, in the post where it changes, before the rest of the post.

Pick a recipe. If you operate a regulated counterparty in this space — a bank, an exchange, a custody desk, a fund — read your current disclosure surface. Then ask which of those disclosures is required because the regulator needs the property to hold and which is required because the cryptography of 1985 had no other way to verify it. The first set is permanent. The second set is migrate-able. The migration is worth real money in lower disclosure liability and real customer trust in default privacy.

Anyone who tells you privacy and compliance are at war is selling you something. Usually a surveillance product. Sometimes a privacy product. Always something.

— Sultan