Skip to main content

Oracles Integration Guide

What Are Oracles?​

Smart contracts are inherently isolated and deterministic; they cannot access or retrieve data from external environments without an intermediary. Oracles serve as this intermediary, bridging the gap between off-chain and on-chain data sources.

To enhance efficiency and value retention within decentralized protocols, Atlas introduces an approach leveraging Oracle Extractable Value (OEV). Supporting OEV allows lending protocols, which are customers of these oracles, to auction off the right to liquidate lending positions. This retains as much value within the protocol's ecosystem as possible, rather than leaking this value to the MEV supply chain.

Initially, the solution described in this document will support conducting a pilot with interested lending protocols on BSC (Binance Smart Chain). Later, we expect that this will be developed into a product feature that can be offered to customers on BSC and eventually on any EVM chain.

1. How It Works​

Atlas enables oracles to internalize MEV by integrating OEV auctions into their data update mechanisms. There are two primary scenarios for integrating oracles with Atlas:

  • Push Oracles: Oracles that proactively push data updates to the blockchain at regular intervals or when certain conditions are met.
  • Pull Oracles: Oracles that provide data on-demand, allowing users or contracts to request data updates as needed.

By integrating with Atlas, oracles can auction off the right to perform actions (like liquidations) that depend on their data updates, thereby capturing MEV for the protocol.

2. Integration Overview​

This integration overview serves as an approximation for how integration with most oracles would work. The exact specifics may vary depending on your architecture. Please work with FastLane to determine if there will be any differences.

2.1 System Architecture​

The integration involves several components working together:

  • Data Delivery Layer (DDL): The existing, unmodified data delivery system.
  • Relayer: Collects updates from the DDL and creates Atlas User Operations to update data feeds.
  • Auctioneer: Orchestrates the auction process by collecting bids from solvers for the User Operations provided by the Relayer.
  • Solver Network: A marketplace of solvers specializing in executing actions like liquidations.
  • Bundler: Responsible for creating Atlas metacall transactions from the operations and ensuring their inclusion in upcoming blocks.
  • DataFeed: The on-chain data storage contract.

2.2 Component Interaction​

2.3 Timing Requirements​

For a transaction to land in the current block, the OEV auction must start on the Auctioneer 1,750ms before the block is published by the validator. On BSC, the block time is 2,500ms, with 300ms allocated for block building and other PBS-related activities. An additional 120ms is reserved for worst-case BON propagation times, and 330ms is for the Auctioneer to conduct the auction and related bundling activities.

If a transaction is received in the first 1,750ms of a block’s time period, it should target inclusion in the next block. If received later, it will target inclusion in the subsequent block.

Initially, a 300ms auction time will be used to maximize competition in the auctions, but as the market evolves, further constraints like geographic co-location for solvers may be introduced.

2.4 On-Chain Components​

  • BundlerEOA: The Externally Owned Account controlled by the Bundler, responsible for submitting transactions.
  • Atlas: The core contract handling execution of operations.
  • DAppControl: Module defining allocation rules and behavior.
  • DataFeed: Contract storing oracle data.
  • Solver: Executes actions based on updated data.
  • DApp: The application using oracle data.

3. Integration Scenarios​

There are two different scenarios for integrating oracles with Atlas: Push Oracles and Pull Oracles. Each scenario has its own characteristics and integration approach.

3.1 Push Oracles​

Push oracles work by having a relayer send an update transaction to the blockchain periodically, usually after either a certain amount of time has passed since the last update or when the value being tracked by the oracle changes by more than a certain amount since the last update.

3.1.1 Characteristics of Push Oracles​

  • Scheduled Updates: Update prices at regular intervals, regardless of usage.
  • Lower Frequency: Data might not always be as current for high-frequency use cases like liquidations.
  • Cost-Effective: More economical when real-time data is not critical.

3.1.2 OEV Approach for Push Oracles​

Integrating OEV into a push oracle can be approached by bundling solutions with the oracle update:

  • Bundling with Oracle Update:
    • An off-chain auction is conducted before the oracle update transaction is created and sent.
    • Solvers bid for the right to include their backrun operations (e.g., liquidations) with the oracle update.
    • The winning solver's operation is bundled with the oracle update in a metacall transaction.

