---
title: 3.7 Prediction Market Design
description: Theory and use-cases of Prediction Markets, and the re-application of the mechanism design behind prediction markets for a wide variety of use-cases
---

# 3.7 Prediction Market Design

The final lecture in our DeFi series is titled ‘Prediction-Market Design’ - and very clearly not only prediction markets. Why would this be the case? Because despite prediction markets being a quiet and slowly growing DeFi product in its own right, there is much more opportunity and interest from leveraging the mechanism design surrounding ‘prediction-markets’ for a wide variety of on-chain verification use cases. This lecture as such is broken up into two parts: The ‘boring’ theory and use-cases of prediction markets, and second, the much more interesting re-application of the mechanism design behind prediction markets for a wide variety of use-cases. 

## Prediction Market Mechanism Design: What Is The Value?

‘Validation’ typically refers to validation of the L1 blockchain itself, done relatively automatically through node operators running software, and delegators allocating tokens to node operators. The specific type of data that is being validated, is thus digital data, and relatively uncontroversial insofar as all of the data is being created with the next block created on-chain. Any working explorer or indexer can show the same story to all of the validator nodes, such that it is quite automated to maintain the node on the network. 

One step slightly more advanced than this, would be Oracles attempting to bring data on-chain for specific things like price-feeds, from APIs of real world events. Centralized Oracles, guarantee the accuracy of these price-feeds by synchronizing multiple APIs - decentralized oracles however require their own validation mechanism. 

One step even more advanced than this, would refer to the data that is collected from the physical world, and uploaded on-chain either manually, via a sensor, or even from a human being. How is such a system verifiable at scale? 

Herein lies the means by which the logic of a ‘prediction market’ can be utilized: As verification of data moving on chain becomes less quantitative, and more qualitative - that is to say, more ambiguous - and less mathematically verifiable from digital-only data - there is a need for a mechanism by which such data could be verified in a decentralized manner. 

_Put another way, the closer to attempting to track the physical state of a specific asset or event, the more difficult it is to verify that physical state, in a decentralized manner._

To date, prediction market mechanics are the most promising foundation, from which one could construct a decentralized, on-chain mechanism for ‘validating’ such data. 

## Traditional Prediction Market Design

