Hedera Technical Insights: Smart Contract Oracles on the… | Hedera Hedera Network Services Token Service Mint and configure tokens and accounts. Consensus Service Verifiable timestamps and ordering of events. Smart Contracts Run Solidity smart contracts. HBAR The Hedera network's native cryptocurrency. Insights How It Works Learn about Hedera from end to end. Explorers View live and historical data on Hedera. Dashboards Analyze network activity and metrics. Network Nodes Understand networks and node types. Devs Start Building Get Started Learn core concepts and build the future. Documentation Review the API and build using your favorite language. Developer Resources Integrations Plugins and microservices for Hedera. Fee Estimator Understand and estimate transaction costs. Open Source Hedera is committed to open, transparent code. Learning Center Learn about web3 and blockchain technologies. Grants Grants & accelerators for your project. Bounties Find bugs. Submit a report. Earn rewards. Ecosystem ECOSYSTEM Hedera Ecosystem Applications, developer tools, network explorers, and more. NFT Ecosystem Metrics Analyze on-chain and market NFT ecosystem metrics. CATEGORIES Web3 Applications Connect into the innovative startups decentralizing the web on Hedera. Enterprise Applications Learn about the Fortune 500 companies decentralizing the web on Hedera. Wallets & Custodians Create a Hedera account to manage HBAR, fungible tokens, and NFTs. Network Explorers Hedera mainnet and testnet graphical network explorers. Developer Tooling Third-party APIs, integrations, and plugins to build apps on Hedera. Grants & Accelerators Boost your project with support from the Hedera ecosystem. Partner Program Explore our partners to bring your vision into reality. Hedera Council Over 30 highly diversified organizations govern Hedera. Use Cases Hedera Solutions Asset Tokenization Studio Open source toolkit for tokenizing assets securely. Stablecoin Studio All-in-one toolkit for stablecoin solutions. Hedera Guardian Auditable carbon markets and traceability. Functional Use Cases Data Integrity & AI Reliable, secure, and ethically governed insights. Sustainability Enabling fair carbon markets with trust. Real-World Asset Tokenization Seamless tokenization of real-world assets and digital at scale. Consumer Engagement & Loyalty Mint, distribute, and redeem loyalty rewards. Decentralized Identity Maintain the lifecycle of credentials. Decentralized Logs Scalable, real-time timestamped events. DeFi Dapps built for the next-generation of finance. NFTs Low, fixed fees. Immutable royalties. Payments Scalable, real-time, and affordable crypto-payments. HBAR Overview Learn about Hedera's token, HBAR. Treasury Management Hedera’s report of the HBAR supply. Governance Decentralized Governance Hedera Council See the world's leading organizations that own Hedera. About Meet Hedera's Board of Directors and team. Journey Watch Hedera's journey to build an empowered digital future for all. Transparent Governance Public Policy Hedera's mission is to inform policy and regulation that impact the industry. Meeting Minutes Immutably recorded on Hedera. Roadmap Follow Hedera's roadmap in its journey to build the future. Resources Company What's New Partners Papers Careers Media Blog Technical Press Podcast Community Events Meetups Store Brand Navigation QUICKSTART Hedera Technical Insights: Smart Contract Oracles on the Hedera Platform technical May 08, 2019 by Paul Madsen Head of Identity, The HBAR Foundation If a smart contract requires data from the external world (for instance, an insurance contract requiring the level of flood waters to determine payouts), the contract cannot directly query sources to pull dynamic or volatile data. If each copy of a smart contract running on different nodes were to directly query such sources, those different queries would very likely return different data (even if sent to the same source). Consequently, each smart contract copy would process different data and create different results — destroying the fundamental consistency of the smart contract state. To guarantee that multiple instances of the state controlled by a smart contract do not diverge, smart contracts can only act on data that exists on the ledger — and has been processed into consensus state. One possibility would be to allow clients to submit such data themselves, after retrieving from external sources. But a client of a smart contract might be motivated to lie about the value in order to gain some benefit. Oracles provide a set of mechanisms that collectively ensure that the necessary data exists on the ledger such that smart contracts can avail themselves of it and be confident of its credibility. An oracle is a service that provides data to a smart contract deployed on a ledger, via transactions submitted to the ledger and applied to consensus state. Oracles listen for requests coming from the ledger for the particular data they provide, obtain that data, and then return it back to the ledger in the form of a transaction for the requesting application to use. For instance, if a smart contract required the temperature of a shipping container at a given time (to ensure that the frozen food within did not thaw), an oracle would query the relevant sensor on the container and push those readings back to the supply chain contract through a transaction submitted to that contract. Oracles typically manifest as: 1. A smart contract, to which requests for the associated data can be sent, with the request stipulating a callback address to which the response transaction should be sent. 2. Infrastructure by which the data can be sourced (for example: making API calls, querying a set of users on some subjective proposition). 3. Mechanisms to submit the response as a transaction. While an oracle could connect to a single data source, the desire for decentralization generally suggests incorporating multiple sources through an oracle network. For instance, if a smart contract requires the temperature not of a single shipping container, but of a city on a given day, multiple weather networks might be queried through their various APIs, with an average or median calculated on the different numbers. In this way, the effect of any single weather feed being corrupt or compromised can be mitigated. The high level architecture for an oracle is represented below: The dapp smart contract requires some data from the external world; the oracle smart contract and supporting off-ledger infrastructure work together in order to obtain and deliver that data to the dapp contract. The above description of oracles is generic — we can consider how oracles will manifest on the Hedera platform and whether there are any special considerations or advantages. As the Hedera ledger supports the Solidity language, any oracle smart contract components (Step 1 in the above) will work on Hedera as they do on Ethereum. Additionally, the sourcing of data from various data origins (Step 3 in the above) will be unchanged. Steps 2 and 4 in the above will however need to be bound to the Hedera platform– leveraging Hedera’s comparable mechanisms. For instance, Step 3 could leverage Hedera’s records and state proofs or perhaps the network of mirror nodes, and Step 4 would manifest as a Hedera API ContractCall. While designed to minimize the risk, oracles inevitably introduce the possibility of corrupt data compromising the integrity of a smart contract’s state. The Hedera network uniquely offers an optional binding arbitration model which provides a mechanism to remediate. If, when the smart contract was first initialized on the Hedera platform, particular public keys were designated with multi-sig logic, then the corresponding private keys would have administrative rights over that contract. If, in the future, it was determined that an oracle had sent incorrect or corrupted data to the contract, then those admin keys could, after suitable analysis and an arbitration process, remediate the situation. In Ethereum, the transaction by which the oracle submits the data back to the smart contract, like any other transaction, must be funded with sufficient gas and a gas price to encourage miners to add that transaction to their blocks. If the stipulated gas price is insufficient, then miners may not choose to add that transaction, and the transaction will wait in the mempool and consequently be unavailable to the waiting smart contract. There is nothing comparable to ‘gas price’ in Hedera’s fee model — clients do not need to encourage/bribe nodes to process a given transaction as the hashgraph algorithm is leaderless and does not empower any one node with special powers. Additionally, the expected consensus latency for Hedera transactions is seconds and not minutes or hours. Consequently, after initiating a request of an oracle for some data, a smart contract can expect to quickly have access to the returned data (depending, of course, on the latency of the oracle network itself). Hedera’s support for consensus timestamps and state proofs could further help resolve disagreements over oracle data. Imagine the following sequence: 1. The oracle receives a smart contract request for shipping container geolocation and temperature. 2. The oracle retrieves geolocation and temperature data from the relevant container. 3. The oracle submits geolocation and temperature data to the relevant smart contract via a transaction to Hedera. The transaction stipulates that a record for the transaction be created. 4. The shipping smart contract processes the data. 5. Within an hour, the oracle queries the Hedera network for the transaction record and stipulates it desires a state proof be created. 6. Hedera node returns transaction record and state proof that indicates: The transaction was successfully added to consensus; The consensus timestamp for the transaction; The transaction data; and A collective assertion from the network as to the above. 7. The oracle stores away the above information in case of future litigation where the validity of the geolocation, temperature data, and timing of its submission to the Hedera ledger is questioned. If smart contracts are to model real-world business processes and interactions, they must be connected to that world. Oracles — whether software, hardware, or human — enable that connection. Hedera provides a number of features that uniquely enables smart contract oracles. Share This Back to blog What is gRPC, gRPC-Web, and Proxies? Ed Marquez Pragmatic Blockchain Design Patterns – Integrating Blockchain into Business Processes Michiel Mulders Zero Cost EthereumTransaction on Success: Hedera's New Fee Model for Relay Operators Oliver Thorn Hedera Adopts Chainlink Standard for Cross-Chain Interoperability To Accelerate Ecosystem Adoption Hedera Team Hedera Developer Highlights March 2025 Michiel Mulders Hedera Release Cycle Overview Ed Marquez View All Posts Sign up for the newsletter CONNECT WITH US Transparency Open Source Audits & Standards Sustainability Commitment Carbon Offsets Governance Hedera Council Public Policy Treasury Management Meeting Minutes LLC Agreement Node Requirements Community Events Meetups HBAR Telegram Developer Discord Twitter Community Support FAQ Network Status Developer Discord StackOverflow Brand Brand Guidelines Built on Hedera Logo Hedera Store About Team Partners Journey Roadmap Careers Contact General Inquiry Public Relations © 2018-2025 Hedera Hashgraph, LLC. All trademarks and company names are the property of their respective owners. All rights in the Deutsche Telekom mark are protected by Deutsche Telekom AG. All rights reserved. Hedera uses the third party marks with permission. Terms of Use  |  Privacy Policy