1 of 69

eOracle

🏁 Quickstart

What is eOracle?

While smart contracts are excellent at enabling on-chain programmability, they have inherent limitations due to their inability to access real-world data. Oracles bridge the gap between the on-chain and off-chain worlds, enabling the integration of off-chain data into smart contract applications.

eOracle introduces a novel blockchain architecture designed with restaking, leveraging the established trust network of Ethereum validators and staked ETH.

eOracle's mission is to create a competitive marketplace where anyone can independently provide or consume data directly. Like the innovations and value enabled by permissionless AMMs, the eOracle marketplace will introduce new opportunities to the ecosystem.

The eOracle stack enables programmable oracle validation to deliver off-chain data and compute to unlock the next wave of permissionless innovation.

Build, provide, and use data permissionlessly with the security and benefits of Ethereum.

Why eOracle?

How does the eOracle protocol compare to a typical oracle?

To understand how eOracle compares to traditional oracles, the section below illustrates differences in approach and implementation.

🔒 Closed Market vs Open Market 🌐

Traditional oracles act as middlemen that decide on cost, supply, and the variety of data. eOracle's data marketplace abstracts away the middleman and replaces it with the largest and most diverse network of blockchain validators. This enables validators and dapps to interface directly in a free market, benefiting the ecosystem with diverse and high-quality data. The direct relationship between validators and dapps benefits both by creating cheaper and more cost-effective data. In this market, new innovations and opportunities are unlocked through efficiency and inclusivity.

🔐 Closed operations vs Globally Distributed Operations 🌏

In contrast to the nature of the blockchain ecosystem, registration and operations of traditional oracle nodes are limited to a chosen set of nodes. eOracle embodies the ecosystem's values and security principles by relying on nodes operated by Ethereum validators, extending the security of Ethereum's PoS to the oracle space.

🏷️ Trust in Brand vs Trust in Ethereum Security

Conventionally, oracles rely on bootstrapping branded pools of stake, adding trust assumptions and attack vectors to consumer applications. By leveraging Ethereum validators, eOracle enables applications to utilize secure data without introducing new actors or attack vectors to their security considerations.

🌑 Opaque vs Transparent & Programmable 💡

Previously, insular oracle systems with obfuscated aggregation were implemented to compensate for validation limitations. With the advent of EigenLayer and the restaking primitive, eOracle implements standards of incentives, transparency, and cryptoeconomic security consistent with ecosystem standards.

🚫 Restricted Access vs Permissionless Integration ✅

Open and free access to information is not only an ecosystem value but a crucial aspect of innovation. Any decentralized application on any blockchain can access and use eOracle data. Instead of limiting industry progression with infrastructure limitations, applications can use their required data anywhere without sacrificing efficiency.

How to use eOracle?

eOracle simplifies blockchain integration with off-chain data via its robust oracle infrastructure. It manages validators, settlement layers, and data delivery, allowing you to focus on your data needs. With reduced barriers, developers can create new oracles as Oracle Validated Services (OVS) or utilize off-chain data in existing decentralized applications (dapps).

Built on , eOracle benefits from cryptoeconomic security supported by Ethereum validators. Operators can register to earn rewards by contributing to the eOracle ecosystem.

eOracle provides on-chain native price feeds that are reliable, secure, and require no permissions for integration.

Build on eOracle as an OVS or a dapp, or join as an Operator to earn rewards. Find below the relevant information according to your role.

OVS Developers

Oracle Validated Services (OVS) are expert data collectors and aggregators that implement specialized oracles on top of the eOracle ecosystem.

To learn more and become an OVS, visit .

Dapp Developers

Dapp developers can access pricing data here: .

To integrate your dapp with eOracle, visit the

Operators

EigenLayer operators registered with eOracle earn rewards by fetching data feeds and supporting the eOracle ecosystem for permissionless data innovation.

To learn more about becoming an operator and to register permissionlessly, see the .

📖 Understand eOracle

Ethereum Proof of Stake Oracle

If you are unfamiliar with the concept of an oracle, reference the Ethereum Foundation's

As blockchain technology gains widespread adoption and the usage of its applications expands, the economic significance and security requirements of oracles inevitably grow with it.

Ethereum's Proof of Stake (PoS) has consistently demonstrated economic security, trust minimization, and a resilient network of independent validators, which construct the most effective solution to today's emerging challenges.

The emergence of shared security (via ) represents a key advancement, enabling Ethereum's Proof of Stake to expand beyond execution and consensus and enable oracles to connect the off-chain and on-chain worlds.

This innovation facilitates the creation of a new generation oracle network that relies on Ethereum's established cryptoeconomic security and core principles of blockchain technology.

Access to the largest pool of staked funds

Staked ETH is orders of magnitudes larger than the staking of all other traditional oracles combined. An oracle network with access to staked ETH inherits the established security instead of creating another pool. This access provides a more economically secure and capital-efficient way to build oracle networks.

Native staking

eOracle's security backing, ETH, is independent of eOracle operations. This makes it robust against issues that other oracles who use their token for staking, such as temporal drops in token value and death spirals. , leading to security reduction and vice versa.

Slashing for malicious behavior

eOracle's system is designed to deter and address malicious activities. Utilizing , eOracle can initiate procedures that may lead to the slashing of an attacker's staked funds. Slashing completes eOracle's incentive model, matching Ethereum's security apparatus.

Distributed validation

Validators worldwide verify data accuracy, making the network robust against localized disruptions. This approach ensures that no single point of failure can compromise the system, enhancing both security and reliability. Additionally, the diverse geographic distribution of validators contributes to a more resilient and fault-tolerant network capable of withstanding various types of attacks and ensuring continuous neutrality and operations.

Economic and diverse Trust

Economic trust is the amount of capital at stake (quantity), while diverse trust is the variety and balance of nodes involved (quality).

For a protocol to achieve security and liveness in a decentralized manner, it needs a sufficient amount of economic trust and a diverse, well-balanced set of nodes. Only Ethereum has reached sufficient economic and diverse trust.

With restaking via Eigenlayer, an oracle design containing these elements is enabled, providing a practical path to achieving sufficient trust via diverse and economically trusted Ethereum validators.

Permissionless Innovation

Data marketplaces in today's blockchain ecosystem have not yet reached free competition, with centralized actors limiting what data is available to consumers. The challenges of building oracle infrastructure have led to a situation where there are few 'data' suppliers that smart contracts can interact with, restricting innovation.

To address this, eOracle's mission is to create a marketplace where anyone can independently supply or consume data.

Permissionless Market