Advantages:

  • Predictable Sequencing: Eliminates MEV concerns by ensuring the order of execution.
  • Efficient Use of Resources: Reduces the need for solvers to monitor the mempool for opportunities.
  • Private Bidding: Solver bids can be kept private before sequencing, limiting timing advantages.

Challenges:

  • Custom Infrastructure: Requires developing custom components for the Auctioneer.
  • Centralization Risks: Introduces some centralization in the auction process.
Sequence Diagram for Bundling with Oracle Update​

3.2 Pull Oracles​

Pull oracles are simple in that a data packet, along with a state root proving its validity, is passed into the DApp as part of the user's transaction. This data is used as the oracle value for the transaction.

3.2.1 Characteristics of Pull Oracles​

  • Real-Time Data Needs: Ideal for scenarios requiring timely and accurate data, like liquidations.
  • Cost Implications: Higher costs due to frequent updates.
  • Efficiency in High-Frequency Scenarios: Ensures data is up-to-date, reducing risks associated with stale data.
Sequence Diagram for Pull Oracles​

3.2.2 OEV Approach for Pull Oracles​

For pull oracles, the OEV integration involves:

  • Privileged Access for Liquidators:

    • Liquidators submit transactions to the DApp with privileged access for a limited time (e.g., 10 seconds).
    • This allows them to perform actions like liquidations before others.

  • Grace Period:

    • After the grace period, all users can perform the same actions, ensuring fairness.
Sequence Diagram for OEV with Pull Oracles​

4. Integration Challenges and Considerations​

The integration challenges for both push and pull oracles are similar. To avoid duplication, we have consolidated them here.

4.1 Common Challenges​

  • Auction Timing: Ensuring auctions are conducted within the required timeframes to align with block production schedules.
  • Bundling Transactions: Properly bundling User Operations with Solver Operations to create atomic transactions.
  • Custom Infrastructure: Developing custom components like the Auctioneer and integrating with the Operations Relay.
  • Security: Verifying data integrity, preventing malicious actors, and ensuring that only authorized solvers can participate.
  • Complexity Management: Managing additional components and processes without overcomplicating the system.

4.2 Atlas Support​

Atlas provides support and templates to assist with these challenges, aiming to simplify the integration process:

  • Standard Modules: Templates for common oracle architectures.
  • Mechanism Design Assistance: Consultation with FastLane's mechanism designers.
  • Operations Relay Integration: Facilitating communication with the solver network.
  • Documentation and SDKs: Tools and guides to streamline development.

5. Integration Steps​

5.1 Frontend and Backend Changes​

  • Relayer Modifications:

    • Update the relayer to trigger auctions via the Auctioneer.

  • Auctioneer Deployment:

    • Set up the Auctioneer to handle User Operations and collect Solver Operations.

  • Bundler Setup:

    • Deploy or integrate with a Bundler to create and submit Atlas metacall transactions.

  • Solver Network Coordination:

    • Engage with solvers interested in participating in OEV auctions.

  • DAppControl Module Development:

    • Create custom modules defining allocation rules and behaviors.

6. Benefits to Your Protocol​

  • Internalizing MEV: Capture MEV generated from oracle updates and related actions, increasing protocol revenue.
  • Efficient Operations: Enhance the efficiency of critical processes like liquidations.
  • Customizable Value Allocation: Use custom modules to define how captured value is allocated (e.g., rewarding participants, funding development).
  • Competitive Advantage: Offer more secure and profitable services, setting your protocol apart in the DeFi space.

7. Conclusion​

Integrating oracles with Atlas, whether they are push or pull oracles, enables protocols to internalize MEV and enhance their value proposition. While there are challenges involved, Atlas provides resources and support to streamline the integration process.

Next Steps:

  • Review the System Architecture to understand component interactions.
  • Explore the Atlas SDK for building operations.
  • Consult with FastLane's Mechanism Designers for assistance in developing custom modules.