Skip to main content

​
TWAPs decide whether proposals pass or fail

The goal of futarchy is to accept proposals that increase the value of the project. Unfortunately, you can’t just take prices at the end of the proposal because those could be easily manipulated. So instead, we use time-weighted average prices (TWAPs).

​
TWAPs are lagged to mitigate the effects of manipulation

Normal TWAPs also have their flaws. For example, a Solana validator could manipulate a TWAP by setting the price extremely high for a few slots. If said validator controlled 1% of slots, they could force a proposal through by 100xing the pass price during their slots. We deal with this by using a special form of TWAP we call a lagging price TWAP. In a lagging price TWAP, the number that gets fed into the TWAP isn’t the raw price - it’s a number that tries to approximate the price but which can only move a certain amount per update. We call the number that gets fed into the TWAP an observation. To take an example, imagine that a market’s initial observation is $500 and it can change at most $5 per minute. If market is currently trading at $550, it will take 10 minutes before the last observation reflects the price.

​
24-Hour Delay Before TWAP Recording

Before TWAP recording begins, there is a 24-hour delay period. This gives traders time to properly price the market and evaluate the proposal before recordings start. This delay is important in a permissionless system—it ensures that participants have adequate time to analyze and react to new proposals rather than being caught off-guard by immediate TWAP calculations.

​
Pass Thresholds

MetaDAO uses different pass thresholds depending on the proposal type:
Proposal TypePass Threshold
Team Sponsored-3%
Non-Team Sponsored3%
Team sponsored proposals have a negative threshold (-3%), meaning they require slightly less market confidence to pass. The rationale is that teams generally have better context on what’s good for their project. Non-team sponsored proposals have a positive threshold (3%), making it slightly harder for external proposals to pass than to fail. This provides a conservative default for permissionless governance.
We’re actively tuning these parameters. Check the DAO structure onchain to understand exactly what thresholds have been configured for any specific organization.
For more context on the reasoning behind these threshold choices, see this discussion.