Privacy Deep Reference

Advanced cryptographic details for the privacy primitives described in the Privacy Stack overview.

Encrypted Mempool: Pre-execution Privacy

The encrypted mempool is a separate Aptos primitive from CA, UTT, and ACE. It operates at the consensus layer, before any of the other privacy tools apply.

The problem it solves: On a standard mempool, validators and observers can see transaction contents before they're ordered into a block. A validator watching the mempool can see "this transaction is a large BTC buy at $95K" and front-run it by inserting their own order first, extracting MEV before the original order lands on the book.

How it works: Transactions are submitted encrypted. Validators commit to an ordering of ciphertexts before decrypting. Once the ordering is committed (and therefore immutable), the decryption keys are released and execution proceeds. By the time anyone can read the transaction content, the execution order is already locked. Front-running requires knowing the content before the order is fixed. Encrypted mempools break that.

The mechanism: Threshold decryption. The decryption key for each block's transactions is held in shares by validators, released only after consensus on ordering. Similar to how Flashbots SUAVE works on Ethereum but native to Aptos consensus.

Archon complication: Aptos's Archon multi-leader architecture creates a timing coordination problem. With multiple concurrent block proposers, threshold decryption needs to coordinate across leaders without introducing latency. This is the unresolved engineering challenge.

Status: Proposed October 2025, pending governance vote. Not live on mainnet. For Whop, this is the layer that protects order flow before it hits the BigOrderedMap. CA and UTT handle privacy after execution. The encrypted mempool handles privacy before.

Threshold Mint Authority for UTT

Every UTT coin carries a Pointcheval-Sanders (PS) signature from the mint authority. PS signatures are specifically chosen because they can be verified inside a ZK circuit without revealing the signature itself. You can prove "I have a valid mint signature on this coin" without exposing the signature to the verifier.

Why threshold: If the full PS signing key were compromised, an attacker could mint arbitrary UTT coins with arbitrary values. These coins would be indistinguishable from legitimate ones: valid Pedersen commitments with valid PS signatures. This is an existential risk to the system.

How it works: The PS signing key is split into shares across a k-of-n committee. To issue a new coin, k parties must cooperate to produce partial signatures that combine into a valid PS signature. If fewer than k parties are available or compromised, no new coins can be minted.

Who holds the shares for Whop: The most defensible architecture for launch is 2-of-3: Aptos Labs (protocol developer), Whop (operator), and a regulated third-party custodian (Fireblocks or similar). This mirrors the ACE committee trust model. Institutional clients will ask about this immediately.

DeKART: Range Proofs Inside ZK Circuits

The UTT production circuit has ~14 constraints. Several of those are range proofs that verify values are non-negative: output coin values can't be negative (which would create money), the budget coin decrement can't go below zero, and the value conservation equation must balance.

Why not Bulletproofs: Bulletproofs work well as standalone proofs but are expensive when embedded inside a Groth16 circuit. Verifying a Bulletproof requires a multi-scalar multiplication (MSM) over a curve, and encoding that MSM inside a Groth16 circuit creates thousands of additional constraints just to verify the range proof within the outer proof.

