At its core, EO is an open infrastructure platform that empowers developers to build secure blockchain oracles backed by Ethereum's battle-tested security model. EO creates a foundation for specialized data services that combine deep domain expertise with unmatched cryptoeconomic security.

Smart contracts are powerful tools for executing transparent, immutable logic. However, to reach their full potential, they need reliable access to real-world data. Blockchain oracles serve as the critical bridge between blockchain systems and external data sources, enabling smart contracts to interact with the world beyond their native blockchain.

Two essential principles guide EO's protocol:

Trust Minimization

Trust minimization is achieved through a decentralized network of 100+ staked-backed operators, an immutable data layer, and a coordination system allowing different unrelated entities to take part and contribute while putting stakes at risk through an infrastructure that is designed to maintain trusted, reliable data operation for decentralized data machines.

Permissionless Innovation

The EO stack provides a comprehensive platform that anyone can use to build specialized blockchain oracle services without permission or gatekeeping. Domain experts can leverage our infrastructure to deliver high-quality data solutions for their specific use cases, focusing on what they do best. With EO handling the complex security and coordination challenges, builders can freely innovate within their expertise – whether it's financial data, real-world events, or computational services – and deploy their solutions immediately.

This open architecture creates a vibrant marketplace where specialized blockchain oracle services thrive through competition and innovation. The ecosystem benefits from a rich diversity of secure data solutions, each optimized for specific use cases while maintaining rigorous security standards. This permissionless approach unlocks Web3's true potential by giving users and applications access to an ever-expanding landscape of secure, specialized data services – all protected by Ethereum-grade security.

Choose your path in the EO ecosystem through three distinct roles:

Build on EO - Blockchain Oracle Developers

Blockchain Oracle Validated Services (OVS) enable domain experts to build specialized blockchain oracle solutions using EO's secure infrastructure.

• To learn more and explore the OVS Framework → visit Introduction to EO Stack

Use ePRICE - Dapp Developers

ePrice is EO's flagship product, providing secure and reliable price feeds for decentralized applications. Built with robust security mechanisms and availability across all major networks, ePrice offers permissionless integration for any application requiring trusted price data.

• To integrate your dapp with blockchain Oracle → visit the Integration Guide or check our Data

Take part in the Operation - Operators.

Operators form the backbone of EO's decentralized network, validating data and maintaining network security. By staking ETH through EigenLayer, operators earn rewards while contributing to the ecosystem's security and reliability.

• To learn more about becoming an operator and to register → see the Operator Guide.

The Current Reality

Today's blockchain oracle landscape is dominated by a small group of companies that must build and maintain everything: infrastructure, security, node networks, and data solutions. This "do-it-all" approach has created an unsustainable bottleneck in blockchain innovation.

Why Traditional Blockchain Oracles Fall Short

When diving deep into solving the blockchain oracle problem, two layers of complexity emerge that make any centralized solution fundamentally insufficient.

First is the inherent complexity of data itself. Each domain demands its own specialized understanding. Financial data requires sub-second updates and sophisticated anomaly detection. Social media data demands extreme throughput and ability to track emerging patterns in real-time. Risk and cyber analysis require complex prediction models and automated decision-making. Each domain comes with its own patterns, failure modes, and expertise requirements. A solution perfect for one becomes fundamentally flawed for another.

But that's only half the challenge. Building infrastructure for trustless data delivery - with high reliability, consistent uptime, and true decentralization - requires solving deep problems in cryptography, game theory, and distributed systems. The technical complexity here rivals that of the base layer blockchains themselves.

Complex coordination problems of this scale cannot be solved by any single entity. Instead, they require the power of free market innovation, where diverse participants can contribute their specialized knowledge and compete to deliver the best solutions. Just as no single provider can solve every blockchain's unique challenges, no single blockchain oracle provider can possess all the expertise needed to bring the world's data on-chain.

The Two-Layer Solution

EO introduces a fundamental shift: separating blockchain oracle services into distinct layers:

• The security layer (EO) handles infrastructure and cryptographic guarantees

• The data layer (OVS) enables specialists to focus purely on their domain expertise

This separation represents the natural evolution of a maturing market - where different participants can specialize and perfect their part of the solution, resulting in better outcomes for everyone.

The EO stack creates the foundation for a marketplace of blockchain oracle services where specialized knowledge can flourish and compete. Through this marketplace, the blockchain oracle problem will solve itself through the distributed efforts of countless builders and innovators, secured by Ethereum itself.

This section provides a comprehensive overview of EO's smart contract infrastructure. Our design creates a modular and programmable platform that supports new blockchain oracle development through flexible operator management, diverse data types, and customizable aggregation methods.

The Aggregation Library is a collection of smart contracts that provides reliable on-chain data aggregation for various use cases. Each method addresses specific data scenarios to maintain accuracy and integrity in decentralized environments.

Considerations for choosing the proper aggregation:

1. Time-variance. Since time is continuous, fetchers access the source at slightly different times. We don’t expect the time differences to be significant; more particularly, the time differences should not exceed one second, which is the rate of our blockchain i\o.

