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
  • Reporting the Derivative Prices
  • Updating the Verification Index
  • Regulating the Operator Marketplace
  1. Key Concepts
  2. Oracles

Telescope Ether

Telescope-Ether currently has 3 responsibilities:

Reporting the Derivative Prices

Oracle updates the Price Merkle Root at least once a day and possibly more frequently.

  1. All validator pub-keys of a pool are stored in Portal.

  2. Oracle fetches all the pub-keys and validator specific details like fee etc.

  3. Total Ether amount is calculated from the validator balances, and claimable portion of the Withdrawal Contract balance.

  4. Total of the Fee is deducted from the total Ether.

  5. New price is calculated with respect to totalSupply.

  6. A Merkle Tree is created containing all the prices of all the pools.

  7. A Merkle Root of the Merkle Tree is sent to Portal by Oracle.

  8. Anyone can sync prices of the derivative to the Oracle price with valid proofs collected from watchers.

  9. Updated price will be valid for the next 24 hours, or until the next Merkle Root update.

Derivative prices can be synced by anyone with the correct Merkle Proofs.

A valid price is required whenever a deposit or a withdrawal operation is requested.

Updating the Verification Index

Operators can create new validators on behalf of a staking pool, up to the allowance amount set by the maintainer of the pool.

Validator creation is a 3 step process:

  1. Validator Proposal

  2. Proposal Verification

  3. Pooled Staking

Every validator has a unique index (0:n]

Oracle verifies the proposed validator pub-keys by simply stating the latest verified index.

While doing so, the faulty proposals that have a lower index than the new verificationIndex are excluded.

These faulty proposals are called aliens and this pubkeys can not be ever used again.

Regulating the Operator Marketplace

Alienation

Alienation process results in Node Operator being imprisoned for the next 14 days, meaning it can not access to the Portal at all.

All possible reasons of alienation:

  • Faulty sig1

  • Faulty sig31

  • Stealing the block rewards from staking pools. Obviously this causes imprisonment.

  • Validator is not exited by Operator although the expectedExit has past. Anyone can blame a validator and effectively imprison the Operator until the exit happens.

PreviousOraclesNextTelescope Avax

Last updated 2 years ago

🔭
Withdrawal credential frontrunning