System Overview: Concepts and Architecture

The Purpose and Philosophy

Prediction DAO emerges from a fundamental observation about collective decision-making: communities often know what they value but struggle to determine which actions will advance those values. Traditional governance systems ask individuals to vote on complex proposals requiring technical expertise they may not possess. The result is decisions driven by rhetoric rather than evidence, subject to manipulation by those who speak most persuasively rather than those who understand most deeply.

This platform implements futarchy, a governance model that separates two fundamentally different types of decisions. The community expresses its values through democratic processes, establishing welfare metrics that define what success means for the protocol. When specific proposals arise, prediction markets aggregate distributed knowledge about whether those proposals will advance the chosen metrics. Traders profit only when their predictions prove accurate, creating economic incentives that align individual gain with collective benefit.

The architecture reflects a careful balance between transparency and privacy, between open participation and protection from manipulation. Privacy mechanisms prevent vote buying and collusion while maintaining enough visibility for community oversight. The system combines established patterns from multiple domains: conditional tokens from Gnosis provide market mechanics, zero-knowledge proofs from Nightmarket enable private trading, and key-change messages from MACI prevent coercion. These components work together to create something greater than their sum.

Foundational Entities and Their Relationships

At the heart of the system lies the Futarchy Governor, which orchestrates the entire proposal lifecycle. When someone submits a proposal seeking funding or authorization for action, the Governor coordinates with other components to create markets, manage trading periods, collect oracle reports, and ultimately execute or reject based on market signals. This central coordinator ensures that all pieces move in harmony while avoiding the tight coupling that would make the system brittle.

The Welfare Metric Registry maintains the community's shared definition of success. Through democratic voting, participants establish which measurements matter and how much weight each carries. The primary metric typically tracks treasury value, measuring the protocol's financial health through time-weighted average prices. Secondary metrics might include network activity, indicating ecosystem vitality through transaction volumes and active addresses. Additional metrics capture security, developer engagement, or other dimensions the community deems important. These metrics provide the objective foundation against which proposals get evaluated.

Proposals live in the Proposal Registry, which tracks submission details, milestone definitions, and lifecycle status. When someone believes they can improve the protocol, they post a bond and describe their plan, specifying what resources they need and what outcomes they expect. The Registry maintains this information throughout the proposal's journey from initial submission through potential execution.

Markets emerge from the Conditional Market Factory whenever a proposal enters the trading phase. The Factory creates matched pairs of PASS and FAIL tokens, each representing a claim on future welfare metric values under different scenarios. If the proposal gets implemented, PASS tokens become redeemable for the actual welfare metric increase (or decrease). If the proposal gets rejected, FAIL tokens carry that redemption right instead. This structure transforms abstract predictions into concrete financial instruments.

The Privacy Coordinator sits between traders and markets, encrypting positions to prevent surveillance while proving their validity through zero-knowledge proofs. When you submit a trade, the Coordinator receives an encrypted commitment to your position along with cryptographic proof that it satisfies all system rules. The Coordinator batches these submissions, processes them in epochs, and updates market state without revealing individual actions. This approach maintains trader privacy while ensuring market integrity.

Oracle resolution determines whether proposals succeed or fail by measuring actual welfare metric changes. The Oracle Resolver manages a multi-stage process where designated reporters submit measurements, the community reviews evidence, challengers can dispute results, and escalation mechanisms provide final arbitration when disagreements persist. This careful process balances efficiency with accuracy, allowing quick resolution in consensus cases while ensuring thorough review when stakes warrant scrutiny.

The Ragequit Module provides protection for those who disagree with proposal outcomes. When a proposal passes but some token holders believe it will harm rather than help, they can withdraw their proportional share of treasury assets during a timelock period before execution. This mechanism prevents tyranny of the majority while maintaining the system's ability to act decisively when consensus exists.

Architectural Structure and Component Integration

The architecture follows clear separation of concerns while enabling necessary interactions. Each component owns a specific domain of functionality and exposes well-defined interfaces to others. This modularity allows components to evolve independently while maintaining system coherence.

Consider how components interact during a typical proposal lifecycle. Submission begins at the Proposal Registry, which validates the bond payment and stores proposal metadata. The Registry emits events that inform the Futarchy Governor about the new proposal entering the review period. After the review concludes, the Governor instructs the Conditional Market Factory to create trading instruments. The Factory deploys new token contracts, initializes the LMSR market maker with appropriate liquidity parameters, and registers the market with the Privacy Coordinator.

