OpenZeppelin Brings Confidential Balances and Transfers to Stellar

As part of an ongoing partnership with the Stellar Development Foundation, OpenZeppelin is delivering the next major addition to its Stellar library: Confidential Token contracts.

OpenZeppelin's contracts already run as core infrastructure on Stellar with more than $1.7B in total value locked across the network. Bringing confidential token primitives to the network extends that foundation into institutional and commercial applications. It gives regulated activity something it has largely gone without: the ability to transact without putting every balance and amount in public view.

The contracts are audited by OpenZeppelin and ready to be deployed on Stellar mainnet. They implement the ERC-7984 confidential token interface, aligning this work with the shared standard the Confidential Token Association is driving across ecosystems, with Stellar and OpenZeppelin among its members.

Practical confidentiality on public networks

Most financial and commercial activity requires basic privacy. Consider a routine payroll run, a settled trade between two counterparties, or an internal treasury transfer. None should have to broadcast every amount and balance to the entire network, even when the transaction itself is meant to settle onchain and remain verifiable. That constraint has kept a significant amount of activity off public ledgers.

The parallel is the early web. As Boyan Barakov, Senior Open Source Developer at OpenZeppelin, writes in this deep dive, public blockchains sit roughly where the internet did before traffic was encrypted: open and functional, but missing a privacy layer. Online commerce only took off once encryption became standard. Onchain finance is at a similar point, and a practical model that balances confidentiality with compliance is what moves it forward.

Confidential Tokens are that layer for Stellar. Balances and transfer amounts stay private while the activity still settles on the network, so payroll, treasury management, and institutional settlement can move onchain without exposing the numbers behind them. A corporation can move funds between its own branches without publishing the amounts, and an employer can keep compensation confidential while the employment relationship itself stays visible.

This design is confidential, not anonymous. It is built for workflows where counterparties already know each other but figures need to stay private, rather than for hiding who is participating.

Compliance and control out of the box

For regulated assets, confidentiality is useful if administrative control is maintained. Under this model, an auditor can view amounts and balances where the rules require it, and an account holder can prove a single fact to a single party, confirming a payment met a reporting threshold, for example, without exposing the rest of their activity.

Key compliance and administrative controls in the Confidential Token contracts include:

• Configurable compliance policies: Plug in policy contracts that act as allow-list or block-list identity registries
• Scoped compliance visibility: Designated reviewers can see amounts and balances where oversight requires it, without a single key that exposes everyone's activity
• Selective disclosure: an account holder can prove a single fact to a single party, without exposing anything else, for example, the amount of one transaction, or whether a balance is above a threshold. A basic disclosure flow will come with the SDK, and the architecture supports building custom disclosure circuits and flows for specific use cases
• Account-level freezing: Cascades from the existing Stellar Asset Contract controls
• Authorized asset recovery: Clawback, governed by separation between administrative and auditing roles, so no single party can both view balances and move funds unilaterally

How it works: wrapper and standalone models

Architecturally, a Confidential Token can operate as a wrapper over an existing asset. An existing SEP-41 token is deposited into the confidential token contract, transacted with balances and amounts hidden, and withdrawn back to the underlying token, which is never modified. The design also supports issuing a confidential token directly, with confidential issuance, though that standalone model isn’t included in this release.

For the full design rundown, see Boyan Barakov's article, which details the deployment models, the controls behind them, and their application to confidential stablecoins.

Inside the v0.8.0 release

The Confidential Token lives in its own package, stellar-confidential.

Note that the OpenZeppelin security audit scope covers the onchain Soroban smart contracts and circuits. The SDK and client-side tooling are a separate, unaudited demo in active development, not part of this release.

This release includes:

• The Confidential Token contract: A contract that sits on top of any SEP-41 token, giving it private balances and transfer amounts. Balances are held as Pedersen commitments, and every operation on private state carries an UltraHonk proof, verified onchain.
• Auditor and verification key registries: the onchain registries that manage auditor access and the verification keys for proofs.
• A compliance extension: Account freezing, Stellar Asset Contract passthrough, external authorization policy, and authorized asset recovery (clawback).
• Noir proof circuits, with pinned verification keys.
• Examples: A compliant token, an allowlist policy, and a factory, under examples/confidential.

v0.8 also ships work beyond Confidential Token, including a compliance toolkit for RWA (T-REX) tokens, a new way to compose fungible and non-fungible token types with compile-time safety, and smart account updates.

Getting started

Whether you're already building on Stellar or evaluating confidential assets for your organization’s workflows, you can start testing the audited contracts in OpenZeppelin's library for Stellar, released in v0.8.0.

The documentation and developer preview video cover the design and usage, and the step-by-step example is a good starting point walking through the whole suite with a testnet deployment. Make sure to also check the best practices section providing guidance for different stakeholders. Further integration guides and SDK packages will follow.

A note for teams using the smart-accounts module. v0.8.0 changes how signers authorize: they now commit to a structured authorization digest, so offchain signing flows will need updating (migration guide in packages/accounts/README.md).

This follows a related security fix in v0.7.3 for a delegated-signer issue (GHSA-jpg9-m7w4-c7wc), which affects versions below 0.7.3 and the 0.8.0 release candidates (rc.1 up to 0.8.0). Affected users should upgrade, including any delegate accounts.