What DeKART is: DeKART (Discrete-logarithm-based Knowledge of Range Technique, from Alin's research group) uses a lookup argument instead of MSM-based verification. It proves range membership using precomputed lookup tables that are cheap to verify inside an R1CS circuit (the constraint system Groth16 uses). The result is range proofs that add a small, predictable number of constraints rather than thousands.

Why it matters for UTT: Without DeKART, the range proofs would dominate the circuit size. With DeKART, the full production circuit stays at ~14 constraints. Smaller circuit means faster proving time (~1-2 seconds on a laptop) and cheaper onchain verification.

Key Recovery for UTT

If a user loses their secret key sk, their UTT coins are permanently inaccessible. Unlike account-based systems where a wallet can be reconstructed from a seed phrase, UTT coins have no onchain address to recover to. The coins live in a global Merkle tree, associated with a pseudonymous public key derived from sk. Without sk, you cannot compute the nullifier for any coin, so you cannot spend it.

Three mitigation options:

• ›

  Derived keys from Aptos account (retail users). sk for UTT is derived deterministically from the user's Aptos private key using a one-way derivation (HKDF or similar). Recovering the Aptos account via standard seed phrase recovery also recovers the UTT sk. The risk is a single point of failure: compromised Aptos account means compromised UTT coins. But the UX is familiar and asking retail users to manage a separate UTT key backup is a non-starter.

• ›

  HSM custody (institutional vaults). sk lives in a hardware security module (Fireblocks MPC, AWS CloudHSM) that never exposes the raw key. Recovery is handled by the HSM vendor's key recovery procedures. This is the cleanest institutional answer.

• ›

  Encrypted backup with social recovery. sk is encrypted and backed up across a set of trusted parties. Recovery requires threshold cooperation from the backup set. Same model as Safe's social recovery wallet. Operationally complex but trustless.

ACE Worker Economics

Running an ACE worker requires a dedicated server and a dedicated Aptos fullnode. The worker must independently verify onchain permission state. It cannot trust a shared RPC because a malicious provider could return false permission results, granting decryption to unauthorized users.

Cost estimate per worker: Dedicated fullnode is $300-800/month on cloud infrastructure. The worker server itself is lightweight (IBE key operations and RPC calls). Total: ~$500-1,000/month per worker. For a 2-of-3 committee, that's $1,500-3,000/month.

Who pays: For Whop's metered Feed content, this cost is trivially covered by Whop as a platform operational expense. The per-paragraph revenue at any meaningful scale covers it easily. For time-locked signal pre-commitments where Aptos Labs and a neutral third party hold shares, those parties are running workers for protocol integrity reasons.

The unsolved incentive problem: For any ACE deployment where Whop wants an external party to run a worker and that party is not doing it for protocol integrity reasons, there's no designed compensation mechanism. Two options: Whop pays the external worker directly (a service agreement), or the worker earns a micro-fee per decryption request (ProofOfPermission issued). The first is simpler but makes Whop a counterparty. The second is more decentralized but adds UX friction.

The signal pre-commitment dependency: If Whop pays the neutral third-party worker and stops paying, the worker stops running, and signal pre-commitments can't unlock. The long-term solution is an Aptos Foundation grant to fund neutral workers as protocol-level infrastructure, ensuring the committee operates independently of any single party.

Three-zone Privacy Architecture

• ›Zone 0 (public): Known sender and receiver, sub-second finality, 30k TPS, all transactions visible unless opted out
• ›Zone 1 (Confidential Assets): Known sender and receiver, hidden amounts and balances. BSA $10K/day reporting threshold compliance via auditor key.
• ›Zone 2 (UTT Invisible): Sender hidden, UTXO model, amounts hidden, full trade graph hidden. IRS $600/year reporting threshold addressed via monthly anonymity budget cap and threshold audit above cap.

The compliance mechanism is different at each zone. Zone 1 uses an auditor key. The token issuer designates who can decrypt amounts. Zone 2 uses the budget coin. Compliance is enforced by the ZK circuit itself, not by policy or a human decision. This is why the Bank of Israel approved UTT: the anonymity cap is mathematically enforced, not contractually promised.

Privacy Selection Recommendation Engine

Most users don't know what Zone 0, 1, or 2 means. The Privacy Selection Recommendation Engine handles this automatically.

How it works (purchase flow):

1. 02Purchase Initiated
2. 04Read Product Tags (creator has tagged their product with a recommended zone)
3. 06Check Amount vs. Budget (system checks the buyer's remaining anonymity budget for their preferred zone)
4. 08Recommended Privacy Level surfaced to buyer
5. 10Buyer Confirms (or overrides to a different zone)

Product tagging: Every Whop product gets tagged at listing with a recommended privacy zone, or Whop auto-classifies based on product type. A vault run by a hedge fund → Zone 2. A retail signal group with a public leaderboard → Zone 0.

Zone mapping: Based on transparency/privacy assumptions of the product. A public indicator where the creator wants a verifiable track record → Zone 0 by default. A vault where contributors don't want their stake visible → Zone 2.

Buyer override: Buyers can always opt for more privacy than the product's default recommendation. The system nudges but does not enforce.

Transaction routing flow (once zone is selected):

1. 02Transaction Initiated
2. 04Reads Privacy Engine Config
3. 06Checks Remaining Anonymity Budget
4. 08Routes to Optimal Zone (Zone 0 / Zone 1 / Zone 2)
5. 10Transaction Done

Trade Splitting. Semi-private Trading via Randomness

Traders on Decibel perps or the spot CLOB can split trades across multiple accounts using 0x1::randomness, making it harder to attribute onchain activity to a single wallet. The trader's aggregate PnL is still provable via Reclaim zkTLS for verification (PnL cards, leaderboards), but no observer can easily reverse-engineer which addresses belong to them. Available today, no governance vote, no ZK circuits needed.

Speculative: composing UTT + CA privacy on the orderbook

This section describes a speculative composition of Aptos's privacy primitives onto a fully-onchain orderbook. It is not confirmed roadmap for either Decibel or the forthcoming Whop spot CLOB. UTT (Invisible Assets) is still research, AIP-143 Confidential Assets is pending governance, and no onchain CLOB to date has publicly committed to layering these onto order sizes or settlement flows. Documented here as a design target, not a shipping spec.

The four-layer model

If the primitives land at the protocol layer and an exchange chooses to compose all of them, the logical layout is:

Layer 1: Encrypted mempool (pre-execution). Hides transaction contents before block inclusion. Nobody sees an order before it lands on the book. Proposed October 2025, pending governance.

Layer 2: Public prices (on-book). Price levels and time priority visible, intentional, required for market-making efficiency and taker price discovery.

Layer 3: CA-hidden sizes (on-book). Order amounts encrypted with Confidential Assets (AIP-143). Observers see that a bid exists at $95,000 but not that it's for 14.3 BTC. Prevents size-based front-running.

Layer 4: UTT settlement (post-fill). Filled orders settle through UTT rather than a visible transfer. Nobody can link the settlement back to the trader's wallet or reconstruct a position history from chain data. The monthly anonymity-budget cap enforces compliance at the cryptography level.

Why margin stays on CA, not UTT. Perps margin requires constant incremental updates (funding debits, partial liquidations, cross-margin moves). UTT's UTXO model would require destroying and recreating a coin on every update, a ZK proof on every funding-rate tick is impractical. CA (account model, amounts hidden, easy in-place updates, auditor key) is the right layer for margin. This is why Decibel today uses CA for margin, and why margin does not belong on UTT even if settlement flows eventually do.

Signal-group timestamping via UTT nullifiers

A secondary speculative use of UTT in a trading context: a signal caller's entry uses a UTT nullifier, which fixes a cryptographic onchain timestamp. A call is not publishable until that nullifier is committed. The caller cannot publish first and execute after the move, cannot cherry-pick winners by hiding losers, and cannot forge the order of events. No signal-group product today enforces this, but it's the cleanest mechanism to solve the narrow Whop-specific MEV problem, callers front-running their own audience, if and when the primitive ships.

Both patterns above depend on primitives that are not yet live. Treat them as design targets for when UTT lands and an exchange chooses to adopt it, not as current product.

Confidential Atomic Transactions

The open question in onchain privacy: CA hides amounts in transfers, UTT hides the full trade graph. But how do you do private swaps, private multi-party settlements, or private DeFi transactions where multiple parties need to receive different amounts atomically without anyone seeing the split?

Confidential atomic splits use CA to distribute payments to multiple parties in a single atomic transaction. Each party sees their own share. Nobody sees anyone else's. No outside observer can infer the split percentages or the total.

How Whop uses this:

• ›Content Rewards distribution: Signal caller (50%), community (25%), indicator creator (20%), and Whop (5%) all receive their share in one atomic CA transaction. The split percentages are invisible to everyone except the parties.
• ›Vault profit distribution: When a vault closes a profitable position, pro-rata shares distribute to all contributors atomically. Each contributor sees their payout. Nobody sees anyone else's stake or return.
• ›Tiered commissions: A top-tier vault contributor earns a different commission rate than a standard member. Both receive their earnings in the same atomic transaction, neither can see the other's rate.
• ›Copy trading fees: The per-second CA stream from follower to signal caller is private. The rate is known only to the two parties.

Why this matters beyond Whop: This is the primitive for private DeFi on Aptos. Any protocol that needs to split revenue, distribute rewards, or settle multi-party transactions without revealing the economics to competitors or the public can use CA atomic splits. The mechanism is general purpose, not specific to Whop's products.