Building the Privacy Layer for Stablecoin Payments

Overview

Stablecoins can make global payments faster, but public ledgers expose information most institutions cannot share openly: balances, counterparties, payroll, vendor relationships, collateral movements, treasury strategy, and payment flows. For banks, PSPs, fintechs, and enterprises, the challenge is keeping blockchain verifiability while preventing sensitive financial activity from becoming public data.

That is why Utila brought together privacy infrastructure leaders for Episode 09 of the Stablecoin Builder Series. Lauren Buchholz of Utila is joined by Sophia Roman of Aleo, Jose Anaya of zkSync, Aurélie Dhellemmes of Canton Network, ​Arik Galansky of Zama, Lukas Götz of TACEO, and ​Georgi Koreli of hinkal to discuss why privacy is becoming a requirement for institutional stablecoin payments, what privacy models are emerging, and how builders should think about confidentiality, compliance, composability, and liquidity.

Key Takeaways

Public ledgers expose more payment data than institutions can share

The panel framed privacy as a condition for institutional stablecoin adoption. Public blockchains can reveal balances, payment amounts, counterparties, vendor relationships, payroll flows, collateral movements, and treasury activity. That level of visibility may be acceptable for some crypto-native activity, but it creates direct business, compliance, and security concerns for banks, PSPs, enterprises, and institutional treasury teams.

Institutional privacy means selective disclosure

Speakers pushed back on the idea that privacy means hiding everything from everyone. The requirement is more specific: institutions need to decide who can see what, at which point in the transaction, and under which authority. A regulator, auditor, compliance team, custodian, or counterparty may need access to certain information, while the same data should remain hidden from competitors, unrelated counterparties, traders, and public data tools.

Counterparty privacy is a direct business requirement

Several speakers emphasized that privacy is not only about competitors watching public wallets. In payments, the counterparty often creates the biggest exposure. A vendor may be able to infer what a merchant pays other vendors. A customer may be able to see merchant balances. A payroll recipient may expose compensation patterns. Stablecoin payments need to protect amounts and relationships, not only wallet addresses.

Privacy has to be designed before the transaction happens

Privacy cannot be added after sensitive payment data has already been written to a public ledger. The panel discussed transaction-level configurability, encrypted on-chain data, private stablecoins, private wallets, private amounts, and need-to-know access models as ways to make privacy part of the payment architecture from the start. Builders need to decide what remains public, what gets encrypted, and which parties can access the data.

Compliance and privacy need to work together

The discussion made clear that privacy infrastructure cannot ignore compliance. Institutions still need sanctions screening, regulatory reporting, auditability, and the ability to disclose information to approved parties. The strongest privacy models are not built around total opacity. They support controlled disclosure, so institutions can protect sensitive activity while still meeting obligations to regulators, auditors, compliance teams, and counterparties.

Different privacy models solve different institutional problems

The panel described several approaches to privacy-preserving infrastructure, including private networks, public blockchains with encrypted amounts, public blockchains with private wallets and private amounts, zero-knowledge proofs, fully homomorphic encryption, MPC-based approaches, trusted execution environments, and configurable privacy at the application or transaction layer. The right model depends on where the transaction happens, who needs access, what data must remain private, and how much composability the institution needs.

Composability and liquidity still matter

Private stablecoin payments only work if they connect to the financial activity institutions already need: wallets, counterparties, tokenized assets, treasury products, cross-border settlement, and liquidity sources. Speakers warned against privacy models that create isolated liquidity environments or make it harder to interact with the broader on-chain economy. For institutional use cases, privacy has to preserve the ability to move capital, settle payments, and connect with other financial infrastructure.

Key Speaker Insights

​Sophia Roman, Partnerships & Venture, Aleo

“Institutions really can’t adopt fully on-chain payments, trading, use cases, treasury management, if all their data is going to be publicly displayed and visible to their competitors, to traders, to counterparties.”

Explaining why public transaction data blocks many institutional stablecoin use cases.

Jose Anaya, Business Development Lead, Matter Labs

“It’s become more a matter of data protection than it has about privacy.”

Discussing why confidential payments need to protect both user data and business strategy.

​Aurélie Dhellemmes, Head of Network Growth, Canton Network

“It’s not like everything is private or everything is public. Every app at an app level, you decide what is on a need-to-know basis.”

Explaining configurable privacy and why institutional systems need selective access.

Arik Galansky, Chief Product Officer, Zama

“For a lot of institutions, it basically means privacy from the public, not privacy from my providers or my regulators or my counterparties in some situations.”

Clarifying how institutions think about who should and should not see transaction data.

Lukas Götz, Co-Founder & CPO, TACEO

“The main thing you see in a public transaction is the sender address, the recipient, the asset, the amount. On a private transaction, you have all or part of this information somehow encrypted, shielded, not visible to everyone.”

Breaking down how confidential transactions differ from standard public blockchain transactions.