1. Introduction

The financial sector is rapidly innovating with blockchain-based tokenized money and assets – stablecoins, CBDCs, deposit tokens, tokenized money market funds and other forms of digital currencies. While tokenization brings programmability and efficiency, it also introduces new challenges. In particular, confidentiality and privacy, particularly important in financial and business transactions, has been a big challenge.

Blockchain transactions recorded on a shared ledger build trust by making all transactions transparent and verifiable by all participants.  However, this creates significant privacy issues that hinder adoption by companies and financial institution that must maintain privacy and confidentiality of their business transactions, payments, etc. Observers with access to the shared ledger can view transaction amounts and the balances of associated accounts, creating financial privacy risks for individuals, companies, and financial institutions.

Federal Reserve Board whitepaper on “Data Privacy for Digital Asset Systems” has explored the challenges and potential solutions.  This topic has been raised frequently in digital asset conferences, most recently at the CB+DC Conference 2025.  Banco Central do Brasil work to overcome data-privacy concerns on its CBDC project DREX hasn’t reached a successful conclusion. 

Forbes recent article on the project notes, “But the project soon ran into the so-called “Drex Trilemma” – solving for privacy, scalability and programmability within a decentralized, albeit permissioned, environment. Specifically, the challenge at hand was to ensure a sufficient level of privacy so as to comply with Brazil’s data protection laws, while simultaneously giving the Central Bank’s supervisory node full visibility – all without breaking composability.”

These challenges have prompted our focus on transaction confidentiality and privacy as part of Oracle Blockchain Platform Digital Assets Edition (OBP DA).  Initially launched in February 2025, this is a powerful enterprise-grade solution designed to streamline the development and deployment of digital assets applications and to enable unified ledgers. To address the business confidentiality and financial privacy needs, the latest update of OBP Digital Assets edition launched in September 2025 enables Confidential Transactions feature. The same Confidential Transactions capabilities are included in the recently announced Digital Assets Data Nexus to ensure compliance with financial transactions privacy regulations, such as US Gramm-Leach-Bliley Act (GLBA), which requires financial institutions to protect customer data.

This innovation addresses long-standing concerns around transaction confidentiality in tokenized blockchain networks, enabling secure, private transfers while maintaining full verifiability on a shared ledger. With confidential transactions, sensitive data, such as transaction amounts, account balances, and account IDs of the participants is now visible only to the organizations involved in the transaction, while regulators and auditors retain secure role-based access for compliance verification and audits. This ensures both privacy and verifiability of high-value payments in interbank and wholesale digital currency networks.

The confidential transactions feature uses advanced cryptography based on Pedersen commitments to hide sensitive information, such as transaction amounts and balances, without compromising the network’s integrity or the participants’ ability to verify transaction validity.  We use these methods to ensure privacy for transactions, while also allowing Zero-Knowledge proofs to be used to prove validity without disclosure. This approach is similar to ones used by Monero (Ring Confidential Transactions), Liquid Bitcoin (L-BTC), and Zether on Ethereum.

To simplify and accelerate the confidential transaction adoption, OBP-DA has provided a full suite of capabilities to enable quick, out-of-the-box exploration of digital currency use cases with confidential transactions:

• Enhanced low-code Blockchain App Builder to automatically include confidential transaction support in a generated chaincode based on fungible tokens (Stablecoins, Tokenized Deposits, CBDCs, etc.)
• Pre-built example of confidential transaction chaincode for wholesale CBDCs (wCBDCs)
• Domain-specific wrapper APIs that simplify integration with existing systems, and
• A sample wCBDC web app and analytics package using this confidential wCBDC chaincode

This release enables financial institutions to rapidly experiment with, and confidently deploy, secure, private, and compliant blockchain-based payment systems. It’s a major step forward in building the foundation for the next generation of regulated digital payment system.

2. The Solution: Confidential Transactions in OBP Digital Assets Edition

Oracle’s new Confidential Transaction feature in Oracle Blockchain Platform – Digital Assets Edition introduces a robust, scalable, and efficient system for secure value transfer transactions. The design ensures that sensitive information is never exposed to the entire network. Instead, only the organizations directly involved in a payment can view the clear-text data, while auditors with the right role-based access can still perform compliance checks across all transactions. This balance of confidentiality and verifiability makes it ideal for wholesale CBDC and other regulated financial applications.

Here’s how it works:

2.1 Automatic Confidential Chaincode Generation

The process begins with automatic confidential transaction smart contract or chaincode generation. Developers simply can add a “confidential: true” flag in the declarative specification file when defining their token. For example, in the case of a wholesale CBDC, the developer describes the token asset, its anatomy (fungible, fractional), behaviors (mintable, burnable, holdable), and roles (minter, notary, burner). With that single change of “confidential: true” flag, the Blockchain App Builder automatically generates chaincode that comes pre-loaded with confidential transaction logic, eliminating the need for cryptography expertise or manual coding.

2.2 Pedersen Commitments & Private Data Collections (PDCs)

