Developer Preview: Confidential Tokens on Stellar

Editor's note: Stellar's Developer Previews put new developer tooling and protocol capabilities in developers' hands before they're production-ready. While they're not yet approved for mainnet, the Confidential Token contract is live on testnet. Preview and test them now while the contract and verifier audits are underway.

Today we're introducing our latest privacy feature: Confidential Tokens, a contract suite from OpenZeppelin, wired to an UltraHonk verifier implemented by Nethermind, that adds private balances and private transfer amounts to any SEP-41 token.

Privacy on a public blockchain isn't one thing. Different use cases need different properties, and the architecture you choose at the start decides what you can do later.

Confidential Tokens are deliberately scoped: they hide balances and transfer amounts while keeping sender and recipient addresses visible. For developers already transacting onchain, where amounts and balances are public by default, that's a meaningful step forward. Suitable use cases include treasury management, payroll, and institutional settlement, among others.

By comparison, the other option in Stellar's privacy stack—privacy pool implementations like Stellar Private Payments (SPP)—shields both the parties and the amounts. This post focuses on the Confidential Token use case: known counterparties, hidden amounts.

Architecturally, a Confidential Token is a wrapper contract. A user takes any existing SEP-41 token—USDC issued via the Stellar Asset Contract, a contract-native token, anything that implements the standard—and deposits it into a confidential token contract.

Inside the wrapper, the balance is encoded as a Pedersen commitment—hidden from public view, but fully verifiable by the network. Transfers between accounts inside the wrapper move funds without revealing values. To exit, a user withdraws back to the underlying SEP-41 token.

The base ledger stays open and auditable. Privacy lives entirely at the application layer, in the wrapper contract. This isolation is by design: if a bug were ever found in a confidential token circuit, it could only affect the tokens inside that wrapper. By design, any vulnerability is contained to the token(s) inside that wrapper, without affecting the underlying asset or wider network.

Proofs are written in Noir and verified onchain via Nethermind's UltraHonk verifier, using the cryptographic host functions introduced in Protocol 25 (X-Ray). This is a working testnet implementation you can build against today.

This preview includes primitives designed to support compliance-oriented workflows:

• Auditor view key. A designated auditor role can view transaction amounts and account balances for assets in the wrapper.
• Selective disclosure. Account holders can prove a specific transaction occurred to a specific party without exposing the rest of their activity.
• Account-level freezing. Cascades from the existing Stellar Asset Contract (SAC) controls.
• Configurable compliance policy engine. Lets you plug in policy contracts that act as allow-list or block-list identity registries.

The full compliance extensions doc walks through the freeze, SAC passthrough, and policy hook design in detail. These compliance extensions are open source and actively being iterated on.

The quickest way to get a feel for Confidential Tokens is to run the demo by OpenZeppelin locally and make a confidential transfer on testnet.

The demo on Stellar Testnet walks through three roles: account holder, disclosure receiver, and auditor. To try it in the browser, connect your wallet—we recommend Freighter on Stellar Testnet. Go to Stellar Lab and select "Fund account" to get test XLM.

To run locally:

1. Clone stellar-confidential-token-demo
2. Review README for basic and more advanced usage
3. Pick the relevant modules from the lib
4. Submit issues during the testnet window.

We welcome design partners and community contributions—If you're building compliance-focused privacy solutions on Stellar, an SCF cohort member or joined our recent Stellar Hacks: Real-World ZK hackathon—share what you're working on in our Developer Discord.

We're excited to have Boyan Barakov (Senior OSS Developer, OpenZeppelin) join Alessandro Voto (Senior PM, Stellar) to introduce Confidential Tokens and the work with OpenZeppelin furthering privacy onchain.

Tune in Jul 2 @ 4:00 PM UTC to watch the stream on @BuildOnStellar

Confidential Tokens are part of a broader privacy stack on Stellar. For background on the upgrades that made this possible, see: stellar.org/privacy, Stellar's developer docs on privacy, and the taxonomy in the Appendix below.

An easy way to understand privacy solutions onchain is to ask:

What does the network see, and what stays hidden?

Why both lanes exist. Confidential Tokens are designed for known-counterparty flows where amounts shouldn't be public (e.g. payroll, treasury management, B2B settlement). You could have two banks settling in USDC with each other, where each side already knows who they're transacting with, but the settlement amounts (and the resulting balances inside the wrapper) stays reasonably hidden from the wider network.

Stellar's privacy layering hierarchy

Application layer: Stellar smart contracts that implement specific privacy behavior. These include Confidential Tokens and privacy pool implementations like Stellar Private Payments (SPP).

Verifier layer: An onchain verifier is a smart contract that accepts a compact ZK proof and confirms its validity without re-running the original computation. Examples include Nethermind's UltraHonk Verifier (used by the Confidential Token contract) and the RISC Zero (Groth16) Verifier. The original verifier was built by a community member, @yugocabrio. Nethermind took ownership and updated it to use the Stellar Protocol 25/26 host functions, making it more efficient and practical for testnet evaluation.

Cryptographic host functions: Built into the Stellar protocol at the base layer: elliptic curve operations on the BN254 and BLS12-381 curves, and the Poseidon/Poseidon2 hash function. Introduced in the X-Ray (Protocol 25) and Yardstick (Protocol 26) upgrades.

Base (public) ledger: Privacy lives in the layers above it, never in the base.