Privacy Zones

Privacy First with Sensible Compliance. Aptos is public by default. Privacy is an opt-in upgrade, turned on by the issuer or the specific deployment, through two primitives. Confidential Assets keeps the sender and recipient addresses visible onchain while the transfer amount and account balance stay encrypted. UTT (Invisible Assets) goes further: sender, recipient, amount, and balance are all completely private.

For compliance, an auditor key can decrypt UTT or CA transactions when regulators or the token issuer need to audit. Whop can set configurable anonymity budgets per user and per jurisdiction, so sensible privacy is preserved across Whop and the Whop Payments Network while each jurisdiction keeps its own compliance policy.

The framing is straight from the UTT paper by Alin Tomescu (Head of Cryptography at Aptos Labs). The paper's term of art is accountable privacy; sensible anonymity is the property the anonymity budget enforces: private by default, accountable when it actually matters. An issuer can attach an auditor key to a CA deployment, and a UTT deployment carries the configurable monthly anonymity budget in the ZK circuit itself. Neither requires operator trust or a kill switch, and neither is forced on users who don't need them.

Quick Reference

Confidential Assets (AIP-143) · deep dive

Hides amounts and balances using Twisted ElGamal homomorphic encryption and ZK proofs. Sender and receiver wallet addresses remain publicly visible. The key distinction from UTT is that addresses remain visible.

Once a user has participated in at least one confidential transfer, their balance becomes hidden. Neither the transferred amount nor the updated balances of sender and recipient are visible to external observers. Addresses are always visible. Only amounts are not. Timestamps are also not hidden by CA and remain public onchain.

The Auditor Key

Balances and transferred amounts are made confidential from every participant in the network except the intended recipient and the auditor. The token issuer designates an auditor who can decrypt amounts. Regulators can still verify when required.

Pending governance approval. TypeScript SDK live. Protocol-level feature, opt-in. Alin hosted an AMA on March 24, 2026, three days after posting the UTT blog post.

Whop Integration

Every payment on Whop can flow through CA. Subscription rates, per-use prices, royalty streams, creator earnings, and merchant payouts move with the amounts encrypted, so how much a user pays or a creator earns is private to the two parties and the issuer's designated auditor. Addresses stay visible, which is what makes ordinary payment reconciliation still work.

UTT (UnTraceable Transactions)

UTT is a cryptographic protocol for decentralized ecash with accountable privacy. Alin Tomescu began UTT research at VMware Research in 2018 while completing his cryptography PhD at MIT (2020), advised by Srini Devadas. The project was rebooted in 2021 and the paper, published in April 2022, was written by Alin Tomescu, Adithya Bhat, Benny Applebaum, Ittai Abraham, Guy Gueta, Benny Pinkas, and Avishay Yanai. Aptos Labs was founded in 2022 with a team that included Alin Tomescu, Josh Lind, and others from Meta/Diem. The research was presented at Stanford Blockchain Conference in 2023, at Yale, and at a16z directly, and was deployed in a Bank of Israel pilot for digital shekel research and integrated into VMware's Concord BFT system. Invisible Assets is Alin Tomescu and Josh Lind's implementation of UTT on Aptos.

Authors: Alin Tomescu, Adithya Bhat, Benny Applebaum, Ittai Abraham, Guy Gueta, Benny Pinkas, Avishay Yanai.

Key people status:

• ›Alin Tomescu: Head of Cryptography, Aptos Labs
• ›Ittai Abraham: Founding Engineer and Cryptography Researcher at Aptos Labs (now research partner at a16z crypto)
• ›Benny Pinkas: Bar-Ilan University professor, VMware Research affiliate 2017-2022. World's leading MPC/PSI researcher. NOT connected to Libra/Diem.

How It Works

UTXO coin model, not account-based like CA. Every coin is a sealed envelope: a Pedersen commitment C = Pedersen(pk, v).

Nullifier: nl = prf(i; sk_i) where i = leaf index in Merkle tree, sk_i = secret key. Uses Poseidon hash on BN254 field elements (ZK-friendly). Only the owner can compute the nullifier because sk_i is secret.

State: Append-only commitment tree (leaves are Pedersen commitments) plus a nullifier set. Neither structure is ever reduced, only appended to.

Frontier Merkle tree: storage grows as O(log n) in the number of leaves, which works out to about 1 KB in practice even at a billion leaves.

Nullifiers in Table: O(1) lookups, no full-set serialization.