2. Simplicity. It is crucial due to runtime considerations and explaining to users how our mechanism works (KISS/Occam’s razor).

3. (Honest) mistakes. Although we have incentive mechanisms to punish/reward fetchers’ behavior, mistakes are unavoidable. For instance, downtime, latency, etc. These can happen even if fetchers are honest and thus should be accounted for.

4. Malicious behavior. Our solution should be as robust as possible to attacks. Namely, it should minimize the consequences of an attack and facilitate punishing attackers.

For detailed explanations, please refer to Robust Aggregation 101

For some shor example for aggregation methods please refer to Median

A core feature of PoS protocols is the ability to implement transparent and objective rewards and penalties mechanisms. The objective is to incentivize data validators to maintain data quality and accuracy and discourage attempts to manipulate the blockchain oracle.

The fundamental prerequisites to enable a quality mechanism are:

1. Inaccurate data reports should be detectable

2. Honest mistakes and malicious manipulation attempts should be distinguishable

3. Faults should be objectively attributable (which is trivial in the canonical case where data validators sign their data reports)

4. Metrics on data quality should be defined

EO chain serves as a robust infrastructure to achieve these abilities as:

1. Operators are stake-backed

2. Data validators' past activity is transparent and recorded in an immutable manner

3. Prepared on-chain components to support rewards distribution and slashing

For a fundamental analysis of blockchain oracle cryptoeconomic security and key considerations behind slashing in a subjective environment, please refer to:

This section outlines the Principal Token (PT) pricing methodologies supported by EO. It introduces three foundational pricing models and discusses a hybrid approach designed to balance stability and market responsiveness.The guidelines provided are general. Specific implementation details depend significantly on the issuer's protocol design and the underlying AMM architecture.

Pricing Methods

PT pricing involves two primary components: selecting a price source and defining the pricing model. Price sources may include trading data or fixed APY assumptions. The three core pricing models are: linear discounting, zero-coupon bond, and AMM-based pricing.

Deterministic models rely solely on time-based formulas, independent of external price feeds. They offer predictability and manipulation resistance, making them ideal for low-liquidity environments.

1. Define and implement data validators execution logic - Writing DV code to retrieve the required data. Data here refers broadly to any output from computations, including fetching information from APIs, querying databases (blockchains included), and calculating statistics on account balances.

2. Transaction format - Data validators must pack their computation results into a transaction structure before sending them to EO chain. Data reports may include additional data such as timestamps, proof of computation etc. Transaction are signed using either BLS or ECDSA.

3. Sending transaction to EO chain - The EO chain is EVM-compatible, supporting the standard transaction formats used by common libraries like ethers.js and web3.js.

After the data validator code is established, The EO Wrapper facilitates interaction with the EO chain:

• Retrieving OVS configuration, including update notifications

• Sending reports to the EO chain with minimal latency

• Publishing Prometheus metrics to monitor the off-chain component's health

Key considerations

• Data validators typically run identical logic. This redundancy achieves decentralization and ensures that malicious behaviors can be easily validated on-chain. However, this replication creates coordination challenges. Data validator task should be easily scaled to run among all OVS operators.

• In certain scenarios, computation integrity evidence can be recorded on-chain to verify the actions of data validators. This process helps in validating data accuracy and quality.

EO addresses the Blockchain Oracle problem from the first principles. As the first blockchain oracle built on EigenLayer, we believe true innovation in blockchain data requires:

• Decoupling complex problems into layers

• Solving each layer with dedicated, high-quality solutions

• Maintaining uncompromising security standards

Current Blockchain Oracle solutions, managed by a few centralized organizations, create stagnation in blockchain innovation. Domain experts from diverse data fields are unable to bridge their valuable insights on the chain due to the complexity of building a secure blockchain Oracle infrastructure.

The EO stack changes this by providing production-ready infrastructure components. Data experts can now build custom blockchain Oracle solutions focused on their domain expertise while EO handles the security and infrastructure complexities. Through blockchain Oracle Validated Services (OVS), specialized data solutions can be built and deployed without compromising on security or decentralization.

These docs guide you through the core concepts of the OVS framework, introducing the components and features of the EO stack and outlining how to start building.

EOFeedManager: The entry point for submitting feeds to the target chain, holding the latest feeds EO has published to the chain.

https://github.com/eodata/target-contracts/blob/develop/src/EOFeedManager.sol

EOFeed Verifier: Used by the feed manager to verify the integrity of the payload and the signatures of the witnesses who signed it.

https://github.com/eodata/target-contracts/blob/develop/src/EOFeedVerifier.sol

EOFeedAdapter: This smart contract exposes an interface identical to Chainlink contracts (the industry standard of having dedicated contracts per feed) from our client's side. Adaptation is needed because while our novel batching method reduces costs, all feeds are managed by the feed manager.

https://github.com/eodata/target-contracts/blob/develop/src/adapters/EOFeedAdapter.sol

OVS

Blockchain Oracle Validated Services (OVS) are decentralized blockchain Oracle protocols built on top of EO. The OVS framework introduces a new paradigm for blockchain Oracle design, focusing on separating infrastructure from specialized data solutions, creating a mature market with a clear separation of concerns.

