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 - eOracle implements Chainlink's AggregatorV3Interface, enabling seamless transitions between oracle providers. See Integration Guide for details on consuming data from eOracle.

3. Verification scheme - eOracle 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 eOracle Cryptographic Broadcaster

1. OVS registration on eOracle chain - Include registration as an OVS and define data feeds and sources. The relevant contracts to be deployed are described in eOracle 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

eOracle 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 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 eOracle operators

The OVS design and deployment process consists of four parts:

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

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

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

4. Target chains publishing - Configure eOracle broadcaster eOracle Cryptographic Broadcasterto establish update parameters, triggering conditions, and verification schemes Target Chains Publishing

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 eOracle 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 eOracle chain - The eOracle 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 eOracle Wrapper facilitates interaction with the eOracle chain:

• Retrieving OVS configuration, including update notifications

• Sending reports to the eOracle 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.

1. Aggregation logic- Teams must define the proper method for aggregating validator reports into a single 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 eOracle 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