Flux docs
Creation and Resolution Windows
How data requests get created and resolved
Resolution windows are the time periods in which validators can stake on outcomes to reach a bonded_outcome in order to resolve a data request. A bonded_outcome of a given resolution window is calculated when validators stake on the data request until the current resolution window has its resolution bond (or bond_size) met. A challenge is the act of staking on a different outcome after the resolution bond of a given resolution window is met.
Due to the multi-contract architecture of the Flux oracle, data request creation involves a couple cross-contract calls to coordinate a requester contract and the oracle:
Data request creation
The formula for calculating a resolution bond R of round i is:
Ri=2mmax{fee,Ri1};R_i = 2m*\max{\{fee,R_{i-1}\}};
Where m is an optional multiplier set by the requester contract (by default = 1) and R0 = validity bond.
For typical data requests after the initial resolution window, the resolution bond required for subsequent round doubles with each round. However, escalation games cannot go on indefinitely, hence the need for a final arbitrator as a backstop. This arbitrator determines the final outcome of the request in the case that the resolution bond becomes too large and threatens the health of the protocol. They cannot otherwise affect the outcome of a data request and is triggered when the resolution bond of a data request is equal to 2.5% of FLX total supply (subject to change by the Flux DAO).
Export as PDF
Copy link