Privacy in Onchain Finance: Balancing Transparency and Confidentiality

A trading desk moves a $50 million position into a tokenized fund. Within minutes, anyone watching that wallet can see the size of the trade, the counterparty, and the timing, and can act on it before the desk finishes rebalancing. On a public blockchain, that kind of exposure is the network working exactly as designed, which is an obstacle for financial institutions weighing onchain finance.

Every transfer, balance, and contract interaction on a public network is visible to anyone who wants to look. This transparency is a large part of why blockchain works as settlement infrastructure: it removes the need for trusted intermediaries and gives every participant a shared, verifiable source of truth.

But for asset managers, banks, and other financial institutions, that same transparency can be a liability. Trading strategies, counterparty relationships, and client positions are commercially sensitive. Broadcasting them onchain, in the clear, for anyone to analyze, is not something most institutions can accept.

This is the core tension in onchain finance today: the ledger needs to stay immutable and verifiable, but the data on it often needs to stay confidential. Getting this balance right is as much a technical problem as a policy one.

Why Transparency and Confidentiality Both Matter

Before looking at solutions, it helps to be clear about what each side of this tradeoff is actually protecting. Transparency onchain supports:

• independent verification of balances and transaction history without relying on a central party;
• real-time settlement finality;
• composability between protocols and applications; and
• public accountability for smart contract behavior.

Confidentiality protects:

• trading positions and strategies from front-running or copy-trading;
• counterparty relationships in bilateral or institutional trades;
• client data, which is often subject to contractual or regulatory confidentiality obligations; and
• competitive information, such as portfolio composition or rebalancing activity.

Institutional clients are increasingly requiring privacy for their transactions before they'll move capital onchain at all. A financial system with no visibility into activity, on the other hand, cannot be assessed for risk, audited, or trusted by counterparties. The goal is to make disclosure selective and intentional instead of a byproduct of the technology.

Three Technical Approaches to Onchain Privacy

Institutions generally choose from a few different architectural approaches to obfuscate transaction data on a blockchain, often combining more than one depending on the use case.

1. Private and Permissioned Chains

The most direct approach is to move activity onto a network designed to limit who can see transaction data, either by restricting who can join the network at all, or by restricting what any given participant sees once they're on it.

The first version, a fully permissioned consortium chain, works well for financial institutions transacting within a closed group, since it gives them shared infrastructure without exposing activity to the broader market. The tradeoff is that this model gives up some of the openness and interoperability that make public blockchains valuable, and it still requires careful governance over who is granted access and under what terms.

Canton takes the second approach. It's a public, permissioned network with no staking requirement to run a validator node, and privacy is enforced at the transaction level rather than the network level: each smart contract shares data only with the parties who are actual stakeholders in that transaction, so a bank settling the cash leg of a trade never sees the securities leg, and vice versa. Because it's the data flow that's restricted rather than network access itself, Canton avoids the openness tradeoff described above while still keeping transaction details confidential from uninvolved parties.

A different mechanism achieves a similar outcome. On some public, permissionless chains, state and transaction execution happen offchain, sometimes on a private device, and only a cryptographic proof is submitted onchain to confirm validity. Users can choose which accounts or transactions to keep private versus public, making privacy programmable and disclosure selective rather than all-or-nothing. OpenZeppelin has worked on this kind of privacy-native design with Miden and Midnight, whose underlying approaches differ but share this model. On Miden, private state management means an account's data is known only to its owner rather than replicated across every node, which is what makes private multisignatures practical: signers can coordinate and update a shared threshold without exposing the multisig's balance, signer set, or transaction history to the rest of the network. Midnight takes a related approach at the protocol level, allowing developers to leverage shielded and unshielded tokens with different privacy primitives adapted to application requirements, with OpenZeppelin building privacy-preserving contract libraries and developer tooling for it.

2. Confidential Tokens and Encrypted Transaction Data

A second approach keeps activity on a fully public network but encrypts the sensitive parts of a transaction, such as balances and transfer amounts, while still letting the network verify that the transaction is valid. Unlike the offchain execution model above, computation stays on the base chain and the data itself is encrypted, typically using fully homomorphic encryption (FHE) or zero-knowledge proofs, so a smart contract can confirm a transfer follows the rules without ever decrypting the underlying values.

Confidential token standards are an active area of research and development, and several implementations now allow issuers to encrypt balances and transfer amounts by default while preserving programmability. Stellar, for example, released a developer preview of Confidential Tokens built by OpenZeppelin, with a zero-knowledge verifier from Nethermind, that hides balances and transfer amounts on any SEP-41 token while keeping addresses visible and preserving compliance features like auditor access and account freezing. It's live on testnet only for now, with a security audit and mainnet launch still ahead. This kind of confidentiality is attractive for tokenized assets and stablecoins broadly, where institutions want the settlement guarantees of a public chain without publishing every transfer amount to the world.

The tradeoff here is complexity. Cryptographic privacy schemes expand the smart contract attack surface, and they require rigorous, specialized audits. A bug in a zero-knowledge circuit or a flawed encryption scheme can be far more difficult to detect than a bug in a standard token contract, which makes independent security assessment essential before any confidential token standard is used to move real value.

