Build with Confidential Transactions on Aptos

5 min readJun 4, 2025

Customers of traditional financial applications often expect confidentiality when transacting. But public blockchains, by design, are open and transparent, revealing key details of a transaction. This can make it challenging for many regulated financial and enterprise-grade use-cases to adopt the technology.

Aptos Confidential Transactions (ACTs) solve this by making transaction amounts and balances confidential to the general public, opening up the space for developers to build compliant confidential use cases. This still allows for selective disclosure to authorized auditors, so institutions can meet their reporting and oversight obligations.

Confidential Transactions are now live on devnet. Explore how this feature can be used to build a simple payments application: https://confidential.aptoslabs.com/

Note: The existing features may change when ACTs launch on mainnet.

What it is: ACTs encrypt token balances and transaction amounts on-chain, making them confidential to outside network participants (including validators), except designated third-party auditors.

A third-party auditor equipped with the decryption key can selectively decrypt and review encrypted balances and transfer amounts to help regulated entities meet their obligations without exposing those details to the wider network. This means developers can perform required oversight and audit transactions for legal and compliance purposes without compromising overall user privacy.

What it is not: ACTs DO NOT hide sender and recipient identities; they focus exclusively on confidentiality of token balances, while all other transaction information remains public.

How ACTs work:

At a high level, user balances are made confidential under a long-term encryption key—potentially different from the normal account signing key.

To transfer between confidential accounts, a sender can make the transferred amount confidential and convince the validators with a zero-knowledge proof (ZKP) that the amount does not exceed their balance.

Overview of Confidential Transactions

ACTs on Aptos adhere to three fundamental principles:

1. Balances and transferred amounts are made confidential from every participant in the network, except the intended recipient and the auditor

2. The recipient is able to decrypt the balance

3. Validators have no visibility on confidential token balances or transferred amounts, but the network still ensures integrity: no negative balances, no artificial inflation etc.

They are built on two main primitives:

Additively Homomorphic Encryption Scheme (E)

This encrypts integer amounts and allows ciphertexts to be combined directly without decrypting.

E(ek, v; r) -> c encrypts a value v under the encryption key ek using some randomness r, producing a ciphertext c.

Later on D(dk, c) -> v can decrypt the ciphertext c using the corresponding decryption key dk associated with ek, revealing the originally encrypted value v.

Most importantly, E is homomorphic in the sense that encryptions c1 and c2 of two values v1 and v2 (respectively) can be combined into an encryption of their sum v1+v2 by simply computing c1+c2.

No decryption is necessary.

More formally, for any values v1, v2 and randomness r1,r2, the encryption function E has the following property:

E(ek, v1; r1) + E(ek, v2; r2) = E(ek, v1 + v2; r1 + r2)

ek is the public encryption key.
v1 and v2 represent the transaction amounts or balances encrypted within ciphertexts.
r1 and r2 are random scalars for blinding and encrypting the underlying amounts.

Balances can be encrypted, updated, added, or subtracted directly on-chain, without ever revealing plaintext amounts.

Zero-Knowledge Proof (ZKP) Scheme (Π)

What happens if a sender has an encrypted balance of 4 tokens, but tries to send an encrypted amount of 5? How can the validators tell that the encrypted amount is higher than the balance?

The sender will convince the validators using a zero-knowledge proof that the encrypted amount does not exceed the encrypted balance.

Validators learn nothing beyond this fact about the encrypted values.

Lifecycle of a Confidential Transaction

Here’s the practical lifecycle of a confidential transaction, explained through these primitives:

Step 1: Each user generates an encryption key-pair for all transactions: a public encryption key ek & a private decryption key dk.

Step 2: When Alice confidentially sends coins to Bob:

Alice encrypts the amount v under both her encryption key ek_Alice and Bob’s encryption key ek_Bob, using the random blinder r.

c_Alice = E(ek_Alice, v; r)

c_Bob = E(ek_Bob, v; r)

Alice then generates a zero-knowledge proof π, proving three things simultaneously:

Both ciphertexts c_Alice and c_Bob encrypt the same numeric value v.
The value v is within a valid numeric range.
Alice’s resulting balance after subtracting v remains valid (≥ 0).

Step 3: Validators verify Alice’s proof π, confirming correctness without decrypting amounts.

Balances are then updated homomorphically:

Alice’s encrypted balance decreases by subtracting the encrypted amount. Bob’s encrypted balance increases by adding the encrypted amount.

No numeric values are revealed to validators or unauthorized observers.

Step 4: Using his private key dk, Bob decrypts the ciphertext to discover the received amount.

Audits for Compliance

ACT supports auditors who can selectively decrypt amounts and balances for regulatory compliance:

Each transfer can additionally encrypt amounts under an auditor’s encryption key.
Senders adjust the zero-knowledge proof to now prove all ciphertexts encrypt the same amount under Alice’s, Bob’s and the auditor’s encryption key.

Implementation Choices

An account maintains three primary states:

Pending Balance: Receives incoming confidential transfers temporarily, preventing front-running.
Actual Balance: Primary encrypted balance for spending.
Frozen Flag: Pauses incoming transfers temporarily during secure key rotations.

Start Building

ACTs unleash a whole host of new use cases and we are excited to see what the ecosystem builds.

“We want to thank our partner Distributed Lab (https://distributedlab.com/) for co-building this functionality with us. Shoutout to (@olkurbatov) for the collaboration.”

A few examples: