Flux docs
Search…
⌃K

1.3. Resolution Windows

Resolution windows are timed rounds in an economic game in which validators stake FLX on outcomes in order to resolve a data request to earn a fee. Resolution windows are first created when a validator first stakes on a data request, and new ones are created when the bonded_outcome is filled during staking. All data requests resolve with the outcome as the bonded_outcome of the second to last resolution window (unless the final arbitrator is called), since a new round without a bonded_outcome being achieved indicates no dispute round for the previous round. Each resolution windows has the following associated data:
ResolutionWindow {
id: Number, // auto-increments
round: Number, // auto-increments
bond_size: Balance, // increases each round
bonded_outcome: Outcome, // either set or unset
// stake amounts, globally and for each validator
outcome_to_stake: Map<Outcome, Balance>,
user_to_outcome_to_stake: Map<Address, Map<Outcome, Balance>>,
start_time: Timestamp, // round 1 starts at dr creation
end_time: Timestamp, // start_time + initial_challenge_period
}
Once the bond_size is met in a resolution window after enough validators stake on the associated data request, a new data request is generated which if end_time is reached before bond_size is reached, will be finalizable to the bonded_outcome of the previous window.
If disputed, a new resolution window will open with a bond_size twice as large as the previous round’s (unless a stake_multiplier is set on the requester which modifies how the bond_size increases each round; see 2.1.1.). If there are multiple windows and a bonded_outcome is not reached on the last when the end_time expires, the data request can be finalized with the last window with a bonded_outcome.
As a final backstop against attacks, a final arbitrator is triggered when the resolution bond of a data request is equal to 2.5% of the FLX total supply.