Once deployed, the system uses Hyperledger Fabric’s implicit Private Data Collections (PDCs) to protect non-numeric account attributes. Information like user identifiers (e.g., bank account numbers) are stored in clear-text only in the private data of the organizations participating in the transaction and are replaced by one-way hashes in the shared ledger.

For numeric attributes, such as balances and transaction amounts, which need to be verifiable and auditable Confidential Transactions feature employs Pedersen commitments to protect these sensitive attributes on the shared ledger. These cryptographic commitments enable perfect hiding (also known as information-theoretical hiding – a security property that holds unconditionally, even against an adversary with unbounded computational power) of the actual values on the shared ledger, while keeping them verifiable. The corresponding clear-text numbers are stored in the PDCs of the sender and receiver organizations, maintaining confidentiality without sacrificing integrity.

2.3 Blinding Factor for Security

To prevent predictability, Pedersen commitments require a random value, which has to be provided as input for chaincode execution of each request on the endorsing peers.  In Oracle Blockchain Platform, we use the REST Proxy to generate a unique random blinding factor for each transaction and provide it to each endorser executing the chaincode. This blinding factor is applied when chaincode creates the Pedersen commitment, making it mathematically impossible for other network participants to guess the original values – even if two transactions happen to involve the same amount.

The blinding factor generation is triggered by inclusion of Confidential-Transaction: True header in the REST API call. The generated random value is passed to the chaincode via transient data, so it is not stored on the shared ledger as part of the transaction record, but the chaincode stores it in the private data collection, which audits to validate commitments against clear-text values.

2.4 Auditor Role Access

For regulatory oversight and auditing, the system includes an auditor access model. Both system-level and organization-level auditors can be granted permissions that allow them to view clear-text confidential data when necessary, ensuring compliance while respecting privacy. Thus a local financial institution auditor can retrieve and verify the commitments against the clear-text data in the local nodes PDC, and a system auditor (e.g., regulator or central bank) can be granted special privileges that allow them to access PDC data remotely.

2.5 Atomic Debit and Credit Operations

Inter-organization transfers are handled with precision through atomic debit and credit operations. The system splits each payment into a debit leg and a credit leg, coordinating them via a two-phase commit (2PC) protocol. This is required so that each organization can independently update its account balance without it being visible to the other party, except in a protected commitment form.

2PC protocol built into Oracle’s Blockchain Platform Fabric nodes guarantees reliability – either both sides of the transfer succeed together, or neither does – protecting against inconsistencies.  In other words, if the credit operation fails for any reason, the funds remain safely in the debit account and failed transaction can be retried.

2.6 Throughput Optimization

The solution also addresses performance bottlenecks. During times of heavy transaction load, it parallelizes operations using temporary sender and receiver objects that hold the transferred value to reduce lock contention and avoid concurrency errors common in Fabric networks. These temporary objects can be thought of as an equivalent of a payment check that holds value for the receiver without being part of the account balance.  If the outgoing payment amount exceeds the current account balance, these additional stored value “checks” will be swept into account balance to reach the required amount for the requested payment.  In addition, a built-in reconciliation mechanism periodically sweeps these temporary objects into the account balances, preventing ledger bloat and keeping the system efficient over time.

One of the most powerful innovations is how OBP-DA extends the low-code Blockchain App Builder to support confidential transactions without requiring users to master cryptography. With a simple attribute update to the specification template, the tool will automatically generate a full confidential transaction chaincode – complete with Private Data Collections, Pedersen commitments, and role-based auditor access already built-in – all exposed through the domain-specific APIs, which also include the Confidential-Transaction: True header.

3. Accelerating adoption with Confidential Transactions

To accelerate adoption, OBP DA includes ready-to-use assets so enterprises, financial institutions, and central banks can begin using this capability immediately:

3.1 Pre-Packaged Capabilities for Wholesale CBDC Confidential Transactions Solution

At the heart of any blockchain solution is the smart contract, or “chaincode” in Hyperledger Fabric. Writing and hardening these contracts for financial-grade use cases is a complex process, especially when it involves advanced privacy-preserving techniques like Pedersen commitments and Private Data Collections.

OBP-DA has removed this barrier by delivering a pre-packaged confidential transaction chaincode for wholesale CBDC:

• It comes production-ready, so central banks and commercial banks don’t have to build confidentiality logic from scratch.
• The chaincode already implements secure token lifecycle operations – mint, transfer, hold/escrow, redeem, and burn – with confidentiality built in.
• It supports inter-org transfers with notary-based approval, ensuring atomic settlement even across multiple institutions.
• All numeric values (balances, amounts) are automatically protected on the shared ledger and stored securely in org-specific private data collections, with auditor access built-in
• Auditing or verification process leveraging rich history DB replication of shared ledger transaction history and private data collections is documented in detail.

Banks and central banks can start piloting wholesale CBDC payments immediately, without requiring cryptography experts to build custom implementations.

3.2 Pre-Packaged Rich API Support

Even with a robust chaincode in place, integration is often the hardest part. Pre-packaged rich API support speeds up and streamlines enterprise integration of digital assets, reducing complexity, providing dedicated end points and improving automation.