By providing a platform for diverse participants to create specialized blockchain oracles, EO 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.

For a deeper understanding of the vision and necessity behind OVS, please refer to

What Does It Take to Build a Blockchain Oracle?

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

A decentralized blockchain oracle needs to address the following questions:

• Sources - What are the qualitative sources for this type of data? What off-chain computation should be transmitted 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 validator participation be assessed and appropriately rewarded or penalized? In particular, how can misreports be detected and distinguished between honest mistakes and malicious manipulation attempts?

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.

Audience

Potential OVS builders include:

1. Blockchain Oracle-First Companies - Teams that build specialized blockchain oracle services using EO's infrastructure.

2. Blockchain Oracle-Dependent Products - Projects that need custom blockchain Oracle solutions not currently available.

3. Internal Blockchain Oracle Needs - Teams looking to connect their existing operations on-chain through blockchain Oracle integration.

Next, the key features of the EO stack are explored, which teams can use to build their OVS.

The data processing consists of 3 stages:

1. Data validators obtain data from sources using WebSockets, APIs, or perform some general off-chain computations. They sign this data and send it as a transaction to the EO-chain.

2. Chain validator nodes receive the signed reports, verify the reporter's identity, and aggregate the verified reports using dedicated schemes. This computational aggregation process and its result become an immutable part of the EO-chain.

3. EO Cryptographic broadcaster bridges data feeds from the EO-chain to various target chains. This involves monitoring EO-chain events in real-time, validating feed data against predefined criteria, signing data, and submitting verified feed updates to target chains.

All of the above actors are stake-backed EO\eigen’s operators.

For more detailed information, please refer to

The following sections describe how builders can use and configure EO's features to meet their OVS needs

The OVS design and deployment process consists of four parts:

1. Set up - Register as an OVS on EO chain, specify operator prerequisites, and define data feeds and sources.

2. Off-chain Components - Develop the logic for the data validator to retrieve data and define the update format. Use the EO Wrapper to retrieve the OVS configuration from the EO chain, and publish Prometheus metrics to monitor the health of the off-chain component.

3. On-chain components - Design aggregation logic and incentive management related contracts including slashing, rewards distribution, and so on.

4. Target chains publishing - Configure EO broadcaster to establish update parameters, triggering conditions, and verification schemes

1. Target chain updating -Teams should establish their publishing requirements according to their data reporting needs and specific use cases.

   1. Deciding on exact data to be delivered

   2. Setting triggering parameters

   3. Chain-specific batching strategies and optimizations

2. Data consumption interface - EO implements Chainlink's , enabling seamless transitions between blockchain oracle providers. See for details on consuming data from EO.

3. Verification scheme - EO broadcaster supports BLS, ECDSA and additional cryptographic techniques supporting bridging data cross-chain and proving integrity. While the canonical flow of the broadcaster is recommended, different use-cases may require different solutions on the perfomance-security tradoff curve.

Key considerations

• Performance-Security Tradeoff Analysis for Optimized Verification Per Use Case

• Gas minimization through appropriate data compression

• End users experience

For more information, see

The EO stack is production-ready, with a phased approach to permissionless building. EO's flagship product ePRICE, focused on price feeds, is operational alongside EtherOracle, the peg-securing blockchain oracle.

Established companies are building on EO to decentralize their existing products, while new teams leverage our stack to build from day one. Both benefit from focusing on their domain expertise without compromising on security and infrastructure design.

The potential for OVS spans across blockchain innovation. From zkTLS blockchain oracles validating encrypted web data to prediction market dispute mechanisms, any decentralized consensus-based process can be built using the EO stack.

Let's explore the current projects building on EO.

• - EO flagship Price blockchain oracle for Defi

Price feeds make or break DeFi - too vital to run on promises alone. ePRICE represents a fundamental shift in price feed design, built on the core principles of restaking and cryptoeconomic security. Where traditional solutions rely on reputation and centralized trust, ePRICE ensures reliability through transparent architecture and Ethereum-based security guarantees.

The Dual Challenge of Price Blockchain Oracles

DeFi protocols depend on price feeds as their source of truth, creating two fundamental challenges that ePRICE addresses head-on through innovative design and robust infrastructure.

1. The Data Challenge: Getting the Right Price

The core challenge of price feeds lies in the fundamental nature of crypto markets: trading occurs simultaneously across multiple venues, prices vary between markets, and liquidity shifts continuously. At its heart, this creates a complex price discovery problem where market manipulation must be distinguished from legitimate price movements.

A robust price indexing model must maximize responsiveness to legitimate market-wide price movements while minimizing reactions to temporary or isolated price anomalies.

The ePRICE Approach: Our solution combines continuous data collection from multiple high-quality sources with sophisticated indexing algorithms that adapt to market behavior and liquidity changes in real-time. Each price feed is tailored through dedicated DeFi research, considering the unique characteristics and trading patterns of different assets. This market-aware approach ensures our price discovery remains accurate even as market dynamics evolve.

2. The Infrastructure Challenge: Guaranteed Delivery

