Confidential-Only Transfers

Execute direct encrypted transfers between Encrypted Token Accounts (ETAs) or to public ATAs without using the mixer pool for fast confidential payments.

Confidential-only transfers enable direct movement of funds between Encrypted Token Accounts (ETAs) without routing through the Unified Mixer Pool. These transfers hide transaction amounts while maintaining on-chain efficiency.

Overview

Confidential transfers operate entirely within the Confidential Domain-they never touch the mixer pool. This provides:

Benefit	Description
Amount Privacy	Transfer amounts are encrypted, invisible to observers
Efficiency	No mixing delay required
Lower Complexity	No ZK proofs for UTXO spending
Immediate Settlement	Funds available instantly

Trade-offs

Aspect	Confidential Transfer	Mixer Transfer
Amount Privacy	✓ Hidden	✓ Hidden
Sender/Recipient Privacy	✗ Visible on-chain	✓ Anonymous
Speed	Immediate	Mixing delay required
Complexity	Simple	Requires ZK proofs
Use Case	Fast private payments	Breaking transaction links

Transfer Types

Confidential transfers support multiple destination types:

ETA → ETA (Confidential to Confidential)

The most common confidential transfer-moving encrypted funds between two ETAs:

Aspect	Details
Sender Balance	Decremented (encrypted arithmetic)
Recipient Balance	Incremented (encrypted arithmetic)
On-Chain Visibility	Only that a transfer occurred between addresses
Amount Visibility	Hidden from everyone except sender, recipient, and MPC

ETA → ATA (Confidential to Public)

Unshielding funds from an encrypted account to a public token account:

Aspect	Details
Sender Balance	Decremented (encrypted)
Recipient Balance	Incremented (plaintext)
Amount	Becomes visible on-chain at destination
Use Case	Paying merchants, off-ramping, public transactions

How It Works

The MPC's Role

Confidential transfers are processed by the Arcium MPC network. The MPC performs encrypted arithmetic without ever seeing plaintext values:

Receive encrypted inputs - Sender's balance, transfer amount
Verify sufficiency - Check sender has enough funds (in encrypted domain)
Update balances - Decrement sender, increment recipient
Commit new ciphertexts - Write updated encrypted balances on-chain

Encryption for Recipient

When transferring to another user, the MPC must encrypt the recipient's new balance using their X25519 public key. This is why X25519 registration is required for receiving transfers.

Sending to Registered Users

When the recipient has registered their X25519 public key:

Step	Action
1	Sender specifies recipient's L1 address and amount
2	Protocol looks up recipient's registered X25519 public key
3	Sender encrypts transfer amount for MPC submission
4	MPC updates both balances
5	Recipient decrypts their new balance using their X25519 private key

Sending to Non-Registered Users

A powerful feature of Umbra is the ability to send confidential transfers to users who haven't yet registered their X25519 public key. The transfer still occurs, but with a caveat.

How It Works

Scenario	Behavior
Recipient not registered	Transfer held in pending state
Recipient registers later	Can claim all pending transfers in a single transaction
Confidentiality	Maintained throughout-amounts never exposed

Claiming Pending Transfers

When a non-registered user later registers their X25519 public key, they can claim all pending transfers in one transaction:

Register X25519 public key
Call claim instruction
All pending transfers are processed
ETA balance updated with sum of all pending

This is efficient for recipients who receive multiple transfers before registration.

Transaction Flow

Instruction: `ConfidentialTransfer`

Parameter	Description
sender	Sender's L1 address (signer)
recipient	Recipient's L1 address
amount	Encrypted transfer amount
mint	Token mint address

Step-by-Step Flow

Authorization - Sender signs with their L1 key
Encryption - Amount encrypted using shared secret with MPC
Submission - Transaction submitted to Umbra program
MPC Processing - Arcium network processes the encrypted computation
Balance Update - Both sender and recipient balances updated on-chain
Decryption - Each party decrypts their new balance with their X25519 key

Privacy Analysis

What's Hidden

Information	Visibility
Transfer Amount	Hidden (encrypted)
Sender's Balance	Hidden (encrypted)
Recipient's Balance	Hidden (encrypted)

What's Visible

Information	Visibility
Sender Address	Visible on-chain
Recipient Address	Visible on-chain
That a transfer occurred	Visible
Token Mint	Visible
Timestamp	Visible

Privacy Comparison

Privacy Goal	Confidential Transfer	Mixer
Hide amounts	✓	✓
Hide sender	✗	✓
Hide recipient	✗	✓
Break transaction links	✗	✓

Recommendation: Use confidential transfers for everyday payments where speed matters and parties are known. Use the mixer when you need to break transaction links or hide participation.

Use Cases

Payroll

Salary amounts hidden from public
Employees visible (acceptable for payroll)
Fast, immediate settlement

B2B Payments

Benefit	Description
Competitive Privacy	Competitors can't see payment amounts
Relationship Visible	Business relationship is public (often acceptable)
Audit Trail	Clear on-chain record of payments

Personal Transfers

Send funds to friends/family with amount privacy
No need for full anonymity when parties know each other
Faster than mixer for casual use

Requirements

Sender Requirements

Requirement	Description
X25519 Registered	Must have registered X25519 public key
ETA Initialized	Must have an existing ETA for the token
Sufficient Balance	Encrypted balance must cover transfer
L1 Key	Must sign the transaction

Recipient Requirements

Requirement	For Immediate Receipt	For Pending
X25519 Registered	Required	Not required
ETA Initialized	Auto-created if needed	Auto-created on claim

Summary

Aspect	Details
Transfer Types	ETA → ETA, ETA → ATA
Amount Privacy	Always hidden
Address Privacy	Visible on-chain
Speed	Immediate (no mixing delay)
Complexity	Lower than mixer
Non-Registered Recipients	Supported via pending transfers
Claim Mechanism	Single transaction claims all pending
Best For	Fast private payments where parties are known

On this page