Throughout the trading phase, the Privacy Coordinator receives encrypted position submissions from traders. Each submission includes a Poseidon hash commitment and a Groth16 zkSNARK proof. The Coordinator verifies proofs against public parameters, accumulates valid submissions into batches, and periodically processes batches to update market state. The actual trading logic resides in the Conditional Market Factory, which implements the LMSR pricing formula and maintains token supplies. The Coordinator acts as a privacy-preserving gateway rather than reimplementing market mechanics.

When trading ends, the Oracle Resolver takes center stage. A designated reporter stakes their bond and submits welfare metric measurements for both outcome scenarios, providing evidence supporting their calculations. The Resolver holds these values during a settlement window, giving the community time to verify the methodology and cross-check the data. If someone identifies problems, they can post a challenge bond and submit counter-evidence, triggering escalation to UMA's broader oracle network. Once resolution finalizes (either through unchallenged acceptance or successful arbitration), the Resolver instructs the Conditional Market Factory to resolve markets and enable token redemption.

The Futarchy Governor maintains oversight throughout this process. It tracks phase transitions, enforces timing requirements, validates state changes, and ultimately executes approved proposals after the timelock period expires. The Governor holds execution authority over the treasury, allowing it to transfer funds or trigger actions when markets signal approval. This authority comes with constraints: spending limits prevent individual proposals from draining reserves, daily caps limit aggregate exposure, and the guardian multisig can pause operations if critical vulnerabilities emerge.

Privacy Architecture and Anti-Collusion Mechanisms

Privacy support rests on two complementary approaches addressing different threat models. The Nightmarket-style position encryption prevents observers from learning what trades individuals make, while MACI-style key changes prevent enforcers from verifying compliance with coercion agreements.

When you prepare a trade, you generate a random nonce and combine it with your position details (amount, direction, price limits) through the Poseidon hash function. This produces a commitment that reveals nothing about the position itself. You then generate a zkSNARK proof demonstrating that your position satisfies validity constraints: the amount is positive, the direction is either PASS or FAIL, you have sufficient balance, and all values fit within expected ranges. The proof reveals only these facts without exposing the specific values.

The Privacy Coordinator receives your commitment and proof, verifies the proof against public circuit parameters, and adds your submission to the current epoch batch. Periodically (perhaps every hour or when batch size reaches a threshold), the Coordinator processes all pending submissions together. It decrypts positions in random order, applies them to market state, calculates new prices, updates balances, and emits only aggregate statistics: total volume, final prices, number of trades. Individual positions remain private throughout.

This approach works well when participants act voluntarily, but coercion changes the dynamics. An attacker might try to bribe you or threaten you, demanding that you trade a specific direction and prove compliance by revealing your nonce after submission. Simple position encryption doesn't prevent this because you could provide the reveal key after the fact.

Key changes solve this problem by allowing you to invalidate previous commitments. When you register with the Privacy Coordinator, you establish a public key that encrypts your submissions. If someone coerces you into agreeing to trade a certain way, you can later submit a key-change message encrypted under your old key. This message contains your new public key. The Coordinator processes it, updates your registration, and considers all positions submitted under the old key invalid for future settlement. You can then submit new positions under the new key, effectively voiding your coerced commitment. The coercer has no way to prove you didn't change keys, making enforcement impossible.

The combination of these mechanisms creates a trading environment where honest participants can act on their knowledge without fear of surveillance or coercion. Markets aggregate information through prices while protecting the privacy of individual contributions.

Market Mechanics and Economic Incentives

The Logarithmic Market Scoring Rule provides automated liquidity for prediction markets through an elegant mathematical structure. Unlike order book systems requiring matching buyers and sellers, LMSR allows traders to transact immediately against a pooled fund. The market maker accepts all trades at computed prices, adjusting quotes continuously as the token supply changes.

The cost function defines market maker behavior through an exponential relationship. As more PASS tokens get purchased, the price of additional PASS tokens rises, reflecting increased market belief in proposal success. Simultaneously, FAIL token prices fall, maintaining the constraint that both prices sum to one. The liquidity parameter controls how quickly prices adjust: higher values provide tighter spreads and more stable prices but require larger capital commitment from the market maker.

This mechanism exhibits several important properties. The bounded loss guarantee ensures the market maker's maximum loss equals the liquidity parameter times the natural logarithm of the number of outcomes, providing predictable capital requirements. Traders cannot gain advantage by splitting large orders into smaller pieces, since the path-independent cost function charges the same total amount regardless of order subdivision. Prices naturally interpret as implied probabilities, allowing intuitive assessment of market sentiment.