The most accurate price data becomes worthless if it can't be reliably delivered, especially during market stress periods when price feeds are most critical. A secure blockchain oracle infrastructure must maintain true decentralization while ensuring no single point of failure can compromise the system.

The ePRICE Approach: As the first blockchain oracle built on the EO Stack, ePRICE leverages a decentralized, modular system designed specifically for high-stakes data delivery. Our network of 130+ validators, backed by over $2M in restaked ETH, ensures data integrity through real-time performance tracking and sophisticated outlier detection. Each price update flows through a transparent process where operators submit signed data to our proof-of-stake chain, achieving consensus before being cryptographically broadcast to target chains.

Experience ePRICE

ePRICE combines battle-tested infrastructure with sophisticated price discovery to deliver a new standard in blockchain oracle security and reliability. Built on Ethereum's security through restaking, our solution offers permissionless integration for any protocol requiring trusted price data.

This approach combines AMM TWAP pricing with a protective price floor. The floor can be implemented in two ways:

• ZCB Floor: Sets a lower bound using the ZCB model with a relatively high APY.

• Linear Discount Floor: Leveraging linear discount's tendency to underprice the market value.

This approach allows protocols to choose between stronger price protection (linear) or better market alignment (ZCB) while maintaining TWAP's market responsiveness. The price at time is given by:

With Linear Discount Floor:

With ZCB Floor:

where _t is the AMM-observed spot price over each sampling interval, is the elapsed time of that interval, and the sums run over all samples in the averaging window ending at . In the linear floor, denotes the total term (so - is the time remaining) and in the ZCB floor, denotes the time to maturity (years).

This design leverages the natural tendency of deterministic models to underprice PTs, creating a protective lower bound that ensures stability. Meanwhile, when market conditions are favorable and trading prices exceed this floor, the TWAP component allows the PT to track higher market prices, enabling better capital efficiency. This balance helps protect against downside risk while maintaining upside potential.

1. Aggregation logic- Teams must define the proper method for aggregating validator reports into a single blockchain oracle update. Considerations include resistance to manipulation, performance, simplicity, and more. Methods vary significantly for different data types and use cases.

   For an exhaustive explanation of robust aggregation and the EO aggregation library, please refer to

2. Incentives mechanism- Define metrics for data quality and implement tools to evaluate operator performance. Based on these metrics, rewards and penalties are distributed through smart contracts. For an exhaustive elaboration on incentives design please refer to

More sophisticated pricing methods can be obtained by incorporating multiple pricing methods and deviation-based parameter updating, enabling higher capital efficiency while maintaining stability.

Market-driven models derive prices from observed trading activity, enabling real-time responsiveness. They are better suited to high-liquidity environments where pricing should reflect market conditions.

Definition

The median algorithm returns the middle value from a sorted list of validator reports. It is most naturally used for numerical data but can be applied to any ordered set of data.

A possible variant is the weighted median - Let $w^i$ be the stake of data validator $i$, and assume that $\sum_{i=1}^Nw^i=1$. Also, for simplicity, assume that $r_t^1,r_t^2,...,r_t^N$ are sorted. The weighted median is an element $r_t^k$ such that

Rationale and Properties

• Resistant to extreme values and outliers, as they only affect the tails of the sorted list—ignores the impact of anomalous data points due to its reliance on central values.

• The aggregation value will always be between the honest reports, assuming a majority of the stake belongs to honest validators (weighted median)

Limitations

• May not reflect the influence of large/small prices if they are outliers

• Non-incremental - the aggregated value cannot be updated upon each report in an online manner (as opposed to mean, for example, which supports $m_n=\frac{n-1}{n}\cdot m_{n-1}+\frac{r_n}{n}$ where $m_i$

  is the mean after $i$ reports and $r_i$ is the $i$-th report).

Prices are susceptible to noise and volatility. Therefore, financial applications often average prices over time. Well-known methods include Moving Average, Exponential Smoothing, Time-weighted Average Price (TWAP), and Volume-weighted Average Price (VWAP)

Definition

TWAP (Time-Weighted Average Price) - calculates an average value over a specified time period, weighting each data point by the duration or frequency of updates.

TWAP is calculated as follows:

where $P_j$ is the value of the at the $j$-th measurement and $T_j$ is the change in time since the previous measurement.

Rationale and Properties

• Reduces the impact of rapid fluctuations in the data by spreading them out over time.

• Incorporates time factors, making the final output reflective of trends rather than single-point events.

• Offers smoother price data for algorithmic trading and liquidity management.

Limitations

• Less appropriate sensitive to fast market shifts or abrupt changes -smoothing over time makes TWAP less responsive than other algorithms.

• Requires additional storage of the historic data.

Borsa Network: Intent Solving Blockchain Oracle

Revolutionizing DeFi Execution

Borsa Network is building a specialized blockchain Oracle Validation Service (OVS) on EO to bring sophisticated intent-solving capabilities to DeFi. Their system ensures efficient, fair execution of user intents through decentralized validation.

Core Innovation

The protocol transforms DeFi intent solving through a three-stage process:

• Intent Composition & Submission

• Network-Level Processing & Bundling

• On-chain Execution