A permissionless market offers numerous benefits that foster innovation, efficiency, and accessibility. Enabling a diverse range of participants allows anyone to supply or consume data without restrictive barriers. This inclusivity leads to more data sources and solutions, promoting creativity and unique developments. Increased competition drives down costs, benefiting consumers with more affordable options. The open nature of a permissionless market encourages continuous improvement and competition as participants strive to offer superior quality and innovative data.

No Single Price Authority

Decentralized pricing promotes fair and accurate costs, driven by competitive pressure. This encourages innovation, as potential data suppliers are more likely to enter the market with favorable pricing structures. Consumers benefit from lower prices and increased choices.

Transparency

Transparency ensures that all participants have access to accurate and timely information, which promotes fair competition and prevents price manipulation. As anyone can see how prices are set and transactions are conducted, trust is created between consumers and suppliers. Transparency encourages accountability, reducing the risk of fraud, cover-ups, and unethical practices.

The next wave of web3 innovation will be enabled by an open, neutral, and efficient data marketplace.

Modularity and Programmability

eOracle is a highly modular and programmable tool designed to provide blockchains, developers, and users with the same level of freedom and versatility as native smart contracts.

With eOracle, you can seamlessly connect to any specific data you need, tailored to custom requirements, by creating your own (OVS).

Builders can create an OVS and offer them on the eOracle marketplace, or developers can use them for their own applications.

Configure Your Data Sources

Configuring your data sources allows you to gain full control over your data inputs. You can select any data source to ensure you receive the most relevant and accurate information for your blockchain applications. Whether you need financial data, real estate data, or any other type of data, our platform enables you to tailor your sources to meet your specific needs.

Build Custom Aggregation Logic

Empower applications with custom aggregation logic that fits unique requirements. Instead of relying on pre-defined aggregation methods, our platform enables you to design and implement custom logic. This flexibility ensures that you can process and combine data in ways that best serve applications, providing enhanced functionality and performance.

Permissionless Deployment

With the rapid increase in the number of new blockchains, traditional oracle providers often hinder the swift deployment of new blockchains. Oracles have become essential infrastructure, yet many projects lack the resources to collaborate with traditional oracle providers.

eOracles addresses this challenge by offering a seamless integration solution for rollup-based projects through permissionless deployment. Developers can easily access eOracle's on-chain contracts and deploy them on their rollup or dedicated chain without the need for prior approval.

The blockchain architecture of eOracle serves as the source of truth for aggregated data in a transparent and reliable manner. Smart contracts deployed on rollup solutions verify all data written to them, maintaining integrity and consistency.

By eliminating dependencies on oracle integration capabilities, eOracles significantly reduces the time-to-launch for new rollup solutions, fostering a more cohesive and efficient blockchain ecosystem. This streamlined approach accelerates innovation, allowing projects to enter the market more swiftly and effectively.

Architecture Overview

If you are unfamiliar with the concept of an oracle, reference the Ethereum Foundation's

The following is a brief overview of the core components that define the eOracle protocol, to contextualize the data aggregation process.

Ethereum Eigenlayer Integration

EO-Chain

Validator Clients

Aggregator Modules

eOracle Endpoints

Target Network Contracts

Data Processing

eOracle operators connect, compute, validate, and publish off-chain data to Dapps securely, permissionlessly and transparently.

Reporting

Any publicly accessible real-world data can be added to the eOracle network, where eOracle operators will begin reporting on it. Reports are sourced from different endpoints, such as a WebSocket or an API. The frequency of reporting and the values to be extracted are programmable by the user. Once the operator obtains the data, it signs it and sends it in a transaction to the EO-chain. Any operator with an above-threshold stake can participate in reporting, weighing each report by their stake. A report for a specific operator cannot be faked by another party, and their participation is an immutable part of the EO-chain state once received.

Validation & Aggregation

Dapps can use eOracle's standard aggregations, which employ advanced algorithms and protocols to identify and discard outliers, or custom aggregations defined for a specific use case. For consensus and security, the computation is distributed among the validators and verified by them.

The computational aggregation process and its result become an immutable part of the EO-chain. The decentralized, transparent, and permissionless nature of this process ascertains that the reports and the aggregation results are authentic, accurate, and verifiable. Those results are then eligible for publication.

Publication

Publication is the process of posting eOracle aggregated data onto a target blockchain. A target blockchain is any blockchain network where dapps wish to use eOracle data. To provide eOracle data, each target blockchain has a smart contract that verifies, parses, and approves data signed and produced by the EO-chain.

Consumption

Dapps, individuals, and institutions can easily interface with eOracle in the smart contract layer by using the eOracle Solidity SDK and reading their required aggregated data on-chain.

Off-chain infrastructure can use our WebSocket interface to cache aggregated data and provide a smooth and low-latency user experience, enabling instant integration and execution available on user-facing services. Our low-latency interface makes on-chain security and transparency accessible to provide a seamless user experience.

Conclusion

Process Overview

Reporting is permissionless, transparent, and unfalsifiable.
Aggregation is decentralized, programmable, secure, modular, immutable, and easily verifiable.
Publishing is efficient, interoperable, permissionless, and censorship-resistant.
Consumption is dynamic, highly compatible, and a simplified user experience.

In summary, the eOracle platform enables users with customizable requirements, dynamic security needs, niche data dependencies, and more to define their data flow. By defining the data type, sources, aggregation logic, and other desired variables, users can programmatically and comprehensively satisfy all workflow requirements to provide data and computation on-chain.

Any party can interface with the eOracle network for a given data need, and retrieve the proof components, a BLS-signed Merkle root & Merkle path. This can be used to prove the validity of data cross-chain. The signed Merkle root component enables the verification of a valid eOracle Validator Set, while the Merkle path can then be used to prove the inclusion of aggregated data. Due to the transparent and verifiable nature of the process, users are always assured of the authenticity of the computation, operator participation, and staked security.

Security

The following sections outline security aspects of the eOracle protocol

Cryptoeconomic Security

While traditional oracles rely on their proprietary tokens to maintain ecosystem health and secure operations, eOracle introduces a novel security approach with its dual-token design. The model synergizes the specific advantages of a protocol-dedicated token with the enhanced security and economic stability provided by a well-established token like ETH, used for staking purposes.

This dual-token approach marks a notable shift from the single token model. By incorporating ETH for staking purposes, eOracle connects to a broader and more resilient economic base. This strategy effectively mitigates risks associated with blockchain protocols that rely on protocol-specific tokens.

The following sections provide a mathematical analysis, showing the enhanced security and stability of such a system.

Measuring Cryptoeconomic Security

Cryptoeconomic security (CES) is a useful measure for analysis, consider the following;

Given a set of colluding validators that we henceforth term the attacker, we assume that the attacker has the ability to corrupt the majority of the validators. Therefore, the attacker possesses the power to manipulate the consensus process, potentially leading to double-spending, censoring transactions, or altering the integrity of the blockchain's state.