OpenZeppelin has been working directly on this with Zama, co-authoring ERC-7984, a confidential fungible token standard, and maintaining a Confidential Contracts library that implements it. Zama's FHE approach computes directly on encrypted data, making it composable across use cases, and is built on lattice-based cryptography, which is expected to hold up against quantum computers. OpenZeppelin, Zama, and Inco co-founded the Confidential Token Association to develop the standard as cross-ecosystem infrastructure, not just for EVM chains.

The clearest example in production is CMTAT Confidential, a privacy-preserving security token standard from the Capital Markets and Technology Association (CMTA), built on the Zama Protocol and OpenZeppelin's library, and audited by OpenZeppelin before release. Because it reuses CMTAT's modular architecture, issuers can adopt confidentiality selectively rather than across the entire token lifecycle.

3. Privacy Overlays and Protocols on Existing Networks

The third approach adds a privacy layer on top of existing infrastructure, using mechanisms like stealth addresses, view keys, or shielded pools that sit above the base chain. Participants transact on the public network as usual, but a privacy protocol handles the obfuscation of specific details, such as linking a transaction to a real-world identity or wallet history.

Overlay approaches are appealing because they let institutions keep the liquidity, interoperability, and network effects of established public chains. The main technical consideration is that the security of the overlay is only as strong as its weakest link. Institutions need to assess both the base chain and the privacy protocol layered on top of it, since a vulnerability in either can compromise the whole setup.

Selective Disclosure: Privacy without Opacity

Full anonymity is rarely the right target for a regulated financial institution. What institutions actually need is selective disclosure: the ability to keep transaction details private from the general public while still being able to prove compliance to a regulator, auditor, or counterparty on request. This is where view keys, notary roles, and permissioned decryption become important design elements. A well-designed confidential token or privacy overlay should let an authorized party decrypt transaction history when required, without exposing that same data to every other participant on the network.

Most institutions are seeking privacy restricted to participants who are supposed to have it, often called permissioned privacy. Some protocols achieve this through selective disclosure alone; others require every participant to be identity-verified before they can use the protocol. A related design choice is whether a notary, such as the issuing institution or a regulator, can decrypt transaction details on request, or whether the protocol is built with no such mechanism at all, meaning no party can recover the data later, even the institution itself. Institutions evaluating a privacy protocol need to know which model they're adopting, since it determines whether they can meet their own disclosure obligations down the line.

Complexity Raises the Security Bar

Whether an institution chooses a permissioned chain, a confidential token standard, or a privacy overlay, the underlying smart contracts and cryptographic primitives need the same rigor applied to any other piece of financial infrastructure: independent audits, formal verification where possible, and battle-tested libraries and frameworks rather than custom, unreviewed code.

There's also a standardization gap institutions need to weigh. NIST has an active Privacy-Enhancing Cryptography project, but it hasn't yet endorsed specific ZK-SNARK, ZK-STARK, FHE, MPC, or ring signature schemes with a formal rating. That absence shapes practical decisions like whether an institution's hardware security modules can natively support a given scheme and how the key ceremonies around it need to be structured. It also compounds a longer-term post-quantum risk: a scheme that looks secure today could still be broken by a future quantum computer, exposing transaction data years after it was created and reviving the same disclosure obligations that applied at the time.

There's a reputational dimension as well. Privacy protocols with no identity layer and no path to selective disclosure are also usable by anyone, which makes institutions understandably cautious about the company they keep. This is part of why permissioned, identity-aware privacy models tend to be the more practical fit for regulated finance, even when they trade off some of the stronger anonymity guarantees available elsewhere.

Privacy features are only valuable if the systems implementing them are secure. The trading desk from the opening example needs both its position hidden and the mechanism hiding it to have survived the same audit rigor as the trade itself. That's the bar institutions should hold every privacy protocol to before moving real capital onchain.

FAQs

Why is transparency a problem for financial institutions using public blockchains?

Public blockchains make every transaction visible by default, which can expose trading positions, counterparty relationships, and client data that institutions are contractually or competitively obligated to protect.

Can institutions have privacy and still meet compliance requirements?

Yes, through permissioned privacy models that combine selective disclosure with identity verification, such as view keys, notary roles, or permissioned decryption, which let institutions keep transaction details private from the public while still proving compliance to regulators or auditors on request.

Why haven't privacy-enhancing cryptography schemes been widely adopted by institutions yet?

NIST hasn't yet issued formal ratings for specific ZK-SNARK, ZK-STARK, FHE, MPC, or ring signature schemes through its Privacy-Enhancing Cryptography project, which affects institutional confidence and practical decisions like hardware security module support and key ceremony design.

Does privacy-enhancing technology carry any long-term risk?

Yes. Encrypted transaction data that's secure today could become vulnerable if future quantum computers can break the underlying encryption, a risk known as "store now, decrypt later," which could expose data still subject to disclosure obligations years after it was created.