Unlike traditional MEV-driven models, Borsa's case-agnostic approach prioritizes user outcomes while preventing exploitation.

Technical Architecture

Built on EO's infrastructure, Borsa's OVS implements:

• Proof-of-stake validation for intent fulfillment

• Optimization verification ensuring best execution

• Full ERC-4337 compatibility for standardized processing

Security & Infrastructure

Leveraging EO enables Borsa to focus on intent solving while gaining:

• Ethereum-based security through restaked ETH

• Decentralized operator network

• High-performance infrastructure for complex computations

Impact

This implementation demonstrates how specialized builders can leverage EO's infrastructure to create sophisticated, secure blockchain oracle services. Borsa's OVS represents a significant advancement in DeFi infrastructure, enabling more efficient and trustless operations.

1. OVS registration on EO chain - Include registration as an OVS and define data feeds and sources. The relevant contracts to be deployed are described in EO Chain contracts

2. Setting operators requirements - Specify prerequisites for operators to participate on OVS, including:

   1. Stake - Amount and type of tokens operators must hold → OVS native tokens can serve as a prerequisite, requiring a matching strategy on eigen . For more details: https://github.com/Layr-Labs/eigenlayer-contracts/tree/dev

   2. Reputation requirements based on operator activity history

   3. Software, runtime environment, and technology prerequisites

EO supports both permissionless operator registration (where operators join the OVS quorum upon meeting predefined criteria) and manual approval by the OVS manager.

Key considerations

• The Corruption-Analysis Model helps establish the minimum stake requirement by comparing the potential costs and benefits of corrupting the blockchain oracle. For a detailed explanation, please refer to Cryptoeconomic Security

• Default settings can be applied for stake and reputation requirements, using restaked ETH and auto-approved EO operators

Overview

The EO Broadcaster is a distributed system designed to bridge data feeds from the EO Chain to various target chains with high reliability, low latency, and cryptographic security.

The broadcaster's multilayer architecture enables flexibility and dynamism in handling data report formats, verification schemes, and update triggering logic.

System Architecture

The system consists of four main components that work together through message queues and a shared state database:

• Witnesses

• Aggregators

• Processors

• Publishers

Witnesses

Witnesses monitor the EO Chain for specific events and cryptographically attest to their validity.

Key responsibilities:

• Monitor EO Chain events in real-time

• Validate feed data against predefined criteria

• Generate Merkle trees for efficient data verification

• Sign data using both BLS and ECDSA signatures

• Submit signed attestations to the aggregators

The witness component ensures that each feed update is independently verified and signed by multiple parties.

Aggregators

Aggregators process witness signatures and combine them when sufficient voting power is achieved. They implement a stake-weighted consensus mechanism based on witness voting power.

Key responsibilities:

• Threshold-based sealing

• BLS and ECDSA signature aggregation

• Distributed coordination

aggregators achieve distributed coordination through the state database and capable for horizontal scaling.

Processors

Processors handle sealed aggregations and prepare them for target chain distribution. They maintain the latest state of feeds and generate proofs for target chain verification.

Key responsibilities:

• Verify aggregated signatures

• Maintain latest feed values in the state database

• Generate and store Merkle proofs

• Route updates to appropriate target chains and schedules.

• Implement feed routing logic based on target chain configurations

Publishers

Publishers handle the final submission of verified feed updates to target chains, implementing chain-specific optimizations and transaction management to ensure proper delivery, the one and only task of the publisher is to get the package delivered, no altering, or other logic and without opening the package.

Key features:

• Dynamic gas price optimization

• Transaction retry logic

• Chain-specific batching strategies

Definition

Groups identical/similar data points together and at the end of each aggregation window outputs the value corresponding to the heaviest cluster assuming sufficient weight (x% of total validators stake)

Default parameters:

• Aggregation window of one block

• Sufficient stake is 67% of the total validators stake

Rationale and Properties

• Proper in cases where we expect the same result among all data validators . For example, fetching from a single and stable source or performing the same computation

• Final result is strictly backed by most validators or stake weight (assuming 67% requirement)

• Given a relative majority submitting accurate reports, iInaccurate reports do not affect final result (as deviant or malicious reports fall into smaller clusters)

• Efficient online implementation and possible optimizations (Cleaning small clusters occasionally etc)

Limitations

• Storage inefficiency in worst case scenarios (ccurs when reports have high variance)

• Limited effectiveness with volatile data—when values change rapidly, multiple small clusters form instead of a clear majority, making it difficult to reach consensus.

Decentralized Validation Blockchain Oracle for Liquid ReStaking

When billions in liquid staking assets depend on accurate reward calculation, centralized blockchain oracles become an unacceptable risk.

Beyond Price Feeds

Liquid staking protocols have revolutionized ETH staking, but they've introduced new challenges. When millions of users depend on accurate reward distribution and token rebasing, the blockchain oracle that powers these calculations becomes critically important. This isn't just about price feeds – it's about complex validator performance analysis, reward accrual verification, and secure rebasing execution.

The Complexity of Trust

