Aptos can now keep APT balances and transfer amounts encrypted on mainnet while still verifying each state transition. For developers, the useful mental model is an encrypted accounting layer—not a separate private token.
Aptos emerged from Meta's Diem engineering lineage, and its founding team helped create Move, Move Prover, and Block-STM. Since mainnet launched in 2022, the proof-of-stake Layer 1 has expanded toward settlement infrastructure for payments, stablecoins, trading, and tokenized assets.
Within that trajectory, Aptos Confidential APT is an opt-in mainnet feature in Aptos's fungible-asset framework. Users deposit public APT into a protocol pool and register an encryption key. Balances and transfer amounts are then encrypted, while Sigma and Bulletproof proofs let validators verify each update without reading the amount. Withdrawals convert the encrypted claim back into public APT. Addresses and entry-and-exit amounts remain visible.
As of August 16, Aptos held approximately USD 1.24 billion in stablecoins, 21.3 times its USD 57.97 million DeFi TVL. It also carried about USD 630.79 million in non-stablecoin real-world assets (RWAs), including USD 61.35 million in distributed and transferable assets, while trailing-30-day stablecoin holder-to-holder transfers reached USD 15.46 billion.
The live Confidential APT pool held 15,116.25711844 APT, worth roughly USD 8,000. These differently defined stock, flow, and pool metrics are not an adoption ratio. Together, they place a new confidentiality primitive inside an ecosystem already carrying substantial on-chain assets and transfer activity.
The same snapshot gives Aptos a 95.16 Security Score and AAA tier on CertiK Skynet. All six component scores exceeded 91.5, led by Governance at 96.32 and Code Security at 95.85. This is a network-level view; the sections below examine Confidential APT's mechanism and controls directly.
That context leads to the central engineering question: How does Aptos enforce asset conservation when the chain cannot see balances or transfer amounts? The answer combines proofs with an account state machine, live proof inputs, key management, auditor configuration, and governance controls.
What Confidential APT Changes
Confidential APT is an opt-in path inside Aptos's fungible-asset framework. A user moves public APT into a protocol pool, registers an encryption key, and receives an encrypted balance. Transfers within that confidential domain update encrypted claims rather than moving the underlying APT out of the pool.
The chain does not need the plaintext amount to enforce conservation. The sender provides encrypted balance updates and a zero-knowledge proof showing that the old balance equals the new balance plus the transfer amount, that the same amount is encoded for every applicable reader, and that the resulting values stay within the permitted range.
Confidential does not mean anonymous. Sender and recipient addresses, asset type, timing, gas, entry-function calls, transaction structure, and public deposits or withdrawals remain observable. Amounts crossing the public-confidential boundary are visible as well. The feature narrows what the public ledger reveals about value; it does not hide the existence of the transaction.
From Public APT to a Confidential Balance
A complete balance lifecycle has five operations:
Register. The user registers an encryption key and proves knowledge of the corresponding decryption key.
Deposit. Public APT enters the protocol pool, and the same amount is credited to the user's encrypted pending balance. The deposit amount is public.
Rollover. The account owner moves pending funds into the encrypted available balance before they can be spent.
Confidential transfer. The sender proves a valid encrypted balance update. The recipient receives the amount in pending state.
Withdraw. The user reduces the encrypted balance and releases public APT from the pool. The withdrawal amount is public.
The Confidential APT lifecycle keeps public entry and exit separate from encrypted internal transfers.
This lifecycle explains why a wallet cannot present confidential APT as a single ordinary balance. It needs to distinguish public APT, pending confidential funds, and spendable confidential funds, then guide the user through the transitions between them.
How a Hidden Transfer Stays Verifiable
Proof generation happens on the client. Before constructing a transfer, the client fetches the sender's current confidential state, the recipient's encryption key, and the effective auditor key if one applies. It then encrypts the amount for the relevant readers, builds the proof, and signs the outer Aptos transaction normally.
The Move module verifies the proof against live on-chain inputs and applies the encrypted balance updates atomically. A failed transfer does not partially update either account. The proof protects the accounting relation; Aptos execution still enforces authorization, configuration, pause state, and the rest of the transaction rules.
A proof shows that a transition is valid for the state it references; it does not freeze that state until the transaction executes.
The client proves a transition from live state; the chain checks it before committing the update.
That separation matters for retries. If a proof-bound balance or encryption key changes before execution, the client must fetch fresh state and regenerate the proof. A recipient pause, asset disablement, pending-update limit, or emergency pause can reject a transaction without necessarily making the proof itself cryptographically invalid. Clients should classify the abort before deciding whether to rebuild the proof, retry later, or stop.
Why Pending Balances Matter
Each per-user, per-asset confidential store separates pending and available balances. Incoming transfers accumulate in the pending balance rather than rewriting the recipient's spendable ciphertext directly. Only the account owner rolls that pending value into the available balance. This design keeps senders from changing the state that a recipient is actively using to prove outgoing transfers.
The trade-off appears in the product experience. A wallet may show funds as received but not yet spendable, and it must know when to roll over or normalize the store. Pending-state management is therefore part of the payment flow, not a maintenance detail users should discover only after a failed transfer.
Auditors and Governance Define the Trust Boundary
Confidential APT supports configurable auditor access. When an auditor key applies, the proof ties the sender-, recipient-, and auditor-readable ciphertext components to the same transfer amount. Aptos does not give an auditor the user's decryption key for the relevant confidential store, and auditor support does not make balances publicly readable.
The effective auditor can also receive a handle for the sender's updated available balance. Because it may read both the transferred amount and the post-transfer aggregate balance, its visibility can extend beyond one isolated event. This does not reveal the individual historical transfers that formed the balance, and it is not a cryptographic break.
Auditor access is part of the governed configuration. Aptos framework authority can enable supported asset types, install a global or asset-specific auditor, and activate an emergency pause. These controls make selective deployment possible, but they also mean availability and disclosure policy depend on current on-chain configuration, not cryptography alone.
While allow-list enforcement is active, disabling one asset blocks new registrations, deposits, and confidential transfers. Withdrawals, rollover, normalization, and key rotation remain available under their normal preconditions; the global emergency pause is broader.
Governance controls admission and optional auditor configuration without publishing transfer amounts to everyone.
At the framework level, the confidential decryption key is separate from the account's transaction-signing key. Before rotating that key, the account must enter a quiet state: incoming transfers are paused, and the pending balance and receive counter are zero. The protocol then verifies that the available balance was re-encrypted correctly under the new key.
This separation gives wallets and custodians room to design distinct authorization and recovery controls. It also creates a hard responsibility: recovery material for the confidential store must be treated as critical user data. Recovering the Aptos signing key alone does not provide an on-chain mechanism for decrypting an independently managed confidential balance.
What Builders Need to Get Right
A usable integration has to handle more than proof generation:
- Fetch fresh confidential state before constructing a proof. If a proof-bound input changes, regenerate the proof and rebuild and re-sign the transaction.
- Classify failures by cause. Stale proof-bound state requires a new proof, while operational gates—such as an asset disablement or emergency pause—may only require the relevant state to be rechecked.
- Show pending and available balances separately, with rollover or normalization integrated into the user flow.
- Protect decryption-key recovery material, and test backup, migration, and key rotation across wallet versions.
- Monitor asset enablement, auditor configuration, and emergency-pause state rather than assuming that the launch configuration will remain unchanged.
Mainnet Is the Starting Point
Confidential APT moved from an early devnet implementation in June 2025 to an accepted AIP-143 in March 2026. Aptos Proposal #188 executed on April 24, enabling APT confidentiality and batched Bulletproofs. Aptos announced mainnet access through Petra and Confidential Assets Web on June 17, followed by a broader Petra Mobile rollout in July.
At the August 16 snapshot, APT confidentiality was enabled, allowlisting was active, emergency pause was off, and the public confidential pool held approximately 15,116.26 APT. That pool balance is a point-in-time measure, not a complete measure of adoption.
The next stage is broader wallet support, carefully designed asset integrations, and repeat use in payments, treasury operations, payroll, and settlement. The protocol primitive is live; the product opportunity is to make proof refresh, pending-state management, key recovery, and governance changes feel predictable to ordinary users.
Builders can start with the Aptos Confidential Asset documentation and TypeScript SDK, then map the implementation assumptions in their wallet or application to the deployed framework revision.