To assess whether attacking is beneficial, the attacker must take into account two elements: the Cost of Corruption () and the Profit from Corruption ().

encompasses the total resources the attacker must invest to successfully manipulate the protocol, i.e., slashing of their stake, technical resources required for the attack and other associated expenses. Since we focus on assessing the efficacy of stake slashing as a deterrent and its influence on the CES, we assume that the primarily involves the loss of the attacker's staked assets, while other costs will be disregarded.

signifies the potential gains the attacker would achieve post-successful manipulation. Our analysis requires a more subtle approach towards , and thus we divide into two sources as follows:

Profit from Manipulation () is the internal profit the attacker can gain by manipulating the protocol. For instance, for Oracle protocols, it is the profit that could be extracted by a malicious price update. The is upper-bounded by the protocol's Total Value Secured (TVS).
Profit from Depreciation () addresses the external profit the attacker can gain from betting on price volatility or depreciation through, e.g., derivative markets or short selling.

Notice that . A rational attacker will only attack if .

We capture this in the following definition.

Definition (CES Margin). A protocol has a -crypto-economic security margin, or a -CES margin, if

In what follows, we explicitly assume that increasing the CES margin implies a more crypto-economically (CE) secure protocol and say that a protocol is CE-secure or CE-vulnerable, referring to a positive or negative CES margin, respectively.

Profit from Short Selling

CES: A Tale of Two Oracles

To demonstrate how the CES margin is affected by the nature of the protocol's token, we compare the following two scenarios:

EnshrinedOracle, which relies on the base-layer's token that we denote by $ETH.
TraditionalOracle, relying on its own token that we denote by $TRD.

The value and utility of $ETH are independent of EnshrinedOracle's activities, unlike $TRD, whose value is closely tied to the operations of TraditionalOracle.

Resilience to Attacks

Under the same attack, the EnshrinedOracle is far more cryptoeconomically secure, as the underlying stake is not derived from the operations of the EnshrinedOracle. In contrast, such an attack would devastate the cryptoeconomic security of the TraditionalOracle.

Divergences in the Cost of Corruption

Being able to short $TRD based on the TraditionalOracle's operations increases the potential profit from attack, whereas there is no such benefit for attacking EnshrinedOracle.

Market Fluctuation Impact

Next, we analyze the ramifications of a sudden decrease of $TRD market cap. Such a change in valuation could result from the volatile nature of the crypto space or the unintended fault of the protocol.

This observation is demonstrated using an example.

Example 1:

Next, we analyze EnshrinedOracle, relying on the independent $ETH token. The CES margins of EnshrinedOracle before the event is

The figure below depicts the change in the CES margin of EnshrinedOracle due to the same event. Importantly, under precisely the same event, EnshrinedOracle remains CE secure.

The TraditionalOracle's CE security is far more susceptible to market fluctuations, whereas EnshrinedOracle's security is resilient to external market forces.

Beyond Profit from Depreciation

Scaling Cost of Corruption with Total Value Secured

Passively, due to an increase in $TRD market cap.

Let us examine these two solutions. For the passive approach of experiencing an increase in $TRD market cap, note that the TraditionalOracle cannot (legally) control the price and ensure a positive CES margin. Particularly, if the TVS fluctuation and the price fluctuation are not identical (correlation is not enough in this case), the TraditionalOracle could become CES-vulnerable (a scenario similar to that in Observation 3). The active approach is also challenging, as it requires the TraditionalOracle to call capital on demand while not being connected to an independent pool of capital.

EnshrinedOracle can mitigate a TVS increase by controlling the stake, allowing the CoC to scale accordingly.

Cost of Capital

TraditionalOracle's security scheme demands stakers hold $TRD , thus, stakers have to posses a token with relatively small market cap that depends on the protocol's performance. In contrast, EnshrinedOracle could accept stake in $ETH, the base-layer's token. $ETH is less volatile, does not suffer from inflation, and is a multi-purpose token. These differences allow EnshrinedOracle to demand less of its stakers compared to TraditionalOracle's stakers, who may demand a premium for the additional risks they take (possessing $TRD and being exposed to a potential turbulent macroeconomic environment). Additionally, since EnshrinedOracle's stakers could be re-stakers through Eigenlayer, their capital efficiency is maximized.

The Dual Token Model

An independent token makes EnshrinedOracle significantly more CE secure than its counterparts utilizing a staking token. However, oracle sovereign tokens offer other advantages if decoupled from the CES risks.

By rewarding validators with a token, an incentive structure can be designed to increase the rate of rewards. Factors such as uptime, accuracy , and longevity of validators may increase their rewards earned. This achieves both incentivization of higher quality validation, and alignment of validators with the interests of the protocol.

A token vesting mechanism requires validators to be aligned with the network by locking their rewards and ensuring the commitment of the validators during the vesting period. This enhances the stability and security of the network.

A sovereign token design also allows for creating a punishment structures , where rewards can be revoked on non-malicious misbehavior. To avoid slashing Beacon Chain ETH , all non-malicious behavior will addressed with sovereign token punishments.

Implementing all of these mechanisms while having stake rooted in $ETH retains the CES benefits of EnshrinedOracle while avoiding the CES vunerabilities of TraditionalOracle.

Proofs

Proof of Observation 1.

Proof of Observation 2.

Proof of Observation 3.

Proof of Observation 4.

End Notes

Aegis - Validator Set Configuration

eOracle Validator Sets are integrated into the Ethereum PoS Validator Set through the Aegis protocol, enabling Ethereum validators to participate freely in the eOracle network permissionlessly.

Validator Set Membership

eOracle is an expansion chain that derives its cryptoeconomic security from Ethereum staking and benefits from the stability of ETH. Through innovative infrastructure provided by Eigenlayer, Ethereum Validators are able to participate in the eOracle blockchain as part of Validator Set. Validators can initiate a withdrawal from the Validator Set, and membership can be revoked for misbehavior, within Ethereum.

Naively implementing a new PoS protocol is not possible since the validators' stake is managed on Ethereum rather than directly by the protocol. To address this challenge, we developed Aegis—a novel protocol for creating an expansion chain based on primary-chain stake, in our case, restaked ETH. The eOracle blockchain is built on Aegis.

Aegis uses references from Aegis blocks to primary-chain blocks to define Validator Set, checkpoints on the primary chain to perpetuate decisions, and resets on the primary chain to establish a new committee if the previous one becomes obsolete. It ensures safety at all times and rapid progress when latency among Aegis nodes is low.

OVS DEVELOPER GUIDES

Oracle Validated Services (OVS)

OVS

