# Alin Tomescu's Confidential Assets -- From UTT Theory to Deployed Encryption on Aptos Author: alinush Date: 2026-04-21T00:00:00Z Category: Feature Progress Importance: 10/10 Source: https://github.com/aptos-labs/aptos-core/tree/main/aptos-move/framework/aptos-framework/sources/confidential_asset Canonical: https://aptos-intelligence.vercel.app/reports/confidential-assets-deep-dive Interactive: https://aptos-intelligence.vercel.app/#confidential-assets-deep-dive --- ## Advanced Analysis Alin Tomescu: From Academic Theory to Production Encryption Alin Tomescu (alinush), Aptos Labs' Head of Cryptography since the founding team was assembled in February 2022, has shipped what may be the most sophisticated on-chain encryption system in production blockchain history. But to understand what he built -- and what he has not yet built -- you need to understand the gap between his academic research on fully anonymous payments and what is actually deployed on Aptos today. The Academic Foundation: UTT (2022) Tomescu's most ambitious cryptographic research is UTT: Decentralized Ecash with Accountable Privacy (IACR ePrint 2022/452), co-authored with Adithya Bhat, Benny Applebaum, Ittai Abraham, Guy Gueta, Benny Pinkas, and Avishay Yanai. UTT proposes a system where sender identity, receiver identity, AND transaction amounts are ALL hidden -- what the paper calls "sensibly-anonymous decentralized payments." The key innovations are: Anonymity budgets: Users can send payments anonymously, but only up to a configurable amount per time period. This balances privacy with accountability -- you cannot launder unlimited funds. Pointcheval-Sanders (PS) signatures: UTT uses re-randomizable anonymous credentials built from PS signatures. A coin is essentially a signed credential that can be "refreshed" (re-randomized) so that the new coin is unlinkable to the old one. This is what provides sender anonymity. No zkSNARKs: Unlike Zcash, UTT deliberately avoids general-purpose zero-knowledge circuits. It uses sigma protocols and structured algebraic proofs, which are simpler, faster (~1,000 payments/sec at ~100ms latency), and require no trusted setup. Threshold authorities: The bank, registrar, and auditor are all implemented via threshold cryptography over BFT infrastructure, so no single party holds the keys to break anonymity. Tomescu also published related work on pairing-based anonymous credentials and the power of re-randomization, showing how PS signatures can sign Pedersen commitments directly and be re-randomized together with the signed commitment -- the core mechanism that makes UTT coins unlinkable. What Is Deployed: Confidential Assets v1.1 The system deployed on Aptos (pending mainnet governance vote as of April 2026) is fundamentally different from UTT. It provides amount confidentiality only. Sender and receiver addresses remain fully visible on-chain. Here is exactly how it works, from the source code: Encryption Scheme: Chunked Twisted ElGamal From confidential_balance.move, a balance a is split into 16-bit chunks: const CHUNK_SIZE_BITS: u64 = 16; const PENDING_BALANCE_CHUNKS: u64 = 4; // 4 × 16 = 64-bit pending const AVAILABLE_BALANCE_CHUNKS: u64 = 8; // 8 × 16 = 128-bit available Each chunk a_i is encrypted as a Twisted ElGamal ciphertext: P_i = a_i * G + r_i * H // Pedersen commitment (hides value) R_i = r_i * ek // ElGamal component (enables decryption) where G is the Ristretto255 basepoint, H = basepoint_H (a nothing-up-my-sleeve second generator), ek is the user's encryption key (a Ristretto255 point), and r_i is per-chunk randomness. The "twist" is that the commitment base G and the encryption key base H are separated. This gives additive homomorphism: you can add two ciphertexts component-wise and get a valid encryption of the sum. From confidential_balance.move: // From confidential_balance.move public(friend) fun add_mut_base( self: &mut Balance, rhs_P: &vector, rhs_R: &vector ) { vector::range(0, rhs_P.length()).for_each(|i| { self.P[i].point_add_assign(&rhs_P[i]); self.R[i].point_add_assign(&rhs_R[i]); }); } } To decrypt, the owner computes: // Decryption a_i * G = P_i - dk * R_i // since dk * R_i = dk * r_i * ek = dk * r_i * dk^(-1) * H = r_i * H // Then solve discrete log of a_i * G for a_i // Feasible: a_i is only 16 bits → baby-step giant-step in ~256 steps. Then they solve the discrete log of a_i * G for a_i, which is feasible because a_i is only 16 bits (baby-step giant-step in ~256 steps). The On-Chain Data Structures The ConfidentialStore (one per user per asset type) from confidential_asset.move: enum ConfidentialStore has key { V1 { pause_incoming: bool, normalized: bool, transfers_received: u64, pending_balance: CompressedBalance, // 4-chunk, 64-bit available_balance: CompressedBalance, // 8-chunk, 128-bit ek: CompressedRistretto, // user's encryption key auditor_hint: Option } } A transfer amount (from confidential_amount.move) is encrypted under multiple keys simultaneously: // From confidential_amount.move struct Amount has drop { P: vector, // shared Pedersen commitments R_sender: vector, // encrypted under sender key R_recip: vector, // encrypted under recipient key R_eff_aud: vector, // effective auditor (optional) R_volun_auds: vector>, // voluntary auditors } } The P components are shared because the committed values are identical -- only the R components differ per key. Six Core Operations register(): Publishes a ConfidentialStore with zero balances. Requires a sigma protocol proof that the user knows their decryption key dk corresponding to their encryption key ek (prevents registration with someone else's key). deposit(): Converts public tokens into confidential balance. Transfers FA tokens from user's primary store into the confidential asset pool. The amount is added to the pending balance with no randomness (R = identity), since the deposited amount is public anyway. From the code: add_assign_pending(&mut ca_store.pending_balance, &new_pending_u64_no_randomness(amount)); withdraw_to(): Converts confidential balance back to public tokens. Requires: (a) a sigma protocol proof that the new balance is computed correctly from the old balance minus the withdrawal amount, and (b) a Bulletproofs range proof that the new balance is non-negative (each chunk in [0, 2^16)). confidential_transfer(): The core privacy operation. Transfers a SECRET amount from sender's available balance to recipient's pending balance. Requires TWO range proofs (new sender balance >= 0, transfer amount >= 0) and a sigma protocol proof that ties everything together. The transfer proof (from sigma_protocol_transfer.move) verifies a complex relation R^{-}_{txfer} that simultaneously proves: - The sender knows dk and can decrypt their old balance - The new balance P components are valid commitments - The transfer amount P components commit to the same values under all keys - Balance conservation: old_balance = new_balance + transfer_amount rollover_pending_balance(): Moves accumulated pending balance into available balance. This is a non-cryptographic operation -- just adds the compressed ciphertexts element-wise. Required before spending because the available balance has 8 chunks (128-bit) while pending has only 4 (64-bit). rotate_encryption_key(): Re-encrypts the available balance under a new key. Requires pausing incoming transfers first and rolling over any pending balance. The proof (sigma_protocol_key_rotation.move) proves correct re-encryption without revealing the balance. Normalize Operation An additional operation, normalize(), is a withdraw with amount=0. It re-encrypts the available balance with fresh randomness, ensuring all chunks are within 16-bit bounds. This is required after rollover because adding pending chunks to available chunks can cause chunk values to exceed 16 bits (e.g., if many deposits accumulated). Normalization "re-chunks" the balance correctly. Range Proofs: Bulletproofs over Ristretto255 From confidential_range_proofs.move, range proofs use batch Bulletproofs verification: const BULLETPROOFS_DST: vector = b"AptosConfidentialAsset/BulletproofRangeProof"; public(friend) fun assert_valid_range_proof( commitments: &vector, zkrp: &RangeProof ) { verify_batch_range_proof(commitments, &ristretto255::basepoint(), &ristretto255::hash_to_point_base(), zkrp, confidential_balance::get_chunk_size_bits(), // 16 BULLETPROOFS_DST) } Each range proof proves that ALL chunks in a balance are in [0, 2^16). Batch verification proves all chunks simultaneously in a single proof. Sigma Protocol Framework Tomescu built a composable sigma protocol library directly in Move (a first for any blockchain). From sigma_protocols/README.md: "Due to Move's limitations (e.g., lack of traits), our sigma-protocol library is rather primitive and potentially-dangerous if not used carefully." The framework represents proofs as homomorphism checks psi(w) = f(X), where w is the secret witness and X is the public statement. Each proof is described as a RepresentationVec -- a list of multi-scalar multiplications (MSMs) that the verifier checks. The Fiat-Shamir transform (sigma_protocol_fiat_shamir.move) makes these non-interactive. Auditor Architecture The system supports three levels of auditing: - Global auditor: Set by governance, applies to all asset types by default - Asset-specific auditor: Overrides global auditor for a particular token type - Voluntary auditors: Sender can optionally encrypt amounts for additional parties (e.g., compliance officers) Crucially, auditors can only see data from after their appointment. From the code, each auditor has an epoch counter that increments on install/change. The EffectiveAuditorHint stored in each ConfidentialStore tracks which auditor the ciphertext was encrypted for, allowing auditors to detect stale (pre-appointment) data they cannot decrypt. No auditor is assigned at launch. Governance retains the authority to install one later. Performance Characteristics Client-side: Proof generation ~25ms, amount decryption ~0.3-0.5ms, balance decryption (baby-step giant-step over 16-bit chunks) ~13ms native / 130-260ms browser. Validator-side: Proof verification ~2ms. No trusted setup required. Gap Between UTT and What Is Deployed This is the critical analysis. Tomescu's academic work (UTT) proposes FULL transaction anonymity -- sender, receiver, and amount all hidden. What Aptos ships hides ONLY amounts. Here is the precise gap: What UTT has that Confidential Assets does not: Sender anonymity: In UTT, coins are re-randomizable credentials. The sender "spends" an old coin and "mints" a new one that is cryptographically unlinkable. On Aptos, the sender's address is plainly visible in every transaction. Receiver anonymity: UTT delivers coins to recipients without revealing who received them. On Aptos, the recipient address is a required parameter of confidential_transfer(). UTXO-style coin model: UTT uses a coin-based (UTXO) model where coins are created and consumed. Aptos uses an account-based model where balances are updated in place. This is a fundamental architectural incompatibility. Anonymous credentials: UTT requires Pointcheval-Sanders blind signatures, credential issuance, and re-randomization. None of this exists in the Aptos framework. Anonymity budgets: UTT's killer feature -- limiting anonymous spending per time period -- requires infrastructure to enforce limits without revealing identity. What would it take to implement full UTT on Aptos: The honest answer is that it would require a fundamental redesign. You cannot bolt UTT-level privacy onto an account-based model. You would need: (a) a parallel UTXO-style coin registry, (b) threshold blind signing infrastructure for credential issuance, (c) nullifier sets for double-spend prevention, (d) re-randomizable credential verification in the Move VM, and (e) anonymity budget enforcement. The DKG/threshold infrastructure in crates/aptos-dkg/ is the most relevant existing building block, but it would need significant extension for blind signing. Existing Cryptographic Primitives That Could Enable Future Privacy The aptos-core codebase has several relevant cryptographic crates beyond what confidential assets uses: crates/aptos-crypto/src/elgamal/ -- Generic ElGamal over Curve25519 (with an ElGamalFriendlyGroup trait for abstraction) and BLS12-381 groups crates/aptos-crypto/src/bulletproofs/ -- Bulletproofs range proofs (currently max 64-bit range) crates/aptos-dkg/ -- Full distributed key generation infrastructure: PVSS (publicly verifiable secret sharing), weighted VUF (Pinkas scheme), range proofs over BLS12-381, sigma protocols crates/aptos-dkg/src/pvss/chunky/ -- Chunked ElGamal schemes for DKG transcripts (including HKZG commitment-based variants) The sigma protocol framework in Move -- composable proof building blocks that could be extended for new relations Tomescu's Broader Cryptographic Contributions to Aptos Beyond confidential assets, Tomescu designed and deployed: - The Aptos on-chain randomness system (DKG + weighted PVSS + Pinkas WVUF), running in production with 112+ validators - Scalable threshold cryptography (IEEE S&P 2020) enabling DKG at scale - The cryptographic foundations for the encrypted mempool (BIBE -- Blind Identity-Based Encryption) for MEV prevention Bottom Line Confidential Assets v1.1 is a carefully-engineered, production-grade encrypted balance system that solves a real problem -- balance and amount privacy -- without requiring changes to Aptos consensus. But it is explicitly NOT the full UTT vision. The sender and receiver are visible. The anonymity budgets, re-randomizable credentials, and threshold blind signing from the UTT paper remain unimplemented. Whether Aptos moves toward full UTT-level privacy depends on whether the ecosystem demands sender/receiver anonymity alongside amount confidentiality, and whether the account-model constraints can be overcome -- possibly through a hybrid UTXO layer. The Full Aptos Privacy Stack: Three Zones Confidential Assets is not standalone — it is Zone 1 of a three-layer privacy architecture designed by Alin Tomescu. Zone 0 (Public)Zone 1 (Confidential Assets)Zone 2 (UTT) What is hiddenNothingAmounts and balancesAmounts, addresses, full trade graph What is visibleEverythingSender and receiver addressesOnly that a transaction happened ComplianceFull transparencyAuditor key (designated decryptor)Anonymity budget (monthly cap enforced by ZK circuit) ModelAccountAccountUTXO StatusLiveCode merged, pending governanceResearch (blog posted Mar 21, 2026) UTT: Untraceable Transactions (Zone 2) Alin's research from 2018 (VMware), rebooted 2021. Published at Stanford Blockchain Conference 2023, presented at Yale and a16z. Bank of Israel pilot deployment for CBDC privacy research. Authors: Alin Tomescu (lead), Adithya Bhat, Benny Applebaum, Ittai Abraham (Aptos co-founder, now a16z), Guy Gueta, Benny Pinkas (Bar-Ilan, world's leading MPC researcher), Avishay Yanai. How UTT Works UTXO coin model. Every coin is a sealed envelope — a Pedersen commitment C = Commit(pid, sn, v). The commitment hides the owner's pseudonymous ID, a secret serial number, and the value. Onchain, a coin looks like a random 32-byte group element. Nullifier: nl = prf(sn; sk) using Dodis-Yampolskiy PRF over BN254 (Poseidon hash — 220 constraints vs 25,000 for SHA256). Only the owner can compute it. Same coin always produces same fingerprint — prevents double-spend without revealing identity. State: Two append-only structures: (1) Merkle tree of coin commitments, (2) nullifier set. Neither is ever reduced. Frontier Merkle tree: O(log n) storage = 1,024 bytes forever regardless of tree size. Nullifiers in Aptos Table: O(1) lookups. Mint authority: Every coin carries a Pointcheval-Sanders (PS) signature from a threshold k-of-n committee. PS signatures can be verified inside a ZK circuit without revealing the signature — you prove "I have a valid mint signature" without exposing it. The 5 Core Circuit Constraints 1. sk_i is the secret key of pk_i sk_j is the secret key of pk_j nl_i = prf(i; sk_i) // nullifier computation nl_j = prf(j; sk_j) // nullifier computation v_i + v_j = v_A + v_B + v_gas // value conservation The full production circuit has ~14 constraints including PS signature verification inside ZK, output commitment integrity, range proofs (DeKART), anonymous credential, and budget UTXO. The Anonymity Budget — Why the Bank of Israel Accepted It Every user gets a budget coin — a Pedersen commitment. When spending privately, the transaction is 3-in-3-out: two payment coins + old budget coin → two new coins + new budget coin (reduced balance). ZK circuit enforces: budget_new = budget_old - amount >= 0. The budget coin is a real UTXO — gets destroyed and reissued with every transaction. Cannot be double-spent or cloned. At $10K/month cap: laundering $100M takes 833 years. Compliance is built into the math, not policy. The Unlinkability Property An outside observer sees a Merkle tree full of sealed envelopes (commitments that look like random group elements) and a nullifier set of spent markers (also look random). 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 is "invisible" — the entire graph of who sent to whom is cryptographically erased. Deployment on Aptos Tier 3 Move module — NOT a consensus-layer change. All primitives already in Move VM: Groth16, BLS12-381, Ristretto255, Bulletproofs. One governance vote needed. Block-STM serialization on UTTState limits throughput to ~200-500 tx/s (acceptable for a privacy layer). IBE (Identity-Based Encryption) enables send-to-identity: send to a phone number or email rather than a wallet address. Shared infrastructure with ACE. ACE: Access Control Encryption Encrypts any data. A Move smart contract decides who can decrypt. If the contract says yes, a distributed committee releases the decryption key. If no, nobody can decrypt. Built on IBE threshold decryption. Three components: Committee (k-of-n IBE key share holders), ContractID (any Move #[view] function returning bool), ProofOfPermission (signed proof verified by workers before releasing key shares). Why better than token gating: Token gating relies on a server deciding to serve content — hack the server, get the content. With ACE, the platform never holds the decryption key. Even fully compromised, an attacker gets useless ciphertext. ContractID as arbitrary logic: Time-locks (auto-release at block height), multi-condition gates (hold stake AND active payment AND registered 30+ days), revocation (lapsed payment → contract returns false → no new keys). Composable with CA and UTT. Status: TypeScript SDK live. Public test workers operational. Production requires own workers with dedicated fullnodes. DeKART: Range Proofs Inside ZK Circuits The UTT circuit needs range proofs (non-negative values). Standard Bulletproofs are expensive inside Groth16 (thousands of constraints for MSM verification). DeKART (from Alin's group) uses lookup arguments instead — cheap inside R1CS. Result: full circuit stays at ~14 constraints. ~1-2 second proving on a laptop. The Encrypted Mempool: Pre-Execution Privacy Separate primitive. Operates at consensus layer, before CA/UTT/ACE apply. Transactions submitted encrypted → validators order ciphertexts → decrypt only after ordering is locked. Uses threshold decryption via BIBE (same DKG as randomness module). Prevents MEV and front-running at the protocol level. The Aptos Cryptography Team PersonRoleKey Contributions Alin TomescuHead of Cryptography, Aptos LabsUTT (lead), AIP-143, ACE, DKG. PhD MIT (Srini Devadas). Ex-VMware Research. Ittai AbrahamAptos co-founder → a16z cryptoUTT co-author, HotStuff consensus. PhD Hebrew U (Michael Ben-Or, MPC founder). Benny PinkasBar-Ilan professor, VMware ResearchUTT co-author. Top 5 global MPC researcher. Bank of Israel credibility. Balaji ArunConsensus engineer, Aptos LabsEncrypted mempool, DKG/RandManager. 20 consensus commits in 90 days. The Gap: What Is Not Yet Deployed Confidential Assets (Zone 1) is shipped. UTT (Zone 2) is researched and designed but not deployed. The gap is architectural: UTT requires UTXO coin model — parallel module alongside the existing account system PS signatures for mint authority need Move native implementation Nullifier set as Aptos Table — straightforward but unbuilt Groth16 verifier exists in Move VM (added for AIP-143) — the circuit needs deployment IBE infrastructure shared with ACE (already prototyped) Alin posted the UTT blog March 21, 2026 — three days before the AIP-143 AMA. The sequencing is deliberate: CA ships first, UTT next. All cryptographic primitives are in the VM. One governance vote away. Mainnet Activation: Governance Proposal #188 (April 21, 2026) As of April 21, 2026, AIP-143 is no longer a draft or a testnet feature. On-chain governance Proposal #188 — "Enable APT for Confidentiality" is live on Aptos mainnet, with voting in progress. This is the exact on-chain action that flips confidential transfers from "code merged, framework-gated" to "live on every APT balance." FieldValue Proposal number#188 TitleAIP 143: Enable APT for Confidentiality NetworkAptos Mainnet Proposer0xdb009ab1a3259c4b27a0d8ff9d0e913e13e4c8b657fc73768f4e9bb811c7a1d8 Execution hash0x34067a0669984c31bf07c84a48ea9f937d96f7966ef39a5ceb7dfc1cd1861d41 Source module2026-04-21-enable-confidential-apt/Enable-confidential-apt.move Vote tally (for)100% — 14,261,274 APT Vote tally (against)<1 APT Turnout1.19% Quorum requirement24.97% Discussionaptos-foundation/AIPs discussion #663 Trackergovscan.live/aptos/proposals/188 What Proposal #188 Actually Does The proposal is narrow and surgical. Its execution payload — the Move script in Enable-confidential-apt.move — flips a single framework flag so that APT itself becomes eligible for confidential transfers. All of the plumbing (the veiled balance resources, the zero-knowledge proof verifiers, the pending inbox mechanics described earlier in this report) is already deployed. The proposal is the feature flag flip. Why is this significant even though "the code was merged"? Because AIP-143 is deliberately scoped to APT only at launch — and the restriction is enforced at the framework level, not at the issuer level. Quoting the AIP directly: "At launch, confidential asset functionality is restricted to APT only and enforced at the framework level. Other assets cannot opt into the confidential asset system." This is explicit: stablecoin issuers, wrapped-asset issuers, and app-token issuers cannot self-enable confidential transfers for their tokens. The framework blocks them. The AIP describes this as "a product and ecosystem decision rather than a technical limitation" — meaning the plumbing exists, but the policy gate is closed for everything except APT. Expansion beyond APT is future governance work. The AIP states: "Governance may consider enabling confidential functionality for additional assets in the future, subject to security review, economic alignment, and policy considerations." So each future asset (or a blanket policy change) is itself a governance decision — not an issuer opt-in. Proposal #188 is the APT-specific activation; any USDC, USDT, or app-token equivalent would require its own on-chain vote. The Execution Flow User signs vote │ ▼ Aptos governance module validates stake + voting window │ ▼ If quorum reached AND majority-for: Proposal queued for execution at next epoch │ ▼ Execution window opens │ ▼ Framework upgrade script runs: - Confidential-asset metadata registered for APT FA - Per-account veiled balance resource authorized - ConfidentialCoinStore enabled in aptos_framework::coin │ ▼ Any account can now call: confidential_asset::veil(amount) confidential_asset::transfer_veiled(to, Ciphertext, Proof) confidential_asset::unveil(amount, Proof) Why the Turnout Looks Small 1.19% turnout vs. a 24.97% quorum threshold looks low on the surface but is typical for Aptos on-chain governance. Only staked APT with active delegation votes, and the vast majority of staked APT is held by validators that vote as a bloc. The 14,261,274 APT that voted "for" likely represents near-unanimous alignment from the top validators plus the Aptos Foundation delegation. The 11-APT "against" vote is either a protest ballot or a test from a small holder. What Changes for Users Immediately After Execution Every APT holder gains the ability to move APT into a veiled balance using ElGamal encryption over the user's own public key. Veiled transfers hide the amount being sent. The sender, receiver, and transfer event are still visible on-chain — only the amount and the post-transfer balances are encrypted. The pending inbox mechanism prevents front-running: incoming confidential transfers sit in a separate encrypted mailbox until the recipient chooses to roll them into their main veiled balance. Unveiling a balance (converting veiled APT back to regular APT) requires a zero-knowledge proof that the unveiled amount matches the encrypted balance. Proofs are generated client-side. Combined Picture: Privacy Stack + Consensus Stack The mainnet activation of AIP-143 is the privacy-layer counterpart to the consensus-layer work covered in the Prefix Consensus deep dive. Together they give Aptos something no other L1 has as of Q2 2026: content-blind ordering at the mempool level via encrypted mempool + amount-blind settlement at the asset level via AIP-143. A sender can route an APT transfer through the encrypted mempool (amount invisible during ordering) and land it as a confidential transfer (amount invisible on-chain after settlement). Every other chain leaks one of these two surfaces. For the full picture of how privacy layering composes with the rest of the stack, see the Aptos Stack Map. --- ## ELI5 (Explain Like I'm 5) The Big Picture: Imagine you have a piggy bank that everyone can see. Right now on most blockchains, everyone can see exactly how many coins are in your piggy bank and exactly how many you send to a friend. That is a big privacy problem. What Alin Built (Confidential Assets): Alin built a special magic box for your piggy bank. When you put coins in the box, the box scrambles the number so nobody can read it. When you send coins to a friend, a magic envelope carries the coins -- the envelope shows YOUR name and YOUR FRIEND'S name on the outside (so everyone knows who sent what to whom), but the number of coins inside is scrambled. How the Scrambling Works (Twisted ElGamal): Think of it like a combination lock with two parts. Part 1 is a "commitment" -- you write the amount on a piece of paper, fold it up with some random confetti (that is the randomness r), and seal it in an envelope (that is P = amount * G + r * H). Nobody can open the envelope to see the number. Part 2 is the "key hole" -- you stamp the confetti pattern with your personal stamp (that is R = r * ek). Only someone with your personal key can match the confetti to unseal the envelope and read the number. The cool trick: if you stack two sealed envelopes on top of each other, the numbers inside ADD together without anyone opening them. That is "homomorphic encryption" -- the blockchain can update your balance without ever seeing the actual number. What Alin's Research Paper (UTT) Would Do: In his dream version (the UTT paper), even the NAMES on the outside of the envelope would be hidden. Nobody would know who sent coins to whom. It would be like sending a letter with no return address and no "to" address -- but the postal system still magically delivers it. To do this, you would need "anonymous credentials" -- special ID cards that prove you are a real person without showing your name. The Gap: Right now, Aptos has the scrambled-numbers part working (that is the hard part from an engineering standpoint). But the scrambled-names part (true anonymity) from UTT is much harder and has not been built yet. It would require changing how Aptos tracks who owns what -- from a list of accounts to something more like a pile of anonymous coins. Why This Matters: Even just hiding amounts is a huge deal. It means hackers cannot target you because they see a big balance, employers cannot snoop on your salary, and competitors cannot see your treasury. The full UTT vision would add even more privacy, but the current system is already a major leap from public balances. What You Learned: You now know that Alin Tomescu is a cryptographer who studied how to make ALL transaction details invisible (UTT paper), but first deployed a simpler system that hides only the amounts (Confidential Assets). The gap between the two is not just engineering effort -- it requires a fundamentally different architecture for how coins are tracked on-chain. The Bigger Picture — Three Zones of Privacy Confidential Assets is just Level 1 of three levels: Level 0 (Public): Everything visible — how most blockchains work Level 1 (Confidential Assets): Balances and amounts hidden, but people see WHO sent to whom — like a bank statement with dollar amounts blacked out but names visible Level 2 (UTT — Invisible Assets): EVERYTHING hidden — amounts, sender, receiver. Like digital cash. Nobody knows who paid whom or how much. The Bank of Israel tested this because it has a built-in monthly spending cap enforced by math, not policy There is also ACE — encrypts any data and lets a smart contract decide who can decrypt it. Like a lock controlled by code, not a person. Even if someone breaks into the server, they get encrypted gibberish. All three designed by Alin Tomescu — Head of Cryptography at Aptos Labs. PhD MIT. UTT co-authors include Ittai Abraham (Aptos co-founder, now a16z) and Benny Pinkas (top 5 global MPC researcher).