QUBIC BLOG POST
Oracle Machines Are Coming to Qubic | Real-World Data for Smart Contracts
Written by

The Qubic Team
Published:
Jan 21, 2026
Listen to this blog post
Blockchains are powerful systems for verifiable computation, but they have a fundamental limitation. They can only work with data that already exists on-chain. If a smart contract needs to know the current price of Bitcoin, the outcome of a sports match, or the weather in Tokyo, it has no way to find out on its own.
Oracle Machines solve this problem. Qubic is introducing its native oracle infrastructure, giving smart contracts direct access to real-world information.
An Oracle Machine serves as middleware between Qubic Core Nodes and external data sources. It handles requests leaving the blockchain and delivers verified data back in a form the network can trust.
Think of it as a three-layer system:
Qubic Core Nodes - where smart contracts live and execute
Oracle Machine Node - the middleware layer that handles routing, caching, and validation
External Oracle Services - price feeds, weather APIs, event data providers
When a smart contract needs external data, it sends a query to the Oracle Machine. The Oracle Machine checks its cache, forwards the request to the appropriate external service if needed, and returns the result to the blockchain in a standardized format.
This architecture keeps external complexity isolated from the core protocol, while enabling smart contracts to access real-world information reliably.

Technical Architecture
The Oracle Machine system uses a modular design with clear separation of concerns:

