Skip to main content

Orbit Governance

This page provides detailed governance mechanics for Orbits, including governance models, decision processes, and Orbit owner rights. For a high-level overview, see Understanding Orbits.

Governance Models​

Orbit creators select their governance model during registration. Note: During Phase 1 (Development), all Orbits operate under a modified Closed Governance model managed by the Orbinum Team or whitelisted partners.

Governance Phases​

Phase 1: Team-Managed (Current)​

All Orbits are currently launched and managed by the Orbinum Team to ensure stability and quality.

  • Creation: Restricted to the Team.
  • Parameters: Tuned by the Team for optimal performance.
  • Community Role: Feedback provided via Discord/Forum; no on-chain voting.

Phase 2: Open Ecosystem (Future)​

Once the network matures, Orbit creation and governance will open to the community.

Governance Models (Phase 2)​

In Phase 2, creators will select between:

Open Governance​

Open governance Orbits operate with community-driven decision-making and transparent processes.

Characteristics:

  • Parameter changes require community discussion and DAO voting
  • Transparent decision-making with stakeholder input
  • DAO can override or deactivate the Orbit if needed
  • Ideal for protocol-level Orbits and community-driven initiatives
  • Slower decision cycles but higher community trust

Decision Process:

  1. Proposal: Orbit owner or high-stake validator submits parameter change proposal
  2. Discussion: Community discussion period (typically 7-14 days)
  3. Voting: DAO votes on proposed changes using staked governance tokens
  4. Implementation: Changes executed on-chain after approval
  5. Notice period: Announcement before changes take effect

When to Choose:

  • Building a protocol-level or foundational Orbit
  • Want community trust and buy-in from day one
  • Value transparency and collective decision-making
  • Willing to move slower for broader consensus
  • Expect long-term operation with stable parameters

Closed Governance​

Closed governance Orbits give creators full control over parameters for rapid iteration.

Characteristics:

  • Orbit creators retain full control over parameter changes
  • Faster decision-making and iteration cycles
  • Creators adjust quality thresholds, emission weights, and evaluation metrics independently
  • DAO retains veto power only for critical network security issues
  • Ideal for specialized or experimental Orbits requiring rapid adaptation

Decision Process:

  1. Proposal: Orbit owner proposes parameter changes
  2. Announcement: Public announcement with rationale (minimum 48 hours notice)
  3. Implementation: Changes executed directly by owner
  4. DAO oversight: DAO monitors and can veto only if security risks identified

When to Choose:

  • Building an experimental or specialized Orbit
  • Need rapid iteration and parameter tuning
  • Have domain expertise requiring quick adaptation
  • Want to maintain competitive advantages through agility
  • Expect frequent parameter adjustments during development

Governance Scope​

Regardless of governance model, Orbit governance covers:

1. Parameter Tuning​

Quality thresholds:

  • Minimum quality scores for miner participation
  • Performance benchmarks and SLAs
  • Quality evaluation frequency

Emission weights:

  • Orbit's share of total network emissions
  • Distribution formulas for miners within Orbit
  • Reward multipliers for exceptional performance

Operational parameters:

  • Maximum number of miners allowed
  • Evaluation cadence (how often miners are scored)
  • Miner registration requirements

2. Code Upgrades​

Validation logic updates:

  • Improvements to quality evaluation algorithms
  • New testing methodologies
  • Security patches and bug fixes

Miner requirements:

  • Hardware specifications
  • Software dependencies
  • API compatibility requirements

Implementation mechanism:

  • Code released as new versions in Orbit repository
  • Validators "vote with their feet" by choosing to update
  • Consensus threshold: >67% of validator stake for new version adoption
  • Fork risk if community significantly splits

3. Miner Management​

Registration policies:

  • Stake requirements beyond protocol minimum
  • Application/approval processes (if permissioned)
  • Geographic or hardware restrictions

Performance standards:

  • Service level agreements (uptime, latency)
  • Quality benchmarks miners must maintain
  • Penalty structures for poor performance

Access control:

  • Whitelisting/blacklisting capabilities (if applicable)
  • Temporary suspensions for quality failures
  • Appeal processes for disputed actions

4. Quality Standards​

Evaluation metrics:

  • Domain-specific quality measures (accuracy, BLEU scores, etc.)
  • Weight distribution across multiple metrics
  • Metric update frequency

Scoring algorithms:

  • How individual metrics combine into composite scores
  • Time-weighted vs. instant scoring
  • Outlier handling and dispute resolution

Implementation Mechanisms​

On-Chain Parameter Changes​

Smart contract execution:

  • Parameter changes proposed and executed via blockchain transactions
  • Immutable record of all governance actions
  • Automatic enforcement of approved changes

Open Governance flow:

  1. Submit proposal transaction with new parameter values
  2. DAO voting period (on-chain voting)
  3. If approved, automatic execution after timelock
  4. Changes reflected immediately in protocol

