> ## Documentation Index
> Fetch the complete documentation index at: https://docs.metadao.fi/llms.txt
> Use this file to discover all available pages before exploring further.

# Finalizing Proposals

> How projects decide whether a proposal passes or fails

## 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*.

<img src="https://mintcdn.com/metadaollc/prgKP2kImec_ApFO/images/twaps.jpg?fit=max&auto=format&n=prgKP2kImec_ApFO&q=85&s=67d8e5e23a16d49efc525e876fc191f2" alt="" width="768" height="384" data-path="images/twaps.jpg" />

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 Type      | Pass Threshold |
| ------------------ | -------------- |
| Team Sponsored     | -3%            |
| Non-Team Sponsored | 3%             |

**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.

<Note>
  We're actively tuning these parameters. Check the DAO structure onchain to understand
  exactly what thresholds have been configured for any specific organization.
</Note>

For more context on the reasoning behind these threshold choices, see
[this discussion](https://x.com/metaproph3t/status/1979243370452258837).