LogoLogo
  • Imua
    • About
  • Manifesto
    • The Problems
    • The Principles
  • Architecture
    • Imua Design Principles
    • Imua Network
    • Imua Modules
    • Client Chain Bridges
      • Trustless Verification of Client Chain State
      • Handling Race Conditions between Imua and Client Chains
    • Client Chain Contracts
  • Concepts
    • Ecosystem
      • Re/stakers
      • Operators
      • Services (AVS)
        • Service Integration with Imua
        • Service Committee
        • Service Integration Details
    • restaked Proof-of-Stake (rPOS)
    • Multi-Token Restaking
    • Multi-Chain Restaking with Trustless Bridging
    • Voting Power
    • Price Oracle
    • Flexible Integration with AVS
    • Tribe Staking
  • Governance
  • Risk Management
    • Risk Analysis
      • Risk Modeling
      • Risk Parameters
      • Crypto-Economic Risk
      • Unintended Slashing
      • Black Swan Events
    • Risk Mitigation
      • Smart Contract Simplicity
      • Audits
      • Slashing Prevention
      • Slashing Vetos
      • Insurance Pools
      • Circuit Breakers
  • Components
    • Testnet
    • Oracle Module
      • Reaching Consensus on Asset Prices
      • Penalty
      • Implementation Detail
    • Smart Contracts
    • Explorer
    • Registry
  • Validator Setup
    • Prerequisites
    • Node Install
    • Compiling Binary from Source
    • Oracle Price Feeder
    • Running the Node
    • Snapshot
    • Register Option 1 (Bootstrap)
    • Register Option 2 (Post Network Launch)
    • Deposit Tokens
    • Delegating Tokens
    • Confirm Election Status
    • Faucets
    • Managing The Validator
    • Security Best Practices
    • Risks & Mitigation
    • Participation in Governance
    • FAQs & Resources
  • Testnet Upgrade to v1.1.1
  • AVS Setup
    • AVS Overview
    • Prerequisites
    • Building the AVS in Imua
    • Hello-World-AVS Example
    • Becoming AVS Operator
    • AVS Register and Deploy
    • AVS Task Example
    • Enhanced and Automated Edition of hello-avs integration guide&example
  • Whitepaper (2023)
    • .pdf
  • FAQ
    • What problems is Imua solving?
    • What are the main design trade-offs that had to be made with an omnichain design?
    • Does the omnichain design imply added trust assumptions (relative to a single-chain design)?
    • What concurrency-related challenges would you face with a different design?
    • How does Imua integrate with new chains?
    • Do specific chains prove unique challenges w.r.t. integration?
    • How is the cross-chain communication is achieved?
    • What are the known attack / censorship vectors here, if any?
    • Are the restaked tokens being pooled in a centralized account?
    • Who will run the validators in the Imua network?
    • Is Imua an AVS?
    • How does Imua address the risks of overloading L1 social consensus?
    • Does the Imua queuing system raise concerns around latency?
    • What are the main benefits of an omnichain design?
Powered by GitBook
On this page
  • Round
  • Quoting Window
  • Consensus Price
  1. Components
  2. Oracle Module

Reaching Consensus on Asset Prices

PreviousOracle ModuleNextPenalty

Last updated 2 months ago

The process for reaching consensus on asset prices is as follows: First, the validators retrieve prices from off-chain data sources (such as Chainlink in Oracle Module V1) and submit this price data to the Imua blockchain. The Oracle module then aggregates the price data from multiple validators, weighting each submission according to the validator's voting power to determine the final consensus price for each asset.

The process of obtaining and submitting price quotations involves several steps:

  1. Price Fetching: Validators retrieve price data for specific asset pairs from sources such as Chainlink or exchanges.

  2. Transaction Creation: After collecting the price data, the validator packages this information into a price-feed transaction, which is then submitted to the Imua blockchain.

  3. Transaction Validation: The transaction undergoes validation through an anteHandler to ensure that:

    • The validator is active.

    • The asset pair corresponds to an open price quotation window.

    • The nonce value is valid, preventing duplicate submissions.

  4. Price Consensus: Once the transaction is accepted, the Oracle module processes the quotes from validators. If sufficient consensus is achieved, the Oracle module promptly updates the price for the asset pair.

    • Sufficient Consensus: This occurs when the accumulated voting power for a specific price exceeds the predefined threshold of 2/3, indicating that a majority of validators agree on the price update. In Oracle Module V1, since Chainlink is the source and each price from Chainlink possesses a deterministic ID, there is no need to wait for additional voting power to be accumulated before the price is updated.

  5. Fallback Mechanism: If consensus is not reached within a round's quotation window, the price from the previous round is carried forward. In this case, the price update occurs at the end of the last block in the quotation window.

Round

Each round represents a specific price update cycle. Each round is assigned a unique round ID, which increments by 1 with every new round, ensuring that round IDs are continuous and sequential. This enables proper tracking of price updates and their associated data.

Each round contains a fixed number of blocks which is called the round interval. The interval of the round (i.e., the number of blocks) is predetermined, ensuring that price updates occur at regular, consistent intervals.

For example:

  • Round 1 could have round_id = 1 and span 30 blocks.

  • Round 2 would have round_id = 2 and cover the next 30 blocks, and so on.

This system ensures that price updates are synchronized with a predictable block schedule, and that every round has a clear, incremental identifier and duration.

The default value of interval in testnet is 30 blocks.

Quoting Window

A specific period during which prices can be submitted in each Round. For example, if round_1 starts at block 100 and has a quoting window of 3 blocks, the quoting window would include blocks {100, 101, 102}. During this window, validators can submit price quotes, and the system will reach consensus on the price for that round.

MaxNonce: This value equals to the size of quoting window which limits the number of price-feed transactions a validator can submit within a single quoting window. The default value of maxNonce is 3 in testnet.

Consensus Price

For any given asset pair, multiple price quotes will be received from validators in each round. In principle, every active validator is required to submit a quote (by sending a price-feed transaction) in each round. In V1 of the Oracle module, the price source is restricted to Chainlink, as its price updates come with a definitive Chainlink round ID (not Imua's round ID). Under this premise, the condition for 'reaching consensus' in V1 of the Oracle module is 'strict equality.' Specifically, when validators representing more than 2/3 of the total voting power submit exactly identical prices, that price becomes the consensus price for the current round on Imuachain.

  • Strict equality: For two price quotes to be considered "exactly identical," both the price and the corresponding Chainlink roundID must be equal. This means that when both the price and the Chainlink roundID in two quotes match exactly, they are considered to be strictly equal.