When markets resolve, token redemption converts trading positions into final payoffs. If a proposal passes and increases the welfare metric by a certain amount, PASS token holders receive that value per token while FAIL tokens become worthless. Conversely, if the proposal fails or decreases the metric, FAIL token holders collect. This structure aligns trading incentives with accurate prediction: profit comes from correctly anticipating welfare metric changes, not from manipulating votes or gaming procedures.

The bond system creates economic stakes for all key participants. Proposers post bonds that get returned only if their proposals receive good-faith consideration, discouraging spam and ensuring serious intent. Oracle reporters stake bonds that get slashed if their measurements prove inaccurate, incentivizing careful methodology and honest reporting. Challengers must exceed reporter bonds to dispute results, preventing frivolous challenges while ensuring anyone with genuine concerns can raise them. These bonds denominate in the native protocol token, aligning all incentives with long-term protocol health.

Essential Workflows and State Transitions

A proposal begins its journey when someone identifies an opportunity to improve the protocol. Perhaps they want to fund development of a new feature, adjust risk parameters for better security, or allocate treasury assets for strategic investment. They prepare a description explaining their plan, specify the resources required, define measurable milestones, and select the welfare metric most relevant to their proposal's impact.

Submission requires posting a bond that demonstrates serious intent. The bond amount (typically 50 ETC) represents meaningful but not prohibitive cost, enough to deter casual spam while remaining accessible to legitimate proposers. Upon accepting the bond, the Proposal Registry records all details and begins a review period lasting several days. During this window, community members can examine the proposal, ask questions, debate merits, and reach informed opinions about whether markets should evaluate it.

After review, the Futarchy Governor activates the proposal by instructing the Conditional Market Factory to create trading instruments. The Factory deploys two new token types (PASS and FAIL), initializes LMSR parameters based on expected trading volume, and opens the trading period. Initial prices start at 0.5, reflecting maximum uncertainty about proposal effects. The Privacy Coordinator begins accepting encrypted position submissions from traders.

Trading continues for a configured duration, typically one to three weeks depending on proposal complexity and community preferences. During this phase, anyone can trade by submitting encrypted positions through the Privacy Coordinator. Each trader makes independent assessments of whether the proposal will increase or decrease the welfare metric, then trades accordingly. If you believe the proposal will improve treasury value, you buy PASS tokens at current prices. If you predict negative impact, you buy FAIL tokens instead. Your profit or loss depends entirely on the accuracy of your prediction when measured against actual welfare metric changes.

Market prices adjust continuously throughout the trading period as aggregate positions shift. If many traders buy PASS tokens, the price rises, signaling growing market confidence in proposal success. If FAIL buying dominates, prices reflect skepticism about proposal benefits. These price movements provide real-time feedback about informed opinion, potentially influencing community discussion and even proposal modifications before execution.

When trading concludes, the Oracle Resolver opens the reporting phase. A designated reporter (often the proposer themselves, though anyone can fulfill this role) stakes a bond and submits welfare metric measurements for both scenarios. The PASS value estimates what the metric would reach if the proposal executes, while the FAIL value estimates the metric under current conditions without the proposal. The reporter provides detailed evidence: data sources used, calculation methodology, timestamp ranges considered, and IPFS hashes pointing to full datasets.

The settlement window provides time for community verification. Anyone can review the evidence, replicate calculations, and assess whether the methodology seems sound. This period typically lasts several days, balancing thoroughness with decisiveness. If the community accepts the report, resolution proceeds automatically. If someone identifies problems—perhaps flawed methodology, cherry-picked data, or calculation errors—they can post a challenge bond and submit counter-evidence.

Challenged reports escalate to UMA's oracle system, where a broader community of token holders votes on the correct resolution. This escalation mechanism provides final arbitration while avoiding the cost and complexity of involving external validators in every resolution. Most reports resolve without challenge, keeping the system efficient, while the escalation option ensures accuracy when disagreements arise.

Once resolution finalizes, the Futarchy Governor compares market values. If the PASS market shows higher expected welfare metric value than FAIL, the proposal gets approved for execution. If FAIL values exceed PASS, the proposal gets rejected. This comparison implements the core futarchy principle: the market's collective judgment about which path better advances community values determines the outcome.