The term OVS refers to custom oracle builders who develop oracles on top of eOracle's infrastructure. By providing a platform for diverse participants to create specialized oracles, eOracle aims to foster a more competitive market that enhances the quality and reliability of data available to smart contracts. This approach not only democratizes access to data services but also ensures that blockchain applications can benefit from the expertise of a wide range of data and computation providers.

What Does it Take to Build an Oracle?

Oracles enhance blockchains by integrating off-chain data while maintaining the core properties of blockchains. Like blockchains, oracles eliminate dependence on a central third party by introducing redundancy through a distributed reporting system.

A decentralized oracle needs to address the following questions:

Sources - What are the qualitative sources for this type of data? Or, what off-chain computation we want to transmit to the blockchain?.
Aggregation - What is the optimal method for aggregating validator reports into a single value? Considerations include resistance to manipulation (robustness), performance, simplicity, and more.
Incentive management and security - How can we assess a validator's participation and reward or penalize them appropriately? In particular, how do we detect misreports and distinguish between honest mistakes and malicious attempts to manipulate the oracle?

Answering these questions requires expertise in various domains, including data science, cryptography, game theory, and the specific field from which the data originates. We do not want a cryptographer performing poor data science nor a data scientist executing inadequate cryptography.

Building an OVS on eOracle, we aim to address the previously mentioned questions. We next outline how eOracle's infrastructure and expertise translates into features for OVS builders, enabling fast and smooth bootstrap of your custom oracle.

Build an Oracle

Building an OVS on eOracle can be divided to two main phases: the setup phase and ongoing maintenance.

Setup Phase: This initial phase involves laying the foundation for the OVS. It includes creating operator software, establishing protocol rules, and setting up infrastructure. These tasks ensure that the oracle operates correctly from the start and are handled by the eOracle ODK.

Maintenance Phase: This phase begins once the oracle is operational. During this phase, it is important to keep the oracle adaptive and adjustable. This involves tracking and monitoring operator activity, updating the system, and evolving the oracle as needed. Ensuring adaptability and adjustability allows the oracle to respond effectively to changes and maintain high performance over time. These tasks are managed by the OVS Manager.

eOracle’s infrastructure and expertise provide essential features to support these phases, enabling a seamless launch of a custom oracle.

eOracle ODK (Oracle Development Kit)

The eOracle ODK is a comprehensive toolkit designed to facilitate the setup phase of building an OVS. It provides all the necessary tools to customize client software, secure the OVS, and implement essential features, ensuring a smooth and efficient launch of a custom oracle.

Customize client software to fetch relevant data and perform light to heavy computations according to OVS needs.
Secure and back the OVS with restaked ETH, EO, or an OVS native token.
Employ eOracle for verifiable execution and settlement. Leverage eOracle’s audited custom contracts for data aggregation, ensuring complete transparency and reliability.
Implement a cross-chain communication component for submitting aggregated results to target chains, supporting high-frequency, low-latency updates and customizable requirements such as update triggers and verification methods.
Track operator behavior using the eOracle chain and establish on-chain detection mechanisms.

📊 Price Feeds

Integration Guide

Price feeds are a crucial component in the decentralized finance (DeFi) ecosystem, allowing for a wide range of financial activities such as lending, borrowing, trading, and derivatives. Price feeds enable dapps to access accurate and updated pricing data in a secure and trustless manner.

eOracle price feeds aggregate information from many different data source and are published on-chain for easy consumption by dApps. This guide shows you how to read and use eOracle price feeds using Solidity.

Reading eOracle price feeds on EVM-compatible blockchains follows a consistent format for both queries and responses across different chains.

eOracle follows Chainlink's AggregatorV3Interface, allowing a smooth transition between oracle providers.

Prerequisites

You have a basic understanding of smart contract development.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.25;

interface IEOFeedAdapter {
    function decimals() external view returns (uint8);
    function description() external view returns (string memory);
    function version() external view returns (uint256);
    function getRoundData(uint80 _roundId)
        external
        view
        returns (uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound);

    function latestRoundData()
        external
        view
        returns (uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound);
}

contract EOCLConsumerExample {
    IEOFeedAdapter public _feedAdapter;
    /**
     * Network: Holesky
     * EOFeedAdapter: 0xDD8387185C9e0a173702fc4a3285FA576141A9cd
     * Feed Symbol: BTC
     */

    constructor() {
        _feedAdapter = IEOFeedAdapter(0xDD8387185C9e0a173702fc4a3285FA576141A9cd);
    }

    function getPrice() external view returns (int256 answer) {
        (, answer,,,) = _feedAdapter.latestRoundData();
    }

    function usePrice() external {
        int256 answer = this.getPrice();
        // Do something
        // .............
    }
}

Edit/Deploy using Remix by clicking here.

The code has the following elements:

An interface named IEOFeedAdapter defines several functions for accessing data from an external source.
These functions include retrieving the decimals, description, and version of the data feed, as well as fetching round data and the latest round data.
The constructor initializes a public variable named _feedAdapter, which is of type IEOFeedAdapter. It sets _feedAdapter to connect to a specific EOFeedAdapter contract deployed on the Holesky network at address 0xDD8387185C9e0a173702fc4a3285FA576141A9cd. This adapter is designated for the BTC feed.
The getPrice() function retrieves the latest price data from the _feedAdapter by calling the latestRoundData() function. It returns the answer, which represents the latest price of the BTC feed.
The usePrice() function internally calls getPrice() to fetch the latest price , illustrating how the price could be parsed and used.

Contact support@eoracle.io for more details on deployments and usage.

API Reference

The service allows users to easily query for recent price updates via a REST API or via a websocket

Through a REST API Endpoint

A user could use this endpoint to query symbol price quotes via REST API. Our REST API endpoints could be found at: https://api.eoracle.network

Get Rate

Endpoint: /api/v1/get_rate
Method: GET
Parameters:
- symbol (string, required): The symbol for which to get the rate.
Authentication The REST API authentication method uses a username and password. The username is the API key provided to you by eOracle, and the password should be left blank.

$ curl -X GET -u your_api_key "https://api.testnet.eoracle.network/api/v1/get_feed?symbol=eth"
{
    "symbol":"eth",  
    "rate":"2235520000000000000000",   
    "timestamp":1704645014000,  
    "data":"0x0c64cc6cb523085bac8aa2221d5458999...2309417974f4a72b98"
}

Get Symbols

Endpoint: /api/v1/get_symbols
Method: GET

Example

curl -u your_api_key: 'https://api.eoracle.network/api/v1/get_symbols'

Response

["jpy", "eth", "btc"]

Socket.IO API

We provide a simple socket stream using the standard Socket.IO library. The message protocol is described in the following section and includes a connection, authentication and subscribe phases.

Connection

Connection is made to our eOracle api endpoint at https://api.testnet.eoracle.network. Once connected the consumer can initiate an authentication event.

