Confidential assets:

A cryptographic deep dive

Alin Tomescu

Head of Cryptography, Aptos Labs

@alinush407

March 24th, 2026

First: a moment of silence for "veiled coins"...

2

Outline

1. What?
2. Why?
3. Demo
4. How? ⚠️

3

Public transactions (the status quo)

4

💰 -20

💰 +20

Public transactions (the status quo)

5

🌍

💰 230

🌍

💰 120

6

🌍

💰 230

🌍

💰 120

Confidential transactions as an option

7

🌍

💰 230

🌍

💰 120

Nobody sees balances nor TXN amounts.

Everybody still sees sender & recipient.

🌍

Confidential transactions as an option

Except auditor(s).

Outline

• What?
• Why?
• Demo
• How? ⚠️

8

Why?

9

Regulatory compliance:

• 3rd party auditors can see ⇒
• detect abuse

Confidentiality = user safety

• hide balances and amounts ⇒
• protects users (e.g., see here)

New use cases:

• on-chain salaries
• on-chain RSU/token grants

Outline

• What?
• Why?
• Demo
• How? ⚠️

10

Demo: Confidential payments (confidential.aptoslabs.com)

11

Keyless (sign in with your Google):

• No 🔑 management needed
• No wallet installation needed (!)

Venmo-like:

• Send payments to usernames
• Secured via Aptos Names

Outline

• What?
• Why?
• Demo
• How? ⚠️

12

Before we dig in… What are the next steps?

1. Mainnet deployment in v1.43
2. Enable APT token
3. Native support in Petra for confidential balances & transfers

We can pause for some early Q&A, if any… 🙋

​

13

Outline

• What?
• Why?
• Demo
• How? ⚠️
• Familiarity with elliptic curve groups of prime order p, with generator G
• Familiarity with ElGamal encryption
• Familiarity with Σ-protocols for linear relations among group elements
• Mostly, familiarity with zero-knowledge proofs for NP relations

14

Comparison to previous account model protocols

15

Comparison to previous account model protocols

16

Comparison to previous account model protocols

17

Comparison to previous account model protocols

18

Comparison to previous account model protocols

19

Comparison to previous account model protocols

20

Comparison to previous account model protocols

21

Deposits: enroll for confidentiality

22

Prereq 1: Chunked'n'twisted ElGamal encryption 🔐

KGen(1^λ) → (dk, ek)

dk ∈_R ℤ_p

ek ← dk^-1 ᐧ H

E_ℓ(ek, v₁, …, v_ℓ; r₁, ..., r_ℓ) → c

R_i← r_i ᐧ ek, ∀i ∈ [ℓ]

P_i ← v_i ᐧ G + r_i ᐧ H, ∀i ∈ [ℓ]

c ← (P_i, R_i)_{i ∈ [ℓ]}

23

i.e., Pedersen commitment to v_i using randomness r_i and commitment key (G, H)

Bolded, underlined variables denote vectors (e.g., c).

Convention: We will use c.Ped := (P_i)_{i ∈ [ℓ]} to denote the Pedersen components of the ciphertext.

Randomness; important!

Prereq 2: Chunking

For Aptos, we will work with:

• 128-bit balances a, split into ℓ= 8 chunks a = [a₁, a₂, …, a₈] of b = 16 bits each
• 64-bit amounts v, split into n = 4 chunks v = [v₁, v₂, …, v₄] of b = 16 bits each

i.e., ToChunks returns u’s base-2^b representation:

• a = ToChunks(a, b, ℓ), such that a = Σ_{i∈ [ℓ]} (2¹⁶)^i-1 ᐧ a_i = Unchunk(a, b, ℓ)
• v = ToChunks(v, b, n), such that v = Σ_{i∈ [n]} (2¹⁶)^i-1 ᐧ v_i = Unchunk(v, b, n)

24

Convention: u = ToChunks(u, b, m) splits u into m chunks of b bits each & returns them as u.

u = Unchunk(u, b, m) does the opposite such that Unchunk( ToChunks(u, b, m), b, m ) = u.

25

i.e.: ToChunks(v, b, ℓ)

Note: Deposited amount is public ⇒ No privacy just yet. (Must send or receive a transfer for that.)