_“Prediction markets: these have been a niche but stable pillar of decentralized finance since the launch of Augur in 2015. Since then, they have quietly been growing in adoption. Prediction markets [showed their value and their limitations](https://vitalik.eth.limo/general/2021/02/18/election.html) in the 2020 US election, and this year in 2022, both crypto prediction markets like [Polymarket](https://polymarket.com/) and play-money markets like [Metaculus](https://www.metaculus.com/questions/) are becoming more and more widely used. Prediction markets are valuable as an epistemic tool, and there is a genuine benefit from using cryptocurrency in making these markets more trustworthy and more globally accessible. I expect prediction markets to not make extreme multibillion-dollar splashes, but continue to steadily grow and become more useful over time.” ([Vitalik](https://vitalik.eth.limo/general/2022/12/05/excited.html))_

As Vitalik explains, prediction markets refer to open-markets, in which users can ‘stake’ or ‘bet’ on the outcome of a binary, ‘yes’ or ‘no’ question. The ‘decentralized’ nature of predict markets are twofold: 

1. First, any user, from anywhere in the world is eligible to participate, such that there is no KYC, discrimination, or localization of participants. This, by extension, enables ‘the wisdom of the crowds’ to provide realistic predictions and foresight towards the future. See Superforcasters or the Foresight Institute for more information on this front. The ‘wisdom of the crowds’ on a particular outcome could have the CIA and the KGB betting on one outcome based on the intel they know - without even knowing it. 

2. Second, the resolution and validation of the market is done by a decentralized suite of participants, all following the same incentive scheme. This is usually designed in the following manner, using the native token of the protocol: 


* Validators stake the native token affirming one of the two binary outcomes. 
* After X period of time, there is the opportunity to challenge the outcome. 
* After Y period of time, there is the opportunity to escalate the challenge. 
* Each escalation requires higher and higher amounts of tokens to be staked on an outcome. 
* When there is no longer an escalation, the side with the majority stake is deemed the correct outcome, and the side with the losing stake is slashed. 

The implicit premise in prediction market design, is that the binary outcome is clearly evident once the event has passed, and as such it is straightforward or self-evident as to what the correct outcome actually is. A non-binary question would prove to be more difficult to resolve especially if there is any room for controversy. 

At the end of the validation - challenge - and escalation sequence, there is typically a resolution period, in which the market resolves, and prepares to payout rewards to the correct validators. Those who have staked value on an outcome, are also rewarded for the outcome that is deemed correct. 

## Augur

Augur was the first dApp ever built on Ethereum, and was used briefly before the mechanism design was hijacked by an anonymous hacker by the name of _[Poyo](https://medium.com/sunrise-over-the-merkle-trees/meet-poyo-an-interview-with-augurs-most-controversial-cat-a6bccae9ffe7)_ . Poyo’s strategy was based on a loophole in the protocol design in which an infinite escalation would eventually resolve as ‘invalid’ and payout both sides of the binary market an equal amount of value (regardless of how clear the correct outcome might be). This initial flaw in the prediction market set back the development of Augur significantly, and demonstrated to many the absolute importance of sound mechanism design. 

On the whole the fundamental issues with Augur beyond its mechanism design also centered on the cost of fees on the Ethereum network, specifically when it came to resolving markets or bidding on outcomes. High costs and slow resolution times made the system scalability limited and painful especially for users. 

## Seda Protocol & Stake GG

Fast forward two years, and Seda protocol (formerly Flux), originally sought to re-test the Augur prediction market design on a cheaper, and more scalable network - our own NEAR Protocol. With the same essential mechanism design minus the fundamental flaws in Augur V1, the logic was that an affordable and quick resolution period could sustain liquid and scalable markets for decentralized forecasting. The resultant product, known as Stake.gg struggled to find active users and venture backing, so with the same mechanism design, the Seda team pivoted into a new cluster: [Decentralized Oracle design](https://docs.seda.xyz/seda-network/introduction/the-oracle-problem), using the same prediction market mechanism design. 

The underlying value proposition is as follows: 

_Unlike existing oracles, that are largely managed in a centralized manner to decide which data is connected to a specific dApp or blockchain, Flux [Seda] purports to leverage the decentralized market resolution design of Augur, in order to secure the correct amount of price and data feeds, connected to a dApp on-chain._

This design is slightly modified, as instead of a user placing  value on a future outcome, it is used to whitelist _requesters_, capable of connecting Seda Oracles to on-chain mechanisms. 

_Requesters →_ Request a data feed from a Seda oracle, and in return for receiving this service, post a fee to validator nodes. 

_Validators →_ Mirror the Augur validation mechanism in staking on outcomes and competing for a share in the fee paid by requesters. 

_Token Holders →_ Curate the list of requesters, via DAO vote, to decide who is allowed to post validation requests. 

The resolution windows are meanwhile set to resolve on a recurring basis, with the fee increasing with each escalation. The design fixes Augur’s ‘Invalid’ status bug, by bringing in a final arbitrator, once 2.5% of the token supply is utilized in a resolution. 

_The value in understanding Flux [Seda], centers upon how the same mechanism for resolving prediction markets, can equally be utilized for ‘economically securing’ data requests as an Oracle._

## Campground

While [Campground ](https://www.campground.co/)remains in its infancy, the thesis of the project was to create a decentralized content management system, in which wrapped content, would be validated by a decentralized community of curators. Users would stake tokens, to place ‘emojis’ on certain pieces of content, with the thesis being that a nuanced conclusion could be achieved on any specific piece of content with sufficient emojis’ placed on the content over time. Content creators would then develop reputations based on the aggregate judgments placed on the content of a creator by the community of curators. The specific mechanism by which curators would ‘validate’ the quality of a content piece, would be by a prediction market mechanism of validation, challenge, and escalation from a (whitelisted) group of curators. 

_The value in this approach, centers upon the prospect of leveraging a prediction market mechanism, for creating a decentralized content management system surrounding reactions to content, and quality and reputation being attributed to a specific author or work over time._

## Open Forest Protocol

Last but not least, [Open Forest Protocol (OFP)](https://www.openforestprotocol.org/), leverages a similar prediction market mechanism for resolving data uploads, uploaded from forest projects seeking to generate carbon credits on the platform. However, unlike Flux Oracles and Campground curators, OFP validators have a 30 day window to validate data uploads, and a maximum of three escalations. Any validator in its current state, must be whitelisted to participate based upon their qualifying criteria. 

## So what is really going on here? Modification Variables

The prediction market mechanism is ultimately a mechanism from which any type of decentralized verification mechanism can be created based upon (1) The types of participants allowed to validate, (2) the timeframes for validating the ‘market’ or ‘data request’, (3) The penalties or rewards for successfully resolving an outcome. 

In addition, there are a number of modification variables that could add further mechanistic complexity: 


* (1) Visibility - between participants: Are validators allowed to see who, when, and how other validators have validated an outcome, or is this only visible after the market has resolved? 
* (2) Timeframes on Resolution of Market: Recurring, expanded time frames, or set timeframes for the type of request in question.  
* (3) Gating who can validate: Is it open to the public or are only specific parties eligible to validate based upon their background, KYC, or other criteria?
* (4) Validator requirements: Are validators all using the same software, API, or price feed, or is their flexibility in terms of how a validator may come to their conclusion on the state of the data request.
* (5) Penalties and Rewards for Validators: How are validators compensated for each data request? Are validators slashed, penalized or barred from the platform if they consistently resolve data requests on the wrong side of the outcome? 
* (6) Validator Communication: Are validators able to discuss the ongoing data request in real-time or are they intentionally siloed from one another in order to prevent collusion? 

It is likely in the future there will be a number of decentralized network designs that will originate based upon the prediction market logic of Augur. The variety and applicability of such a mechanism is a ‘hidden’ gem across network verticals that should be kept in mind for struggling products or industries specifically difficult to bring on-chain.  



