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
This is a peculiar reward mechanism to put it mildly. It makes the aggregate payout liabilities proportional to the number of farmers, which is pretty comfy for StorJ. To farmers it's mostly confusing and feels unfair. Even when supplying resources to the network you can end up with no rewards, and your very real costs of electricity, inconvenience and equipment depreciation are only marginally being taken into account at an unknowable rate.
To offer a counterpoint, as I understand now the parameters of the formula may currently be more favorable than those displayed here because of subsidies. I suspect there are better reward models possible that pose the same minimal risk for StorJ at a similar level of aggregate payouts.