🎉 Sherry can deposit confidential coins into her account!

Withdrawal: dispose of confidentiality

26

Prereq 3: Zero-knowledge proofs (ZKP) for NP relations

​

𝓡(x; w) = 1

27

A ZKP for x ∈ 𝓡

convinces verifier that prover knows

a secret witness w such that 𝓡(x; w) = 1

Public statement: Both prover & verifier have it.

Private witness: Only prover has it.

Goal: Hide it from verifier.

Any publicly-known algorithm, henceforth called a relation

Prereq 3’: Zero-knowledge proofs (ZKP) (e.g.: Sudoku)

Sudoku(puzzle; sol) = 1

28

A ZKP for puzzle ∈ Sudoku

convinces verifier that prover knows

a secret sol such that Sudoku(puzzle; sol) = 1

A publicly-known algorithm for checking if sol is a valid solution to puzzle.

ZK range proof relation for Pedersen-committed values

𝓡^b((P_i)_{i ∈ [ℓ]}; (v_i, r_i)_{i ∈ [ℓ]}) = 1

29

∀i ∈ [ℓ]:

P_i = v_i ᐧ G + r_i ᐧ H ⴷ

v_i ∈ [0, 2^b),

⇔

Prereq 4: Chunked'n'twisted ElGamal decryption 🔐

Dec_ℓ(c; dk) → (v₁ᐧ G, …, v_ℓᐧ G)

(P_i, R_i)_{i ∈ [ℓ]} ← c

v_i ᐧ G ← P_i - dk ᐧ R_i, ∀i ∈ [ℓ]

Dec*_ℓ(c; dk) → v ᐧ G

(v₁ᐧ G, …, v_ℓᐧ G) ← Dec_ℓ(dk, c)

v ᐧ G ←Σ_{i∈ [ℓ]}(2¹⁶)ⁱ ᐧ (v_i ᐧ G)

30

= (P_i) - dk ᐧ (R_i)

= (v_i ᐧ G + r_i ᐧ H) - dk ᐧ (r_i ᐧ ek)

= (v_i ᐧ G + r_i ᐧ H) - dk ᐧ (r_i ᐧ dk^-1 ᐧ H)

= (v_i ᐧ G + r_i ᐧ H) - r_i ᐧ H

= v_i ᐧ G

Discrete logarithm problem (DLP):

given v_iᐧ G, compute v_i.

Fast for 32-bit v_i’s (e.g., ~10ms in Rust)

Note: Fix b and ℓ. Then, Dec*_ℓ( E_ℓ(ek, ToChunks(u, b, ℓ); r); dk ) = u ᐧ G, for all u, r, ek = dk^-1 ᐧ H

31

i.e.: ToChunks(a_S, b, ℓ)

2. A'_S // Sherry’s new balance