1. 02sk_i is the secret key of pk_i
2. 04sk_j is the secret key of pk_j
3. 06nl_i = prf(i; sk_i)
4. 08nl_j = prf(j; sk_j)
5. 10v_i + v_j = v_A + v_B + v_gas

The full production circuit has ~14 constraints including PS signature verification inside ZK, output commitment integrity, range proofs (DeKART), anonymous credential, and budget UTXO.

Anonymity Budget. The Compliance Mechanism

Every user gets a budget coin. A Pedersen commitment in the same Merkle tree. When spending privately, the transaction is 3-in-3-out: two payment coins + old budget coin → two new coins + new budget coin (reduced balance).

The ZK circuit enforces: budget_new = budget_old - amount >= 0. The budget coin has its own nullifier. Can't be double-spent, can't be cloned.

At $10K/month cap: laundering $100M takes 833 years. Above the cap → public or threshold audited (k-of-n key holders). But the majority of users are under this amount and would not face any limitations for private payments. High-value users can request a raise to this anonymity budget, which can be raised based on existing compliance rules.

Two Aptos engineers led this work. Alin Tomescu, now Head of Cryptography at Aptos Labs, and Ittai Abraham, a Founding Engineer and Cryptography Researcher at Aptos Labs (now a research partner at a16z crypto), are both co-authors on the UTT paper alongside Benny Pinkas (Bar-Ilan), Benny Applebaum (Tel Aviv), Guy Gueta, and Avishay Yanai (VMware Research Israel). Israel has a very competitive talent landscape for ZK and MPC research, so clearing the bar for the Bank of Israel to pilot UTT for digital shekel work is an impressive feat in itself. The paper answered the question any central bank asks first: can we have privacy without giving up enforcement? The math says yes, and the anonymity budget is the answer.

The budget coin is a real UTXO. It gets destroyed and reissued with every transaction. It isn't a mutable counter that can be manipulated. It's subject to the exact same ZK circuit constraints as payment coins. You can't fake a higher budget balance by any means other than waiting for the next monthly reset.

The Unlinkability Property

An outside observer sees a Merkle tree full of sealed envelopes (commitments that look like a random group of elements) and a nullifier set of spent markers (which also looks like a random group of elements). There is no computable link between any nullifier and any envelope without knowing the owner's sk. The ZK proof establishes that link in the circuit without ever revealing it publicly.

This is why it's "invisible", not just amounts hidden like Confidential Assets (AIP-143), but the entire graph of who sent to whom is cryptographically erased.

CA is Account-based. UTT is UTXO-based.

CA gives every user a ConfidentialAssetStore resource. A balance record attached to their account address. The math operates on that balance homomorphically. The address is always visible because that's where the resource lives.

UTT has no per-user onchain state at all. All state lives in one global module resource: the append-only commitment tree and the nullifier set. No address is associated with any coin. Each coin carries a private serial number that only the owner knows. That serial number is what proves ownership and prevents double-spending, and it never touches the chain. Without it, a coin on the tree can't be linked to any particular person.

Deployment on Aptos

The Move module is deployed to the Aptos standard library, which is not a consensus-layer change. All primitives are already in the Move VM: Groth16, BLS12-381, Ristretto255, Bulletproofs. One governance vote is needed for the Groth16 verifying key and IBE master key params.

Block-STM manages read-write conflicts on UTTState, so private-payment throughput is lower than non-private payments but still lands in the 1k TPS range, high enough for the scale of Whop Payments Network.

ACE: Access-controlling Encrypted Data

ACE is the encryption layer for Shelby. It was built specifically to make token-gated content on Shelby possible: encrypt a blob, store it on Shelby, and program the access-control conditions inside a Move smart contract. If the contract says the requester is allowed, a distributed committee releases the decryption key. If it doesn't, nobody can decrypt.

IBE: Identity-Based Encryption

The point of IBE is that the "identity" doesn't have to be a wallet. It can be any canonical handle: an email address, a phone number, a Discord username, an Auth0 account. Encrypt a payload to [email protected] or +14155551234 or someuser#1234 and the holder of that identity can decrypt it once they prove the identity to the committee. A direct use case: an email blast to every Stripe merchant currently sitting on a hold balance or a rolling reserve, encrypted to their email, to onboard them into Whop or the Whop Payments Network. The email itself is the decryption key.

Three components:

• ›Committee: A set of worker endpoints that collectively manage decryption keys. No single party holds the full decryption key.
• ›ContractID: The unique identifier that binds an encrypted payload to the specific Move #[view] function that governs its decryption. When a user requests a key, the committee looks up the ContractID, runs the contract, and only releases a key share if it returns true. Without a matching ContractID there is no way to request decryption at all.
• ›ProofOfPermission: Signed proof that a user has onchain permission, which workers verify before releasing their key share.

