Update on June 2020 Payouts

Announcements
1

Update: JANUARY 2021

Please visit Minimum Threshold for Storage Node Operator Payouts for current (January 2021) details

Original text :

Due to unusually high Ethereum transaction fees, we’re in the unfortunate situation of having to make a change to the payout methodology we’ve been following for the past months. The change will not affect the amount or timeliness of payments which are due. Normally, we prefer to provide as much notice as possible about any changes to payments, so we can solicit community feedback, but this is an unusual situation.

Our methodology to this point has been to pay one transaction per Node, per Satellite. This results in 48k payouts in the current month. 33k of those transactions are for payouts worth less than $1.
*We completed the payout for all transactions worth over $1. For the remaining transactions, we’ll be aggregating all payouts across all Satellites and Storage Nodes so that Storage Node Operators will receive one single payment to their respective payout address. *

To be clear, all Storage Node Operator payments will be completed on time this month.

*We’ll continue to use this new payout methodology going forward. The Storage Node Operator Dashboard will accurately reflect the payments per Satellite, however the Ethereum blockchain will only reflect the single payment per payout address. *

We’re considering a number of ideas and contingencies with payouts in the event transaction costs remain high or continue to increase. We’re investigating some alternatives including setting a minimum transaction amount—either a fixed amount or a ratio of transaction fees where payout amounts below a given threshold would roll forward into subsequent payouts until the threshold has been reached.

Long term, we would like to put Storage Node Operators in control using a withdrawal based system, but there is a substantial amount of work required to make that happen.

We value the members of our Storage Node Operator Community and appreciate your understanding. If you have suggestions or ideas that you think might provide a better solution, please let us know.

As always, we’ll keep the lines of communications open as new developments arise.The most effective way to provide feedback is via this thread, which keeps the conversation open and transparent to everybody. You can also enter suggestions under the “Suggestions and Ideas” category. If you would like to provide confidential feedback, please email ask@storj.io

Thank you.

23 Likes
2

I like the idea of $1 minimum before paying a node or charging the transaction fee to the node and allowing node operator to specify minimum payout amount. As SNO it seems acceptable to me.

I dont like the idea of keeping balance on satellite and having SNO manually withdraw it. I would warn storj product team implementing that feature especially if it requires lots of engineering resources. Please make sure to do good research before implementing it. I doubt any SNO would want to accumulate the balance on satellite instead of withdrawing to personal wallet every month.

5 Likes
3

I am surprised at the transaction costs, seeing rates of 32 cents on a 56 cent payout. I would prefer to wait until the cost was a small fraction of the payout.

Due to different SNO opinions, ideally you would have a default payout for SNOs that each of us could change (such as custom threshold) for those of us who prefer to wait for the balance to increase to a level that makes sense.

Screen Shot 2020-06-10 at 6.47.33 PM
Screen Shot 2020-06-10 at 6.47.33 PM945×142 14.6 KB

4 Likes
4

One payout per address is understandable, I hope you keep it regardless of ethereum network transaction fees. It’s cheaper, faster and puts less strain on the network itself.

Regarding the payouts, I see that transactions from what used to be stefan-benten satellite address are still being sent. I got one before this announcement was posted, but the amount was well above what I expected from that satellite. Is this the aggregated payout?

4 Likes
5

This is definitely the smarter approach to bundle the payouts. Thanks for the info on this, I was wondering if there was a hangup on a few of the payouts on some of the satellites I don’t have much data on, appreciate the quick update on the situation.

Doesn’t really make sense to send out transactions where the fee is a large amount relative to the payout. Would also not be opposed to just delayed payouts in situations like this as long as it is communicated so people don’t freak out.

6 Likes
6

I much prefer an aggregated single payout, be it for multiple nodes per satellite or 1 payout for all nodes and satellites. This makes record keeping for tax reporting much easier. As the number of satellites increases and as I add more nodes I was becoming concerned about how many transaction I would have to track. The April transactions (paid May 7th) for me was 18 transactions - 3 nodes x 6 satellites. That was manageable but not fun.

It would be nice if there was also communication indicating the price at which the transaction was performed. Currently I must look up each transaction on etherscan, note the time it occurred, then look up the price at that time on a site like Coinbase.com. Very cumbersome for 18 transactions.

6 Likes
7

Yes, we used the hot wallet we use for the Stefan satellite to do the aggregated payouts this month as it already had enough of a balance. We will probably use another wallet for the aggregated payouts next month.

We still need to import all of the transaction hashes and results back into the Satellites so the SNO dashboards work, but last month’s payouts are now complete. Glad you’re all on board with this new approach! It was a lot easier than we thought it would be to pivot to this quickly. We’ll most certainly continue doing it seeing as how it seems preferred!

6 Likes
8

I’m not sure if the SNO dashboard already shows this, but it does have enough information to on the backend. This is totally something we could put on the SNO dashboard if there’s enough interest.

7 Likes
9

I agree with you. But with most things what sounds easy to us might be going back to manual of a logistical/spreadsheet nightmare for Storj… Well that is untill they get the payout scripts updated. :smiley:
You should stick it in the suggestion page and see how many votes you get.

Either 1 payout per node ( my preferred option so I can tell which node is doing better or might need some intervention)
or
1 payout per address ( a lot easier and less confusion around the number of payments but with less insight)

1 Like
10

I totally agree with the aggregated payout as long as the data in the dashboard will not be missing.

However, I would like to ask a stupid question, who is actually paying for the transaction fee? Storj team or SNO?

1 Like
11

