📖
MetaPoll | Docs
  • Introducing MetaPoll
  • Getting Started
    • Take the MetaPoll tour!
    • FAQs
    • Quickstart Mission
  • MetaPoll User Guide
    • Signing In
    • Adding and Removing DAOs
    • Browsing MetaPolls
      • Filtering MetaPolls by DAO
      • Search and Other Filters
      • Main card
    • Viewing MetaPoll Results
      • Snapshots
      • Options
      • Child Options, Layers, and Navigation
    • Voting
      • Ranked and Unranked Options
      • Ranking and Unranking Methods
      • Casting Your Vote
      • Viewing Vote History
    • Eligible Tokens and Vote Calculation
    • Vote Decay
    • Graduation
  • Authoring MetaPolls
    • Basics of Creating MetaPolls
      • Creating a new MetaPoll
      • Setting up the MetaPoll
      • Creating Options
      • Publishing a MetaPoll
      • Managing your MetaPolls
    • Working with MPTS format
    • Option space design
      • Option Naming Styles: The Abstraction-Precision Trade-off
      • State Change Loop
      • Utility Formats
    • Example MetaPoll types
      • 1. Control Surfaces for Automated Systems
      • 2. Information Sources for Decision-Making
      • 3. Proposal Temperature Checks
      • 4. Proposal Election and Expectation Management
      • 5. Representative Guidance Systems
  • Hypothetical MetaPolls
  • Advanced Topics
    • Decision Spaces
    • Snapshot Data Structure
    • VCIP - Voter Compute Integrity Proof
    • VDIP - Voter Data Integrity Proof
    • Arweave Perma Storage
    • Verkle Trees
    • ZKsnarks
  • Appendix
    • Links
    • Glossary
Powered by GitBook
On this page
  1. Authoring MetaPolls
  2. Option space design

State Change Loop

An often-overlooked aspect of collective decision-making is the distinction between different types of choices. Not all decisions are created equal - they occupy different positions in what we might call the "state-change loop" of collective action.

MetaPolls can be structured to focus on three distinct parts of this loop, each requiring different types of expertise and having different optimal participation patterns:

1. Desired Outcomes (What)

The first and most fundamental part of the loop concerns what we want to achieve. These options focus purely on goals or end states, deliberately excluding implementation details.

For example:

  • "I want to get across this river" (not "I want to build a bridge")

  • "Our community should have clean drinking water"

  • "The protocol should be resistant to MEV attacks"

This level of decision-making has several important properties:

  1. Maximum inclusivity - It requires no specialized knowledge beyond understanding one's own preferences

  2. High alignment potential - People often agree more about outcomes than implementation methods

  3. Implementation flexibility - By not specifying means, it allows for creative, efficient solutions

The key insight here is separating pure goals from implementation guesses. Consider how different "I want to cross the river" is from "I want to build a suspension bridge to cross the river." The latter pre-commits to a specific solution that might be suboptimal - what if the river is narrow enough to jump across? What if the soil can't support bridge foundations? What if the voter has a jetpack? By focusing purely on the outcome, we maximize solution space.

One frequent failure mode in governance is when outcome preferences get contaminated with implementation assumptions. This prematurely narrows options and often leads to inefficient choices driven by voter preferences about things they lack expertise to evaluate.

2. Strategies and Tactics (How)

The second part of the loop concerns how we achieve our desired outcomes. These options focus on methods, approaches, and techniques.

For example:

  • Bridge vs. ferry vs. helicopter for river crossing

  • SEO vs. advertising vs. product improvements for user acquisition

  • Proof-of-stake vs. proof-of-work for consensus mechanisms

This level of decision-making has different properties:

  1. Expertise-dependent - Requires domain-specific knowledge to evaluate effectively

  2. Comparative analysis - Involves trade-offs between different approaches

  3. Context sensitivity - Often depends on specific local conditions

The "how" layer should ideally be reserved for people with relevant expertise. If we want to determine what type of bridge is best for a particular river crossing, this decision should primarily involve civil engineers familiar with bridge construction under various conditions. Having general populations vote on technical implementation details often leads to suboptimal outcomes based on superficial understanding.

This presents an interesting governance challenge: how do we ensure appropriate expertise for "how" decisions while maintaining democratic principles? MetaPolls can help by segregating these decisions into separate layers, potentially with different participation criteria.

3. Execution Parameters (Who and When)

The third part of the loop concerns who will implement our chosen strategies and when they will do so. These options focus on specific execution details:

  • Team composition (e.g., "300 AI agents and 10 human workers")

  • Timeline specifications (e.g., "40 hours/week for 6 months, March-August")

  • Resource allocations (e.g., "70% of budget to development, 30% to testing")

This level requires:

  1. Operational knowledge - Understanding of resource constraints and capabilities

  2. Project management expertise - Familiarity with realistic timelines and dependencies

  3. Local context - Awareness of specific implementation environments

These decisions are the most restricted in terms of who can meaningfully participate, as they require intimate familiarity with the actual execution environment. Having distant stakeholders vote on detailed project timelines often leads to unrealistic expectations and failed delivery.

Designing Effective Decision Hierarchies

The power of MetaPolls lies in their ability to separate these decision types hierarchically. A well-designed MetaPoll might:

  1. Allow broad participation in outcome-level decisions (Layer 1)

  2. Restrict strategy-level decisions to those with relevant expertise (Layer 2)

  3. Delegate execution-level decisions to those responsible for implementation (Layer 3)

This creates a natural filtering of decision authority based on relevant knowledge, while still maintaining overall alignment with community goals.

The hierarchical structure of MetaPolls naturally maps to this delegation pattern, allowing communities to make explicit choices about which types of decisions belong at which levels, and which participants should have influence over different layers of the decision tree.

PreviousOption Naming Styles: The Abstraction-Precision Trade-offNextUtility Formats

Last updated 10 days ago