Bandwidth payout for node more than price user pay for, how it possible

Hi,
I just have a curious question about the bandwidth pricing model.
Storj pay for node $20/TB Egress but only charge $7/TB to user. So how is that possible that the business model is working?

Well, they charge fiat and pay tokens…
Huge difference. :laughing:

2 Likes

Storj is in a growth phase right now. As customers continue to get onboarded, usage will.increase and then at some point the payment model will change. Pricing.will always fluctuate so Storj stays competitive with other services but also add features to help offset traditional models.

But for now, the focus is on growth so some variation in price between what Sno’s earn and what customers pay is normal.

8 Likes

We’ve made the conscious decision to reduce the barrier to entry for new storage nodes and to ensure that we have a stable network of reliable storage nodes by implementing a set of incentives designed to ensure the best experience both for nodes joining the network and people storing data on the network.

We architected the network to run on low-powered hardware or even recycled hardware so that prospective SNOs wouldn’t need to invest in expensive mining equipment to join the network. We created the concept of held amount so that SNOs wouldn’t need to pay an up-front stake to start sharing space on the network. After we reduced our prices in April of 2021 to make the service even more competitive with other cloud object storage providers, we left the SNO compensation rates the same.

From the early days of Storj, we’ve been committed to making sure that running a storage node was economically rewarding. Our target has been to share 60% of any revenue we generate with the network. We have a number of other incentives including surge payouts and L2 payout bonuses. Currently as you point out, we pay much more than 60% and it’s fair to ask whether that is sustainable.

We’ve tried to build a good relationship with node operators as adoption of the service ramps up. We’re seeing increasing adoption in a range of use cases, many of them high-bandwidth use cases. As we get more traction and the service grows, we will make changes to the incentive structure as the needs change.

Right now, we’re happy to continue to pay those extra incentives because at this stage of the network, we need to grow demand. We are focused on growing customers and revenue much more than unit economics at this point. As we grow, we can make adjustments, but we’re happy to pay a little extra to keep our long-term node operators happy because that translates directly into a great customer experience for customers trying decentralized storage for the first time.

What does this mean for the future? We are currently optimized for easy-onboarding with a low cost of entry. Right now we are seeing more traction in great, high-bandwidth use cases and slow but steady growth of capacity. As we onboard larger, multi-PB customers, we’ll need to grow the network, but we need to grow intelligently.

If the network grows too quickly and we have too much supply with insufficient customer demand, we run the risk that the profitability of nodes may be insufficient to retain operators, causing churn in the network. Too much churn clogs the network with repair traffic, reducing performance and if catastrophic, potentially impacting durability. Overall, we need to be able to reward steady state operation, incentivize growth when additional capacity is needed and to moderate growth if we start to see too much supply.

We are currently putting together a plan for future capacity management, proposed changes to the incentive structure as well as evaluating a shift from held amount to a staking mechanism. Consistent with what we have done in the past, we will be soliciting feedback from the node community before implementing any significant changes.

We’re very happy to have a strong relationship with our node operators and won’t do anything to jeopardize what we’ve built together. Stay tuned for more details throughout the rest of this year. We’ll be increasing communications around potential changes as things become more concrete.

19 Likes

Thanks @john for that extensive response!

I want to caution against this course of action though.

Simply put, had this been in place back when I joined, I would not have been here. Putting money at stake before you have even had the chance to test the waters has just never been a thing I found acceptable. Furthermore, this may also impact the cost of running multiple nodes on multiple HDD’s if the staking amounts add up, but the traffic you get does not (due to IP filtering).

Instead, I suggest a rework of the held amount system so that it holds back enough to cover repair. So instead of building it once while the node is small, just keep it leveled based on the amount of data stored. I’ve posted suggestions for something like this before. I understand that the current system doesn’t do enough to cover repair costs, but requiring money up front is the wrong way to go in my opinion.

2 Likes

I agree, requiring money up front has the vibes of unfairness. Who’s to say that the node won’t be just disqualified for some imaginary reason to keep the money? I don’t think Storj would do that, but a new user might, especially if he hits one of the inconsistencies between recommendations and requirements. Disqualifying the node and keeping the held amount (current system) does not feel as unfair, at least I did not put my money into it, because the most that Storj can get is some free service.

Or, I guess there could be node classes - current system and “reliable nodes”, ones that get more traffic, but need to pay up front. But Storj has stated multiple times that they do not want datacenters to participate…

2 Likes

Any kind of class system that impacts distribution would also impact decentralization. I think that’s counterproductive.

It would be nice to have some incentive system for long term reliable nodes though. Lets say repair costs $10 per TB (fictional number just for this example). You could require new nodes to build up a held amount up to $15 per TB and reduce that by $2.50 every year until they are at $5 per TB. For the first 2 years, the held amount would work as a stronger incentive to remain stable than actually needed. And after 3 years the node has proven its reliability enough that Storj can take a bit of a risk on those nodes. By that time there is usually plenty data collected for a lower held amount to be significant enough to do a graceful exit.

1 Like

I mentioned it just to say under which circumstances I would find the up front payment acceptable.

With higher held amount I would start expecting some way to have backups of the node or some way to repair it. Losing a 3 year old node would sting a lot anyway, add to that $100 or more in held amount.

AFAIK, as it is right now, there are multiple ways to get the node disqualified in a few hours, while still having all of the data intact.

2 Likes