Decision markets work best when anyone can participate without gatekeeping, but proposal noise and poorly timed submissions can undermine signal quality. This article proposes a framework that separates proposal creation from decision market activation, giving token holders permissionless access while giving DAOs the tools to manage proposal flow. This is a call for feedback from token holders, project teams, and MetaDAO developers.

The Problem with the Current Proposal Flow

MetaDAO enables DAOs to use decision markets. These are prediction markets where token holders trade on the expected outcome of proposed decisions. The ingenuity of decision markets is that they help surface collective intelligence about which outcome creates the most token value.

Currently, MetaDAO has safety mechanisms including stake thresholds (proposals need minimum backing to go live) and TWAP thresholds (time weighted average price requirements for proposals to pass). However, the current proposal flow creates friction for both project teams and token holders.

We assume MetaDAO has not yet launched fully permissionless proposal creation for two reasons. First, without guardrails, permissionless proposal creation risks flooding decision markets with low quality proposals. Second, MetaDAO is a small team stretched across core protocol development, permissionless ICOs, and other priorities, and has not yet been able to dedicate the focus required to design a robust permissionless system. This is the gap 01Resolved (an ownership coin and decision market research provider) aims to fill.

The Permissionless Problem

There is growing concern in the MetaDAO community that decision markets are falling short of their promise.

  • Teams: They want to avoid a constant stream of distracting proposals that could harm the project, particularly short-term speculative proposals that don't align with long-term value creation.
  • Token holders: They want a permissionless way to propose ideas that become active decision markets without gatekeeping.

MetaDAO's existing safety mechanisms help ensure that proposals meet a baseline of legitimacy, but they don't solve for (a) proposal noise: filtering low quality or poorly timed proposals before they get market attention, and (b) proposal access: ensuring good faith token holders can participate without gatekeeping.

Proposed Solution

We propose splitting "proposal creation" from "decision market activation" with protections for both teams and token holders. This separation allows permissionless proposal creation and submission while maintaining quality control through transparent, DAO specific rules.

In summary, anyone can create and submit proposals at any time, but those proposals only become active decision markets when they meet predefined criteria. This preserves permissionless participation while giving each DAO the tools to better manage proposal flow.

How It Works

  1. Each DAO defines its guardrails: Think of this as each DAO's published "proposal constitution." This is a transparent set of rules specifying what proposals can go live, when they can go live, and with what parameters.
  2. Anyone can submit proposals: Token holders create proposals permissionlessly. Everyone can see upfront whether a proposal meets the guardrails and how much stake it has attracted.
  3. Markets activate when conditions are met: A proposal becomes a live decision market when it (a) meets the staking threshold and (b) satisfies all guardrails.

Activation could initially be done by project founders with a path toward automation as soon as possible.

Guardrail Options

Each DAO would choose and publish guardrails suited for their context and guardrails could have a defined term to force periodic review. 01Resolved would be open to defining a complete list of guardrail options and consulting with projects on their selection. The following is a non-exhaustive list of guardrail examples (also mentioned in our article When a Proposal Tests Futarchy).

Note: Some guardrails may require MetaDAO protocol upgrades or may not be implementable within current program constraints.

Proposal Classes and Timing Windows

Some proposal types are harder to evaluate early and more vulnerable to short-term speculation.

  • "Sensitive" class (buybacks, liquidity changes, token sales, large treasury disbursements, etc.): eligible only after [x] days after ICO
  • "Standard" class (routine decisions): eligible immediately without any changes to guardrails

Token holder protection: timing windows must have clear start and end dates. Once the window opens, proposals cannot be blocked. "Sensitive" class must be based on objective criteria (transaction size, proposal types, etc.) not team judgment.

Runway Protection

Set minimum operating buffers so execution doesn't get derailed by chaotic governance. For example, treasury actions cannot reduce stablecoin runway below [x] months unless the proposal is explicitly a planned wind down.

Token holder protection: runway is calculated using transparent, onchain data that token holders can verify. The minimum threshold should be set below normal operating levels (for example, 6-9 months minimum for DAOs that maintain 12-18 months of runway) to function as a safety net rather than a spending freeze.

Mechanism Tuning by Proposal Class

Adjust market mechanics based on proposal sensitivity:

  • TWAP thresholds: higher for Sensitive proposals, lower for Standard proposals
  • Trading windows: longer for Sensitive proposals to allow more deliberation
  • TWAP calculation windows: later start time for Sensitive proposals to reduce early manipulation

Token holder protection: higher thresholds for sensitive proposals are reasonable, but they must still be achievable. Maximum TWAP thresholds should be capped to prevent de-facto veto of any type of proposal.

Stake Requirements for Proposals

Make it harder to push Sensitive proposals into live markets, but not prohibitively so. For example, require a larger stake amount for Sensitive proposals.

Token holder protection: stake thresholds could be calibrated to token distribution. For example, Standard proposals might require 5-10% of liquid supply while Sensitive proposals could require 15-20%. There could be an upper bound to prevent unreachable requirements.

Benefits and Risks

Benefits

  • For teams: Predictable proposal flow reduces distractions. Guardrails limit certain proposals without requiring manual intervention.
  • For token holders: Transparent rules eliminate ambiguity about what can be proposed and when. Anyone can participate without seeking permission, as long as they meet guardrail criteria.
  • For markets: Better signal because proposals are structured. Market participants can focus on evaluating better proposals.

Potential Risks and Tradeoffs

  • Complexity: Multiple proposal classes and guardrails add complexity to the system. Clear documentation is needed (and some tooling) to help proposers understand which rules apply.
  • Gaming the guardrails: Some token holders might structure proposals to barely meet requirements while still pursuing harmful objectives.
  • Team approvals: Without automation, there is a risk some proposals may be vetoed, or censored/soft-censored by teams.
  • Reduced spontaneity: Some valuable proposals might be time sensitive. Guardrails could delay urgent responses to market conditions.

Next Steps

Now: Technical Feasibility Assessment

Before developing detailed guardrail templates, we need to audit MetaDAO's current program instructions to determine:

  • Which guardrails can be implemented with existing functionality
  • Which would require protocol upgrades
  • Which are technically infeasible and need alternative approaches

This assessment should involve MetaDAO to determine what is possible today vs what requires development work.

Phase 1: Implement Currently Feasible Guardrails (Near-term)

If there is community support, we can help develop:

  • Guardrails template using currently available parameters
  • Proposal creation wizard that shows token holders which guardrails apply and whether their proposal qualifies

Phase 2: Protocol Upgrades for Advanced Guardrails (Medium-term)

Work with MetaDAO to help design upgrades that support the following:

  • Proposal classes and configurable mechanics: beyond the current binary system (for example, Sensitive class, Standard class, dynamic thresholds, etc.)
  • Onchain runway protection: with treasury balance checks
  • Timing window enforcement: for post-ICO delays and proposal cool-downs
  • Other guardrails TBD

Alternative Option

There is also an alternative option where we could fork the MetaDAO decision market program to develop a new version that incorporates permissionless mechanics, proposal guardrails, and advanced decision market features. This fork could serve as a reference implementation that MetaDAO and the broader Solana ownership coin ecosystem can adopt, test, and iterate on.

Conclusion

This document is a call for feedback. We are sharing this high level framework to invite input from token holders, project teams, and MetaDAO developers on the guardrails, proposal classes, and activation mechanics. Based on that feedback, we are prepared to submit a formal proposal to the MetaDAO community through a live decision market.