Closed Governance flow:

  1. Owner submits parameter change transaction
  2. Announcement period (48-hour minimum)
  3. Direct execution by owner wallet
  4. DAO monitors for veto-worthy security issues

Off-Chain Code Upgrades​

Repository management:

  • Orbit owner maintains official GitHub repository
  • New versions tagged and released with changelog
  • Validators monitor releases and decide to upgrade

Validator adoption:

  • Each validator independently chooses to update software
  • Gradual rollout as validators upgrade
  • Network reaches consensus when >67% of stake updated

Fork scenarios:

  • If community significantly splits, Orbit may fork
  • Minority chain typically dies off from lack of usage
  • DAO can intervene in extreme cases

Orbit Owner Rights & Responsibilities​

Rights​

Revenue:

  • Receive 2% commission on all inference fees generated
  • Commission guaranteed regardless of governance model

Control (varies by governance model):

  • Choose governance model at registration
  • Propose parameter changes (approval process depends on model)
  • Manage official Orbit repository
  • Configure quality thresholds and evaluation metrics

Representation:

  • Speak for Orbit in network-wide governance
  • Represent Orbit interests in protocol upgrades
  • Advocate for Orbit-specific needs

Responsibilities​

Quality maintenance:

  • Ensure Orbit maintains minimum quality standards
  • Monitor miner performance and validator accuracy
  • Address quality issues promptly

Stake management:

  • Keep 1,000 $ON stake locked as collateral
  • Accept slashing risk for malicious behavior
  • Maintain stake for duration of Orbit operation

Communication:

  • Announce changes with adequate notice (varies by model)
  • Respond to security concerns from community
  • Maintain documentation for miners and validators

Good faith operation:

  • Act in best interest of Orbit participants
  • Avoid manipulative or extractive behavior
  • Maintain Orbit reputation and legitimacy

Checks and Balances​

Market exit:

  • Miners and validators can exit if owner acts against their interests
  • Poor governance leads to participant exodus
  • Natural economic pressure for fair management

DAO oversight:

  • DAO can veto closed governance changes that pose security risks
  • DAO can deactivate Orbit for protocol violations
  • Network-wide governance supersedes Orbit-level decisions

Slashing:

  • Stake slashed for malicious behavior
  • Economic penalty for protocol violations
  • Permanent reputation damage

Dispute Resolution​

Disputes within Orbits follow escalation hierarchy:

Orbit-Level Resolution​

Process:

  1. Issue raised in Orbit's community channels (Discord, Forum, etc.)
  2. Orbit owner and validators review evidence
  3. Community discussion and debate
  4. Resolution via governance process (open or closed model)

Common disputes:

  • Miner claims unfair quality scoring
  • Disagreement over parameter changes
  • Validator accuracy questions
  • Fee distribution disputes

Resolution mechanisms:

  • Re-evaluation of disputed scores
  • Parameter adjustments if community agrees
  • Validator stake slashing for provable errors
  • Miner deregistration for repeated violations

Network-Level Escalation​

When to escalate:

  • Orbit-level resolution fails
  • Protocol violations involved
  • Security risks to network
  • Systemic governance breakdown

Process:

  1. Submit escalation request to Orbinum DAO
  2. Present evidence and arguments
  3. Network-wide governance review
  4. DAO decision (binding on Orbit)

Potential outcomes:

  • DAO overrides Orbit decision
  • Parameter changes mandated network-wide
  • Orbit owner stake slashed
  • Orbit deactivated if severe violations

Best Practices for Orbit Owners​

Transparency​

Regardless of governance model:

  • Announce all changes well in advance
  • Provide clear rationale for decisions
  • Maintain public changelog
  • Document all parameters and evaluation logic

Open governance:

  • Foster active community discussion
  • Consider minority viewpoints
  • Build consensus before proposals

Closed governance:

  • Over-communicate to build trust
  • Explain rapid changes clearly
  • Proactively address concerns

Inclusivity​

Miner feedback:

  • Listen to feedback on hardware requirements
  • Consider scoring fairness complaints
  • Make miner success achievable

Validator engagement:

  • Ensure validation logic is clear and fair
  • Provide tools and documentation
  • Recognize validator contributions

Community building:

  • Foster collaborative culture
  • Encourage participation in discussions
  • Value diverse perspectives

Stability​

Avoid disruption:

  • Minimize frequent, drastic parameter changes
  • Give advance notice for major updates
  • Test changes thoroughly before implementation

Gradual evolution:

  • Iterate incrementally rather than revolutionary changes
  • Allow participants to adapt to changes
  • Monitor impact before next change

Predictability:

  • Establish clear governance rhythms
  • Communicate roadmap and intentions
  • Honor commitments to community

Next Steps​