> For the complete documentation index, see [llms.txt](https://funarchy.gitbook.io/funarchy/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://funarchy.gitbook.io/funarchy/security-for-prediction-market/governance/dispute-mechanism-abuse.md).
# Dispute Mechanism Abuse
#### **Description**
Prediction markets have a dispute resolution mechanism that allows anyone to dispute the results provided by the oracle. Typically, a deposit is required to prevent false claims, but if this deposit is not properly designed, it can lead to a critical security vulnerability in the system.
If the cost of the deposit is lower than the potential benefits of the attack or the potential damage to competitors, the attacker may engage in financial trolling, intentionally perpetuating the dispute. This can lead to griefing attacks, where a single attacker, even without extensive collusion, can lock up legitimate participants' funds for weeks or even months at a low cost.
#### **Attack Scenario**
{% stepper %}
{% step %}
The attacker bets cheaply on a false outcome with a low probability of occurring.
{% endstep %}
{% step %}
Oracle reports results that are normally true and based on actual facts.
{% endstep %}
{% step %}
The attacker disputes the truth and raises a lower deposit amount, claiming that the outcome is false.
{% endstep %}
{% step %}
Objections may delay market settlement and delay immediate settlement. As market uncertainty increases, the value of your true position may temporarily decline.
{% endstep %}
{% step %}
Attackers continue to drag disputes to higher rounds. Regular users, exhausted by the prolonged disputes and complex processes, either give up on defending or leave the market out of fear of losing their funds.
{% endstep %}
{% step %}
Eventually, when users drop out, false results are confirmed, or the market itself becomes invalid, the attacker achieves their goal of either reaping a large payout from their initial bet or inflicting financial losses on their competitors.
{% endstep %}
{% endstepper %}
#### Real World Case Study
{% hint style="info" %}
[Augur v1 - "Trolling with REP"](https://blog.coinfund.io/trolling-with-rep-c5b6e1e0461)
{% endhint %}
**Vulnerability Analysis**
The problem with Augur v1, a prediction market, arose under specific conditions of low liquidity or low margin requirements.
The expected profit from false claims outweighed the cost of losing margin. Even if an attacker ultimately lost, they could have paralyzed the entire market for weeks or even months at a very low cost.
**Result**
This suggested that financial trolling was possible, not simply through the provision of false information, but through exploitation of the protocol's incentive parameters. This research was instrumental in leading several prediction markets, including Augur v2, to adopt models that exponentially increase margin requirements.
#### **Mitigation**
**Application of exponential deposit growth model**
* The required deposit size should be increased exponentially, doubling, tripling, and so on, with each subsequent dispute round. This should fundamentally eliminate the economic incentive for attackers to reappeal by making the costs of repeated appeals astronomically high.
**Strengthening defender incentives**
* Instead of burning the deposit paid by the attacker when the truth is finally revealed, the deposit is rewarded to the defenders who participated in protecting the truth. \
This motivates the community to actively defend against attacks.
**Dispute duration and round limits**
* To prevent infinite disputes, a cap should be placed on the maximum number of rounds or the total duration of the dispute. However, in this case, a last resort such as a fork must be used to ensure fairness in the final round.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:
```
GET https://funarchy.gitbook.io/funarchy/security-for-prediction-market/governance/dispute-mechanism-abuse.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
