paymentModelFunction = function(gbHours, telemReports, downloadedBytes) {
gbHoursScaled = (gbHours - mean(gbHours)) / sd(gbHours)
telemReportsScaled = (telemReports - mean(telemReports)) / sd(telemReports)
downloadedBytesScaled = (downloadedBytes - mean(downloadedBytes)) / sd(downloadedBytes)
basePayout = 10
ghHourPayout = 12.2221 * gbHoursScaled
telemReportsPayout = 0.1452 * telemReportsScaled
downloadedBytesPayout = 12.6849 * downloadedBytesScaled
finalPayout = ghHourPayout + telemReportsPayout + downloadedBytesPayout + basePayout
}
farmerCutoff = function(farmerData, hoursInMonth) {
subset(farmerData,
GigabyteHours >= hoursInMonth | (TelemetryReportCount >= mean(TelemetryReportCount) &
DownloadedBytes >= mean(DownloadedBytes))
)
}
- There are no rewards for storing less than 1 GB for the month.
- However, if a user has telemetry reports, exchange reports, or downloads they may still receive a reward.
- There are no rewards if a user has not been seen in the past week.
- Each component (gbHours, telemetry reports, and downloaded bytes) is scaled so that each metric ends up being a measurement of how far away you are from the mean
- Those values are multiplied by certain weights and summed to arrive at a final value
Weighted standard deviations: doesn't that mean average node gets nothing; If you have avg stats you get 0 according to the formula? It creates a red queen race that the users can't win: imagine that we both run a bridge - you and me - the average is somewhere in between, so you get rewards and I don't; then I drop off and now you get nothing paid out as the mean is now higher. As a result nobody will get the rewards. Incentive design in games is hard, if players design the system it is too easy on them, if the rewards are too sparse - the opposite happens.