Core Modules:
Module | Responsibility |
NodeConnection | TCP server, IP whitelist validation, session management |
RequestHandler | Query parsing, cache lookup, routing to Interface Clients |
InterfaceClient | Persistent connection to oracle services, async request queue |
OracleCache | TTL-based caching with automatic cleanup |
How Data Flows Through the System
The request lifecycle follows a clear sequence:
Qubic Core Node sends OracleMachineQuery |
↓
NodeConnection receives and validates |
↓
RequestHandler checks cache |
↓
InterfaceClient forwards to oracle service |
↓
Oracle service fetches data (e.g., from CoinGecko API) |
↓
Response cached and returned to Qubic Core node as OracleMachineReply |
↓
Qubic Core nodes generate one OracleReplyCommitTransaction per Computor |
↓
Quorum verifies the oracle reply based on commits of the Computors |
↓
Verified oracle reply is revealed on the chain by a OracleReplyRevealTransaction |
The caching layer is particularly important. Frequently requested data (like popular trading pair prices) can be served instantly from cache, reducing latency and external API load. The TTL-based system ensures data stays fresh while optimizing performance.
Oracle Interface Types
Oracle Machines support different interface types, each with its own query and reply structure. The system will launch with The Price and the Mock interface. More oracle interfaces will be added soon.
Price Interface (Index 0)
The Price interface fetches currency pair data from providers like CoinGecko.
Query Structure (Example):
Oracle: Provider identifier (e.g., CoinGecko)
Timestamp: Query timestamp
Currency1: Base currency (e.g., BTC)
Currency2: Quote currency (e.g., USD)
Note: This is an example. It may need to be revised and a precision requirement will likely be added.
Reply Structure (Example):
Numerator Price numerator (sint64)
Denominator: Price denominator (sint64)
The numerator/denominator format preserves precision for financial calculations without floating-point errors.
Mock Interface (Index 1)
Useful for automated and manual testing.
Two Ways to Request Data
Smart contracts and users can interact with Oracle Machines in two distinct modes:
One-Time Query
You submit a request, the Oracle Machine fetches the data, and you receive your answer. This works well for situations where you need a specific piece of information, at a specific moment.
Example use case: A prediction market contract needs to know who won last night's basketball game to settle bets.
Subscription
A smart contract can subscribe to receive ongoing updates from an oracle. Instead of asking for the current price every time, the contract receives automatic updates at regular intervals.
Example use case: A DeFi protocol needs continuous price feeds to calculate collateral ratios and trigger liquidations.
Request Tracking
Every oracle request gets a unique tracking ID for correlation between queries and replies. Query status can be:
Status | Meaning |
| Request is being processed |
| Data was retrieved and delivered |
| Oracle did not respond within timeout |
Timeouts ensure the system keeps moving. If an oracle fails to respond within the defined window, the request is marked as failed, rather than waiting indefinitely.
Fees and Economics
Aspect | Detail |
Request Fee | Required for all oracle queries to prevent spam |
Fee Destination | Burned (permanently removed from circulation) |
Fee Level | Determined by network Quorum |
This structure aligns with Qubic's tokenomics - where fees are burned rather than redistributed, creating deflationary pressure while incentivizing efficient operation.
What This Enables
Oracle Machines open up categories of applications that were previously impossible to build on Qubic. Combined with Qubic's feeless transactions and high-speed execution, developers can now create:
Prediction Markets: Automatic resolution based on verified real-world outcomes. Sports results, election outcomes, and event occurrences can now settle contracts without manual intervention.
DeFi Protocols: Reliable price feeds enable lending protocols, synthetic assets, and automated market makers. Liquidations can trigger based on accurate, timely price data from providers such as CoinGecko.
Insurance Applications: Parametric insurance contracts can pay out automatically when verified conditions are met such as weather events, flight delays, or other measurable occurrences.
Gaming and NFTs: Real-world data can influence in-game mechanics. Sports NFTs could update based on actual player performance.
For more potential applications, see Qubic Use Cases.
Building New Oracle Services
The Oracle Machine system is designed for extensibility. Third-party developers can add new oracle services by implementing the BaseOracleService interface.
To create a new oracle service:
Define interface structures in Qubic Core (query/reply formats)
Create service implementation inheriting from
BaseOracleServiceImplement data providers for external APIs
Add configuration entries
Register in the build system
The oracle-machine repository includes reference implementations and detailed documentation for building custom oracle services.
This modular architecture means the range of available data sources will expand as the ecosystem grows - without requiring changes to the core protocol.
How Oracle Machines Fit Into Qubic's Vision
Oracle Machines represent another step toward Qubic's goal of building truly intelligent smart contracts. Combined with Useful Proof of Work (uPoW) and Aigarth - Qubic's decentralized AI initiative, oracles give smart contracts the ability to observe and respond to the real world.
As described in Qubic's About page:
"Oracle Machines will be used to make Qubic Smart Contracts even smarter by resolving events through trustworthy data such as stock prices, sports scores, or sensor readings and much more. Also Oracles will give Aigarth the ability to observe the outer world."
This positions Qubic uniquely among Layer 1 blockchains; not just as a transaction settlement layer, but as infrastructure for AI-powered applications that interact with external reality.
Performance Specifications
Metric | Values |
Expected Latency | 3–5 ticks* |
Typical Response Time | ~ 10 seconds* |
Caching | TTL-based with automatic cleanup |
Connection Model | Persistent TCP with auto-reconnect |
The InterfaceClient maintains persistent connections to oracle services with automatic reconnection on failure, ensuring reliability even when external services experience brief outages.
*The values are for reference only and predicted under the testing environment. Actual Values may differ when Oracles are live.
Getting Started for Developers
Developers interested in building with Oracle Machines can explore:
Qubic Documentation - Comprehensive technical guides
Oracle Machine Repository - Source code and implementation details
Smart Contracts Guide - How Qubic smart contracts work
Developer Introduction - Getting started with Qubic development
Qubic Dev Kit - Set up your local testnet
Qubic CLI - Command-line tools for interacting with the network
GitHub Organization - All open-source repositories
For support, join the Qubic Discord community where developers actively collaborate.
Looking Ahead
Oracle infrastructure is foundational technology. Most users will never interact with Oracle Machines directly. Instead, they will use applications that rely on oracles behind the scenes.
Oracle Machines are currently in final testing on Qubic mainnet. Once testing is complete, the infrastructure will be ready for developers and applications to integrate.
Stay updated on Qubic developments through:
Qubic Blog - Latest news and technical updates
Twitter/X - Real-time announcements
Oracle Machines are coming soon. Get ready to build something that matters.