• OBP-DA provides a set of RESTful APIs that wrap around the confidential chaincode.
• These APIs abstract away the complexity of Fabric transactions and transient maps.

Integration becomes plug-and-play. Banks can quickly connect their wholesale CBDC applications, accelerating time-to-market.

3.3 Pre-Built Wholesale CBDC Web App and Analytics

Finally, to showcase these capabilities in action, OBP-DA includes a ready-to-use sample web application and analytics that demonstrates confidential transaction flows.

The confidential transaction wholesale CBDC application:

• Provides an intuitive UI where central bank or commercial bank users can explore the full token lifecycle: mint, transfer, redeem, burn, and escrow.
• Enforces role-based access control, so different user types (CBDC token creator, issuer, central bank & commercial bank officers, central bank & commercial bank managers, auditors) see only what they’re authorized to access.
• Shows how confidential data (like transaction amounts) is hidden from uninvolved parties, while auditors can still verify everything.
• Is designed as a sandbox for experimentation, letting institutions rapidly test and validate wholesale CBDC use cases while also ready to be configured for full production requirements of a bank-grade network.

Instead of starting with a blank slate, financial institutions get a working application on day one. They can immediately experiment with confidential transaction flows, demonstrate prototypes to stakeholders, and validate compliance models without investing in months of custom development.

4. How Do Confidential Transactions Work in Multi-Organization Setup?

Org A, Org B, and Org C are all participants in the same blockchain network. They share a common channel, which serves as the private communication layer between them, and this is where the confidential transaction smart contract is deployed. By operating on this shared channel, all three organizations can access the same chaincode logic, while the confidential transaction design ensures that only the organizations directly involved in a transaction can view the sensitive details. When a user in Org A decides to transfer tokens to a user account in Org B, the process begins with a simple application request. The user is authenticated to confirm identity and permissions, and the request is routed through the OBP API gateway acting as a REST Proxy. At this point, the gateway automatically attaches a blinding factor—a unique random number generated by Oracle Blockchain Platform’s transaction orchestrator—to the transaction’s payload. This blinding factor is critical because it makes every transaction crypto-graphically unique and prevents other parties from guessing actual values.

In step 1, the amended payload, which includes the transaction amount, the receiver’s account ID, and the blinding factor, is sent as a transaction proposal to the peer nodes in both organizations. In step 2, these peers forward the request along with the blinding factor to their copy of the confidential transaction chaincode, the smart contract responsible for managing private token transfers. In step 3, inside the chaincode, a Pedersen commitment is generated for the transaction amount and updated account balance. This is essentially a cryptographic seal that hides the number but still allows it to be verified later using the blinding factor.

In step 4, the system splits the data into two different storage layers. In step-4a, the sensitive details—such as the sender’s and receiver’s readable sensitive data like balances, transaction amount—are stored in the implicit Private Data Collections (PDCs) of Org A and Org B. Only these two organizations have access to this clear-text data. Meanwhile, in step 4b, the blockchain’s shared ledger and state database records only the Pedersen commitments of these values. These commitments are visible to every organization in the network, including Org C, but they reveal nothing about the actual balances or amounts.

As the transfer completes, Org A’s PDC is updated to show the debited balance for the sender, while Org B’s PDC reflects the credited balance for the receiver. Corresponding Pedersen commitments are also updated on the shared ledger so that the change is cryptographically provable, even without revealing the numbers. For uninvolved organizations like Org C, only the Pedersen commitments are visible; they see evidence that a transaction took place but cannot derive the sensitive details about the participating users or the amounts.

Finally, the endorsed transaction is committed to the blockchain. The confidential chaincode ensures atomicity, meaning the sender’s debit and the receiver’s credit always happen together. This guarantees consistency across the network and prevents partial or failed transfers. If an auditor later needs to verify the transactions, they can access the clear-text values in the PDCs through a special role, calculate the commitments and compare them with the commitments on the ledger, and confirm that everything matches.

In essence, this process ensures that Org A and Org B can transact privately, Org C and other participants see only verifiable cryptographic proofs, and auditors retain controlled access for compliance. The result is a system that balances privacy, verifiability, and scalability—exactly what wholesale CBDC transactions demand.

5. Conclusion

The launch of Confidential Transactions feature in Oracle Blockchain Platform Digital Assets edition marks a major milestone in token-based financial systems. By combining zero-knowledge cryptography, Pedersen commitments and Private Data Collections, Oracle has addressed one of the most pressing challenges in any regulated financial networks. This innovation reinforces Oracle’s commitment to providing enterprise-grade, future-proof blockchain solutions for the regulated financial sector. Financial institutions now have the tools to build permissioned and verifiable digital currency systems, ensuring that sensitive data is only visible where it needs to be without sacrificing compliance. With enhanced Blockchain App Builder and confidential transaction chaincode generation feature, pre-built confidential chaincode, pre-packaged domain-specific APIs, and a sample web app and analytics dashboards, commercial banks and central banks can move from proof-of-concept to pilot in weeks rather than months.

For more information, visit the Oracle Blockchain Platform Digital Assets Edition Documentation.