MetaDAO

MetaDAO is building futarchy: a way of governing where decisions are settled by markets instead of token votes. For each proposal, traders buy and sell conditional pass and fail tokens, and the prices those markets reach decide whether the proposal goes through. Getting the mechanism right matters as much as getting the accounting right, because a market that can be skewed produces a governance signal that is quietly wrong.

The protocol is not one program but several, each with its own job: the futarchy program runs the markets, a launchpad bootstraps new tokens, a bid-wall program supports price, and a performance-package program handles price-based unlocks. They lean on outside programs too, most notably Squads for treasury and multisig. That separation is good design, but it also means the most interesting bugs live in the seams, between MetaDAO programs and between their code and the dependencies they trust.

We pulled from across our practice for this one: DeFi accounting, governance and market-manipulation attacks, cross-program interactions, and the hidden constraints that external dependencies quietly impose. The questions we kept returning to were about fairness. Is the system fair, do users get what they expect, and can anyone engineer an advantage the design never intended to give them?

We read each program on its own, then traced the paths that cross between them and out into Squads, since that is where assumptions tend to break. Across the codebase we surfaced 47 findings, including a critical loss-of-funds bug in liquidity withdrawal that was fixed right away. The two below are not the most severe we reported. They are the two that best show the kind of issue this architecture produces.