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
  • Building on top of the Isolated Storage
  • Proposals
  • Governance
  • Senate
  • Limited Upgradability
  • Onboarding Operators
  • New Withdrawal Contract, gETH interface or Liquidity Pools
  1. Key Concepts
  2. Portal

Dual Governance

PreviousIsolated StorageNextLimited Upgradability

Last updated 2 years ago

Building on top of the Isolated Storage

We learned that DataStore keeps different entities in isolated storage slots with different IDs.

However, this functionality is nothing to be excited about without a mechanism to enforce this logic on protocol and contract upgrades.

Geode manages crucial parts of it's operation with 2 step verification:

  1. Governance Proposals

  2. Senate Approvals

This setup creates another safeguard for the users of The Staking Library.

Proposals

A proposal is Geode Governance offering a change within the protocol to the Senate.

Every proposals isolates an ID for DataStore.

After the Controller is chosen, no one else can touch to the given storage ID.

GeodeUtilsLib.sol
  struct Proposal {
    address CONTROLLER;
    uint256 TYPE;
    bytes NAME;
    uint256 deadline;
  }

A Proposal has 4 parameters:

  • TYPE: separates the proposals and related functionality between different ID types.

  • NAME:important for ID generation through DataStore.generateId()

  • CONTROLLER: the address that refers to the change that is proposed by given proposal ID.

    • This slot can refer to the controller of an id, a new implementation contract, a new Senate etc.

  • deadline: refers to last timestamp until a proposal expires.

There can be more TYPE reservations in the future.

ID_TYPE
CONTROLLER

0

NONE -unused

1

new senate address

2

new implementation contract for Portal

3

GAP - unused

4

Controller of a Operator

5

Controller of a Pool

21

Module: Withdrawal Contracts

31

Module: gETH interfaces

41

Module: Liquidity Pool

42

Module: Liquidity Pool Token

Governance

Currently, Governance is an internal ERC-20 token that is only owned by Geode Finance Developers and Treasury.

This internal ownership is a needed step to eliminate the risk of some attacks like Governance tak-over.

In the future, the Governance of Geode is supposed to be decentralized with the distribution of these tokens.

Senate

Currently, Senate is a Multisig of Geode developers.

But GeodeUtils Library includes a logic for changing the Senate, as well as an Election for it.

TYPE 1 proposals stand for Senate Elections.

However, the future of Senate will not be decided by elections, but with an other approach:

A Decentralized Senate with a weighted vote distribution:

Limited Upgradability

TYPE 2 proposals ensure Limited Upgradability on both Portal and Withdrawal Contracts.

Onboarding Operators

TYPE 4 proposals stands for onboarding a new Node Operator to the Marketplace:

page link

New Withdrawal Contract, gETH interface or Liquidity Pools

Other TYPEs like 21, 31 etc. stands for other important parameters of Portal like default Liquidity Pool or withdrawal Contract implementation.

All TYPEs are reserved as ID_TYPE within .

🌀
🤝
globals.sol
Quadratic Weighted Senate (DRAFT)
⚠️Limited Upgradability