Rebasing in liquid staking protocols orchestrates a delicate balance between staked ETH and liquid tokens. When validators accumulate rewards over time, the protocol must precisely calculate these earnings and adjust token supply accordingly. This process demands real-time monitoring of thousands of validators, precise reward calculations, and immediate detection of critical events like slashing or exits. Even a minor calculation error could cascade through the entire DeFi ecosystem, potentially leading to protocol insolvency or unwarranted liquidations. The complexity of this task, combined with the magnitude of assets at stake, demands a solution far beyond traditional blockchain oracle capabilities.

Technical Architecture

EtherOracle leverages EO's infrastructure to create a robust, decentralized validation system:

1. Multi-Source Data Collection

   • Beacon chain API integration

   • Ethereum execution layer monitoring

   • Smart contract state analysis

   • Validator performance tracking

2. Distributed Computation

   • Independent reward calculations

   • APR verification

   • Validator state monitoring

   • Withdrawal request processing

3. Consensus Mechanism

   • Hash-based report verification

   • Quorum-driven agreement

   • Multiple integrity checks

   • Secure mainnet execution

Critical Infrastructure for DeFi

EtherOracle's role extends far beyond the immediate needs of liquid staking protocols. While it directly serves protocols managing validator sets and distributing rewards, its accuracy ripples through the entire DeFi ecosystem. When a user stakes their ETH, they trust the rebasing mechanism to fairly distribute their rewards. When lending protocols accept liquid staking tokens as collateral, they rely on accurate rebasing to maintain proper risk parameters. Even AVS protocols building on EigenLayer depend on precise liquid restaking token balances to ensure their security guarantees. EtherOracle thus becomes a critical infrastructure piece, securing not just individual protocols but the interconnected fabric of DeFi itself.

• Learn more about Etherfi and Liquid Restaking - https://www.ether.fi/

Powered by EO infrastructure and secured by Ethereum through EigenLayer

Securing DeFi's Next Generation of Synthetic Assets

By Bitpulse, in collaboration with EO

The New Complexity of Risk

As DeFi protocols embrace innovations like Bitcoin staking and restaking, the ecosystem is unlocking billions in liquidity. However, these assets introduce unprecedented complexity in risk management. Traditional risk assessment frameworks were not designed for these new primitives, leaving lending protocols struggling to effectively scale and manage their collateral.

Pulse: Reimagining Risk Management for the Next Era of DeFi Lending

Pulse is the first specialized risk intelligence layer for synthetic assets. Built by Bitpulse in partnership with EO, Pulse delivers real-time, multidimensional risk assessments that enable protocols to make informed decisions about synthetic assets in real-time.

Pulse helps the DeFi ecosystem prosper by democratizing risk:

• For lending protocols: Confidently underwrite collateral.

• For investors: Deploy capital into better-managed markets.

• For the DeFi ecosystem: Establish industry standards for synthetic asset risk assessment.

Key Capabilities

• Comprehensive synthetic asset risk analysis using multidimensional scores across protocol, counterparty, liquidity, and market risk.

• Real-time monitoring and risk alerts

• Cross-protocol exposure analysis to detect cascading risks across interconnected assets and protocols.

• Stress-Test Simulations to analyze resilience during black swan events like Luna or FTX collapses.

For Protocols

Integrate with Pulse to:

• Understand whether a synthetic asset should be accepted as collateral given your risk profile

• Make dynamic lending decisions based on real-time risk metrics

• Protect against complex failure modes in synthetic assets

• Adjust parameters based on sophisticated risk analysis

• Access institutional-grade risk assessment tools

Built by Risk and Protocol Experts

Developed by Bitpulse and EO, combining deep expertise in:

• Asset risk analysis

• Machine learning for financial systems

• DeFi protocol architecture

• Building scalable risk and data platforms in banks like Anchorage Digtial and giant tech giants like YouTube

Join Us in Securing DeFi's Future

We're actively partnering with lending protocols to validate and refine our risk assessment framework. If you're building or operating a lending protocol interested in safely expanding into synthetic assets, we'd love to collaborate -> Website, X

Key features of the EO stack include:

1. Modular stake-backed operators - OVS builders can selectively configure a subset of EO EigenLayer validators to handle blockchain oracle tasks—ranging from fetching data from custom APIs, running specialized off-chain computations, to monitoring real-time events. Each validator’s service is secured by restaked ETH (through EigenLayer), EO tokens, or an OVS-native token, ensuring alignment and integrity through staking-based incentives.

1. Execution & Consensus Layer - EO's purpose-built blockchain manages decentralized blockchain oracle operations, from data aggregation to consensus achievement.

2. Modular and Programmable blockchain oracle platform - A comprehensive smart contract architecture creates a modular and programmable blockchain oracle platform that supports new blockchain oracle development. This design provides a programmable layer for operator management, diverse data types, and aggregation algorithms while integrating with off-chain components and EO chain.
3. Data aggregation library - Collection of audited contracts that provides reliable on-chain data aggregation for various use cases. Each algorithm addresses specific data scenarios and security requirements.

