How It Works

How MetaDAO implements futarchy

Overview

MetaDAO is composed of 3 programs deployed on the Solana blockchain:

• a conditional vault program,

• a time-weighted average price (TWAP) program,

• and autocrat, the program that orchestrates futarchy.

The TWAP program is built on top of OpenBook V2’s central limit order book.

Conditional vault program

As described previously, futarchy requires the ability to ‘revert’ trades in a market so that everyone gets back their original tokens. Unfortunately, blockchains don’t allow you to revert transactions after they’ve been finalized, so we need a mechanism to simulate reverting transactions. That mechanism is conditional tokens.

Before minting conditional tokens, someone needs to create a conditional vault. Conditional vaults are each tied to a specific underlying token and settlement authority. In our case, the underlying token would be either META or USDC, and the settlement authority would always be MetaDAO's treasury account.

Once a vault is created, anyone can deposit underlying tokens in exchange for conditional tokens. You receive two types of conditional tokens: ones that are redeemable for underlying tokens if the vault is finalized and ones that are redeemable for underlying tokens if the vault is reverted. For example, if you deposit 10 USDC into a vault, you will receive 10 conditional-on-finalize USDC and 10 conditional-on-revert USDC.

At any time, the settlement authority can either finalize or revert a vault.

If a settlement authority finalizes a vault, conditional-on-finalize token holders can redeem their conditional tokens for underlying tokens. Conversely, if a settlement authority reverts a vault, conditional-on-revert token holders can redeem their conditional tokens for underlying tokens. Because the finalization and reverting are mutually exclusive, total vault liabilities will never exceed total assets.

For each proposal, MetaDAO creates two vaults: one for USDC and one for META. If a proposal passes, it finalizes both vaults. If a proposal fails, it reverts both vaults. So we call the conditional-on-finalize tokens conditional-on-pass tokens and the conditional-on-revert tokens conditional-on-fail tokens.

This allows us to achieve the desired reverting of trades. For example, if someone mints conditional-on-pass META and trades it for conditional-on-pass USDC, either the proposal will pass and they can redeem conditional-on-pass USDC for USDC or the proposal will fail and they can redeem their conditional-on-fail META for their original META.

So we create two markets per proposal: one where conditional-on-pass META is traded for conditional-on-pass USDC and one where conditional-on-fail META is traded for conditional-on-fail USDC. This allows traders to express opinions like “this token would be worth $112 if the proposal passes, but it’s only worth $105 if the proposal fails.”

TWAP program

All MetaDAO markets are on OpenBook v2. There didn’t exist a TWAP oracle for OpenBook or for any other Solana AMM or CLOB, so we built our own. It uses the same design as Uniswap V2, and uses several mechanisms to ensure manipulation-resistance.

Autocrat

The last piece of the puzzle is autocrat, the program that orchestrates futarchy.

Anyone can interact with autocrat to create a proposal, which contains fields such as a proposal number, proposal description link, and an executable Solana Virtual Machine (SVM) instruction. For example, someone could create a proposal to transfer 150,000 USDC to a development team to improve a product that’s managed by MetaDAO.

The requisite conditional vaults and markets are created at the same time.

After a configurable amount of time (currently 10 days), anyone can trigger proposal finalization. In finalization, autocrat checks if the TWAP of the pass market is higher than the TWAP of the fail market. If it is, it executes the SVM instruction, finalizes the pass market, and reverts the fail market. If it isn’t, it marks the proposal as failed, finalizes the fail market, and reverts the pass market.