Request Events

authenticate

name: authenticate
payload:

{ 
  "token": "your_api_key" // your oracle api key
}

subscribe

name: subscribe
payload:

{
   "topic": "feed", //(string, required): The topic to subscribe to (e.g., 'feed').
   "symbols": ["btc", "eth", "jpy"] //(array of strings, optional): An array of symbols to subscribe to. If empty, subscribe to all symbols.
}

authenticated
- This message is received when your client was successfully authenticated with a valid API key. Once you receive this it's a good trigger point for subscribing to quote feeds.
- name: 'authenticated'
- payload: none

quote

name: quote
payload:

{
  "symbol": "eth",
  "rate": "1923.45", 
  "timestamp": 1238971228, 
  "data": "0xbd3de674b8bd65........93c9220fb3202e405266", // provable merkle tree
 }

Off-chain Examples

Integrating off-chain data into your workflow is essential for creating robust and dynamic decentralized applications. This section provides a detailed guide on how to access eOracle's API off-chain.

import { ethers } from 'ethers';

// ABI of the IEOFeedManager interface
const IEOFeedManagerAbi = [
  "function getLatestPriceFeed(uint16 symbol) external view returns (tuple(uint256 value, uint256 timestamp))",
  "function getLatestPriceFeeds(uint16[] calldata symbols) external view returns (tuple(uint256 value, uint256 timestamp)[])"
];

// Address of the deployed IEOFeedManager contract on Holesky network
const IEOFeedManagerAddress = "0x723BD409703EF60d6fB9F8d986eb90099A170fd0";

async function main() {
  // Connect to the Ethereum network (Holesky in this case)
  const provider = new ethers.providers.JsonRpcProvider('https://some.holesky.rpc');

  // Create a contract instance
  const feedManagerContract = new ethers.Contract(IEOFeedManagerAddress, IEOFeedManagerAbi, provider);

  // Example to get the latest price feed for a single symbol (e.g., BTC:USD with symbol ID 1)
  async function getPrice(symbol: number) {
    try {
      const priceFeed = await feedManagerContract.getLatestPriceFeed(symbol);
      console.log(`Price: ${priceFeed.value.toString()}, Timestamp: ${priceFeed.timestamp.toString()}`);
      return priceFeed;
    } catch (error) {
      console.error('Error fetching price feed:', error);
    }
  }

  // Example to get the latest price feeds for multiple symbols
  async function getPrices(symbols: number[]) {
    try {
      const priceFeeds = await feedManagerContract.getLatestPriceFeeds(symbols);
      priceFeeds.forEach((feed: { value: ethers.BigNumber, timestamp: ethers.BigNumber }, index: number) => {
        console.log(`Symbol: ${symbols[index]}, Price: ${feed.value.toString()}, Timestamp: ${feed.timestamp.toString()}`);
      });
      return priceFeeds;
    } catch (error) {
      console.error('Error fetching price feeds:', error);
    }
  }

  // Call the functions with example symbol(s)
  await getPrice(1); // For BTC:USD
  await getPrices([1, 2]); // Example for multiple symbols (e.g., BTC:USD and ETH:USD)
}

main().catch(console.error);

from web3 import Web3
# Connect to holesky
rpc_url = "https://some.holesky.rpc"  # Replace with your rpc
web3 = Web3(Web3.HTTPProvider(rpc_url))

# Check if connected to the node
if not web3.isConnected():
    print("Failed to connect to the Ethereum node.")
    exit()

# Contract address and ABI
contract_address = '0x723BD409703EF60d6fB9F8d986eb90099A170fd0'
contract_abi = [
    {
        "inputs": [{"internalType": "uint16","name": "symbol","type": "uint16"}],
        "name": "getLatestPriceFeed",
        "outputs": [{"components": [{"internalType": "uint256","name": "value","type": "uint256"},{"internalType": "uint256","name": "timestamp","type": "uint256"}],"internalType": "struct IEOFeedManager.PriceFeed","name": "","type": "tuple"}],
        "stateMutability": "view",
        "type": "function"
    },
    {
        "inputs": [{"internalType": "uint16[]","name": "symbols","type": "uint16[]"}],
        "name": "getLatestPriceFeeds",
        "outputs": [{"components": [{"internalType": "uint256","name": "value","type": "uint256"},{"internalType": "uint256","name": "timestamp","type": "uint256"}],"internalType": "struct IEOFeedManager.PriceFeed[]","name": "","type": "tuple[]"}],
        "stateMutability": "view",
        "type": "function"
    }
]

# Initialize contract
contract = web3.eth.contract(address=contract_address, abi=contract_abi)

# Function to get the latest price feed for a single symbol
def get_latest_price_feed(symbol):
    price_feed = contract.functions.getLatestPriceFeed(symbol).call()
    return price_feed

# Function to get the latest price feeds for multiple symbols
def get_latest_price_feeds(symbols):
    price_feeds = contract.functions.getLatestPriceFeeds(symbols).call()
    return price_feeds

# Example usage
if __name__ == '__main__':
    # Get the latest price feed for symbol 1 (e.g., BTC:USD)
    symbol = 1
    price_feed = get_latest_price_feed(symbol)
    print(f'Price Feed for symbol {symbol}: Value = {price_feed[0]}, Timestamp = {price_feed[1]}')

    # Get the latest price feeds for multiple symbols
    symbols = [1, 2]  # Example symbols
    price_feeds = get_latest_price_feeds(symbols)
    for i, feed in enumerate(price_feeds):
        print(f'Price Feed for symbol {symbols[i]}: Value = {feed[0]}, Timestamp = {feed[1]}')

import { ethers } from "ethers";

// Define the ABI of the IEOFeedAdapter contract
const IEOFeedAdapterABI = [
  "function latestRoundData() view returns (uint80 roundId, int256 answer, uint256 startedAt, uint256 updatedAt, uint80 answeredInRound)"
];

// Define the address of the IEOFeedAdapter contract
const IEOFeedAdapterAddress = "0xDD8387185C9e0a173702fc4a3285FA576141A9cd";

async function getLatestRoundData() {
  // Connect to the Ethereum provider (in this case holesky)
  const provider = new ethers.JsonRpcProvider("https://some.holesky.rpc");
  
  // Create a contract instance
  const feedAdapterContract = new ethers.Contract(IEOFeedAdapterAddress, IEOFeedAdapterABI, provider);
  
  // Call the latestRoundData function
  const latestRoundData = await feedAdapterContract.latestRoundData();
  
  // Destructure the returned data
  const [roundId, answer, startedAt, updatedAt, answeredInRound] = latestRoundData;

  // Log the data
  console.log("Round ID:", roundId.toString());
  console.log("Answer:", answer.toString());
  console.log("Started At:", new Date(startedAt * 1000).toLocaleString());
  console.log("Updated At:", new Date(updatedAt * 1000).toLocaleString());
  console.log("Answered In Round:", answeredInRound.toString());
}

