# 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:
PathDescription
Direct confirmation

(A -> B -> C)		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).
Challenge

(A -> B -> D -> ...)		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.
Fallback 1

(A -> L -> M)		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.
Fallback 2

(A -> L -> N)		Both data provider and fallback don't submit any value and final value defaults to inflection.
{% 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: 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: ``` GET https://docs.divaprotocol.io/introduction/what-is-diva-protocol/how-it-works/settlement.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.