Confidential Tokens on Stellar: Privacy, Compliance, and Public Blockchain Payments
Financial transactions on public blockchains are transparent by default. Every payment amount, sender, and recipient is visible to anyone who queries the ledger. For many business and institutional use cases, this level of transparency is a barrier to adoption. Payroll, vendor payments, intercompany transfers, and competitive trade execution all require some degree of confidentiality.
The Stellar Development Foundation has been developing confidential token capabilities that would allow transaction amounts to be hidden from public view while remaining verifiable and auditable. This article examines what confidential tokens are, how they differ from privacy coins, what the current development status is, and what developers should understand before building with them.
Key Takeaways
What Confidential Tokens Are
On a standard Stellar transaction, the following information is publicly visible:
| Field | Visibility |
|---|---|
| Sender account | Public |
| Recipient account | Public |
| Asset type | Public |
| Amount | Public |
| Memo | Public |
| Transaction hash | Public |
With confidential tokens, the goal is to change one element:
| Field | Visibility |
|---|---|
| Sender account | Public |
| Recipient account | Public |
| Asset type | Public (or optionally confidential) |
| **Amount** | **Hidden (cryptographically committed)** |
| Memo | Public |
| Transaction hash | Public |
The sender and recipient remain visible. The asset type may remain visible. But the amount is replaced with a cryptographic commitment that proves the transaction is valid (positive amount, no inflation, sender had sufficient balance) without revealing the actual value.
How It Works: Cryptographic Foundations
Pedersen Commitments
A Pedersen commitment allows someone to commit to a value without revealing it. The commitment has two properties:
In simplified terms, a commitment to amount v looks like:
C = v * G + r * HWhere G and H are generator points on an elliptic curve, v is the amount, and r is a random blinding factor. Without knowing r, an observer cannot determine v from C.
Range Proofs
A Pedersen commitment alone does not prevent an attacker from committing to a negative number (which would effectively create money). Range proofs solve this by proving that the committed value falls within a valid range (e.g., 0 to 2^64) without revealing the value itself.
Bulletproofs are a compact form of range proof that is particularly efficient for blockchain use. They produce small proofs (around 700 bytes) and can be verified quickly, making them practical for inclusion in blockchain transactions.
Verifying Balance
The key property of Pedersen commitments for payments is that they are homomorphic: you can add commitments together and the result is a commitment to the sum of the original values. This means validators can verify that:
Sum of input commitments = Sum of output commitments + commitment to feeThis proves that no value was created or destroyed in the transaction, without anyone learning the individual amounts.
Privacy vs. Anonymity
This distinction is critical for understanding Stellar's approach:
Privacy coins (Monero, Zcash) aim to hide the identities of senders and recipients, making transactions difficult or impossible to trace. This creates challenges for regulatory compliance, anti-money laundering (AML), and know-your-customer (KYC) requirements.
Confidential tokens on Stellar take a different approach:
| Property | Privacy Coins | Stellar Confidential Tokens |
|---|---|---|
| Sender identity | Hidden | Visible |
| Recipient identity | Hidden | Visible |
| Transaction amount | Hidden | Hidden |
| Transaction graph | Obfuscated | Visible |
| Regulatory compliance | Difficult | Compatible |
| AML/KYC | Challenging | Supported |
Stellar's approach preserves the ability to trace who transacted with whom, which regulators and compliance officers require. What it hides is how much was transferred, which is often the sensitive business information that institutions want to protect.
SDF CEO Denelle Dixon has framed the design philosophy: "The base layer is always going to be open. Then the institution gets to decide how compliance and privacy come into play." The practical problem SDF identifies is "self-doxxing": when transacting parties reveal public addresses to each other, both can view all past and future transactions and asset balances linked to that address.
Why Institutions Need Transaction Confidentiality
Payroll
When a company pays employees using a public blockchain, every employee's salary is visible to anyone who identifies the sending and receiving accounts. Confidential amounts solve this by hiding the payment values while the payroll transaction itself remains auditable.
Business-to-Business Payments
Vendor payments reveal pricing, contract terms, and business relationships. A retailer paying a supplier on a public blockchain effectively publishes its cost structure. Confidential amounts keep the transaction relationship visible (for compliance) while hiding the competitive intelligence.
Institutional Settlement
When financial institutions settle large positions, the amounts involved can move markets if visible in real time. Settlement needs to be verifiable and auditable after the fact, but broadcasting the amount to the entire network during settlement creates front-running and information leakage risks.
Tokenized Assets
As more real-world assets are tokenized on Stellar (including the expected DTCC integration), institutional holders may not want their position sizes visible on a public ledger. Confidential amounts allow holding and transferring tokenized securities without revealing portfolio details.
Coexistence with Compliance
A common concern with any privacy feature on a blockchain is whether it undermines regulatory compliance. Stellar's approach is designed to maintain compliance:
Auditor view keys: The confidential token contracts support a designated auditor role that can decrypt and view transaction amounts and account balances within the confidential wrapper. A regulated stablecoin issuer like Circle could see USDC transaction amounts while the public cannot.
Selective disclosure: Account holders can prove specific transactions to chosen parties (auditors, regulators, compliance officers) without revealing their full activity history. This uses the blinding factors from Pedersen commitments.
Account-level controls: Stellar's existing authorization and clawback controls (CAP-0035, CAP-0018) cascade into the confidential layer. The issuer retains the ability to freeze or recover assets.
Configurable compliance policy: The contracts support pluggable policy contracts that function as allow-list or block-list identity registries. Asset issuers decide whether transfers require KYC checks.
FATF Travel Rule compatibility: Because sender and recipient addresses remain public, Stellar's confidential tokens are architecturally compatible with FATF Recommendation 16. Regulated entities can still collect and share originator and beneficiary information as required.
Current Development Status
Confidential token capabilities on Stellar are implemented as Soroban smart contracts, not as protocol-level changes. The cryptographic foundations are live on mainnet, but the confidential token contracts themselves are in developer preview.
| Component | Status | Where |
|---|---|---|
| BLS12-381 host functions (CAP-0059) | Live | Mainnet (Protocol 22) |
| BN254 host functions (CAP-0074) | Live | Mainnet (Protocol 25, Jan 2026) |
| Poseidon hash functions (CAP-0075) | Live | Mainnet (Protocol 25) |
| Extended ZK functions (CAP-0080) | Live | Mainnet (Protocol 26, May 2026) |
| Confidential Token contracts | Developer Preview | Testnet only |
| Privacy Pools prototype | Research prototype | Testnet only |
SDF announced the confidential tokens developer preview in late June 2026, built by OpenZeppelin (contract suite) with Nethermind (UltraHonk verifier). Proofs are written in Noir (Aztec's ZK language) and generated client-side via WebAssembly, so private data never leaves the user's device. On-chain verification uses the BN254 host functions added in Protocol 25.
The contracts wrap any existing SEP-41 token. Depositing USDC into the confidential wrapper converts the balance to a Pedersen commitment. Transfers operate on committed values. Withdrawing converts back to a standard transparent balance.
Mainnet availability is targeted for late summer 2026, pending completion of security audits.
Important: Do not build production applications that depend on confidential token features until audits are complete and SDF announces production readiness. The contracts and verifiers are explicitly labeled as unaudited and not intended for real assets.
Technical Considerations
Transaction Size
Confidential transactions are larger than standard transactions due to the inclusion of commitments and range proofs:
| Component | Standard Transaction | Confidential Transaction (Estimated) |
|---|---|---|
| Amount field | 8 bytes (int64) | ~33 bytes (Pedersen commitment) |
| Range proof | None | ~700 bytes (Bulletproof) |
| Total overhead | 0 | ~725 bytes per output |
This increase affects network throughput and storage costs. A Stellar network processing 200 transactions per second would need to handle significantly more data per transaction with confidential amounts.
Verification Performance
Range proof verification is more computationally expensive than standard amount verification. Validators need to perform elliptic curve operations for each confidential transaction, which increases the CPU cost of consensus.
Bulletproofs support batch verification, where verifying N proofs together is faster than verifying them individually. This partially mitigates the performance impact for validators processing blocks of transactions.
Compatibility
Confidential tokens need to interact with the existing Stellar ecosystem:
Risks and Limitations
Regulatory Risk
Regulators in some jurisdictions may view any privacy enhancement on a blockchain negatively, even if the implementation is compliance-friendly. The Travel Rule (requiring sender/recipient information for transfers above certain thresholds) applies to amounts as well as identities in most interpretations.
Implementation Complexity
Cryptographic systems are difficult to implement correctly. Bugs in commitment schemes or range proofs could allow inflation (creating tokens from nothing) or other exploits. The implementation will need extensive auditing and testing.
User Experience
Confidential transactions are more complex for users. Wallet applications need to manage blinding factors, and recovering from lost blinding factors may be impossible. The user experience needs to be designed so that confidentiality does not come at the cost of usability.
Performance Trade-offs
The additional data and computation required for confidential transactions reduces the network's effective throughput. This trade-off needs to be weighed against the privacy benefits, especially as Stellar prepares for higher-volume use cases like institutional settlement.
What Developers Should Monitor
How This Connects to Stellar's Broader Strategy
Confidential tokens fit into Stellar's positioning as a compliance-friendly network for institutional use:
The goal is not to compete with privacy-focused blockchains. It is to give regulated institutions a reason to use a public blockchain by solving the "everyone can see our transaction amounts" problem.
Sources and Further Reading
*Prepare for confidential assets on Stellar. LumenQuery provides managed Horizon API and Soroban RPC with monitoring and analytics tools that will support confidential token queries as they become available. Start free.*