// Execute the function
getLatestRoundData().catch(console.error)

from web3 import Web3

# Connect to holesky
rpc_url = "https://some.holesky.rpc"  # Replace with your rpc
web3 = Web3(Web3.HTTPProvider(rpc_url))

# Check if connected to the node
if not web3.isConnected():
    print("Failed to connect to the Ethereum node.")
    exit()

# Contract address and ABI
contract_address = web3.toChecksumAddress("0xDD8387185C9e0a173702fc4a3285FA576141A9cd")
contract_abi = [
    {
        "constant": True,
        "inputs": [],
        "name": "latestRoundData",
        "outputs": [
            {"name": "roundId", "type": "uint80"},
            {"name": "answer", "type": "int256"},
            {"name": "startedAt", "type": "uint256"},
            {"name": "updatedAt", "type": "uint256"},
            {"name": "answeredInRound", "type": "uint80"}
        ],
        "payable": False,
        "stateMutability": "view",
        "type": "function"
    }
]

# Initialize the contract
contract = web3.eth.contract(address=contract_address, abi=contract_abi)

# Call the latestRoundData function
try:
    round_data = contract.functions.latestRoundData().call()
    round_id, answer, started_at, updated_at, answered_in_round = round_data
    print(f"Round ID: {round_id}")
    print(f"Answer: {answer}")
    print(f"Started At: {started_at}")
    print(f"Updated At: {updated_at}")
    print(f"Answered In Round: {answered_in_round}")
except Exception as e:
    print(f"An error occurred: {e}")

🌎 Operators

🔍Concepts

Cryptoeconomic Security

The following sections provide a mathematical analysis, showing the enhanced security and stability of such a system.

Measuring Cryptoeconomic Security

Cryptoeconomic security (CES) is a useful measure for analysis, consider the following;

To assess whether attacking is beneficial, the attacker must take into account two elements: the Cost of Corruption () and the Profit from Corruption ().

signifies the potential gains the attacker would achieve post-successful manipulation. Our analysis requires a more subtle approach towards , and thus we divide into two sources as follows:

Profit from Manipulation () is the internal profit the attacker can gain by manipulating the protocol. For instance, for Oracle protocols, it is the profit that could be extracted by a malicious price update. The is upper-bounded by the protocol's Total Value Secured (TVS).
Profit from Depreciation () addresses the external profit the attacker can gain from betting on price volatility or depreciation through, e.g., derivative markets or short selling.

Notice that . A rational attacker will only attack if .

We capture this in the following definition.

Definition (CES Margin). A protocol has a -crypto-economic security margin, or a -CES margin, if

Profit from Short Selling

We now discuss the ingredient and suggest a (stylized and simplified) way to quantify it. Crucially, it does not rely on any property of a protocol and refers to any asset, be it cryptocurrency, fiat, or stock.

Consider a token we call $TOK, and assume that the attacker can short $TOK. Since we assume the attack is relatively quick, we neglect the shorting fees. The amount of short positions is bounded by $TOK's short interest. Namely, the percentage of $TOK's free float market cap that the attacker could short sell, which we denote by . We stress that typically . Further, let denote $TOK's total market cap (in USD). We therefore assume the attacker can open a short position of USD. Next, let denote the percentage of depreciation due to the attack, for . A short seller can thus earn for every $TOK they short. All in all, a successful short trade will grant the attacker a profit of USD.

CES: A Tale of Two Oracles

To demonstrate how the CES margin is affected by the nature of the protocol's token, we compare the following two scenarios:

EnshrinedOracle, which relies on the base-layer's token that we denote by $ETH.
TraditionalOracle, relying on its own token that we denote by $TRD.

We assume that the only difference between EnshrinedOracle and the TraditionalOracle is the token used for staking. In both scenarios, the market cap of the stake is equal and worth (measured in USD); however, as we show shortly, the two scenarios imply different CES margins. The reason is that an attack's ramifications are different.

The value and utility of $ETH are independent of EnshrinedOracle's activities, unlike $TRD, whose value is closely tied to the operations of TraditionalOracle.

Resilience to Attacks

For TraditionalOracle ($TRD), a successful attack on the TraditionalOracle will affect the $TRD value, as the $TRD's inherent value is tied to the operations of TraditionalOracle. The attacker can gain USD by shorting $TRD prior to the attack; hence, in TraditionalOracle's case .

For EnshrinedOracle ($ETH), as the value and utility of $ETH are unrelated to the EnshrinedOracle protocol the price of $ETH will not be affected. Thus, the equals 0 for EnshrinedOracle.

. If the TraditionalOracle, which relies on its own token $TRD, has a -CES margin, then EnshrinedOracle, which relies on the base-layer's token $ETH, has a -CES margin.

Observation 1 is illuminating. To illustrate, assume that the TraditionalOracle is a medium-sized decentralized service ( billion USD) with a reasonable short interest ().

Under a severe attack (), its CES margin is smaller by 70-100 million USD compared to EnshrinedOracle.

Divergences in the Cost of Corruption

External, unforeseen events can break the CES of the TraditionalOracle. A crucial observation is that the , which is the stake of the validators, is always smaller than $TRD's market cap . Let denote the proportion of $TRD market cap used for staking in the protocol, namely . We use this formulation to analyze the robustness of the protocol and suggest it is susceptible to a death spiral.

For any real number , the TraditionalOracle could be CE-vulnerable even if the cost of corruption is times the profit of manipulation, i.e., .

The above observation means that attacks might be executed even if the is negligible, provided that the attacker can gain from a $TRD price decrease after the attack. The component should thus reflect not only the TVS (through ) but also the short interest (through ).

Being able to short $TRD based on the TraditionalOracle's operations increases the potential profit from attack, whereas there is no such benefit for attacking EnshrinedOracle.

Market Fluctuation Impact

Assume the protocol is CE-secure. Any fluctuation in $TRD market cap can make the protocol CE-vulnerable.

This observation is demonstrated using an example.

Example 1:

We analyze the CES of TraditionalOracle after a major price drop, which occurs due to, e.g., a major crypto volatility event. We denote by the time of the price drop. We assume that the stake proportion is the attacker's foreseen price drop is , and the short interest is .

Before the attack at , we assume the market cap of $TRD is (all monetary quantities are given in million USD terms). Consequently, , and Additionally, we assume that before time the potential profit from manipulation is

