Voluntary Payout Reductions — and How to Set One Up

Node Operators
1

Over the past few days, several Storage Node Operators have reached out to us with a version of the same generous offer: a temporary and voluntary payout reduction to support the network.

We want to say — genuinely — thank you. It’s lovely to be part of a community that shows up like this. This kind of support isn’t something we take for granted.

How to set it up

You can set custom rates for your node directly via a config tag:

contact.self-signed-tags: "storage_price=X,egress_price=X,repair_price=X,audit_price=X"

Where each X is the price you’re comfortable earning, in USD per TB. The current standard rates — and the maximum values allowed here — are:

contact.self-signed-tags: "storage_price=1.5,egress_price=2,repair_price=2,audit_price=2"

Anything above these maximums will simply be ignored, so you can’t accidentally set a rate higher than default.

Once the config is updated, restart your node to apply the change.

Important: removing this line from your config does not revert your rates. Whatever values you last submitted stay in effect on the satellite. To go back to standard pricing, you need to explicitly set the tag back to the standard rates and restart:

contact.self-signed-tags: "storage_price=1.5,egress_price=2,repair_price=2,audit_price=2"

There’s no “right” number — pick whatever you’re comfortable with. A few examples of what this can look like:

  • A modest reduction: storage_price=1.25,egress_price=1.5,repair_price=1,audit_price=1
  • A full (100%) reduction: storage_price=0,egress_price=0,repair_price=0,audit_price=0
  • A partial, time-limited reduction: storage_price=0.57,egress_price=1.5,repair_price=0,audit_price=0

Whatever combination you choose is entirely up to you.

Timing

Custom rates are read at the time your payout is calculated, and apply to the entire payout period — not just data transferred after you made the change. Depending on how quickly you make the change, it may be reflected in the upcoming payment coming in the next few days. If you’d prefer to start with a later payment, just hold off on the config change until then.

A note on future data allocation

We’re also exploring whether this same mechanism could be used to send more data to nodes with lower rates. Nothing is confirmed or live yet — this is still an idea we’re developing. For now, the only incentive for setting a lower rate is good will, not preferential data allocation.

A few things worth repeating

  • This is entirely optional — no pressure, no expectation.
  • It’s fully adjustable — change your rates or revert to default at any time.
  • Every bit helps, regardless of size.

Thank you to everyone who’s reached out with this offer. It means a lot.

2

Because I am lazy this is my code snipet for a $0 rate:

for f in /mnt/sn*/node*/storagenode/config.yaml; do
  if [ -f "$f" ]; then
    if ! grep -q '^contact.self-signed-tags:' "$f"; then
      echo 'contact.self-signed-tags: "storage_price=0,egress_price=0,repair_price=0,audit_price=0"' >> "$f"
      echo "Updated: $f"
    else
      echo "Skipped (already set): $f"
    fi
  fi
done
sudo systemctl restart 'node*'
3

This approach is very interesting. Could be worth to make it part of the node selection process and mandatory for every node to set a price.

A word of caution however: A node operator could set it to 0 to get most traffic and then hold the data hostage and increase the price later for the data he has accumulated.

So only solution would be that SNO must not be able to increase the price tag after he received the data pieces.

4
  1. Is there any way how to confirm what values are used for my node?
  2. I don’t want to experiment. I’d be happy to set those values using environment variables in docker yaml. Is it possible? How? Now I have:
    restart: unless-stopped
    stop_grace_period: 300s
    environment:
      - WALLET=_not_important_here
      - EMAIL=hwm.land_email
      - ADDRESS=address:28967
      - STORAGE="11TB"
  1. It’s max-capped, so I can set it to 999 when I want to return to original rates and I’m fine? (whatever rates are there in the future)
5

On a similar vein, my question is what I should add to a docker startup command :slightly_smiling_face:

And yes, before some people start calling me names, I am happy to do this for free because I do it for shits and giggles and costs me insignificant money and little time.
I like seeing my kit used.
That said, I will expect payments to resume if and when the company is on a sounder ground.

6

I would have to look that up in the database. That is the only way we can check it right now.

Should be STORJ_CONTACT_SELF_SIGNED_TAGS=[…]

Yes that would do it.

7

To be honest I did it partially because of the peer pressur. I originally planned to go with the 0.57 pricing which should reduce my payout to a minimum while still pay enough for electricity and bandwidth. Last second before sending the command to my nodes I thought well lets join the club. A 0 rate will workfor me as well for this year.

But any value is welcome. Put in the number you all feel comfortable with.

8

Thanks. I set it to:

# Voluntary Payout Reductions (now set to 50%)
# Set it to 999 (or whatever nonse-big value) to revert
# see https://forum.storj.io/t/voluntary-payout-reductions-and-how-to-set-one-up/32204
- STORJ_CONTACT_SELF_SIGNED_TAGS="storage_price=0.75,egress_price=1,repair_price=1,audit_price=1"

It’s set now for node 127Lop9dGyfi5tCJ55U3GzpJXShumYe932nFAg3h9oMZKPpvvm5 if you have time to check. Without feedback I consider it working :slight_smile:

9

The solution we have for that in mind would be a moving average over at least 10 months. That would mean the moment you put down a higher rate it will not increase your payout as fast and while each month gets you closer to your target rate the repair service will move pieces away from your node.

That would be one idea how it can be done. We would announce that in advance and give all the nodes enough time to adjust their configs. For now you can change the rate when ever you want and it will be applied on the next payout calculation.

10

This is something new: interesting! If decisions on where to send uploads did start to take custom pricing into consideration… then… yeah we’d have SNOs bidding to fill their nodes.

I don’t think we’d have to worry about people who set their price artificially low to fill their node… then put the price back up. Because as soon as the price was raised they’d stop winning uploads and bloom filters would start to deflate their node. So they’d need to use a reasonable price to stay full.

But it could be a short-term strategy: to get that initial fill.

11

So there will be no price reduction for all only voluntary?
To be honest this feature can make real market, who have better price get more data, but need to think how to implement it. Different regions have different electricity price also.

12

Yes it works. I can see your node in the database. Thank you very much.

13

I wonder how big of an impact this will have. There are tens of thousands of nodes and thousands of SNOs, but I assume only a fraction of them read the forum.
Maybe it would be a good idea to also send this out by e-mail.

And could you perhaps expose these numbers somehow, to see how many nodes selected which pricing?

14

This sound a lot like SIA for me. They can set the price too. And if they change it back or set it too high, they just start loosing contracts as soon as they expire

15

Or even just include it in the monthly payout posts we used to get. Add one more line: "… and this month the average prices that were paid were:

storage_price=1.05,egress_price=1.4,repair_price=1.37,audit_price=0.5

16

The ideal way would be to expose this via the satellite, as part of the node list offered for storing the chunk, along with the IP, port, capabilities, etc.

17

I am going to say not right now. I see a few different options what might happen from here on.

  1. Enough people do higher voluntary payout reductions to the point that any smaller permanent reduction could backfire raise the total payout.
  2. The data we are collecting can be used to estimate a possible permanent reduction. Ofc using temporary payout rates to calculate a permanent rate means we can’t just follow through and set it. But we can use the data to come up with a model and at the end ask you all to switch from temporary to permanent payout rates and basically use this as kind of a voting system.

I personally hope for #1 .

18

@littleskunk do you see changes for 1wazW5wX9tz4ioGu6hdwqoCkezYWd75LnPJ9epJcJor9NxyGKK ?

19

Confirmed. Thank you very much.

20

I suspect you’re going to be overwhelmed with requests for confirmation :wink: