MetaDAO: The Bear Case

Issues with the first futarchy.

The article assumes that you are familiar with both futarchy and its first implementation, MetaDAO. It outlines the four core issues that MetaDAO faces.

Table of contents:

1. Airdrop Mistake
2. Power Transfer
3. Inefficient UX
4. Proposals Programs

Airdrop Mistake

The airdrop for MetaDAO’s native token $META ended up giving ~45% of the supply to the community. This averages out to ~0.5% of the total supply, per airdrop participant.

Figure 1) The source of the current 20,885.99 Meta in circulation.

The founder, Proph3t has admitted that this was his biggest mistake, as it was too much to pay to acquire users. Future MetaDAO competitors, as part of a competitive incentive program, could give away a thousand times less per user, over multiple airdrop rounds. This would help them to poach MetaDAO's customers. You only have the power to decide the token supply by decree, once.

Power Transfer

Leaders are the most fearful of giving up power to futarchy. Leaders are MetaDAO's key customer base. Robin Hanson has suggested that adoption and interest by elites will be needed for futarchy to take off. However, futarchy is a direct challenge to the existing elites. It appears that spreading futarchy demands either a ‘Long March through the institutions’ or the creation of a counter-elite, similar to Bitcoin's rise from 2009 to 2021, via the wealth MetaDAO generates for its customers.

Figure 2) The equivalent maturity of MetaDAO as shown on Bitcoin’s timeline.

Having a MetaDAO tenant become so successful that it creates a wealth effect will likely require many iterations and 'shots on goal'. These opportunities are currently being limited by the UX.

Inefficient UX

User friction for creating proposals and DAOs is high, as shown by the pattern of questions in Discord. Uniswap, the organization that most recently introduced a new market primitive, launched their V1 with a UI to create new AMM pairs, which is equivalent to new proposals or new DAOs for MetaDAO. The high liquidity requirements (~$100,000) and complexity of the proposal process is not on par with the UX of creating an AMM in Uniswap. It requires clicking about five button and entering about six short strings to onboard onto Uniswap. While the process of creating a MetaDAO futarchy is still permissioned.

Figure 3) A screenshot of the current MetaDAO onboarding form on the left and Uniswap onboarding UI on the right.

The MetaDAO white paper refers to "... open and permissionless markets." Two years later, the UX is preventing this from being a reality. The UX and security issues around proposals are the most technically challenging problem MetaDAO faces and may take many more years to solve.

Proposal Programs

The majority of proposals consist of two parts: an article to describe the suggestion and program instructions for the relevant onchain actions. The autocrat executes the program instructions. Without the program instructions, the decision markets would merely play an advisory role. Currently, the MetaDAO team helps write this code for proposers. These program instructions are available in the UI for anyone to view.

Traders and holders need to be able to validate that the program instructions match the proposal and that they are not malicious or unsafe. As I see it, the end state of any ‘Futarchy as a Service’ platform is to offer composable formally verified proposal primitives for the autocrat to trigger. As per the Pareto principle, a substantial number of proposals will be of a few core types, e.g. transferring tokens to another account or adding another account to a multi-sig. However, it is not clear how many unique primitives will be required. Currently only MetaDAO itself seems willing to experiment with new proposal types.

Figure 4) A graph showing the use of each proposal program type by each of MetaDAO’s four tenant DAOs as of September 2024. Note there have only been three proposal types so far.

Two teams building on Ethereum, Lektek and Metalex, are making progress in the area of, formalized natural language contracts implemented as smart contracts. Other than MetaDAO, I am not aware of any teams doing anything similar on Solana. Simple formalization of a few typical proposal program instructions, without formal verification, will likely not be enough. A proposal can require complex arbitrary code, with many interacting primitives composed together, so MetaDAO’s current approach of handcrafting ‘contracts as code’ or proposal instruction is not scalable or safe.

Security is paramount for MetaDAO as tenant DAOs have to trust the protocol with their treasury. Rugs and hacks have destroyed many crypto protocols, see Mango Markets. Formally verifying the proposal instructions would substantially increase MetaDAO’s safety. The Move programming language (especially Sui dialect) and the Move Prover have tighter constraints than the Rust or Anchor languages, in which Solana programs are currently written. These tighter constraints make formal verification easier. Unlike Aptos, Solana does not currently have any open-source code for formally verifying programs. However, there is the expensive and slow option of using the Certora. As it stands today, any project requiring frequent formal verification should be written in Move, if possible. I should caveat here, that it is not clear whether the Move prover is flawless, the domain of formal verification of smart contracts is technically complex and evolving.

If an open-source, quick, and reliable, formal verification tool for programs written in Rust or Anchor is not created, I suspect that Solana development might shift to using the Move language. This is because Move is Rust-based and could be compiled down to Solana-compatible LLVM code. A team writing a futarchy protocol in Move today could gain a significant head start over MetaDAO. Given the trust and inertia that is required to be overcome for tenant DAOs to move their treasuries as well as the network effects of a Futarchy as a Service protocol, such a head start would be a significant advantage.

---

For the sake of accountability, here is my bull case.