The event at , which occurs due to a major crypto volatility event, causes the market cap of all crypto tokens to decrease. Particularly, we assume that $TRD drops by and that the more stable$ETH drops by . Furthermore, such a market cap change also decreases the . TraditionalOracle's TVS is comprised of different tokens, for instance in $ETH, wrapped versions of $BTC, stable coins ($USDT/$USDC ), and more. Some of those tokens are more volatile than others, and some do not fluctuate at all. We thus assume that, on average, the drops on the same scale as $ETH, namely by .

The figure below depicts the situation before and after , as we formally analyze next.

Let us analyze the CES margin. Before , we see that the CES margin is positive, since

\textit{CoC} - \textit{PfM} - \textit{PfD} = 200 - 90 - 75 = 35.

After , which occurs due to a major crypto volatility event, the market cap of $TRD drops by and becomes . As a result, the falls to and the drops to . Furthermore, the market cap of all crypto market drops and, as noted above, the drops by . Overall, the CES margin becomes negative, since

\textit{CoC} -\textit{PfM}-\textit{PfD} = 100 - 72 - 37.5 = -9.5.

Thus, the event at that sparked a price drop made the TraditionalOracle CE vulnerable.

Next, we analyze EnshrinedOracle, relying on the independent $ETH token. The CES margins of EnshrinedOracle before the event is

\textit{CoC} -\textit{PfM}-\textit{PfD} = 200-90-0=110.

The event at affects EnshrinedOracle's CES margin as well. First, EnshrinedOracle has no as it relies on an independent token; thus, the attacker cannot gain from betting on price drops. Secondly, EnshrinedOracle's decreases due to the drop of $ETH, by to become. Thirdly, as in the case of TraditionalOracle, the drops by , becoming . Overall, the CES margins of EnshrinedOracle after the event is

\textit{CoC} -\textit{PfM}-\textit{PfD} = 160-72-0=88.

The figure below depicts the change in the CES margin of EnshrinedOracle due to the same event. Importantly, under precisely the same event, EnshrinedOracle remains CE secure.

The TraditionalOracle's CE security is far more susceptible to market fluctuations, whereas EnshrinedOracle's security is resilient to external market forces.

Beyond Profit from Depreciation

Until now, we have focused on , an element that plays a crucial role in the TraditionalOracle but not in EnshrinedOracle. The analysis assisted in understanding how an independent token ($TRD) decreases the CES margin (Observation 1), making the protocol susceptible to attacks even if the is orders of magnitude greater than the (Observation 2), and could result in vulnerabilities in times of price fluctuations (Observation 3). But relying on a dedicated token $TRD bares other weaknesses. In the next section, we extend our analysis to challenges in the , particularly around issues of scaling and cost of capital.

Scaling Cost of Corruption with Total Value Secured

Assume that both protocols gain traffic and usage, resulting in a ten-fold increase in the TVS. The higher the TVS, the higher the ; hence, the CES margin decreases dramatically. For simplicity, we shall assume that the is a constant fraction of the TVS. How can the protocols regain their CE security?

To keep the CES margin positive, the should scale linearly with the TVS.

Recall that for TraditionalOracle, where is the staked proportion of $TRD and is $TRD market cap. The TraditionalOracle can hence increase its in two ways:

Passively, due to an increase in $TRD market cap.
Actively, by increasing the staked proportion .

EnshrinedOracle can mitigate a TVS increase by controlling the stake, allowing the CoC to scale accordingly.

Cost of Capital

The Dual Token Model

Implementing all of these mechanisms while having stake rooted in $ETH retains the CES benefits of EnshrinedOracle while avoiding the CES vunerabilities of TraditionalOracle.

Proofs

Proof of Observation 1.

The TraditionalOracle satisfies , with . EnshrinedOracle has the same and , but zero since it relies on the independent $ETH token. Its CES margin is thus .

Proof of Observation 2.

Assume that , namely that . Therefore,

CoC-PfM-PfD=sm-\frac{sm}{q}-kdm=m\left(s(1-\frac{1}{q})-kd\right).

The attack is thus beneficial as long as . Specifically, if the short interest is greater or equal to the stake proportion , the protocol becomes CE-vulnerable if the attacker expects a price drop of . This vulnerability still remains even if , since could potentially reach 1 and for any

Proof of Observation 3.

Assume that before the event, the market cap satisfies ; thus, the protocol is CE-secure since

CoC-PfD-PfM=m(s-kd)-PfM > m(s-kd) -m(s-kd)=0.

Assume that the does not depend on the market cap . This is the case for, e.g., lending markets that mostly offer contracts in $ETH, etc. Since , there exists a real number , for , such that . Denote by the market cap of $TRD after the event. Consequently, if , it holds that

CoC-PfD-PfM=m'(s-kd)-PfM = (m'-m_0)(s-kd) < 0;

thus, the protocol is CE-vulnerable. In other words, if the is not affected by the event, a market cap decrease can spark an attack.

Proof of Observation 4.

For the sake of this proof, we use the subscript to refer to objects in time ; for instance, is the at time . The CES margin at time is given by

CoC_t -PfM_t-PfD_t.

Assume at time the CES margin is positive and equals . Further, assume by contradiction that , where is the . Our assumption about the being a constant fraction of the TVS implies that also holds. By definition, there exists a time for which , and hence

