teleo-codex/decisions/internet-finance/metadao-develop-amm-program-for-futarchy.md

type	entity_type	name	domain	status	parent_entity	platform	proposer	proposal_url	proposal_date	resolution_date	category	summary	tracked_by	created
decision	decision_market	MetaDAO: Develop AMM Program for Futarchy?	internet-finance	passed	metadao	futardio	joebuild	https://v1.metadao.fi/metadao/trade/CF9QUBS251FnNGZHLJ4WbB2CVRi5BtqJbCqMi47NX1PG	2024-01-24	2024-01-29	mechanism	Proposal to replace CLOB-based futarchy markets with AMM implementation to improve liquidity and reduce state rent costs	rio	2026-03-11

MetaDAO: Develop AMM Program for Futarchy?

Summary

Proposal to develop an Automated Market Maker (AMM) program to replace the existing Central Limit Order Book (CLOB) implementation in MetaDAO's futarchy system. The AMM would use liquidity-weighted price over time as the settlement metric, charge 3-5% swap fees to discourage manipulation and incentivize LPs, and reduce state rent costs from 135-225 SOL annually to near-zero.

Market Data

• Outcome: Passed
• Proposer: joebuild
• Created: 2024-01-24
• Completed: 2024-01-29
• Budget: 400 META on passing, 800 META on completed migration
• Timeline: 3 weeks development + 1 week review

Technical Scope

Program changes:

• Write basic AMM tracking liquidity-weighted average price over lifetime
• Incorporate AMM into autocrat + conditional vault
• Feature to permissionlessly pause AMM swaps and return positions after verdict
• Feature to permissionlessly close AMMs and return state rent SOL
• Loosen time restrictions on proposal creation (currently 50 slots)
• Auto-revert to fail if proposal instructions don't execute after X days

Frontend integration:

• Majority of work by 0xNalloK
• Mainnet testing on temporary subdomain before migration

Significance

This represents a fundamental mechanism upgrade for MetaDAO's futarchy implementation, addressing three core problems with the CLOB approach:

1. Liquidity: Wide bid/ask spreads and price uncertainty discouraged limit orders near midpoint
2. Manipulation resistance: CLOBs allowed 1 META to move midpoint; VWAP vulnerable to wash trading
3. Economic sustainability: 3.75 SOL state rent per market pair (135-225 SOL annually) vs near-zero for AMMs

The proposal explicitly prioritizes simplicity and cost reduction over theoretical purity, noting that "switching to AMMs is not a perfect solution, but I do believe it is a major improvement over the current low-liquidity and somewhat noisy system."

The liquidity-weighted pricing mechanism is novel in futarchy implementations—it weights price observations by available liquidity rather than using simple time-weighted averages, making manipulation expensive when liquidity is high.

Relationship to KB

• metadao.md — core mechanism upgrade
• MetaDAOs Autocrat program implements futarchy through conditional token markets where proposals create parallel pass and fail universes settled by time-weighted average price over a three-day window — mechanism evolution from TWAP to liquidity-weighted pricing
• futarchy adoption faces friction from token price psychology proposal complexity and liquidity requirements — addresses liquidity barrier
• futarchy is manipulation-resistant because attack attempts create profitable opportunities for defenders — implements explicit fee-based defender incentives

Full Proposal Text

Source: futard.io, tabled 2024-01-24

Overview

In the context of Futarchy, CLOBs have a couple of drawbacks:

1. Lack of liquidity
2. Somewhat susceptible to manipulation
3. Pass/fail market pairs cost 3.75 SOL in state rent, which cannot currently be recouped

Lack of liquidity

Estimating a fair price for the future value of MetaDao under pass/fail conditions is difficult, and most reasonable estimates will have a wide range. This uncertainty discourages people from risking their funds with limit orders near the midpoint price, and has the effect of reducing liquidity (and trading). This is the main reason for switching to AMMs.

Somewhat susceptible to manipulation

