Skip to content

Understanding Real-Time Oracles

Understanding Real-Time Oracles

Traditional push oracles operate on a "store-then-consume" model where price updates are pushed on-chain at regular intervals or when specific deviation thresholds are met. This approach has several limitations:

  1. Staleness: Data can be outdated by the time it's consumed, especially in volatile markets
  2. Front-running: Since price updates are visible in the mempool before being included in a block, MEV bots can extract value by front-running transactions that depend on these updates
  3. Gas inefficiency: Every price update consumes gas, regardless of whether the data is actually used
  4. Limited granularity: Update frequencies are constrained by gas costs and network congestion

The Morpher Oracle takes a fundamentally different approach using an "intent-based" model:

  1. Just-in-Time Data: Instead of storing data on-chain, prices are injected exactly when needed as part of the same atomic transaction that consumes them
  2. MEV Protection: By bundling price data with the consuming transaction in a single atomic operation, front-running opportunities are eliminated
  3. Gas Optimization: Gas is only spent when data is actually used by a contract
  4. Data Dependency Resolution: The Oracle understands which contract functions require what data and automatically injects the required prices
  5. ERC-4337 Integration: Leverages Account Abstraction to handle the complexity of bundling Oracle data with user transactions

This architecture is particularly powerful for applications that:

  • Require microsecond-accurate pricing (e.g. options, futures)
  • Need atomic execution guarantees
  • Want to minimize MEV exposure
  • Seek to optimize gas costs for Oracle usage