Tardigrade reciprocation for STORJ node operators

It would be nice if there was a way for a STORJ node operator to supply (X * expansion factor) to the network in exchange for X amount of capacity via Tardigrade, with no fee incurring/payment involved. Sure, this can be approximated by using storage node proceeds to pay for tardigrade costs but this presupposes the storagenode can be filled enough to become profitable enough, etc.

Use case:

I currently pay a fixed $X/mo for a backup solution that I’d prefer to move to tardigrade. If I simply cut over to tardigrade then my costs would rocket to roughly $4X/mo as a starting point. I’m a cheapskate and don’t want to pay service fees that high. However, I don’t mind acquiring the additional storage node hardware required to host 3x or 4x my backup requirements.

I’m weird but maybe this is not an uncommon desire so I figured I’d mention it.

2 Likes
  1. you get 150GB storage and bandwidth for free, so you don’t start paying until your usage exceeds those limits.
  2. Added hard drive capacity will not produce a steady income and will take months until you even get any sizeable earnings. Storj does not pay for capacity offered but for actual space occupied by customer data and bandwidth provided for downloads. So we can’t just say providing X TB of potential space and bandwidth as SNO will get you Y amount of free storage on Storj DCS.
  3. you can already use the STORJ tokens you earn to pay for renting space on Storj DCS. In the future, we may make it even easier to deposit the payments. We are already working on a much improved native STORJ payment service that will replace CoinPayments.
2 Likes

Yes, I agree with all points. But I think you missed what I was trying to communicate. :slight_smile:

For point #1, I’m in the tens of TB range so a free 150GB has virtually no impact on me.

For point #2, that is a point that I’m well aware of and mentioned in my opening (“but this presupposes the storagenode can be filled enough to become profitable”).

For point #3, I covered this as well: “Sure, this can be approximated by using storage node proceeds to pay for tardigrade costs”

To restate what I’m proposing: If I offer 30TB to the network, I’d like to be able to upload for no cost 10TB (or whatever expansion factor multiple). i.e., node operators supporting other node operators as a feature for being a node operator. ( …But therein lies the rub, since “Storj does not pay for capacity offered but for actual space occupied” so it would have to be an economic opt-in by other storagenode operators or something).

You may refer to the community-provided earnings estimator to get an idea how long that may take to actually fill 30TB with your node. Again, even if you had already 30TB filled the actual diskspace used will vary depending how fast customers may decide to delete some of their data vs how much new data gets uploaded. There is no easy 30TB storage provided → 10TB worth of space on Storj DCS formula we could offer.

The only thing that we could consider is implementing an option for SNOs to select that instead of receiving payout, they want the earned amount to not be disbursed to their wallet but applied to their STORJ DCS account balance in equal dollar terms. That would also require them to signal that they have an account on a certain satellite and under which username/email. You can ask people to vote on such a proposal so that devs may consider to add this to the road map if there is sufficient demand for this.

I am not sure I understand your proposal involving collaboration with other node operators.

1 Like

I’d fill out the form and make that suggestion under ‘other’. Someone will have to read it.

If we get paid on zksync we can’t do this. and storj encouraged us to move to zksync.

1 Like

If that’s a possibility I’ll probably move my backups to storj, transaction fees were just too high for the amount of data I store.

I don’t think that that could work, also because I’m not sure storj has a way of checking that you actually have 30TB of free space, it just relies of system information.

1 Like

zkSync deposits are expected to also be added to our new STORJ deposit workflow in a later iteration (probably not the first round.) The more people ask for it, the more likely this may get a higher priority. However, if you were to hold payouts for several pay periods on L2 zkSync until it is worthwhile to withdraw to L1 (please remember that you would receive 10% extra exactly to help cover these withdrawal fees), you could directly withdraw to the STORJ deposit address our new workflow will display even while direct L2 zkSync deposits are not activated yet. This is no different from withdrawing earnings to an exchange L1 address after accumulating in your zkSync L2 wallet.

That timeframe to wait has significantly increased due to the recent drop in value of the storj token. For myself as an example I am currently down around 30% of the value I had accumulated over a year. I know the markets are volatile and the losses could be erased as equally as they arrived but as things currently stand I will be waiting a lot longer to do any transfers anywhere on zksync. 10% bonus or not.

Using zkSync is not compulsory. If you do not want to bear the risk of volatility of STORJ price, the best option is to stay with L1 payouts and let the earnings accumulate until they reach the payout threshold, and it would be converted from USD earned to STORJ at time of payout.

If Storj had implemented a system to use credits of SNO’s to pay for storage without receiving a payout first that would actually make sense for some people. But that isn’t the system we have yet. Is it? In my case I deleted my first ever Storage node as I wanted to use that storage for other things. It made sense to convert that node to zksync before deletion rather than leaving that payment sit for an indefinite period - and indeed we now see the long term goal of Storj is to move to 10% payment thresholds. Moving L1 payments further and further away for the average SNO. Particularly given the disclosure by Storj that the average node life was 9 months.
That means an average SNO would simply never get an L1 payment. Ever.

At least until Polygon is live the alternative is get a payment we can’t use or never get a payment at all. Great alternatives. I very much hope Polygon will change that. I’ve certainly been able to move around Golem payments ever since day 1. Big contrast with Storj.

Ah, you’re right. No sealing for proof of space-time. :wink:

I suppose the only way this idea could work would be to offer the space and then based upon how much was used would determine how much you could upload, since that is what the satellites could track. At that point, using proceeds to pay for usage would probably actually be viable, and a simpler approach.

1 Like

If using the same payout address on all your nodes on L1, this would reduce the amount of time it would take to meet the payout threshold. Unfortunately we cannot implement all parts of the new STORJ deposit system on the customer billing side at once. It is not trivial to build an entire new system from scratch to accept payments rather than using a third party payment provider as we have been until now. With the current CoinPayments system, it would not even be possible to switch to zkSync deposits. So with our own native system we will have more flexibility to implement different options as we see demand for them from customers and SNOs who want to also use Storj DCS with their STORJ earnings.

1 Like

What you are describing is basically what I offered earlier as option 3.

1 Like

srsly heunland? You’re earlier option #3 was identified in my original post. You’ve repeatedly missed point.

The problem with making any long term decisions about Storj and L1 is the goal posts have changed several times invalidating those previous choices.
Don’t get me wrong. I understand the reasons for doing this. The payments system has serious cost implications for Storj. I also understand Storj is still running at a loss paying SNO’s currently. But the implications for an SNO are that making a choice to use the L1 anticipating a payment on L1 in the longer term can be invalidated down the line by future changes by Storj.

1 Like

Well to be fair you listed it as the option you wanted to avoid because

Should we create a vote so that the community can express interest or is it meant to be expressed in this thread ?