4. Immutable data layer - EO chain serves as a permanent, transparent record of all blockchain oracle-related activity. This enables:

   • Verifiability: anyone can independently confirm the origin and accuracy of data.

   • Incentive Mechanisms: Permanent logging of operator performance enables the implementation of incentive mechanisms, including slashing, rewards distribution, insurance, and other advanced strategies to ensure consistently high service quality.

5. cryptographic broadcaster - a distributed system designed to bridge aggregated data from the EO Chain to various target chains with high reliability, low latency, and cryptographic security.

1. EO Ecosystem - EO Chain serves as a fertile ground for collaboration between multiple blockchain oracle protocols. Different OVS solutions can integrate to provide richer, more comprehensive data services. For example, a risk analysis oracle and a price feed oracle can combine to offer lending protocols price rates accompanied by risk analysis.

2. OVS Management - An app enabling OVS builders to manage operators, fetch data, publish, and configure various parameters

The ZCB model uses a compound interest formula to determine the PT price:

where $\text{initialAPY}$ is the APY fixed at inception, $t$ represents years to maturity, and $F$ is the face value. This model captures the exponential accumulation of yield over time and is widely adopted in traditional finance. It offers a more precise representation of time value compared to linear discounting, making it particularly appropriate for longer-term PTs or contexts requiring alignment with standard bond valuation practices.

The linear discount model is commonly used due to its simplicity and its ability to capture the essential behavior of PTs: a steady appreciation toward face value as maturity approaches. It models this convergence through a linear function, and can be viewed as a first-order approximation of traditional bond pricing, substituting exponential growth with a linear interpolation over the term.

The price at time $t$ is given by:

$P(t)=F- \text{baseDiscount} \cdot t$

where $t$ represents time to maturity and $F$ stands for the face value.

Setting the base discount:

There are two principal approaches to determining the base discount:

1. Direct APY assignment: The base discount is often set equal to the current APY at the time of market creation. This method is widely used for its simplicity, but tends to underprice by not accounting for compound interest effects.

2. Calibration to a target initial price: The base discount can be chosen to achieve a desired initial PT price. This approach treats the initial price as the primary input from which the base discount is derived. For example, in a one-year market, setting the base discount to $\frac{F\cdot APY}{1+APY}$ yields an initial price that aligns with the target APY.

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer: https://rootstock.blockscout.com/

• RPC: https://rootstock.drpc.org

• Chainlist: https://chainlist.org/chain/30

This model uses AMM-observed prices averaged over time. This method smoothens volatility and provides resistance to price manipulation, though it responds slowly to rapid market changes. This trade-off can be adjusted through different time window settings.

The price at time $t$ is given by:

where $P$_t denotes the AMM-observed spot price over each sampling interval and $Δt$ is the elapsed time of that interval. The sums cover all samples within the window ending at $t$. If all intervals are equal ($Δt$ is constant), TWAP reduces to the arithmetic mean of the sampled prices.

PT pricing involves balancing trade-offs between manipulation resistance, market responsiveness, simplicity, and capital efficiency. The optimal approach depends on the protocol's risk preferences, market conditions, and asset liquidity.

In a world where social signals drive markets and shape digital communities, bringing verified social data on-chain unlocks new horizons for web3 applications.

Beyond Simple Metrics

Social data isn't just about likes and follower counts. Understanding social influence requires deep analysis of engagement patterns, network effects, and temporal dynamics. Echo begins with X , parsing through complex social signals to deliver verified, meaningful insights about social impact and reach.

From X to Universal Social Truth

Echo starts by solving the immediate challenge of bringing verified X engagement metrics on-chain. But this is just the beginning. Our architecture is designed to expand across all social platforms, creating a comprehensive social blockchain oracle that can capture and verify social signals wherever they emerge. Through standardized data models and flexible validation frameworks, Echo enables progressive integration of new social platforms and metrics.

Technical Architecture

Echo's infrastructure processes social data through multiple layers:

• Raw Data Collection: Direct API integration with X, capturing real-time engagement metrics and network analysis

• Verification Layer: Cross-reference multiple data sources to ensure accuracy and detect manipulation attempts

• Pattern Analysis: Advanced algorithms to identify genuine engagement versus artificial inflation

• Network Effect Calculation: Measuring true reach and impact across social graphs

Security

Echo leverages EO's infrastructure and Ethereum security through EigenLayer to ensure reliable, tamper-proof social data delivery.

Initial Implementation

Echo's first deployment focuses on X engagement metrics crucial for web3 communities:

• Real-time monitoring of specified accounts

• Engagement analysis (likes, retweets, replies)

• Reach calculation and virality tracking

• Community growth patterns

• Network influence scoring

Impact Across Web3

While Echo begins with X metrics, its implications reach across the entire web3 ecosystem:

• DAO governance enhanced by social signal integration

• DeFi protocols incorporating social sentiment

• NFT valuations informed by creator engagement

• Community platforms with on-chain social reputation

• Marketing campaigns with verifiable impact metrics

Try ECHO beta Version on Camp Network testnet -

Powered by EO infrastructure and secured by Ethereum through EigenLayer

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer:

• RPC:

• Chainlist:

Pendle PT Price Feeds

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer:

• RPC:

• Chainlist:

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer:

• RPC:

• Chainlist:

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer:

