AIP-143 (Confidential APT) — Mainnet Activation via Governance Proposal #188

AIP-143 (Confidential APT) — Mainnet Activation via Governance Proposal #188

On April 21, 2026, on-chain governance proposal #188 — "Enable APT for Confidentiality" — went to a live vote on Aptos mainnet. This is the governance action that flips AIP-143 (Confidential Assets) from merged-but-gated framework code into a live mainnet feature for APT itself.

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."

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<APT> enabled in aptos_framework::coin
      │
      ▼
Any account can now call:
   confidential_asset::veil<APT>(amount)
   confidential_asset::transfer_veiled<APT>(to, Ciphertext, Proof)
   confidential_asset::unveil<APT>(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.

Further Reading

• Full Confidential Assets deep dive — UTT theory to deployed encryption
• Prefix Consensus — content-blind ordering at the consensus layer
• Aptos Stack Map — how privacy composes with the rest of the stack

Related Systems

Other Deep Dives

View this report interactively with Advanced / ELI5 tabs at https://aptos-intelligence.vercel.app/#aip-143-mainnet-proposal-188. Plain-text version: /reports/aip-143-mainnet-proposal-188.txt.