Practical Confidential Stablecoins: An Issuer-Controlled Architecture

This is a guest post by Boyan Barakov, Senior OSS Developer at OpenZeppelin, who worked on the Confidential Token contract on Stellar.

This is the first article in a two-part series. Starting from OpenZeppelin's open-source confidential token for Stellar, it examines how confidential stablecoins can protect transaction amounts and balances while preserving the controls and visibility needed in an issuer-managed system. The second article will detail the implementation itself.

A public blockchain serves as a transparent and trustless settlement layer, open to any economic actor. Transacting parties use cryptographically derived public keys, which do not directly reveal their real-world identities. However, because the ledger is fully verifiable, every transaction and every amount remains permanently on the record. Anyone can reconstruct the complete transaction history of an address: how it was funded, which addresses it interacted with, how much moved, and when. When this information is combined with the extensive data footprints users leave outside the blockchain, real-world identities can often be linked to onchain activity which is often seen as a potential risk.

The early web that was built on open and unencrypted protocols offers a useful parallel. HTTP alone couldn't unlock the internet's commercial potential, and it was only after the introduction of SSL/TLS encryption that large-scale consumer activity became possible. Public blockchains are at a similar inflection point today. Without a robust privacy layer, one that balances user confidentiality with regulatory compliance, serious commercial and institutional use will likely remain niche and experimental.

Stablecoins are a good illustration of this challenge. They represent one of the strongest use cases of the blockchain: they can settle payments in seconds, reduce transaction costs, and serve retail, business, and institutional users on the same infrastructure. Yet the transparency that makes their settlement verifiable also makes them difficult to use for many ordinary financial activities.

The challenge, then, is not only to add privacy. It is to determine what kind of privacy a stablecoin needs and how that privacy should interact with the issuer's responsibilities and operational controls.

The Starting Point: A Confidential Token for Stellar

At OpenZeppelin, we have built an open-source confidential token for Stellar: a set of composable contract modules, standardized interfaces aligned with ERC-7984, and an example implementation, all publicly available in the repository.

The design uses the Stellar network's publicly verifiable ledger as the settlement layer and builds confidentiality on top of it. Balances and transfer amounts are stored onchain as cryptographic commitments and not as readable numbers, and every state change is verified against a zero-knowledge proof.

This article takes that work as its starting point and narrows the discussion to one token class: stablecoins. They provide a useful model for examining which information should remain private, and which controls the token architecture should enable.

Defining the Spectrum: Anonymity and Confidentiality

Before going further, it is important to separate two different forms of privacy: anonymity and confidentiality.

Anonymity hides who is transacting, such that the transaction graph can't be reconstructed. Whereas confidentiality hides what is being transacted: the amounts moving between parties and the balances they hold, while the participating addresses remain public.

The confidential token for Stellar follows the second model. An observer can see that account A transferred tokens to account B, but not how much was moved between them.

The Case for Visible Identities

At first glance, confidentiality without anonymity might look like a half-measure, but actually, these two models do not necessarily compete: anonymity-preserving systems serve legitimate use cases in which the transaction graph itself is sensitive. However, a large share of stablecoin activity might not require the relationship between the parties to be hidden.

Consider examples where corporations move funds between their own branches, or scenarios where employment is known but compensation is confidential. In both cases, the existence of the counterparty relationship is public, and the transacting amount is the sensitive data.

Keeping participant addresses visible at the smart contract boundary, especially in an issuer-controlled stablecoin, is an architectural choice because of its practical benefits on the compliance side. When addresses remain public, the token contract can apply controls to a specific account. An authorized operator can restrict an identified address, while external policy systems can determine whether an account is permitted to participate.

Anonymous systems can also support account restrictions and other administrative actions, but doing so generally requires more complex cryptographic machinery because the contract cannot directly identify the participants. Keeping addresses visible makes these controls simpler to implement, examine, and explain.

Confidentiality, of course, has its limits. It's not a definitive answer to blockchain privacy, it rather should be considered as a pragmatic point on the spectrum: one designed for payment activity in which financial values are sensitive and auditable account-level controls are required.

Design Requirements for an Issuer-Controlled Stablecoin

A stablecoin issuer is responsible for operating the asset, maintaining its policies, and responding to events involving particular accounts. Confidentiality must therefore coexist with a number of operational capabilities.

First, the issuer needs a way to restrict identified accounts. A restriction must apply consistently across the token's operations, including sending, receiving, depositing, and withdrawing.

Second, the token needs to enforce decisions made by external policy and screening systems. Identity verification, account eligibility, risk assessment, and similar processes take place outside the token contract. The onchain system should be able to consume their results without duplicating those processes in its own logic.

Third, authorized parties may need scoped visibility into transfers and balances. A confidential system must provide that visibility without creating a universal key capable of exposing every user's financial activity.

Fourth, the architecture needs a controlled mechanism for intervening that should prevent any single operational role from both obtaining private financial information and exercising unrestricted control over the assets.

Finally, an account holder may need to disclose to a third party one specific fact, such as the amount of an incoming payment or whether a balance falls below a threshold, without revealing their complete history.

These capabilities do not make a stablecoin deployment compliant by themselves. They define the technical building blocks that an issuer can combine with proper governance, security, legal, and operational processes.

From Requirements to Mechanisms

The Stellar confidential token addresses each of these requirements through a separate mechanism. Together, they form an architecture in which privacy is neither absolute nor controlled by a single privileged actor.

Account Restrictions

Authorized administrative roles can freeze or unfreeze a specific account. The contract stores a persistent flag for that address and checks it during every relevant operation. Once restricted, the account cannot send, receive, deposit, or withdraw funds.

