Metadao Futarchy: Recent Developments and Reflections

The first Metadao resolution has been finalized, utilizing an on-chain futarchy implemented through an immutable, verified, open-source program created by proph3t. This significant milestone is marked by the approval of "proposal 0", which, upon finalization, triggered the allocation of 1000 META to autocrat.sol as a signal or green light for a proposed LST product. The details of this transaction can be viewed here.

The Experiment

MetaDaoProject is an experiment of governance by Futarchy, where the objective function is simply maximizing token value.

Non-market governance has been difficult and cumbersome. Its hard to manage and colate the masses, adhere experts, and avoid corruption by elites. Note: this masses, experts, elites breakdown dubbed by Robin Hanson.

Experiment's goal is to avoid this:

Proposal 0: Observations and Insights

The proposal was the first instance where price discovery occured for the META token.

• Market Prices: The prices of both markets were quite wild and thin. Originally the pass market traded as high as 10x the fail market. There were also some wicks. Near the proposal finality, both markets were trading closer to one another.

• Active Development of UI: Despite the active development of the user interface, approximately 40 unique signers participated in the process, a notable engagement given the limitations and bugs in the interface.

• Culture: the proposal drafting channel has roughly 20 well decently formulated ideas for the community to discuss. Additional discussions included creating an off-dao marketplace for META, history of governance both on and off chain, conditional market observations, questions and confusion over the implementation interface, debugging ui issues, and jokes and artwork related to "cranking hog" have been spotted.

Conditional Token-Based Futarchy?

that sounds like forking with extra steps…

After this proposal is finalized, where pass succeeded, the conditional vaults allow the following:

• pMETA can be converted to META from vault
• pUSDC can be converted to USDC from vault
• fUSDC/fMETA can be burned

But, let's say there were people who really didn't like Proposal 0 and wanted go on as if the Fail market was selected. They could spin up another MetaDAO program that uses that fail token as its original token, META. The only thing lost is the original MetaDao's treasury, but presumably for the proposal to pass, all the fail token believers could have been able to sell their pass tokens to bootstrap this treasury.

Essentially, this is a fork with extra steps (the formalized monetary opportunity to exit).

Designing Metadao V1: Improving the Process

Current metadao v0 is immutable

Hyperparameter Considerations

• TWAP Constraints: The TWAP can only change by 1% from its previous value and starts at 0, making it quite crank-dependent.

  • should consider make consideration of notional as well

• 10-day Minimum to Finalize Proposal: A 10-day minimum is required to finalize a proposal, with a 5% threshold TWAP required for the pass market to succeed.

• Cost Formula to Initialize a Proposal: Considerations for the cost formula to initialize a proposal.

Broader Incentive/Design Details

• Lack of Incentive for Accurate Pricing: There's no incentive to accurately price a market expected to fail. Once it leaves the realm of possible of getting selected, all work in price discovery is moot.

  • @Durden ∞ suggested, ability to recombine e.g. fMETA and pMETA back into META would facillitate arbitrages between fail and pass markets, even when one outcome is clearly favored.
  • Potential solution.

• Inadequate Time for Exit: Conditions to finalize a proposal don't give adequate time for exit for those who vehemently disagree.

  • counter arguement is: If you disagree you can just sell on the pass market right? If you do it early enough (hence the 10 days), you will either push the pass twap below fail twap, or you're provided an exit by someone filling your order
  • dynamics can change when an outcome is more certain, resolving a market that is inconsistent with the twap balance doesn't seem fair to those who wish to exit (since twap has manipulation risk and overweights historic viewpoint of market)
  • Potential solution.

• Hinging on TWAP Calculation: The entire resolution process hinges on TWAP calculation. There could also be considerations for market depth or volume weighting.

  • counter point: Market depth and volume weighted price could be nice proxies for governance participation, but I'm not sure they accurately apply here: shallow markets with mostly takers could be accurately pricing the proposal, pass market could have less volume than the fail because participants are more reckless due to confidence the proposal will pass. Generally, I'm not sure that adding more gameable predictors really help solving a gamed indicator.
  • treating min size the same as large wall doesnt really reflect the economic value at stake between the two. there are multiple instances of min sized orders impacting the twap for proposal 0. requiring larger orders to push moving average might change dynamics for the better (those who want proposal to pass, however illiquid, might put more at stake up based on their local valuation model)

• Scenario-Based Issues: Exploration of potential scenario-based issues and proposed solutions:

  1. If someone submits a proposal for an instruction that cannot be executed, it locks all the funds minted in that conditional market. Instead after set period of not being executed, the proposal should probably just automatically revert. Technically, the fail market could increase in value to change the TWAP for the market to fail, but that feels cumbersome.

  2. Allowing conditional minters to withdraw before finalizing (requiring burning both pass/fail tokens one for one). Interesting to know if there's any reason to not allow this.

  3. Determining who should execute an idea after a draft proposal is made is quite tricky. (.marie in Discord has suggested some built-in functionality similar to a contractor bidding process).

  4. Every decision being binary is not as market-friendly as some would like. For instance could the market be designed to select a sliding scale of pay that optimizes token value? Or a clean way to selecting from multiple options?

  • would have to consider how it's possible without further sacrifices to UX. looking at how election markets with multiple candidates work could give better insight.

More Data / Reading

• dodecahedr0x's futarchy reflections
• metadao dune dashboard