Settlement
DIVA Protocol's universal settlement process
Last updated
DIVA Protocol's universal settlement process
Last updated
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:
On a high level, the settlement process can be broken down into the following four paths:
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.
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 to mitigate the risk of malicious actors.
Learn how to settle pools in our DIVA App Training.
