Published in · 5 min read · Nov 13, 2023
--
WeatherXM station owners are familiar with the concept of a Rewards Allocation Mechanism used to calculate the rewards each station gets every day. This article describes the new rewards mechanism (v1.5), the ideas behind it and what’s coming with v2.0.
A staged rollout of Rewards Mechanism v1.5 is planned for this week, and station owners will probably see their rewards change.
Please note:
- This is the first version that takes into account the quality of the data (QoD) received from stations. (Version 1.0, the one beta testers have been seeing for the last 1.5 years, was a very primitive version, used to test various aspects of the system, and the mechanism described in the Whitepaper was never deployed.)
- After this, rewards calculation is not expected to change before the token launch. Any future changes will be announced in blog.weatherxm.com.
The most important changes in v1.5 compared to what we had described in the Whitepaper draft:
- Quality-of-Data is factored in. This means more rewards for stations correctly installed (and fewer rewards for stations not installed correctly).
- v1.5 is simpler and easier to understand. We believe that designing things in such a way that our community can effortlessly get a grasp of the design is key to having informed (informal for now, formal later) participation in the project’s governance.
- More rewards are distributed to active stations. The previous version of the Rewards Mechanism, as described in the Whitepaper, distributed rewards to cells first, then to stations. If a cell had fewer stations than its capacity, the rewards for the “missing” stations were returned to the Business Development Pool. This is not the case any more as v1.5 uses cell modeling to decide on rewardable stations, and then distributes the total daily rewards to all rewardable stations.
- v1.5 also implements the concept of hardware classes. Hardware classes were mentioned even in the earliest versions of the Whitepaper, but now they are treated as a factor that affects rewards in a very specific way and not as an abstract idea.
- Finally, proof-of-location is also integrated in the mechanism, as well as a relocation penalty
The Reward Mechanism has two parts: the first one is the rewards calculation and the second part is the rewards distribution.
- v1.5 changes the way rewards are calculated.
- v2.0 that will come a bit later, changes how rewards are distributed: We will have a new chain (we will replace Polygon, used today, with Arbitrum), a new claim flow and other technical changes. We will have an article dedicated to v2.0 before it’s deployed.
Based on the WeatherXM cell model, we divide the world into hexagon shaped cells, and assign to each cell a number that indicates the maximum number of stations that will get rewards in the specific cell. We call this number “cell capacity”.
The following factors define the rewards allocated daily for each station:
- Daily Emissions (DE): This is a constant. DE=14246.
This is the number of $WXM tokens available for rewards every day. - Proof-of-Location Score (PoL): PoL is a rational number in the range [0,1].
An algorithm evaluates location data associated with each station, their accuracy, and consistency and generates a score which is a confidence indicator about the station’s location. WeatherXM places great importance on station continuity, and discourages location changes. When a station is relocated, its PoL score is set to 0 for 7 days. - Proof-of-Location Threshold (PoL_Threshold): PoL_Threshold is a rational number in the range [0,1].
This number indicates the minimum PoL score a station must have on a given day to be eligible for rewards. - Quality-of-Data Score (QoD): QoD is a rational number in the range [0,1]
An algorithm evaluates the quality of weather data provided by each station and provides a score. (See also, Quality of Data, simplified.) We need meaningful and usable data and the QoD score is an attempt to quantify this metric. - Quality-of-Data Threshold (QoD_Threshold): QoD_Threshold is a rational number in the range [0,1]
This number indicates the minimum QoD score a station must have on a given day in order to be eligible for rewards. - Hardware-Class Weight (HCW): HCW is a rational number > 0.
Each type of approved hardware (weather station) belongs to a specific Hardware Class. Hardware Classes are used to award more tokens to weather stations that have special capabilities, increased sensor accuracy or range, new sensor types, or other capabilities that make them more valuable to the network. For now, all Hardware Classes are considered equal. - Last Claim Time (LCT): Claim time is a unix timestamp (integer).
Last Claim Time is set to the timestamp of the last time someone claimed the station (usually performed during station deployment). It is used as a seniority indicator ( LCT1<LCT2 then station 1 is more senior than station 2). - Cell Capacity (CC): CC is an integer number > 0.
Each cell has a predefined cell capacity that depends on its geospatial characteristics. The cell’s capacity is the maximum number of stations that may receive rewards in a specific cell. If N weather stations are rewardable in a cell with a capacity CC during a specific day, if N>CC, then only the first N stations (ordered first by their rewards score defined below, and then by seniority) will receive rewards.
Using the above, and assuming the Network has N stations on a given day, the rewards for station i (0<i<N+1) for a specific day are calculated as follows.
- For each station, we calculate its PoL and QoD scores for the specific day.
- Stations are excluded from rewards (non-rewardable) based on the following criteria:
a. Stations without a wallet address are excluded.
b. Stations with low thresholds are excluded.
QoD<QoD_Threshold OR PoL<PoLThreshold
c. We iterate over all cells. If N weather stations are rewardable in a cell with a capacity CC during a specific day, and N>CC, then only the first N stations (ordered first by QoD hight-to-low, then by LTC low-to-high) are rewardable. The rest are excluded.
The next steps take into account only the M (≤N) stations that have passed these two tests.
3. We calculate the TotalWeights of the day:
TW=Sum( HCW[s], for every rewardable station s )
4. The rewards for a rewardable station s on this day, are
Rewards[s] = DE * QoD[s] * HCW[s] / TW
Note: If all M stations have the same HCW (this is the case today), then HCW[s]/TW = 1/M (i.e. the hardware class has no impact on rewards in this case).
