LogoLogo
SDKAPI
Version-v1.4.0 (current)
Version-v1.4.0 (current)
  • Learn
    • Introduction
      • Obol Collective
      • OBOL Incentives
      • Key Staking Concepts
      • Obol vs Other DV Implementations
      • Obol Splits
      • DV Launchpad
      • Frequently Asked Questions
    • Charon
      • Introduction to Charon
      • Distributed Key Generation
      • Cluster Configuration
      • Charon Networking
      • CLI Reference
    • Futher Reading
      • Ethereum and Its Relationship With DVT
      • Community Testing
      • Peer Score
      • Useful Links
  • Run a DV
    • Quickstart
      • Quickstart Overview
      • Create a DV Alone
      • Create a DV With a Group
      • Push Metrics to Obol Monitoring
    • Prepare to Run a DV
      • How and Where To Run DVs
      • Deployment Best Practices
      • Test a Cluster
    • Running a DV
      • Activate a DV
      • Update a DV
      • Monitoring Your Node
      • Claim Rewards
      • Exit a DV
    • Partner Integrations
      • Create an EigenLayer DV
      • Create a Lido CSM DV
      • DappNode
  • Advanced & Troubleshooting
    • Advanced Guides
      • Create a DV Using the SDK
      • Migrate an Existing Validator
      • Enable MEV
      • Combine DV Private Key Shares
      • Self-Host a Relay
      • Advanced Docker Configs
      • Beacon node authentication
    • Troubleshooting
      • Errors & Resolutions
      • Handling DKG Failure
      • Client Configuration
      • Test Commands
    • Security
      • Overview
      • Centralization Risks and Mitigation
      • Obol Bug Bounty Program
      • Smart Contract Audit
      • Software Development at Obol
      • Charon Threat Model
      • Contacts
  • Community & Governance
    • Governance
      • Collective Overview
      • The Token House
      • The RAF
      • Delegate Guide
      • RAF1 Guide
    • The OBOL Token
      • Token Utility
      • Token Distribution & Liquidity
      • TGE FAQ
    • Community
      • Staking Mastery Program
      • Techne
    • Contribution & Feedback
      • Filing a Bug Report
      • Documentation Standards
      • Feedback
  • Walkthrough Guides
    • Walkthroughs
      • Walkthrough Guides
  • SDK
    • Intro
    • Enumerations
      • FORK_MAPPING
    • Classes
      • Client
    • Interfaces
      • ClusterDefinition
      • RewardsSplitPayload
    • Type-Aliases
      • BuilderRegistration
      • BuilderRegistrationMessage
      • ClusterCreator
      • ClusterLock
      • ClusterOperator
      • ClusterPayload
      • ClusterValidator
      • DepositData
      • DistributedValidator
      • ETH_ADDRESS
      • OperatorPayload
      • SplitRecipient
      • TotalSplitPayload
    • Functions
      • validateClusterLock
  • API
    • What is this API?
    • System
    • Metrics
    • Cluster Definition
    • Cluster Lock
    • State
    • DV Exit
    • Cluster Effectiveness
    • Terms And Conditions
    • Techne Credentials
    • Address
    • OWR Information
  • Specification
Powered by GitBook
On this page
  • Purpose
  • Overview: The Obol Token House and RAF
  • The Security Council
  • Administration and Implementation
  • Vision for Fully On-Chain Governance
Edit on GitHub
  1. Community & Governance
  2. Governance

Collective Overview

Obol Collective Overview

PreviousGovernanceNextThe Token House

Last updated 6 days ago

Purpose

The Obol Collective’s governance system has two primary goals:

  1. Resource allocation. Allocate resources effectively to support the Collective’s vision and grow the Obol Collective's sustainable value. Long-term vision may sometimes conflict with short-term value creation; thus, governance requires a blend of short-term and long-term thinking to allocate the token treasury and protocol revenue effectively.

  2. Capture resistance. Governance plays a key role in securing the anti-capture and censorship resistance of the Obol Collective. Governance should:

    1. make it possible for operations to continue over the long term without reliance on any individual entity;

    2. prevent any one entity or small group of entities from being able to control or censor.

Overview: The Obol Token House and RAF

Two houses govern the Obol Collective: the Token House and the Obol RAF.

In the Token House, OBOL Token holders are responsible for submitting, deliberating, and voting on governance proposals using the Governance Portal. Token holders can delegate their OBOL Token voting power to their own address or an eligible third party. Addresses with delegated voting power are called “Delegates”.

In the Obol Retroactive Fund (RAF), OBOL Token Delegates are responsible for allocating funds within the RAF to projects and teams that provide value to the Obol Collective.

All OBOL holders and Delegates are expected to exercise their authority responsibly and follow the Delegate and the general for the forum.

The Security Council

The Security Council is a committee of multi-sig wallet signers with the power to perform certain emergency actions as delegated to it by the Obol Association.

The Security Council can execute any software upgrade or perform other emergency actions without delay to respond to a security emergency, should one arise. The Security Council must not use its power to perform Emergency Actions except in a true security emergency, such as a critical vulnerability that could significantly compromise the Obol Collective.

After taking any Emergency Action, the Security Council must issue a full transparency report (at an appropriate time after the security emergency has passed) explaining what was done and why such action was justified.

Administration and Implementation

The Obol Association, via its governance administrators, will facilitate administration to ensure that anyone may participate thoughtfully in governance. Such administrative services may include:

  • Moderation of governance proposals to ensure they are validly submitted and voted upon;

  • Removal of proposals that reasonably appear to be fraudulent, spam-oriented, defamatory, hateful, or otherwise inappropriate or inconsistent with the values of the Collective;

  • Monitoring of votes, voting power, the votable token supply, and voting periods for purposes of determining whether quorums and approval thresholds are met or accurately reflected;

  • Management of mutually contradictory or duplicate proposals that are submitted simultaneously or close to one another;

  • Maintenance of the Governance & RAF Portal;

  • Other tasks that the Obol Association deems appropriate in connection with the above.

Approved governance proposals will be routed to the Obol Association for implementation. Upon receipt of an approved proposal or chosen RAF recipients, the Obol Association will determine whether the proposal is safe, consistent with the purposes of the Obol Collective, and capable of being implemented legally (including potential KYC requirements).

  • If it is, the Association will act diligently and in a commercially reasonable manner to consider the proposal for implementation.

  • If it is not, the Association may, at its discretion, remove the proposal for resubmission or implement it with guardrails, coupled with an explanation.

Vision for Fully On-Chain Governance

Once Collective’s governance develops and is deemed as sufficiently mature by the Obol Association, the implementations of passed proposals will follow full on-chain execution, where possible. Instead of the Collective’s reliance on the Obol Association for implementation, passed proposals will be moved to a queue to prepare for execution. The queue action will send the proposal to a Timelock contract, which starts a countdown until the proposal can be executed.

Executing a proposal will run its function calls on-chain. Each proposal can be associated with one or more function calls. These calls will perform actions such as transferring assets from the treasury, updating the Governor's parameters, or calling another smart contract.

In all cases, Obol Collective governance is intended to be carried out in a manner consistent with the Delegate and the general for the forum. The Obol Association will steward this process as described below, with the goal of increasingly decentralising its role over time.

Rules of Engagement
Code of Conduct
Rules of Engagement
Code of Conduct