GCP – The oracles of DeFi: How to build trustworthy data feeds for decentralized applications
Distributed ledger technology (DLT) emerged with Bitcoin as a censorship-resistant way to conduct payments between distrusting peers. After a period, traditional financial institutions began to explore the technology, recognizing the potential of its immutability, decentralization, and programmability to redesign financial instruments and workflows.
However, a foundational issue has stalled many enterprise blockchain projects at the pilot stage: the data integrity problem. Moving from controlled test environments to production systems introduces attack vectors and failure modes that don’t exist in traditional centralized systems – a challenge that is particularly pressing for institutions like DZ BANK that are pioneering enterprise DLT adoption.
To solve these challenges, DZ BANK and Google Cloud built an architectural solution for trustworthy data delivery to blockchain applications. This post describes how market data can be securely fed into DZ BANK’s Smart Derivative Contracts (SDCs) using Google Cloud technology.
2025 is the year of strategic engagement
Distributed ledger technology (DLT) has reached a maturity inflection point. Regulatory frameworks are stabilizing, scalability limitations are being addressed, and the Eurosystem’s validation work demonstrates that smart contract protocols enable efficient settlement across separate DLT infrastructures. The exploratory phase is ending — institutions that haven’t moved beyond pilot projects risk being left behind as competitors deploy production blockchain systems.
The technology’s core value proposition — immutable, programmable, decentralized execution — enables new digital financial products that weren’t previously feasible. Smart contracts can eliminate counterparty risk, automate complex settlement procedures, and enable peer-to-peer financial interactions without traditional intermediaries. But realizing these benefits requires solving a fundamental challenge that early blockchain systems were designed to avoid.
Eurosystem research shows that smart contract protocols enable efficient settlement for financial instruments and functional interoperability across separate DLT infrastructures. Based on these results, the Eurosystem recently announced plans to strengthen activities in this field, aiming to create a harmonized digital European financial market infrastructure.
The need for trustworthy data
While DLT was conceptualized as a technology where code is law, banks, asset managers, and clearinghouses require off-ledger data from external sources. This includes price feeds, interest rate feeds, KYC/AML attestations, legal event triggers, proofs of reserves, IoT sensor data, and payment confirmations.
Data trustworthiness is paramount in DLT systems. Wrong data can have unintended consequences in any system, but DLT transactions are often irreversible. A payment using an incorrect interest rate can be cancelled in traditional systems, while DLT transactions are typically final – especially when participants are pseudonymous and unreachable by legal interventions. This creates new attack vectors: attackers who manipulate off-ledger data can cause significant financial harm, including theft of on-chain assets.
Building trustworthy oracle architecture
Off-chain data is supplied to DLT systems via oracles –- interfaces that deliver external information to smart contracts. Trustworthy oracle services require addressing three key aspects:
-
Data must be correct at the source – underlying systems must produce accurate information.
-
Data must remain untampered during transit and processing.
-
Data must be delivered timely and reliably.
The combination of Google Cloud’s secure, highly available infrastructure with DZ BANK’s vision for standardized, deterministic financial protocols meets these requirements. Google’s global technical infrastructure provides security throughout the entire information processing lifecycle, ensuring data integrity and reliability at source and in transit. DZ BANK’s focus on technology-agnostic, deterministic patterns for financial instruments enables trustworthy, automatable financial innovations. Together this approach provides the foundation for delivering timely, untampered data to any DLT system and establishes scalable protocol standards for secure digital financial services.
This architectural pattern provides a blueprint for other institutions facing similar challenges, creating reusable components for trustworthy data delivery across different financial smart contracts and blockchain networks.
The Smart Derivative Contract: a DLT-based financial instrument relying on trustworthy data
The Smart Derivative Contract (SDC) use case covers a fully algorithmic financial product lifecycle that relies heavily on external data, serving as an archetype for oracle-based financial data feeds produced on Google Cloud and consumed by smart contracts. The deterministic settlement cycle requires robust oracle services to determine settlement values. Key functionalities include deterministic valuation, automated margining, netting, and trade termination handling to remove counterparty credit risk in OTC transactions. These processes depend on reliable real-time market data from oracles to determine net present value (NPV) and settlement amounts.
The underlying protocol is published as Ethereum Request for Comments (ERC) 6123. Based on this open protocol, DZ BANK has conducted several pilot transactions with binding legal effect and successfully validated the use case on Bundesbank’s DLT infrastructure (the Trigger Solution).
Why are derivatives the hardest test case? They require precise mathematical calculations using current market data to determine NPV for settlement. Interest rate swaps, for example, need current swap quotes to bootstrap discount and forward rate curves before calculating settlement amounts. The entire process must be deterministic and tamper-proof, with cryptographic evidence of data integrity throughout the pipeline. A secure oracle service is essential for the SDC lifecycle and automated settlement.
Technical foundation: security layers
The oracle system architecture addresses distinct threat models, each requiring different technical countermeasures:
Mitigating software supply chain issues
For SDCs, an attacker might tamper with code that determines NPV calculations – for example, modifying functionality to return artificially low values by default. This would cause settlement at incorrect amounts. To mitigate these issues, we follow Secure Software Supply Chain practices, leveraging Binary Authorization to enforce policies that only permit container images with valid attestation to be deployed. This attestation certifies that container images have passed required checks, such as build verification by trusted CI pipelines, generating build provenance. For maximum security, SLSA Level 3 assurance is desired. By verifying this attestation at deploy time, Binary Authorization blocks unauthorized or tampered images, preventing the malicious code from running.
Secure connections to data sources
Oracle functions calculating NPV need to access relevant market data, which could reside in cloud databases like Cloud SQL. The workload can connect via Private Service Connect, enabling access to the Cloud SQL instance using a private internal IP address within its own VPC network. This keeps all traffic within the Google Cloud network, allowing secure data access without traversing the public internet.
TEE attestation
Ensuring oracle data correctness requires proving that data was generated by specific untampered software versions. For SDCs, this applies to software responsible for value calculations. Using Confidential Space, a trusted execution environment, ensures that only authorized, unmodified software workloads can process data.
This is achieved through remote attestation, where data owners set access conditions based on verification of authorized workload attributes, including the specific digest of containerized software images. Code identity verification complements the inherent trust participants place in the oracle’s business logic. A verifiable attestation token provides strong assurance and can be packaged with the oracle data output to prove origin and correctness.
Transport Layer Security
Transport Layer Security (TLS) adds an additional layer by encrypting oracle data output during transmission to the blockchain. While TEE attestation proves data was generated by authorized, unmodified software within a secure environment, TLS protects data from interception or tampering during network transit.
Applications beyond derivatives
The architectural patterns developed for SDCs apply to other enterprise blockchain use cases that require trustworthy external data. Cross-chain asset transfers, for example, need reliable payment confirmation data to avoid double-spending attacks. Supply chain applications need verified sensor readings and logistics confirmations.
Secure cross-chain protocols are essential for financial interoperability, especially for settling asset and cash legs across separate networks. However, current protocols like HTLC rely on time-outs, creating security vulnerabilities. A more secure approach, proposed in ERC-7573, uses a stateless oracle that releases cryptographic keys contingent on payment success to either complete asset swaps or return funds. By decrypting keys as instructed by a smart contract, the oracle enhances both security and efficiency – an example of how: trustworthy off-chain oracles enable smart contracts.
Building production-ready blockchain infrastructure
The collaboration between DZ BANK and Google Cloud demonstrates that enterprise blockchain adoption is no longer limited by technology. Success depends on integrating decentralized applications with existing business systems while maintaining security and reliability standards.
For developers and architects working on enterprise blockchain projects, this collaboration provides both technical patterns to emulate and infrastructure components to leverage. The challenge isn’t building blockchain applications — it’s building blockchain applications that enterprises can trust with critical business processes.
Ready to explore how these architectural approaches can support your blockchain infrastructure requirements? The frameworks and patterns developed through this collaboration offer practical starting points for building trustworthy oracle systems that meet enterprise security and reliability standards.
The team would also like to thank Christian Fries at DZ BANK and Googlers Chris Diya, Yuriy Babenko, and Latif Ajouaoui for their contributions.
Read More for the details.