CoC_{t'} -PfM_{t'}-PfD_{t'} \leq CoC_{t'} -PfM_{t'}<0;

therefore, the protocol is CE-vulnerable at time .

End Notes

In practice, the attacker would buy leveraged contracts and employ trading strategies. We focus on short positions, ensuring our model is simple yet aligned with reality.

Risk Management and Market Integrity

Data Feed Categories

At eOracle, we've implemented a comprehensive categorization system for our data feeds. This system is designed to inform users about the intended use cases of each feed and highlight potential market integrity risks associated with data quality. Our goal is to provide you with the information needed to make informed decisions when integrating eOracle feeds into your applications.

It's important to note that all feeds published in eOracle's documentation undergo rigorous monitoring and maintenance, adhering to the same high standards of quality. Each feed is subject to a thorough assessment process during implementation. The specific assessment criteria may vary depending on the type of feed being deployed and may evolve over time as our understanding of market integrity risks deepens.

We group our data feeds into the following categories, ranked from lowest to highest level of market integrity risk:

✅ Low Market Risk
🟡 Medium Market Risk
⭕ High Market Risk
⚙ Custom Feeds
🔭

This categorization serves as a guide to help you understand the relative risk profile of each feed. However, we encourage users to conduct their own due diligence and risk assessment when integrating any data feed into their smart contracts or applications.

By providing this transparent categorization, eOracle aims to empower developers and projects with the knowledge they need to build robust, risk-aware decentralized applications. Remember, the appropriate use of a feed depends on your specific use case and risk tolerance.

Key Risk Factors by Market Integrity Risk

Market Integrity Risk - Key Factors

✅ Low Market Risk Feeds

🟡 Medium Market Risk Feeds

⭕ High Market Risk Feeds

⚙ Custom Feeds

Custom Feeds are designed for specific purposes and may not be appropriate for general usage or align with your risk parameters. It's essential for users to examine the feed's characteristics to ensure they match their intended application.

Custom feeds fall into these categories:

Onchain single source feeds: Utilize data from one onchain source, with only one provider currently supporting the feed.
Onchain Proof of Reserve Feeds: Employ a large, diverse group of vetted node operators to obtain and confirm onchain reserve data.
Exchange Rate Feeds: Access exchange rates from external onchain contracts for token conversions. eOracle doesn't own or manage these contracts.
Total Value Locked Feeds: Assess the total value locked in particular protocols.
Custom Index Feeds: Calculate values based on multiple underlying assets using predetermined formulas.
Offchain Proof of Reserve Feeds: Verify offchain reserves through custodian attestations.
LP Token Feeds: Combine decentralized feeds with calculations to value liquidity pool tokens.
Wrapped Calculated Feeds: Specific feeds that are pegged 1:1 to underlying assets, but may deviate from market price given that the price is a derivative formed from a calculated method.

Evaluating Data Sources and Risks

Liquidity and its Distribution

When integrating price data for an asset into your smart contract, ensure the asset maintains adequate market liquidity to prevent price manipulation. Low-liquidity assets can experience high volatility, potentially harming your application and users. Unscrupulous actors may exploit volatility or low trading periods to manipulate smart contract execution.

Some feeds source data from single exchanges rather than aggregated services. These are identified in the feed's documentation. Evaluate the specific exchange's liquidity and reliability.

Liquidity migrations, where tokens move between providers (e.g., DEX to CEX), can temporarily deplete the original pool's liquidity, increasing manipulation risk. If planning a migration, collaborate with stakeholders (liquidity providers, exchanges, oracle operators, data providers, users) to maintain accurate pricing throughout.

Low-liquidity assets may show price oscillations between points at regular intervals, especially when data providers show unusual price spreads. To manage this risk, continuously assess the asset's liquidity quality. Low-liquidity assets may also experience erratic price movements from incorrect trades.

Develop and test your contracts to manage price spikes and implement protective measures. For instance, create tests simulating various oracle responses.

Single Source Data Providers

Certain data providers rely on a single source, which may be unavoidable when only one source exists, either onchain or offchain, for specific data types. It's crucial to thoroughly evaluate these providers to ensure they deliver reliable, high-quality data for your smart contracts. Be aware that any errors or omissions in the provider's data could adversely affect your application and its users. Careful assessment of single-source providers is essential to mitigate potential risks associated with data inaccuracies or inconsistencies.

Crypto and Blockchain Actions

Price data quality can be affected by actions taken by crypto and blockchain project teams. These "crypto actions" are akin to corporate actions but specific to the crypto sphere. They include token renaming, swaps, redenominations, splits, reverse splits, network upgrades, and other migrations initiated by project teams or governing communities. Maintaining data quality depends on data sources implementing necessary adjustments for these actions. For instance, a token upgrade resulting in migration may require a new Data Feed to ensure accurate price reporting. Similarly, blockchain forks or network upgrades might necessitate new Data Feeds for data continuity and quality. Projects considering token migrations, forks, network upgrades, or other crypto actions should proactively engage relevant stakeholders to maintain accurate asset price reporting throughout the process.

Periods of High Network Congestion

Data Feed performance is dependent on the blockchain networks they operate on. During times of high network congestion or downtime, the frequency of eOracle Data Feeds may be affected. It's recommended that you design your applications to detect and appropriately respond to such chain performance or reliability issues. Implementing measures to handle these network fluctuations can help maintain the stability and accuracy of your data-dependent applications.

DEX Volumes

Assets with significant presence on decentralized exchanges (DEXs) face unique market structure risks. Market integrity may be compromised by flash loan attacks, volume shifts between exchanges, or temporary price manipulation by well-funded actors. DEX trades can also experience slippage due to liquidity migrations and trade size. The impact of high-slippage trades on market prices depends on the asset's trading patterns. Assets with multiple DEX pools, healthy volumes, and consistent trading across various time frames generally have lower risk of deviant trades affecting aggregated prices.

Backed and Bridged Asset Considerations

Pricing Considerations for Backed or Bridged Assets

When evaluating a eOracle Data Feed for backed or bridged assets (e.g., WBTC), users should weigh the pros and cons of using a feed specifically for the wrapped asset versus one for the underlying asset.

Decisions should be made individually, considering:

Liquidity
Market depth
Trading volatility of the underlying asset compared to its derivative

Users must also assess the security mechanism maintaining the peg between the wrapped asset and its underlying counterpart. Regularly review these factors as asset dynamics evolve over time.

Price Divergence in Extreme Events for Backed Assets

eOracle Data Feeds are designed to report market-wide prices of assets using aggregated prices from various exchanges. For backed or bridged assets, these feeds continue to report the underlying asset's price in addition to the wrapped token's price. This approach reduces manipulation risks associated with the typically lower liquidity of wrapped tokens.

However, users should be aware that extreme events, such as cross-chain bridge exploits or hacks, may cause significant price deviations between wrapped assets and their underlying counterparts. For instance, a bridge hack could lead to a collapse in demand for a particular wrapped asset.

To mitigate risks during such scenarios, users should implement safeguards in their applications. Circuit breakers, which can be created using eOracle Automation, are recommended to proactively pause functionality when unexpected scenarios are detected in data feeds.

Additionally, consider using eOracle Proof of Reserve for real-time monitoring of wrapped asset reserves. This enables protocols to ensure proper collateralization by comparing the wrapped token's supply against the Proof of Reserve feed.

Exchange Rate Feeds vs Market Rate Feeds

Exchange rate feeds differ fundamentally from standard market rate eOracle Price Feeds in their architecture and purpose.

Market rate feeds provide price updates based on aggregated prices from multiple sources, including centralized and decentralized exchanges. This approach offers a comprehensive view of an asset's market-wide price.

In contrast, exchange rate feeds are specific to particular protocols or ecosystems. They report internal redemption rates for assets within that ecosystem, sourcing data directly from designated smart contracts on a source chain and relaying it to a destination chain.

Exchange rate feeds are particularly useful for:

Pricing yield-bearing assets by combining the exchange rate with the underlying asset's market rate
Enhancing liquidity pool performance for yield-bearing assets by enabling programmatic adjustments to swap curves

It's crucial to note that both feed types have distinct risk profiles and mitigation strategies, which vary based on asset type and liquidity. Users are responsible for selecting the appropriate feed for their needs.