Approved proposals enter a timelock period before execution, typically lasting two days. This delay serves multiple purposes. It provides time for final technical review, ensuring execution won't trigger unintended consequences. It allows those who disagree with the decision to exercise ragequit rights, withdrawing their share of treasury assets before execution changes what those assets might be used for. It prevents last-minute manipulation from immediately affecting the treasury, since manipulation that might pass unnoticed briefly becomes visible during the timelock.

After the timelock expires, the Governor executes approved proposals by calling treasury functions to transfer funds, update parameters, or perform whatever actions the proposal specified. Rejected proposals simply conclude without execution, their bonds returned to proposers who participated in good faith. The system then stands ready for the next proposal, the cycle continuing as the community governs itself through distributed knowledge aggregation.

Design Decisions and Architectural Tradeoffs

The architecture reflects numerous decisions balancing competing concerns. Consider the choice to separate the Privacy Coordinator from the Conditional Market Factory rather than building privacy directly into market mechanics. This separation allows market logic to remain simple and auditable, focusing solely on token accounting and price calculation. Privacy complexity lives in a dedicated component where cryptographic experts can verify zkSNARK circuits, key management, and batch processing without navigating through unrelated market maker code. The tradeoff is additional interaction complexity and gas costs from the extra indirection, deemed worthwhile for the security and auditability benefits.

The decision to use LMSR rather than order books or other market mechanisms stems from multiple factors. Order books require sufficient liquidity on both sides, which small DAOs might not provide reliably. Automated market makers like constant product formulas work well for token swaps but don't naturally express probability beliefs or provide bounded loss guarantees. LMSR's bounded loss property allows precise capital budgeting for market subsidization, while its probability interpretation aligns with futarchy's theoretical foundations. The downside is more complex mathematics and potential for unfavorable pricing when liquidity parameters don't match actual trading volumes, but these costs seem manageable relative to the benefits.

The multi-stage oracle design balances speed, accuracy, and decentralization. A fully decentralized oracle requiring votes on every resolution would slow governance to a crawl and create voter fatigue. A centralized oracle would introduce unacceptable trust assumptions. The designated reporter model with challenge escalation provides fast resolution in typical cases while ensuring access to decentralized arbitration when needed. Most proposals resolve quickly through unopposed reports, while controversial cases get thorough review. The bond requirements prevent abuse without blocking legitimate participation.

Privacy mechanisms use zkSNARKs rather than other cryptographic approaches because SNARKs provide succinct proofs that remain efficiently verifiable regardless of computation complexity. Position validity constraints involve range checks, balance verification, and market rule enforcement—operations that benefit from SNARK flexibility. The use of Poseidon hashes rather than traditional SHA-256 reflects SNARK-friendliness considerations, as Poseidon's algebraic structure makes it far more efficient within circuit constraints. The tradeoff is dependence on newer, less battle-tested cryptography, mitigated by using circuits audited by the broader zero-knowledge research community.

The ragequit mechanism imports lessons from Moloch DAO about the importance of minority exit rights. Without ragequit, a bare majority could force everyone into risky decisions that don't benefit the community as a whole. Those who disagree find themselves trapped, unable to protect their interests except by selling tokens (likely at unfavorable prices given the impending risky decision). Ragequit provides a safety valve that makes governance more legitimate by ensuring participation remains voluntary even after you've joined. The cost is complexity in treasury management and potential for value extraction by sophisticated actors, but the benefit of maintaining trust in governance legitimacy outweighs these concerns.

Spending limits and timelock delays reflect recognition that systems fail and humans make mistakes. Even well-intentioned market participants might get manipulated by sophisticated attackers or misled by carefully crafted false information. Limiting individual proposal size and aggregate spending velocity prevents catastrophic outcomes from single governance failures while still allowing meaningful action. The guardian multisig pause capability provides emergency protection during the progressive decentralization period while the system proves itself, with clear plans to remove this centralization as confidence grows.

Integration Points and External Dependencies

The system connects to several external protocols and systems while maintaining appropriate independence. Treasury management integrates with the broader Ethereum Classic protocol, respecting ECIP-1112 patterns for controlled fund release. The Futarchy Governor holds execution authority but operates within spending constraints and follows established patterns for multi-sig and time-delayed execution common in DAO treasury management.

Oracle resolution can escalate to UMA, leveraging their Optimistic Oracle system for dispute resolution. This integration provides access to a large, diverse set of token holders who can adjudicate complex questions without requiring Prediction DAO to maintain its own separate voter base. The system submits escalation requests with standardized question formats and bond amounts, receives resolution decisions, and applies them to market finalization. This external dependency introduces some trust in UMA's security properties, but alternative oracle systems could substitute if UMA became unavailable or unreliable.

