Geode Document Hub
  • Geode Document Hub
  • The Staking Library
    • 🔥The Issue
    • 🧯A Solution
  • Operator Marketplace
    • 🟢A Validator's Lifecycle
    • 🔵Maintenance Fee
    • 🟡Onboarding New Operators
    • 🔴Regulating the Marketplace
      • 🚨Prison
  • Key Concepts
    • 🪙Staking Derivatives
      • G-Derivatives
        • gETH vs gAVAX
    • 🌀Portal
      • 🔐Isolated Storage
      • 🤝Dual Governance
      • ⚠️Limited Upgradability
    • ⚙️Permissionless Configurable Staking Pools
      • 🎭Current Interfaces
      • ⛏️Maintainers
    • 🛡️Withdrawal Contracts
      • ⛑️Recovery Mode
      • 🕗Withdrawal Queue
    • 🌊Bound Liquidity Pools
    • 🔭Oracles
      • Telescope Ether
      • Telescope Avax
    • 👾Future of Geode
      • Better Maintainers (WIP)
      • Synthetic Liquidity (WIP)
      • Dynamic Withdrawals (WIP)
      • Further Decentralization
        • Supporting EIP-4788 (DRAFT)
        • Quadratic Weighted Senate (DRAFT)
        • Degen Operators (DRAFT)
        • Decentralized Telescope (DRAFT)
      • Chain Sync (AVAX) (draft)
  • Ethereum Guides
    • 📗Staking Pool HandBook
      • Initiating a Customizable Staking Pool
      • Managing Your Operator Set
      • Changing Your Pool's Owner
      • Manage Your Maintenance Fee
      • Private Pools and Whitelisting
      • Using a Bound Liquidity Pool
      • Using Maintainers for Your Pool
      • Securing Your Withdrawal Contract
      • Decentralizing Your Pool
    • 📕Operator Handbook
      • Get Onboarded
      • Initiating an Operator
      • Communicating with Portal
      • Creating Validators
      • Changing an Operator's Owner
      • Switching Your Fee
      • Switching Your Validator Period
      • Using Maintainers
      • Optimizing Your Revenue
      • Exiting Validators
    • 📘Liquidity Pool HandBook
  • Avalanche Guides
    • Staking Pool Handbook
    • Operator Handbook
  • Developers
    • Networks
    • Live Contracts
      • Avalanche v1
      • Ethereum v2
        • gETH.sol
        • Portal.sol
          • globals.sol
          • DataStoreUtilsLib.sol
          • GeodeUtilsLib.sol
          • DepositContractUtilsLib.sol
          • OracleUtilsLib.sol
          • StakeUtilsLib.sol
        • Swap.sol
          • AmplificationUtils.sol
          • MathUtils.sol
          • SwapUtils.sol
          • LPToken.sol
        • WithdrawalContract.sol
        • Interfaces
          • ERC20InterfaceUpgaradable.sol
          • ERC20InterfacePermitUpgradable.sol
    • Audits
    • Bug Bounties
Powered by GitBook
On this page
  • Telescope Powers the Staking Universe
  • Telescope's Structure
  • Implementation Design Principles
  1. Key Concepts

Oracles

PreviousBound Liquidity PoolsNextTelescope Ether

Last updated 2 years ago

Telescope Powers the Staking Universe

This implementation of oracle utilizes the Gnosis Safe Contracts. To understand how multi-signature works, and to get better insight about quorum please read the .

For more technical context, please review the Telescope-Ether on Github here:

Telescope is a chain-specific, pocket-size Distributed Oracle that contains multiple Nodes with multiple roles within Geode's Staking Library.

Like any other Oracle Network, Telescope has multiple Nodes that are collecting and interpreting off-chain information, verifying each other's results and finally submitting the verified data to on-chain contracts, in this case Geode Portal.

Telescope's Structure

Telescope on Ethereum and Avalanche shares the same logic on slightly different tasks:

In the next diagram, red arrows show the journey of a successful price update with a 3/4 multisig setup, with 4 Node Operators:

  1. Nodes: individual scripts watching the Consensus Layer, trying to achieve a consensus on their tasks.

  2. Watchers: Collecting verified signatures from Nodes and submitting them to a multisig contract.

  3. Multisig: After making sure that more than enough Node Operators have signed a Transaction, it updates the Portal parameters.

  4. Portal: Makes sure that the update is within the sane limitations.

Implementation Design Principles

Telescope Is Chain-Specific

While the underlying objectives are preserved, Geodes Developer Team needs to design unique a Infrastructure with different solutions for different Proof-of-Stake blockchains. Because all of them have a different understanding of what "stake" means.

Telescope is Pocket-Sized

It is easy to understand, deploy, run and update. There is nothing complicated on chain either.

Telescope Tracks All Operators and All Pools

Every Pool can have multiple Operators chosen, Telescope does not need to know the full context of the relationships, it tracks all of them.

Telescope is Pessimistic

Telescope does not trust its operators at all, it expects the unexpected.

Geode Portal does not allow any percentage of price changes on daily updates. There is no slashing mechanism on Avalanche, so it doesn't allow the price to decrease. Because of this, it only reports the balanceIncrease. Also, price increase has 0.2% daily upper-limit.

If Quorum is not reached on any given day, the price increase upper-limit increases accordingly for the next daily update, etc..

Telescope Nodes Are Black-Boxes

To make them more secure, Telescope Nodes shouldn't be public servers, URLs, or API end-points, and they don't speak with each other directly.

Telescope Is Not Permissionless

Because the on-chain end point of the Oracle is basically a Gnosis Safe. A battle-tested Quorum mechanism.

More security, less decentralization for price updates.

Telescope Nodes Are Free-To-Run

Because of the gas fees, it is expected to cost some money or tokens to operate on-chain Oracle Nodes. However, Telescope Nodes do not need to pay for anything thanks to Watchers who collect the data, and submit it automatically whenever there is an off-chain quorum.

Telescope Is Persistent to a Single-Point of Failure

Thanks to multiple Nodes and multiple Watchers powered by multiple parties, Telescope does not fail until most of the components fail.

Telescope is Communicative

The operators of Telescope Nodes do not need to check or monitor their Node all the time. Telescope will notify it's operator regularly with e-mails. In case anything goes wrong, it sends messages via Whatsapp and/or Telegram.

Telescope is Stateless

If a Node Operator choses to monitor their node, Telescope stores it's data within an online database. But, Telescope never uses or needs this database to operate normally, any Node can be stopped and rebooted at any given time, only using the information stored in on-chain events and functions.

Telescope is Deterministic

Thanks to the implementation of p-Bank, all of the Telescope Nodes will come to the same conclusion easily, without needing a lot of on-chain activity for verification.

🔭
Gnosis Safe Documentation
https://github.com/Geodefi/Telescope-Ether