> For the complete documentation index, see [llms.txt](https://docs.divaprotocol.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.divaprotocol.io/introduction/what-is-diva-protocol/how-it-works/settlement.md).

# Settlement

The goal of the settlement process is to determine the value of the reference asset prevailing at the time of expiration and with that, the payoffs for short and long position tokens. The settlement process starts right after the pool expires and ends when the status of the final reference value reaches "Confirmed" stage in which case position token holders can start redeeming their position tokens.

DIVA's settlement process was **designed to accommodate different types of oracles** including human oracles as well as decentralized oracle solutions such as Tellor, DIA, Band or Chainlink. It implements an **optional dispute mechanism** that can be activated for human oracles and a **fallback data provider** which steps in if the original data provider fails to submit a value (only guaranteed if data provider is whitelisted).

Below graph illustrates DIVA's settlement process:

![Illustration of DIVA's settlement process](/files/bwQ0EAGsWtGg7VRBFoaG)

On a high level, the settlement process can be broken down into the following four paths:

<table><thead><tr><th width="183.33333333333331">Path</th><th width="446.4571428571429">Description</th></tr></thead><tbody><tr><td>Direct confirmation <br><br>(<mark style="color:green;"><strong>A</strong></mark><strong> -> </strong><mark style="color:green;"><strong>B</strong></mark><strong> -> </strong><mark style="color:green;"><strong>C</strong></mark><strong>)</strong></td><td>Final value is confirmed with the first value submission and users can start redeeming their position tokens. While this offers the best user experience, this path is only suitable for oracles that implement their own dispute mechanism outside of DIVA (like Tellor) or oracles that cannot realistically engage in a review process (like Uniswap v3 oracle).</td></tr><tr><td>Challenge<br><br>(<mark style="color:green;"><strong>A</strong></mark><strong> -> </strong><mark style="color:green;"><strong>B</strong></mark><strong> -> </strong><mark style="color:yellow;"><strong>D</strong></mark><strong> -> </strong><mark style="color:yellow;"><strong>...</strong></mark><strong>)</strong></td><td>Final value is submitted and subject to challenge. Best suited for human reporters which can realistically review and update a submitted value after being challenged. The challenge functionality is optional and can be deactivated at the time of value submission by the data provider. Alternatively, the challenge policy of the data provider can be hard-coded inside a wrapper smart contract to inform users ahead of time.</td></tr><tr><td>Fallback 1<br><br>(<mark style="color:green;"><strong>A</strong></mark><strong> -> </strong><mark style="color:red;"><strong>L</strong></mark><strong> -> </strong><mark style="color:red;"><strong>M</strong></mark><strong>)</strong></td><td>Data provider fails to submit a value and the fallback data provider needs to step in. The fallback data provider guarantees to step in if a whitelisted data provider fails to submit a value within the 24h submission window. For non-whitelisted data providers, it's up to the fallback data provider to decide whether to report a value or not. Values submitted by fallback data providers cannot be challenged. </td></tr><tr><td>Fallback 2<br><br>(<mark style="color:green;"><strong>A</strong></mark><strong> -> </strong><mark style="color:red;"><strong>L</strong></mark><strong> -> </strong><mark style="color:blue;"><strong>N</strong></mark><strong>)</strong></td><td>Both data provider and fallback don't submit any value and final value defaults to inflection.</td></tr></tbody></table>

{% hint style="warning" %}
**IMPORTANT:** The dispute mechanism was designed to prevent human error such as fat-finger error or not accounting for token split. **It CANNOT prevent intentional malicious reporting**! Users should always choose a trusted data provider from the [whitelist](/introduction/what-is-diva-protocol/how-it-works/oracles.md#whitelist) to mitigate the risk of malicious actors.
{% endhint %}

Learn how to settle pools in our [DIVA App Training](/guides/diva-app-training/settle.md).


---

# 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://docs.divaprotocol.io/introduction/what-is-diva-protocol/how-it-works/settlement.md?ask=<question>&goal=<endgoal>
```

`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.