With CLOBs there is always a bid/ask spread, and someone with 1 $META can push the midpoint towards the current best bid/ask. Though this could be countered with a defensive for-profit bot, and as Proph3t puts it: this is a 1/n problem.

Still, users can selectively crank the market of their choosing. Defending against this (cranking markets all the time) would be a bit costly.

Similarly, VWAP can be manipulated by wash trading. An exponential moving average has the same drawbacks in this context as the existing linear-time system.

State rent costs

If we average 3-5 proposals per month, then annual costs for market creation is 135-225 SOL, or $11475-$19125 at current prices. AMMs cost almost nothing in state rent.

Solution

An AMM would solve all of the above problems and is a move towards simplicity. We can use the metric: liquidity-weighted price over time. The more liquidity that is on the books, the more weight the current price of the pass or fail market is given. Every time there is a swap, these metrics are updated/aggregated. By setting a high fee (3-5%) we can both: encourage LPs, and aggressively discourage wash-trading and manipulation.

These types of proposals would also require that the proposer lock-up some initial liquidity, and set the starting price for the pass/fail markets.

With this setup, liquidity would start low when the proposal is launched, someone would swap and move the AMM price to their preferred price, and then provide liquidity at that price since the fee incentives are high. Liquidity would increase over the duration of the proposal.

The current CLOB setup requires a minimum order size of 1 META, which is effectively a spam filter against manipulating the midpoint within a wide bid/ask spread. AMMs would not have this restriction, and META could be traded at any desired granularity.

Additional considerations

What if a user wants to provide one-sided liquidity?

The most recent passing proposal will create spot markets outside of the pass/fail markets. There will be an AMM, and there is no reason not to create a CLOB as well. Most motivations for providing one-sided liquidity can be satisfied by regular spot-markets, or by arbitraging between spot markets and pass/fail markets. In the future, it may be possible to setup limit orders similarly to how Jupiter limit orders work with triggers and keepers.

Switching to AMMs is not a perfect solution, but I do believe it is a major improvement over the current low-liquidity and somewhat noisy system that we have now.

Implementation

1. Program + Review
2. Frontend

Program + Review

Program changes:

• Write a basic AMM, which tracks liquidity-weighted average price over its lifetime

• Incorporate the AMM into autocrat + conditional vault

• Get feedback to decide if the autocrat and conditional vault should be merged

• Feature to permissionlessly pause AMM swaps and send back positions once there is a verdict (and the instructions have been run, in the case of the pass market)

• Feature to permissionlessly close the AMMs and return the state rent SOL, once there are no positions Additional quality-of-life changes:

• Loosen time restrictions on when a proposal can be created after the markets are created (currently set to 50 slots, which is very restrictive and has led to extra SOL costs to create redundant markets). Alternatively, bundle these commands in the same function call.

• If a proposal instruction does not work, then revert to fail after X number of days (so that funds dont get stuck forever).

Ownership:

• joebuild will write the program changes
• A review will be done by an expert in MetaDAO with availability

Frontend

The majority of the frontend integration changes will be completed by 0xNalloK.

Timeline

Estimate is 3 weeks from passing proposal, with an additional week of review and minor changes.

Budget and Roles

400 META on passing proposal, with an additional 800 META on completed migration.

program changes (joebuild) program review (tbd) frontend work (0xNalloK)

Rollout & Risks

The main program will be deployed before migration of assets. This should allow for some testing of the frontend and the contract on mainnet. We can use a temporary test subdomain.

The risks here include:

• Standard smart contract risk
• Adoption/available liquidity: similar to an orderbook, available liquidity will be decided by LPs. AMMs will incentivize LP'ing, though adoption within the DAO is not a certainty.

Section for feedback changes

Any important changes or feedback brought up during the proposal vote will be reflected here, while the text above will remain unchanged.

• It was pointed out that there are ways to recoup openbook state rent costs, though it would require a migration of the current autocrat program.