• RPC:

• Chainlist:

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer:

• RPC:

• Chainlist:

Spectra PT Price Feeds

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer:

• RPC:

• Chainlist:

Spectra PT Price Feeds

Pendle PT Price Feeds

Price Feeds

Compatible with AggregatorV3Interface.

* The xUSD feed reflects the exchange rate published by Stream’s xUSD vault contract (https://etherscan.io/address/0xE2Fc85BfB48C4cF147921fBE110cf92Ef9f26F94), sourced from the roundPricePerShare function. This rate is based on Stream’s internal NAV reporting and is not backed by an independent proof of reserves.

Links

• Explorer: https://etherscan.io/

• RPC: https://eth.llamarpc.com

• ChainList: https://chainlist.org/chain/1

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer: https://katanascan.com/

• RPC: https://rpc.katana.network

• Chainlist: https://chainlist.org/chain/747474

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer: https://explorer-sepolia.inkonchain.com/

• RPC: https://rpc-gel-sepolia.inkonchain.com

• Chainlist: https://chainlist.org/chain/763373

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer: https://testnet-explorer.bsquared.network

• RPC: https://b2-testnet.alt.technology

• Chainlist: https://chainlist.org/chain/1123

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer: https://sepolia.explorer.mode.network

• RPC: https://sepolia.mode.network

• Chainlist: https://chainlist.org/chain/919

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer: https://test-explorer.plumenetwork.xyz/

• RPC: https://testnet-rpc.plume.org

• Chainlist: https://chainlist.org/chain/98867

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer: https://turin.explorer.tac.build/

• RPC: https://turin.rpc.tac.build

• Chainlist: https://chainlist.org/chain/2390

Price Feeds

Compatible with AggregatorV3Interface.

**Exchange-rate feed self-reported by YieldNest. Reflects protocol-defined accounting and does not track traded market price or include independent Proof of Reserves.

Links

• Explorer: https://xdcscan.com//

• RPC: https://rpc.xdc.org

• Chainlist: https://chainlist.org/chain/50

Pendle PT Price Feeds

Price Feeds

Compatible with AggregatorV3Interface.

* The xUSD feed reflects the exchange rate published by Stream’s xUSD vault contract (https://etherscan.io/address/0xE2Fc85BfB48C4cF147921fBE110cf92Ef9f26F94), sourced from the roundPricePerShare function. This rate is based on Stream’s internal NAV reporting and is not backed by an independent proof of reserves.

Links

• Explorer: https://plasmascan.to/

• RPC: https://rpc.plasma.to

• Chainlist: https://chainlist.org/chain/9745

Pendle PT Price Feeds

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer: https://soneium.blockscout.com/

• RPC: https://rpc.soneium.org/

• Chainlist: https://chainlist.org/chain/1868

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer:

• RPC:

• Chainlist:

Price Feeds

Compatible with AggregatorV3Interface.

* The xUSD feed reflects the exchange rate published by Stream’s xUSD vault contract (https://etherscan.io/address/0xE2Fc85BfB48C4cF147921fBE110cf92Ef9f26F94), sourced from the roundPricePerShare function. This rate is based on Stream’s internal NAV reporting and is not backed by an independent proof of reserves.

Links

• Explorer:

• RPC:

• Chainlist:

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer:

• RPC:

• Chainlist:

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Chainlist:

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.

EO 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 EO price feeds using Solidity.

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

EO follows Chainlink's , allowing a smooth transition between blockchain oracle providers.

Prerequisites

• You have a basic understanding of .

Edit/Deploy using Remix by clicking .

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 for more details on deployments and usage.

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer:

• RPC:

• Chainlist:

Price Feeds

Compatible with AggregatorV3Interface.

* The xUSD feed reflects the exchange rate published by Stream’s xUSD vault contract (https://etherscan.io/address/0xE2Fc85BfB48C4cF147921fBE110cf92Ef9f26F94), sourced from the roundPricePerShare function. This rate is based on Stream’s internal NAV reporting and is not backed by an independent proof of reserves.

Links

• Explorer:

• RPC:

• Chainlist:

Price Feeds

Compatible with AggregatorV3Interface.

* The xUSD feed reflects the exchange rate published by Stream’s xUSD vault contract (https://etherscan.io/address/0xE2Fc85BfB48C4cF147921fBE110cf92Ef9f26F94), sourced from the roundPricePerShare function. This rate is based on Stream’s internal NAV reporting and is not backed by an independent proof of reserves.

Links

• Explorer:

• RPC:

• Chainlist:

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer:

• RPC:

• Chainlist:

Price Feeds

Compatible with AggregatorV3Interface.

Links

• Explorer:

• RPC:

• Chainlist:

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.eo.app

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 EO, and the password should be left blank.

Get Symbols

• Endpoint: /api/v1/get_symbols

• Method: GET

Example

Response

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 EO api endpoint at https://api.testnet.eo.app. Once connected the consumer can initiate an authentication event.

Request Events

1. authenticate

• name: authenticate

• payload:

1. subscribe

   • name: subscribe

   • payload:

2. 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

3. quote

   • name: quote

   • payload: