Compliance Architecture

Overview

Whop's privacy stack maps onto existing US regulatory regimes. Privacy and compliance are designed together, not bolted on after the fact.

The core claim: privacy and compliance are not in tension on Whop. They are designed together. The compliance mechanism for each privacy zone is built into the cryptographic protocol itself. It is not a policy layer that can be bypassed, manipulated, or selectively enforced.

The Three Zones

Zone 0. Public Payments (default)

What is visible: Sender address, recipient address, amount, timestamp. Everything.

Technical basis: Standard Aptos L1 transactions. No modification to default behavior.

Performance: Sub-second finality. 30,000 TPS capacity. Consistent low latency under extreme demand (Block-STM v2).

Regulatory treatment: Fully transparent. All transactions verifiable onchain by any party including regulators. No AML or reporting obligations beyond standard crypto transaction monitoring.

When it applies: All Whop transactions unless the buyer or seller explicitly opts into privacy. Public leaderboard signal callers who want verifiable track records use Zone 0 by default. Any trade where the trader wants their performance publicly attributed uses Zone 0.

Default position: Zone 0 is the default for all transactions unless a product is tagged as privacy-eligible or the buyer manually selects a higher zone.

Zone 1. Confidential Assets (AIP-143)

What is visible: Sender address, recipient address. Addresses are always public.

What is hidden: Transfer amounts and token balances. Once a user participates in any confidential transfer, their balance becomes hidden from all observers.

Technical basis: Twisted ElGamal homomorphic encryption. The homomorphic property allows balance updates to be computed on encrypted values without decryption. The new balance is encrypted_balance + encrypted_transfer_amount without any party seeing plaintext values. ZK range proofs (Bulletproofs) verify that the encrypted balance remains non-negative after a transfer without revealing the balance.

Auditor key mechanism: Every confidential token has a designated auditor key, set by the token issuer at deployment. The auditor key holder can decrypt any transaction amount or balance on demand. This is the compliance unlock. Regulators with legal authority can access amounts through the auditor key process.

Regulatory treatment:

• ›Bank Secrecy Act (BSA): The $10,000/day threshold for Suspicious Activity Reports (SARs) is handled through the auditor key. Transactions at or above this threshold can be reviewed by the designated auditor (which could be a compliance officer, a regulated financial institution, or law enforcement with appropriate legal authority).
• ›Know Your Customer (KYC): Zone 1 preserves sender/recipient visibility. The identity layer is unchanged. KYC continues to apply at the address level through standard Aptos identity mechanisms.

When it applies:

• ›Copy trading fee streams (subscriber paying signal caller. Amount private, relationship visible)
• ›Terminal data stream subscriptions (amount private, subscription relationship visible)
• ›Vault revenue distributions (pro-rata amounts private, vault membership visible)
• ›Decibel margin posting (position sizing hidden from competitors, address visible)
• ›Feed article metered payments (per-paragraph charge private, reading relationship visible)

Important: Zone 1 is pending governance approval as of April 2026. TypeScript SDK is live, but protocol activation requires governance vote.

Zone 2. UTT Invisible Assets

What is visible: Nothing. Neither sender, nor recipient, nor amount appears onchain. An external observer sees: (a) a Merkle tree of sealed coin commitments, (b) a nullifier set of spent markers. Both sets of values are computationally indistinguishable from random group elements without the owner's secret key.

Technical basis: UTXO (Unspent Transaction Output) model. Unlike Zone 1's account-based model, every UTT coin is an independent sealed object. A Pedersen commitment C = Commit(pk, sn, v) where pk is the owner's pseudonymous ID, sn is a secret serial number, and v is the value. Spending a coin requires producing a ZK proof (Groth16 on BN254 curve) that proves ownership without revealing any component.

The nullifier construction: $nl = sn^(1/sk)$

where sk is the owner's secret spending key. The nullifier is deterministic (same coin always produces the same nullifier, preventing double-spend) and unlinkable (third parties cannot connect a nullifier to a coin without both sk and sn). The cryptographic construction uses the Dodis-Yampolskiy PRF with a Σ-Protocol and Fiat-Shamir transformation for the zero-knowledge component.

Regulatory treatment:

• ›

  IRS: The $600/year threshold for reportable income is addressed through the monthly anonymity budget cap. Every UTT user has a budget coin. A UTXO that tracks their remaining monthly anonymous transaction capacity. When a transaction is submitted, the ZK circuit enforces: budget_new = budget_old - amount >= 0. Above the monthly cap, transactions either go through Zone 0 (fully public) or through threshold auditing (k-of-n key holders collectively can review). A user attempting to launder $100,000 at a $10,000/month cap would require 10 months minimum.

• ›

  BSA: The monthly budget cap works as a structural AML control. The cap doesn't need to be $10,000/day exactly. It can be configured per product or per user tier. A professional trader with KYC'd identity might have a higher cap than an anonymous retail user. The cap is enforced by the ZK circuit, not by policy.

Why this is not a mixer:

• ›Tornado Cash breaks the address link entirely. Deposit from wallet A, withdraw from wallet B
• ›UTT doesn't break address links. It hides them. There is no deposit/withdraw pattern. Coins are created (via minting with a PS signature from the threshold mint authority) and spent (via the ZK circuit). The conceptual model is digital cash, not a tumbler.
• ›UTT has a monthly anonymity cap. Tornado Cash had none.
• ›UTT has a designated auditor mechanism for threshold review. Tornado Cash had none.
• ›The Bank of Israel accepted UTT for CBDC privacy research. This is the institutional stamp that matters most for the pitch.

When it applies:

• ›Large spot orderbook positions (whale accumulating a BTC position)
• ›Signal caller trade entries (proof of prior entry without revealing position size)
• ›Vault capital pooling (contributor stakes invisible to competitors)
• ›Any trade where the trader specifically needs position size confidentiality

Deployment status: Unreleased on Aptos. Requires one governance vote to set the Groth16 verifying key parameters and IBE master key. All cryptographic primitives needed (Groth16, BLS12-381, Ristretto255) already exist in the Move VM from AIP-143 deployment.

Privacy Selection Recommendation Engine

Non-crypto users cannot be expected to understand the technical distinction between Zone 0, 1, and 2. The Privacy Selection Recommendation Engine handles zone selection automatically.

How It Works

Product tagging at listing: Every Whop product gets tagged with a recommended privacy zone by the creator when listing. Whop auto-classifies products that creators don't tag. The classification logic:

• ›Signal group with public leaderboard intent → Zone 0 (transparent track record building)
• ›Indicator subscription (amount private, performance public) → Zone 1
• ›Vault with institutional capital → Zone 2 (position size confidentiality)

Transaction routing flow:

When a transaction is initiated:

1. 02System reads the product's privacy tag
2. 04Checks the buyer's remaining anonymity budget for their preferred zone
3. 06Recommends the appropriate zone based on product type + budget availability
4. 08Buyer confirms (or overrides to a different zone)
5. 10Transaction routes to the selected zone

Buyer override: Buyers can always select a higher privacy zone than the product's default. A retail trader using a Zone 0 signal group can still execute their own copy trades through Zone 2 if they want position size privacy.

The UX principle: Privacy decisions are made at the product level by creators and at the transaction level by buyers, not by forcing users to understand cryptographic zones. The system presents a single confirmation step. "this trade will be private/confidential/public". And the routing happens automatically.

The Configurable Compliance Argument

This is the argument for institutional and banking clients:

Traditional financial privacy tools (numbered accounts, offshore structures, shell companies) all share a fundamental flaw: they rely on human decisions and jurisdictional arbitrage. A bank can decide not to honor a subpoena. A jurisdiction can change its laws. A trusted party can be compromised.

Whop's privacy architecture relies on neither:

Zone 1 compliance (CA): The auditor key is a mathematical key, not a policy. The token issuer sets the auditor at deployment. If the issuer is a regulated financial institution, the auditor key is held by the compliance function under standard financial regulation. There is no policy layer that can decide to "forget" a transaction. The key exists or it doesn't.

Zone 2 compliance (UTT): The monthly anonymity cap is a ZK circuit constraint. It cannot be increased by anyone except through a governance vote that changes the circuit parameters. There is no compliance officer who can be pressured, bribed, or subpoenaed to grant an exception. The math enforces the cap.

This is the framing for PNC Bank and similar institutions: compliance that is enforced by math is more reliable than compliance enforced by policy, because policy depends on humans who can fail.

The Bank of Israel Precedent

UTT was deployed in a testing pilot with the Bank of Israel for digital shekel research. This is the most important institutional validation for the compliance story.

Central bank digital currencies (CBDCs) have the strictest AML/KYC requirements of any financial product. The Bank of Israel studied UTT specifically because it was looking for a privacy mechanism that could satisfy CBDC privacy requirements without compromising regulatory oversight.

UTT's monthly anonymity budget cap was the specific feature that made it acceptable for CBDC consideration. The cap gives normal users everyday financial privacy (equivalent to using physical cash for small purchases) while making large-scale illicit use mathematically impractical.

The Bank of Israel precedent supports the compliance arguments for Whop's use of the same system.

Compliance by Product

Programmable Compliance

The Whop privacy architecture demonstrates programmable compliance. Compliance as a feature of the cryptographic protocol itself, not a policy layer added on top.

1. 02Lower cost. Automated transaction monitoring at the protocol level vs human review
2. 04Lower risk. Math doesn't make mistakes, but policy implementations do
3. 06Cross-border. Auditor key mechanism is jurisdiction-configurable
4. 08Bank of Israel precedent. Central bank's implicit endorsement of the privacy-with-compliance model

Outstanding Compliance Questions

Before Whop goes to market with Zone 2:

1. 02

   Governance vote timing. The verifying key parameters for the UTT circuit need to go through Aptos governance. What is the expected timeline?

2. 04

   Auditor key governance. Who holds the Zone 1 auditor key? Whop as a company? A regulated third-party custodian? The answer affects how regulators view the compliance mechanism.

3. 06

   Threshold audit k-of-n. For Zone 2 transactions above the monthly cap, who holds the k-of-n key shares? The current design assumes a threshold committee model. What is the specific governance structure?

4. 08

   KYC at the application layer. Zone 2 hides identities at the protocol layer. But Whop's application layer has KYC'd users (Whop account onboarding). The relationship between protocol-layer identity hiding and application-layer KYC needs to be clearly documented for legal.

5. 10

   International regulatory variation. The BSA and IRS thresholds are US-specific. Non-US users on Whop are subject to different reporting regimes. The compliance documentation needs jurisdiction-specific treatment.