Privacy compliance layer for onchain privacy apps

What this enables

• →Privacy apps that survive contact with regulators. Tornado Cash got OFAC-sanctioned because it had no compliance path — deposit anything, withdraw anywhere, no screening, no disclosure. Every privacy app since inherits that liability. A shared compliance layer gives any STRK20-built app deposit screening, sanctions screening, and authorized tracing under legal process without the app team rebuilding it from scratch.
• →Screening at the deposit, not the withdrawal. FPI (feed pull input) screening checks funds against sanctions and risk lists before they enter the privacy pool, so the anonymity set stays clean. Tainted funds are rejected at the door instead of being laundered through the set — the difference between a compliant privacy tool and a mixer.
• →Selective disclosure the account holder controls. Viewing keys let a user prove exactly what they need to prove — source of funds to a bank, income to a tax authority, aggregate spend to an auditor — and nothing else. Disclosure is scoped, cryptographic, and initiated by the holder or by authorized trace under legal process, never a blanket surveillance backdoor.
• →Institutional reporting without a custodian. A fund can generate a complete, tamper-evident report of its positions and flows for its compliance desk while those same positions stay unlinkable to the public. Proof of completeness via STARK proof means no fabrication and no omission — the report is verifiable, not asserted.
• →One integration, every privacy app. Instead of each protocol building bespoke screening and disclosure, they call one shared layer with configurable policies. A remittance app sets light-touch consumer thresholds; an OTC venue sets institutional KYC gates; a payroll tool sets tax-disclosure defaults. Same infrastructure, policy per app.

What you build

A Compliance module any STRK20 app can compose: an FPI screening contract that checks deposits against sanctions and risk feeds before shielding, rejecting or quarantining tainted inflows; a viewing-key registry binding disclosure capabilities to accounts and to authorized third parties; a selective-disclosure prover that emits STARK proofs of scoped facts (source of funds, aggregate balance, sanctions-clear status, transaction inclusion) without revealing the underlying private state; an authorized-tracing path that unwinds a specific flow only under a registered legal-process key, leaving everything else opaque; and a configurable policy engine where each integrating app declares its screening lists, disclosure defaults, threshold rules, and reporting cadence. The output is a set of contracts and an SDK surface, not an app — the compliance primitives every other RFP on this list plugs into.

Why this isn't per-protocol bolt-on compliance

Today every privacy protocol reinvents screening and disclosure in-house, badly and inconsistently. One app screens deposits, another doesn't; one supports viewing keys, another has no trace path at all. Regulators see a fragmented landscape with no common standard and treat the whole category as mixers. A shared layer means screening logic, sanctions feeds, and disclosure semantics are written once, audited once, and identical across every app that integrates — the difference between twelve half-built compliance stories and one that a regulator can actually evaluate.

Why this isn't doing it in-house

An app team building compliance in-house spends its scarce engineering on FPI feed integration, viewing-key cryptography, and trace-authorization plumbing instead of on its product. It ships late, ships incomplete, and carries the full legal liability of any gap. Consuming a shared, audited compliance layer turns compliance from a multi-quarter build into a dependency — the app declares its policy and inherits screening, selective disclosure, and authorized tracing on day one. The layer amortizes the hardest, highest-liability work across the entire ecosystem.

Why this is the shared standard

The strategic point isn't to build one more compliant app — it's to become the compliance standard for programmable onchain privacy. Privacy apps on other ecosystems have no compliance answer and can't get one without a layer like this. If every STRK20 app screens through the same FPI infrastructure, discloses through the same viewing-key model, and traces through the same authorized path, that convention becomes the reference implementation regulators and institutions point to. Owning the compliance standard is how the entire private stack stays legal at scale.