Beyond Token-gated Content

Token gating relies on a server deciding to serve you. That server can be hacked, subpoenaed, or misconfigured. With ACE, the platform never holds the decryption key. The committee does. Even if Whop's infrastructure is fully compromised, the attacker gets ciphertext. Keys are distributed across the committee workers.

The ContractID can be any Move module with any #[view] function. A #[view] function is a read-only call that returns a value from onchain state without submitting a transaction or paying gas. The committee evaluates it at request time to decide whether to release a key share. Any condition expressible in Move can gate decryption, and the check is free and instant. A few examples for the Whop Feed and course creators:

• ›Time-lock. Lock a course drop until a specific block height. Nobody reads it early, not even the creator.
• ›Multi-condition. Require an active CA subscription AND a verified age attestation to unlock a premium community.
• ›Revocation. Cancel your payment stream and the contract returns false on the next check. No new keys are issued.
• ›Private gate. Use a CA payment stream as the condition itself. The gate works, but nobody onchain can see who is subscribed to what.

Private course access. The price of the course can stay hidden, so a creator can charge different prices per user without a publicly set number. Paired with UTT, the entire community can be private end to end, gate-kept by its existing members, with no onchain signal of who is in, who pays, or how much.

ACE Use Cases in Whop

Whop Feed: metered article reads The article's text content is ACE-encrypted before upload to Shelby, and tagged with a ContractID that points to the FeedPayment Move module. When a reader hits the article, the committee calls FeedPayment at that ContractID and checks if they have an active CA stream. Workers release key shares only while the stream is active. Once the reader cancels their payment stream, the contract reports no active subscription and the committee stops issuing new decryption keys.

For per-second metering: encrypt the article in sections (3-4 paragraphs per ACE domain). Each section has its own decryption domain. Reader pays per section they request. "Charged by the second while reading". Each scroll that reveals a new section triggers a micropayment and a new ACE decryption request.

Private .whop name messaging Alice encrypts a message with ACE, ContractID is an allowlist contract she controls with only bob.whop. She posts the ciphertext onchain. Bob requests decryption from the ACE committee, proves his address is bob.whop, gets the key. Encrypted DMs for .whop names, no Shelby needed.

Gated premium content (adult, gambling, paid communities) Full-media content encrypted once, distributed widely via Shelby CDN, decryption gated by any onchain condition: active CA subscription, age-verified attestation, jurisdiction allowlist, or any combination. Leaked ciphertext is useless without the ACE committee releasing a key share.

ACE Storage Architecture

ACE encrypts a blob of bytes. The encrypted data lives on Shelby CDN, onchain as a Move resource, in a WebSocket stream, or in a transaction payload. ACE is the layer that decides who gets the key to read it.

Recommended First Integration

The most valuable immediate integration is ACE for Whop Feed article encryption and gated premium content. Both require:

• ›A TypeScript SDK integration
• ›A small set of Move modules (FeedPayment, ContentGate)
• ›Two ACE worker deployments

The public test workers are usable for building today. For production, Whop runs its own committee. The trust question is who runs the workers. For Feed metered content, Whop running a 2-of-2 internally is fine. For any case where the proof needs to be trustless against Whop itself, a 2-of-3 where Aptos Labs, Whop, and a neutral third party each hold a key share is the right architecture.

Private Payments Use Cases

The CA + UTT combination covers any situation where payment needs to happen but the amount, the identities, or the relationship should stay private. A short list of where this actually lands on Whop:

• ›Subscriptions and creator payouts. Confidential Asset (CA) Standard. Addresses are public for reconciliation, amounts and balances stay private.
• ›Private tipping and high-risk content. Invisible Assets (UTT) Standard. Neither side's wallet or the amount is linkable onchain.
• ›Payroll and contractor payments. An employer's total payroll shouldn't be a public onchain ledger. Each pay event settles privately through CA while the issuer keeps the auditor key for tax reporting, and the same key is available to law enforcement with a legitimate request.
• ›Cross-border remittance. International creators and merchants sending money home don't want their full payment graph indexed onchain. UTT handles sender, recipient, and amount privacy, with the monthly anonymity budget as the jurisdictional policy lever.
• ›Trading. Margin, copy-trading fees, indicator subscriptions, and vault distributions ride the same CA rail to keep amount-level privacy without touching attribution. The trading-specific cryptographic patterns live on the trading product pages.