As far as I know the exchange rate at time of payout is currently not in any of the nodes databases. I would definitely appreciate having this information as it allows us to close the loop on payouts. Currently this is the only thing we can’t exactly calculate based on available information. Now that comparisons can be made on less granular, it becomes even more important to get this information.
Last month I was able to detect a payout issue on saltlake because that specific payout was lower than expected. (This issue is known and should be compensated this month)
With this new (and completely understandable) approach, it will be harder to do things like that unless more information is provided.

I’ve given detailed payout feedback several times over the past months and I’d like to keep doing that, but that’s going to be a little more complicated now. Luckily there is now paystub data to compare it to, but that is still not the actual amount received. Having the exchange rate would close that loop.

2 Likes
12

Thanks for the extensive info @john!
Shouldn’t this be May payouts though? I’ve seen both being used, but I think referring to the month it was paid out for makes more sense.

And that’s also the logic that was used last month when payouts were completed.

image
image774×267 27.3 KB

13

That’s exactly what makes cryptocurrency so weird, those unpredictable and sometimes high transaction fees that can be higher than the amount to send.
Now it seems to backfire that Storj has not implemented its own cryptocurrency. If they had, they would pay transaction fees in their own currency.

I don’t know if it helps but I wouldn’t mind receiving payouts in a different currency that is known for low transaction fees. I would be happy if I could select Dogecoin as payout currency and Storj would be happy paying as little as 1 Dogecoin per transaction or even zero fees.
There is even effort to build SLP token on top of the Dogecoin chain: https://www.reddit.com/r/dogecoin/comments/evw7ff/info_about_dogetoken_slp_tokens/.

I don’t know anything about SLP tokens but I am sure Storj programmers could easily build something like that on their own if they needed to.

I would not be happy not receiving monthly payouts for 2 reasons:

  1. Storj already holding back already earned tokens for repair. Holding back even more turns Storj into a bank for SNOs.
  2. Fluctuation of Storj price

But consolidation into one payout per address would be fine if Storj is going to provide breakdown data per satellite/node.

14

One transaction per sattelite is more than OK even if there are 20 nodes. Payout receipt to email is the best option for all this.

6 Likes
15

In my opinion, group the transactions by address and make a single monthly payment regardless of the number of nodes or not! One transaction = one fee!
He doesn’t have to pay 0.40 to get a 0.34 fee! This repeated 10 times we are talking about $ 3 Transaction Fee! It does not make sense!

4 Likes
16

Here is my opinion:
Grouping payouts to one transaction is decreasing transparency and especially reduces transparency: changing rules in the middle of payouts processing. I see only cost optimization at this moment and bad planning in the past. Please provide an alternative to control payouts per node fo SNO.
(you can use SNO dashboard or email notification)

Another proposition for improving transparency is to provide payout information before real payouts.
On all other services (for example: rent VDS), we have orders before pay for it and can review these orders before real payouts. Only Storj Labs did payouts before “orders” (payout information on the SNO dashboard)

image
image1064×809 45.7 KB

Unfortunately, I did not see real transparency at this moment, but I hope it will be improved on near feature.
Anyway, I appreciate that you raise this topic and will hope that in the near future we will not only talk about transparency but and will see real actions.

10 Likes
17

I agree with the lack of transparency in some of the payout data, but I also see how much work has been done to add more information. With v1.6.3 I believe there is an estimate being displayed for the previous month prior to pay stub being reported back to the node. That would resolve the no data issue, but would still be based on local calculation rather than satellite calculation. Similar to how the earnings calculator does it. It would be even nicer to see both the nodes own accounting as well as the paystub for previous months so we can see right there on the dashboard that they actually match.

I agree that it would be nice to get the pay stub data prior to payout, however I would also like to see the exchange rate and amount of STORJ displayed in that pay stub data, which is only available after payout. Ideally we would have paystub info without STORJ values prior to payouts starting and have that updated with STORJ exchange rate and payout later. But this would require updating it twice.

1 Like
18

its difficult to expect all details… a bit like if you get a house extension built… the estimate will include tons and tons of things that are irrelevant to the customer… like its not really very relevant to the house owner if the contractor’s people needs new boots…

doesn’t mean it’s not important or calculated by the contractor… but it’s totally irrelevant to the house owner…

to assume that we as SNO’s will get all the details is ridiculous… we just need to get paid in an accurate and reliable way, that allows SNO’s to trust the process, and with enough details that we can see poorly performing nodes and make sense of it… enough that we can find problems and such… and maybe check the payouts vs what we stored/egressed…

but the wasted fee’'s are essentially also a waste for us… because it’s wasted money that goes to ether miners which could go to SNO’s instead… i would suggest that fees should be kept to 1-5% max

1 Like
19

I really believe in trust but verify when it comes to this. All I’m asking for is an itemized list of what my node is paid for and how much it is paid, including the exchange rate, so I can check that the payment matches the actual service my node has provided. Currently there are still gaps in that that need to be filled in.

The transaction fees are not a part of that. They are like the boots in your example. A cost for Storjlabs that I shouldn’t have to worry about.

If I can see which amounts of storj were paid out per node per satellite, I can compare that to the amount transferred and see if that matches. I can then do all detailed per satellite/node checks based on the data Storjlabs provides on the dashboard. And then compare that to the actual work my node has done based on its own accounting. Most of that is in place, but the exchange rate and STORJ amounts are not.

3 Likes
20

This is a great idea kinda like an invoice so you know how your nodes are doing, But I have to say this might be more over head your node doesn’t need though. It would be nice to have this kinda details but with current setup our nodes dont need even more data on them then it needs to have.