The system can act on an identified account while preserving the confidentiality of the financial information associated with it.

External Policy Enforcement

Identity verification and participant screening are offchain processes. They may involve an issuer's internal systems, specialized service providers, or a shared registry used across multiple assets. The token contract does not need to reproduce these systems. Its role is to enforce their outcome.

The confidential token provides a pluggable policy hook for this purpose. Before a state change settles, the token calls an external verification method to determine whether the participating accounts are authorized for that operation.

An issuer operating several stablecoins across different jurisdictions can point multiple token contracts to a common policy registry. The policy can evolve without requiring the core confidential layer to be redesigned.

This separation also creates a clear boundary of responsibility: external systems decide whether an operation is permitted, while the token contract ensures that the decision is consistently enforced onchain.

Scoped Audit Visibility

To support compliance processes such as reporting and retrospective transaction monitoring without resorting to a global “master view key,” the token implements a scoped, dual-auditor model. Visibility over transfer amounts and account balances is compartmentalized and assigned to designated auditors.

Each confidential transaction provisions encrypted reporting data across two asymmetric channels. The inbound channel gives the recipient's auditor visibility into the incoming transfer. The outbound channel gives the sender's auditor visibility into the amount transferred and the sender's remaining post-transaction balance.

Authorized Asset Intervention

When required for legal and compliance purposes, intervening in the assets of a specific account for recovery purposes is particularly difficult when balances are confidential. An administrative operator can identify the account but cannot see the amount it holds. The party with auditing visibility can determine that amount but should not be able to move the assets.

The confidential token resolves this tension through coordination between separate administrative and auditing roles.

This separation is designed to ensure a clean system of checks and balances: the administrative operator cannot initiate a recovery on its own because it lacks the cryptographic visibility to generate a valid proof, and the auditing entity cannot independently move or freeze funds.

Prove on Demand: Targeted Selective Disclosure

Administrative controls and auditor visibility apply in situations in which an authorized party needs visibility for compliance purposes or must act on a particular account. Other requests are much narrower.

A bank's review team might ask a customer to demonstrate that a specific incoming payment matches an invoice. An onboarding provider might request evidence that a corporate balance is above a particular threshold. In each case, the account holder needs to reveal one isolated fact to one counterparty, not expose an entire transaction history.

The auditor mechanism is too broad for this purpose. What is needed instead is a mechanism through which the account holder can prove a single statement in a form that the recipient can verify against the public ledger.

The confidential token design supports this through a selective disclosure layer that operates entirely offchain:

1. The requesting counterparty gives the account holder a unique, one-time reference tied to the inquiry.
2. The holder generates a zero-knowledge proof establishing that the requested statement is true and tied to an existing onchain commitment.
3. The holder sends the proof to the counterparty offchain.
4. The counterparty verifies the proof against the onchain record and learns only the requested fact.

Because selective disclosure takes place entirely offchain, it adds no overhead to the token contracts and leaves no onchain record of the individual disclosure event.

Deployment Paths

The confidential token design supports two deployment models.

For an existing stablecoin, the confidential token can operate as an adjacent wrapper around the base asset. This allows the transparent and confidential forms of the asset to coexist while leaving the issuer's existing token infrastructure unchanged.

In this model, the base asset remains the single source of truth for total supply. Users deposit the transparent asset into the confidential contract, transact using confidential balances and amounts, and later withdraw back to the transparent token. The confidential pool can therefore be introduced as an additional mode of use rather than as a replacement for the existing asset.

This approach creates a gradual adoption path. An issuer can make confidentiality available for activities that need it while preserving transparent settlement for other users and integrations.

For a new stablecoin, the confidential contract can instead function as the asset itself. In this standalone model, the issuance boundary is also confidential: mint and burn amounts remain hidden, and the contract maintains total supply as a cryptographic commitment updated with each issuance operation.

Although the total supply is not publicly readable, the issuer can prove statements about it when needed. For example, it can attest to an exact figure or demonstrate that the supply satisfies a defined condition by generating a proof that anyone can verify against the onchain commitment.

The wrapper and standalone models offer different trade-offs. The wrapper prioritizes compatibility and gradual adoption. The standalone model extends confidentiality to issuance and supply, but requires the broader stablecoin system to be designed around cryptographic commitments from the beginning.

Confidentiality Without Surrendering Control

Confidential stablecoins do not have to choose between exposing every financial value and removing the issuer's ability to operate the asset.

By keeping account addresses visible while concealing balances and transfer amounts, the architecture preserves account-level controls, external policy enforcement, scoped audit visibility, authorized asset intervention, and targeted disclosure. Zero-knowledge proofs allow the contract and designated counterparties to verify what they need without making the underlying financial data public.

This approach does not attempt to solve every form of blockchain privacy. Its goal is narrower and practical: to protect the financial information that ordinary payment activity requires while retaining the mechanisms needed to manage issuer-controlled assets.

The next article in this series will examine how these mechanisms are implemented in OpenZeppelin’s confidential token for Stellar, including the contract modules, proof flows, auditor channels, and role separation that make the architecture work.

The opinions, statements, and assessments in this article are solely those of the individual author(s) and do not constitute legal advice, nor do they necessarily reflect the views of OpenZeppelin. Given the inherent nature of the information in this article, its contents are based on information gathered and understood at the time of its creation. It is subject to change. The information is provided on an “as-is” basis without representation or warranty and the author accepts no liability for any action or failure to act taken in response to the information contained or referenced in this article.