Market mechanics build on Gnosis Conditional Token Framework standards, ensuring that PASS and FAIL tokens remain compatible with external tooling and that market resolution follows established patterns. This compatibility allows wallet software, block explorers, and analytics tools to understand and display market positions without custom integration. It also means that if prediction market infrastructure evolves, the system can adopt new standards without complete redesign.

Zero-knowledge proof circuits derive from research by the Privacy and Scaling Explorations group, particularly their work on MACI and secure messaging. Rather than developing novel cryptography, the system adapts proven circuit designs to position encryption use cases. This approach balances innovation with prudence, applying established techniques to new contexts rather than inventing unproven mechanisms.

The architecture deliberately avoids dependencies that would lock it to specific infrastructure choices. Contract logic contains no hardcoded addresses for external services where possible, preferring configurable references that governance can update as needed. Interfaces abstract external system details, allowing implementations to change without rewriting core logic. This flexibility aims to ensure the system can adapt as the broader ecosystem evolves.

Evolution and Progressive Decentralization

The system's current form represents an initial implementation with clear plans for refinement based on operational experience. Early versions intentionally include training wheels that will be removed as confidence grows and community governance matures.

The guardian multisig starts with significant powers during the first year of operation, able to pause the system if critical vulnerabilities emerge or if attack patterns threaten treasury safety. This centralization provides protection while the system proves itself under real-world conditions with material stakes. Over subsequent years, guardian powers decline through predetermined steps: increasing the threshold needed for action, reducing the scope of actions available, and eventually removing pause authority entirely. By year four, the community governs entirely through futarchy, with no special privileges for early participants or original deployers.

Market maker parameters will likely need adjustment as trading patterns become clear. Initial liquidity values reflect educated guesses about trading volumes and desired price stability, but actual usage may reveal better configurations. Governance can propose parameter changes that themselves go through the futarchy process, ensuring that modifications serve collective welfare rather than narrow interests.

Privacy mechanisms may evolve as zero-knowledge technology advances. Current zkSNARK circuits balance proof generation time, verification cost, and security properties based on today's cryptography and hardware capabilities. As recursive proof composition, hardware acceleration, and circuit optimization techniques mature, the system can adopt more sophisticated privacy guarantees without sacrificing usability. The modular architecture positions the Privacy Coordinator for replacement or upgrade without disrupting other components.

Oracle resolution procedures might expand to support more sophisticated evidence types as tooling improves. Current implementations rely on manually submitted IPFS hashes pointing to calculation spreadsheets and data dumps. Future versions could integrate with decentralized computation networks to perform calculations on-chain or in verifiable off-chain environments, reducing trust requirements and enabling automatic metric updates.

The architectural separation between components facilitates this evolution. Each piece can improve independently as long as interfaces remain compatible. Proposal Registry upgrades need not coordinate with Privacy Coordinator changes. Oracle Resolver improvements can deploy without touching market mechanics. This modularity allows the system to evolve gracefully without requiring monolithic upgrades that risk disrupting working functionality.

The Coherent Whole

Understanding Prediction DAO requires seeing how these pieces fit together into a coherent system serving a clear purpose. The goal is not simply to run prediction markets or aggregate information, though it does these things. The goal is to create a governance mechanism that makes better decisions by separating value choices from empirical questions and aggregating distributed knowledge efficiently.

Every architectural choice serves this purpose. Privacy mechanisms prevent manipulation while maintaining transparency where it matters. Oracle design balances speed with accuracy. Market mechanics provide objective signals about informed opinion. Bond requirements align incentives without creating prohibitive barriers. Timelock and ragequit protect minorities while allowing decisive action. Components integrate smoothly because they share common foundations and clear purposes.

The result is a system that respects both individual judgment and collective wisdom, that protects privacy while maintaining accountability, that allows decisive action while safeguarding minority rights, and that evolves through the same futarchy principles it implements. The architecture embodies the philosophy that collective decision-making improves when we separate what we care about from how to achieve it, and when we create markets that reward accurate predictions rather than persuasive rhetoric.

This foundation enables governance that learns and improves over time. Each proposal tests predictions against reality, each market provides feedback about collective knowledge, each oracle resolution refines understanding of what drives protocol success. The system doesn't claim perfect knowledge or optimal outcomes; it claims a process that systematically generates better decisions than alternatives by harnessing the distributed knowledge within its community.