Skip to main content
Oracle API allows you to perform SQL queries over massive volumes of data in the ODF network directly from smart contracts. It’s the first of a kind optimistic oracle that enables reproducibility and verifiability of requests without an expensive consensus protocol (more on this below).

Example

Example of the Solidity contract using ODF oracle:

Getting Started

Start by installing @opendatafabric/contracts package that contains oracle interface and request/response types.
See the example above for the recommended way of forming requests and decoding results. More examples, documentation, and tests can be found in the contracts repository.

Supported Networks

ODF oracle can be deployed on any EVM-compatible chain - you can request network support by filing an issue on the contracts repository. Oracle contract and all providers currently operate with zero fees.

Verifiability

Every response submitted to the oracle by data providers includes special data that allows the query to be reproduced later against the same exact version of input data. In REST API semantics an oracle request that looks like this:
Will be given a result such as:
The input.datasets block of the response contains state information that associates every input dataset with the hash of the last block that was considered during the query. Whenever a provider supplies a response - this state information is recorded in the events emitted by the oracle contract on the blockchain. This data acts as a commitment using which a data consumer can dispute results of a query. If another party repeats the same computations using the state data and arrives at different result - this means that the original provider has acted maliciously. See commitments documentation for details. The reproducibility and verifiability of queries therefore make ODF the first of a kind optimistic oracle where:
  • Queries can be fulfilled fast and cheap just by one provider
  • Without going through a complex consensus mechanism
  • While validity of data can still be ensured through the dispute resolution and sampling mechanisms along with staking and slashing.

Commitment Properties

Using the criteria discussed in the commitments documentation the oracle commitment can be described as follows:
  • Hiding - NO
    • The entire request and response data is publicly available, but this as an inherent limitation of non-ZK blockchains
  • Binding - YES
    • All inputs and outputs are immutably stored on-chain
  • Succinct - YES*
    • All response data ends up stored which we cannot avoid, but the commitment itself does not add much overhead
  • Deterministic - YES
  • Reproducible - YES
    • Original query with all of its parameters is stored on-chain and can be repeated against the state information in response
  • Non-repudiable - YES
    • Automatically achieved as the provider signs the response transaction with its private key
  • Composable - YES
    • Through recursive nature of the commitment

Troubleshooting

To better understand what oracle providers return find the incoming oracle transaction in the block explorer e.g. 0x0f3a..4ff6. Find the ProvideResults log: Copy the data field and paste it in https://cbor.me/ to get something like this: The first three fields are: version, success, data. Refer to OdfResponse to understand the layout of the other fields. Once you have one oracle response - you can use it as input in your unit tests to fully debug the decoding and processing logic without constantly re-deploying the contract and spending a lot of gas. Here’s an example of one such tests in foundry:

Registering Your Own Provider

🚧 Under construction 🚧 - contact us if you’d like to use ODF oracle contract along with your private ODF node.
Last modified on March 16, 2026