3. π_withdraw for (ek_S, v, A_S, A'_S) ∈ 𝓡^withdraw

1. public amount v

// to withdraw from Sherry

i.e.: ToChunks(a_S - v, b, ℓ)

🎉 Sherry can withdraw confidential coins back into her public!

a. ek_S = dk_S^-1 ᐧ H // dk is 👌

b. A'_S = E_ℓ(ek_S, a_S’; r)

c. Unchunk( a_s’, b, ℓ) + v ᐧ G = D*_ℓ(dk_S, A_S)

Infinite money glitch: a_S = 0 and v = 1 ⇒ a_S’ = a_S - v = -1 (mod p) = p - 1 (mod p)

Why? 𝓡^withdraw does not check that v ≤ a_S.

Transfers: leverage confidentiality

32

Prereq 5: Chunked'n'twisted ElGamal batch encryption 🔐

E_ℓ(ek₁, …, ek_m, v₁, …, v_ℓ; r₁, ..., r_ℓ) → c

R_{i, j}← r_i ᐧ ek_j, ∀i ∈ [ℓ], ∀j ∈ [m]

P_i ← v_i ᐧ G + r_i ᐧ H, ∀i ∈ [ℓ]

c ← (P_i, R_{i, 1}, …, R_{i, m})_{i ∈ [ℓ]}

33

Convention: As before, c.Ped := (P_i)_{i ∈ [ℓ]} denotes the Pedersen components of the batch ciphertext.

(m+1)ℓ-sized vs. 2mℓ, if done naively via E_ℓ(ek_j, v₁, …, v_ℓ; r_1,j, ..., r_{ℓ, j}), ∀j ∈ [m]

Prereq 6: Chunked'n'twisted ElGamal homomorphism 🔐

R^a_i← r_i ᐧ ek

P^a_i ← a_i ᐧ G + r_i ᐧ H

34

E_ℓ(ek, a; r) + E_ℓ(ek, b; r’) = E_ℓ(ek, (a + b) mod p; r + r’)

E_ℓ(ek, a; r) + E_n(ek, v; r’) = E_ℓ(ek, (a + v) mod p; r + r’)

Convention: When adding a size-n ciphertext with a larger size-ℓone, we implicitly pad with 0s.

Note: All ciphertexts are under the same ek

Food for thought: If a and b were base-2^b, when combined like this will the result remain base-2^b?

35

2. A'_S // Sherry’s new balance

3. π_txfer for (ek_S, ek_R, c, A_S, A'_S) ∈ 𝓡^txfer

4. π_≤ for (c.Ped), (A'_S.Ped) ∈ 𝓡^b

This update can invalidate Rob’s ZKP w.r.t. A_R

a. 1 = 𝓡^withdraw(ek_S, v, A_S, A'_S; dk_S, r, a_s’)

b. c = E_n(ek_S, ek_R, ToChunks(v, b, n); s)

Why? If v = p - 1 ⇒ a_S’ = a_S - v = a_S + 1 ⇒ (A'_S.Ped) ∈ 𝓡^b will pass

A'_R← A_R+ c =

= E_ℓ(ek_R, a_R+ v; ᐧ )

🎉 Sherry can transfer confidential coins to anyone!

36

2. A'_S // Sherry’s new balance

3. π_txfer for (ek_S, ek_R, c, A_S, A'_S) ∈ 𝓡^txfer

4. π_≤ for (c.Ped), (A'_S.Ped) ∈ 𝓡^b

This update can invalidate Rob’s ZKP w.r.t. A_R

a. ek_S = dk_S^-1 ᐧ H // dk is 👌

b. A'_S = E_ℓ(ek_S, a_S’; r)

c. Unchunk( a_s’, b, ℓ) + v ᐧ G = D*_ℓ(dk_S, A_S)

b. c = E_n(ek_S, ek_R, ToChunks(v, b, n); s)

Why? If v = p - 1 ⇒ a_S’ = a_S - v = a_S + 1 ⇒ (A'_S.Ped) ∈ 𝓡^b will pass

A'_R← A_R+ c =

= E_ℓ(ek_R, a_R+ v; ᐧ )

37

A'_S← E_ℓ(ek_S, a_s’; r)

TXN

2. A'_S // Sherry’s new balance

3. π_txfer for (ek_S, ek_R, c, A_S, A'_S) ∈ 𝓡^txfer

4. π_≤ for (c.Ped), (A'_S.Ped) ∈ 𝓡^b

1. c = E_n(ek_S, ek_R, v; s)

// to withdraw from Sherry and deposit for Rob

pub_S: $10

Sherry (ek_S)

pub_R: $60

Rob (ek_R)

A_R: E_ℓ(ek_R, a_R; ᐧ )

P_R: E_n(ek_R, p_R; ᐧ )

# recv’d: 35

# recv’d_R: 21

A_S: E_ℓ(ek_S, a_S; ᐧ )

P_S: E_n(ek_S, p_s; ᐧ )

P'_R← P_R+ c =

= E_ℓ(ek_R, p_R+ v; ᐧ )

hom. upd.

# recv’d_R← 21 + 1

set new

ava. bal.

Total bal.: a_S + p_S

i.e.: ToChunks(v, b, n)

38

pub_S: $10

Sherry (ek_S)

pub_R: $60

Rob (ek_R)

A_R: E_ℓ(ek_R, ek_A, a_R; ᐧ )

TXN

P_R: E_n(ek_R, p_R; ᐧ )

2. A'_S // Sherry’s new (normalized) balance

3. π_≥ for (c.Ped), (A'_S.Ped) ∈ 𝓡^b

4. π_txfer for (ek_S, ek_R, ek_A, c, A_S, A'_S) ∈ 𝓡^txfer

1. c = E_n(ek_S, ek_R, ek_A, v; ᐧ )

// for debiting Sherry, crediting Rob, and 👀 auditor

# recv’d: 35

# recv’d_R: 21

A_S: E_ℓ(ek_S, ek_A, a_S; ᐧ )

P_S: E_n(ek_S, p_s; ᐧ )

A'_S← E_ℓ(ek_S, ek_A, a_s’; r)

Added auditor ek_A!

TXN

2. A'_S // Sherry’s new balance

3. π_txfer for (ek_S, ek_R, ek_A, c, A_S, A'_S) ∈ 𝓡^txfer

4. π_≥ for (c.Ped), (A'_S.Ped) ∈ 𝓡^b

1. c = E_n(ek_S, ek_R, ek_A, v; s)

// to withdraw from Sherry and deposit for Rob + 👀 auditor

P'_R← P_R+ c =

= E_ℓ(ek_R, p_R+ v; ᐧ )

hom. upd.

set new

ava. bal.

# recv’d_R← 21 + 1

i.e.: ToChunks(v, b, n)

Too many tx’fers ⇒ chunks get large ⇒ expensive DLs.

Solution: Roll over into available balance after 2^b in-transfers.

39

pub_R: $60

Rob (ek_R)

A_R: E_ℓ(ek_R, ek_A, a_R; r)

P_R: E_n(ek_R, p_R; t)

# recv’d_R: 22

A'_R← A_R+ P_R =

= E_ℓ(ek_R, a_R+ p_R; r + t)

After 2^b in-transfers, pending chunks will become < 2^2b

⇒ after rollover, available balance chunks may be ≤ 2b bit-wide.

Solution: “Normalize” to b-bit by withdrawing 0 from your account!

A lot (like a lot) more details can be found at…

alinush.org/confidential-assets:

• Gas costs on Aptos
• TBSGS-k discrete log algorithm + benchmarks
• Global vs. asset-specific auditor (who is the effective auditor)
• Sender-picked voluntary auditors that learn the amount

40

That's it folks! 👋👋

Resources:

• Documentation:
• https://aptos.dev/en/build/smart-contracts/confidential-asset
• Confidential assets Move contract:
• https://github.com/aptos-labs/aptos-core/.../confidential_asset
• TypeScript SDK:
• https://github.com/aptos-labs/aptos-ts-sdk/.../confidential-assets
• Payments demo at confidential.aptoslabs.com (from previous slide)
• Implementation here: https://github.com/aptos-labs/confidential-payments-example
• More resources at alinush.org/confidential-assets#appendix-links

Time for Q&A (part II) 🙋

41

Appendix

42

Part 4a: Move APIs

At a high-level, the public entry Move functions are:

1. register( owner_signer, asset_type, ek, zk-proof ); Note: ek stands for "encryption key"
2. deposit ( sender_signer, asset_type, pub_amt ); Note: pub_amt is the "public amount"
3. withdraw( owner_signer, asset_type, pub_amt, zk-proof );
4. transfer( sender_signer, recipient_address, asset_type, zk-proof );
5. rotate_key( owner_signer, asset_type, new_ek, zk-proof );
6. balance( owner_address, asset_type ) → secret_bal Note: See next slide for more details

Compatible with:

• Any Aptos account types: Keyless, traditional (e.g., ECDSA, Ed25519), etc.
• Any Aptos Fungible Asset (FA) (e.g., USDC, USDT, etc.)

​

43

Actually, a bit more complicated: see next slide

Part 4b: Move APIs (additional complexity)

At a lower-level, there are some extra public entry Move functions:

• pending_balance( owner_address, asset_type ) → secret_pnd_bal
• available_balance( owner_address, asset_type ) → secret_avl_bal
1. Note: Think of the previous slide’s balance( ) as returning a tuple of both the pending and the available balance
• roll_over( owner_signer, asset_type )
• normalize( owner_signer, asset_type, zk-proof );
• set_asset_specific_auditor( apt_gov_signer, asset_type, ek_auditor, zk-proof );
• set_global_auditor( apt_gov_signer, ek_auditor, zk-proof );
• pause_incoming_txfers( owner_signer );
• resume_incoming_txfers( owner_signer );

44

Part 4c: SDK APIs (TODO: update extra/normalization/withdraw auditors)

At a high-level, the TypeScript SDK APIs exposed are:

• gen_encryption_key_pair( ) → dk, ek
• gen_withdraw_proof(secret_bal, dk, asset_type, pub_amt) → proof
• gen_transfer_proof(secret_bal, dk, ek_recipient, [ ek_auditor,]* asset_type, secret_amt) → proof
• gen_normalization_proof(secret_bal, dk, asset_type) → new_secret_bal, proof
• gen_key_rotation_proof(secret_bal, dk_old, dk_new) → proof
• decrypt(secret_bal[/amt], dk) → pub_bal[/amt]
• + APIs for calling all the public entry Move functions from previous slide

​

45

Base-2^b vs. radix-2^b representation

Definition 2: v = [v₁, …, v_ℓ] is a size-ℓ base-2^b representation of v iff.:

1. v is a radix-2^b representation of v
2. v_i ∈ [0, 2^b), for all i ∈ [ℓ] ⇒ v < (2^b)^ℓ

Definition 1: v = [v₁, …, v_ℓ] is a size-ℓ radix-2^b representation of v iff. v = ∑_{i ∈ [ℓ]} (2^b)^i-1 ᐧ v_i

46

Does NOT restrict the sizes of the v_i's at all, nor the size of v!

e.g., v = [1, 1, -1], and v' = [0, 0, 5] are size-3 radix-2 representations of v = 5

e,g., v = [1, 0, 1] is the unique size-3 base-2 representation of v = 5

Size-ℓ base-2^b representations

47

ToChunks(v, b, ℓ) → v = [ v₁, v₂, …, v_m , …, v_ℓ]

Returns the size-ℓ base-2^b representation v of v: i.e., v = ∑_{i ∈ [ℓ]} (2^b)^i-1 ᐧ v_i

ℓ could be larger than this

v₁ is the least-significant chunk (LSC)

v_ℓ is the most-significant chunk (MSC)

128-bit ± 64-bit integer arithmetic mod (~256-bit) prime q

Recall that when we "subtract" two encryptions of bal ∈ [0, 2¹²⁸) and v ∈ [0, 2⁶⁴), we get an encryption of (bal - v) mod q.

​

Q: How can the validators check that the encrypted values satisfy bal ≥ v?

A: Check that v ∈ [0, 2⁶⁴) and bal - v ∈ [0, 2¹²⁸) or, otherwise see what happens 👇

48

Attack 1 (works when you only check v ∈ [0, 2⁶⁴)):

• Set v ← (bal + 1) ⇒ transferred amount > the balance! 😱
• Validators "subtract" and get encryption of:

(bal - v) mod q =

(bal - (bal + 1)) mod q =

(-1) mod q =

(q - 1) mod q ∉ [0, 2¹²⁸)

⇒ new balance > the old balance! 😱

Attack 2 (works when you only check bal - v ∈ [0, 2¹²⁸)):

• Set v ← (q - c), for any c ≥ 1 s.t. v ∉ [0, 2⁶⁴)

⇒ transferred amount likely > the balance! 😱

• Validators "subtract" and get encryption of:

(bal - v) mod q =

(bal - (q - c)) mod q =

(bal + c) mod q

⇒ new balance > the old balance! 😱

​

In general: k-bit ± n-bit integer arithmetic mod prime q

Recall that when we "subtract" two encryptions of bal ∈ [0, 2ⁿ) and v ∈ [0, 2^k), we get an encryption of (bal - v) mod q.

​

Q: How can the validators check that the encrypted values satisfy bal ≥ v?

A: Check that v ∈ [0, 2^k) and bal - v ∈ [0, 2ⁿ), assuming that 2ⁿ + 2^k ≤ q,

49

Attack 1 (works when you only check v ∈ [0, 2^k)):

• Set v ← (bal + 1) ⇒ transferred amount > the balance! 😱
• Validators "subtract" and get encryption of:

(bal - v) mod q =

(bal - (bal + 1)) mod q =

(-1) mod q =

(q - 1) mod q ∉ [0, 2ⁿ)

⇒ new balance > the old balance! 😱

Attack 2 (works when you only check bal - v ∈ [0, 2ⁿ)):

• Set v ← (q - c), for any c ≥ 1 s.t. v ∉ [0, 2^k)

⇒ transferred amount likely > the balance! 😱

• Validators "subtract" and get encryption of:

(bal - v) mod q =

(bal - (q - c)) mod q =

(bal + c) mod q

⇒ new balance > the old balance! 😱

i.e., as long as bal' + v does not "overflow" in the field ℤ_q = {0, 1, …, q-1}; o/w, receiver's balance will wrap around.

Part 1: k-bit ± n-bit integer arithmetic modulo a prime q

Goal: TXN seeks to prove that the encrypted integers v, bal_S, bal_R ∈ [0, q) satisfy:

1. v ≤ bal_S (i.e., sender has enough balance)
2. bal_R + v < q (i.e., sender does not overflow recipient's balance)

​

Assumption 1: ElGamal ciphertext encrypts numbers in {0, 1, …, q-1} = ℤ_q

​

Assumption 2: We maintain an encrypted balance invariant (EBI) that bal_S, bal_R ∈ [0, 2ⁿ)

​

Assumption 3: TXN includes ZKPs for:

1. v ∈ [0, 2^k)
2. bal_S - v mod q ∈ [0, 2ⁿ)

​

​

50

mod q, because that's the only thing range proofs guarantee.

Part 2: k-bit ± n-bit integer arithmetic modulo a prime q

Observation 1: If bal_R ∈ [0, 2ⁿ) (from EBI) and v ∈ [0, 2^k) (from TXN ZKP) hold, then bal_R + v < 2ⁿ + 2^k.

So, if we assume 2ⁿ + 2^k ≤ q, then bal_R + v < q also holds!

​

Theorem 1: bal_R ∈ [0, 2ⁿ) & v ∈ [0, 2^k) & 2ⁿ + 2^k ≤ q ⇒ bal_R + v < q

51

Proof is sketched above ☝

Part 3: k-bit ± n-bit integer arithmetic modulo a prime q

Theorem 2: If k, n, q ∈ ℕ^* and integers bal_S, bal_R, v satisfy:

1. bal_S ∈ [0, 2ⁿ) (from EBI)
2. v ∈ [0, 2^k) (from TXN ZKP)
3. bal_S - v mod q ∈ [0, 2ⁿ) (from TXN ZKP)
4. 2ⁿ + 2^k ≤ q (from Theorem 1)

Then, v ≤ bal_S (as integers, no mod q anymore!) and, of course, bal_R + v < q (restating Theorem 1)

​

Proof: Suppose v > bal_S. Let δ = bal_S - v. Then δ < 0. We know that bal_S - v mod q ∈ [0, 2ⁿ) ⇔ 0 ≤ δ mod q < 2ⁿ ⇔ ∃q s.t. 0 ≤ δ + q · q < 2ⁿ. Note that if q = 0 ⇒ δ ≥ 0 ⇒ contradiction. So, q ≠ 0. Next, suppose q ≥ 2.

Lemma 1: Since δ = bal_S - v, and (1) + (2) hold ⇒ δ ∈ (-2^k, 0) b.c. min bal_S = 0 and max v = 2^k - 1 ⇒ δ ≥ -(2^k-1).

�Applying Lemma 1 and (4), we can lower bound: δ + q · q ≥ -(2^k-1) + 2(2ⁿ + 2^k) = 2ⁿ⁺¹ + 2^k + 1. But we know from before that δ + q · q < 2ⁿ. And 2ⁿ⁺¹ + 2^k + 1 exceeds that. Contradiction. So, q can only be 1.�

Finally, since q = 1, we know δ + q · q < 2ⁿ ⇔ δ + q < 2ⁿ. But q ≥ 2ⁿ + 2^k and δ ≥ -(2^k-1) ⇒ δ + q ≥ 2ⁿ + 2^k - (2^k-1) = 2ⁿ + 1. This is a contradiction. Original, v > bal_S assumption must be false ⇒ v ≤ bal_S. QED.

52