StorjFarmerPayoutCalculationFormula.md

Payout Formula

paymentModelFunction = function(gbHours, downloadedBytes) {
  
  HOURS_IN_MONTH = (24 * 365) / 12
  ## Average number of hours in a month
  
  STORJ_USD_RATE = 0.81671
  
  ## This is determined by value reported on https://coinmarketcap.com/ at time 
  ## of payout calculation. 
  
  gbHoursScaled =  sapply((gbHours - median(gbHours)) / sd(gbHours), 
                          function(x) ifelse(x < 0, 0, x))
  downloadedBytesScaled = sapply((downloadedBytes - median(downloadedBytes)) / sd(downloadedBytes),
                                 function(x) ifelse(x < 0, 0, x))
  ## Both gbHoursScaled and downloadedBytesScaled can not be less than 0 to 
  ## ensure everyone gets at least the base payout amount. 
  
  downloadedBytesFlag = as.numeric(downloadedBytes > 0)
  gbHoursFlag = as.numeric(gbHours >= 730)
  isQualifiedFlag = sapply(gbHoursFlag + downloadedBytesFlag,
                           function(x) ifelse(x > 0, 1, 0))
  ## At least one of the above criteria must be met to qualify for a payment. 
  
  basePayout = (1.50 / STORJ_USD_RATE) * isQualifiedFlag
  ## The current base payout is set to $1.50 USD.
  
  ghHourPayout = 11.45 * gbHoursScaled * isQualifiedFlag
  downloadedBytesPayout = 3.0060 * downloadedBytesScaled * isQualifiedFlag
  
  payoutAmountSTORJ = ghHourPayout + downloadedBytesPayout + basePayout
  
  payoutAmountUsd = payoutAmountSTORJ * STORJ_USD_RATE
  
  cbind(payoutAmountSTORJ, payoutAmountUsd)
}

Details

• Nodes that have not been seen in the past week (from the time first preliminary payouts are calculated) are not included in the metric totals
• Each component (gbHours and downloaded bytes) is scaled so that each metric ends up being a measurement of how far away you are from the median
• Those values are multiplied by certain weights and summed to arrive at a final value

Why the STORJ_USD_RATE is token from the first preliminary payout calculation?

I did't make anything wrong an should carry the market risk? I Carry the market risk already for the hole month of farming, but taking this for the days which Storj need to make a correct calculation/process the payment is not fair.

@BlackDuck888 Thanks for the feedback. I've put thought into this and I have a few points/conclusions.

The idea behind freezing at the initial calculation is to protect both farmers and Storj from market risk. With a floating exchange rate either party may lose value depending on whether the price increases or decreases.

I agree that our payout calculation needs work. The current formulation is a holdover from when we were in beta and learning from the process month to month. It no longer meets the expectations, rightfully, placed on it by our community.

Given the time constraints for June payments I don't think it prudent to make any immediate changes to the process. That being said I do plan in the coming weeks to work on improving it and soliciting feedback from the community.

I want all of our community to know that I genuinely appreciate their support, even when it comes in the form of criticism.
Without you guys we wouldn't be in the place we are today.

Please explain how the protection by freezing at initial calculation should work and how it can protect someone. From my sight of the view no one is protected, with freezing up to the time when the money is paid, there is one winner and one looser, depending on what the rate is at that time.

Let me assume you want pay me 1$ for my work, for storing 1TB or what else. Then you fix the rate and start your work, in the next two weeks the market breaks down, you finish your work and pay me my 1$, but shit this is only 50cent worth.

The points are,

• if you pay on months first, and i hold my coins, then this is my decision and my problem.
• if you fix the rate while processing the payment, everything is fine
• i farmed a hole month, keep data up and so on for a defined price, which is never paid

The hole payment has more from a lottery than a payment for work. To many variables for farmers, to long time until paid, and not last over weeks a risk that i loose everything.

@BlackDuck888 A freeze rate for Storj during the moment of payouts, i believe makes it easier for Storj to show farmers and get the feedback on the payouts. Having a tighter loop from feedback to actual payout(which is a process that they can look into, for e.g. tightening the window to be shorter and shorter, since payout fees and time could be faster now on Eth), reduces market risk on both ends. Farmers could hold or sell, Storj could buy/sell if they do not have sufficient supply.

The idea of protection is both a give and take. Farmers take the risk when prices goes lower. Storj takes the risk when prices are going higher(when they do not have sufficient supply to give farmers.).

STORJ_USD_RATE should be an average of the month and not taken at time first preliminary payout calculation.

I agree with ne0ark and BlackDuck888, the price should A) be the avg of the month, within two standard deviations, that the data was farmed and B) shouldn't be a lottery (By doing A you prevent B)

also if we are going to avg the hours in a month lets use a more correct 365.2422 days in a year so it won't have to change in a leap year as using this number accounts for that time.

Why define HOURS_IN_MONTH = (24 * 365) / 12 if 730 is going to be hard coded later on? Also, won't months with different number of days have the different GB requirement thresholds when holding time fixed at 100% per month? This seems arbitrary: 31 days >= 0.98 GB; 30 days >= 1.01 GB; 29 days >= 1.05 GB (and using 364.2422 doesn't make a difference). Hosting about a GB per month should be easy to do, but I don't quite understand why payout was calculated this way. It's quite unfair to February!

Anyway, I'm late to the game, so I'm sure the payout algorithm is quite different today.