Pinned Tweet
Q3 2026: A quarter of steady infrastructure.
StorX Network continued to grow with:
🔹 2,000+ independent node operators
🔹 5+ PB of stored data
🔹 117,000+ users
🔹 70+ integrations
🔹 Continuous node payouts since 2021
This quarter we looked at how the network works, where it stands today, and what we’re building next.
Read the full Q3 Newsletter 👇
🔗 medium.com/storx-network/5d3…
#StorX #DePIN #DecentralizedStorage
Hosting rewards on the network reduce on a schedule. Operators who joined in 2021 earned more per terabyte than operators joining now, and operators joining next year will earn less than operators joining today.
This is deliberate. A reward that never decreases requires either infinite token supply or infinite demand growth, and neither of those exists. Declining issuance is what makes a payout schedule survivable across a decade rather than a cycle.
If you are modelling node returns, model the decline. Anyone showing you a flat projection is showing you a chart, not a plan.
#SRX #DePIN
The advice that keeps surfacing from teams who have actually done this: keep hot, active data on centralised infrastructure where latency matters, and move cold data — backups, archives, media, historical datasets — to a distributed network where cost matters.
That is not a compromise position we have been backed into. It is the correct architecture. Most of what an organisation stores is cold, and cold data is where a pricing difference compounds.
We would rather hold a large share of the workload we are right for than a small share of everything.
The most common criticism of decentralised storage is latency, and the criticism is correct. Reaching multiple independent nodes and reconstructing a file takes longer than reading from a single nearby data centre. Milliseconds against seconds, depending on conditions.
For a database backing a live application, that is disqualifying. For backup, archive, media libraries and datasets, it is not — those workloads were never latency-sensitive to begin with.
The honest position is not that the criticism is wrong. It is that it applies to a category of workload we are not asking for.
Node check-in.
Backup traffic has a shape. It arrives in windows — overnight, weekends — and the network sees roughly the same pattern every week.
Operators experience it as bursts of write activity followed by quiet. Nothing to manage. It is simply what a network serving business backup looks like from the inside.
Our Google Drive backup and restore integration went through Google's verification process. Worth being precise about what that means: the integration meets Google's requirements for accessing Workspace data on a customer's behalf.
It does not mean Google endorses decentralised storage. It means the connector was reviewed and does what it says it does.
Small distinction, but the kind worth making. Inflating a verification into an endorsement is how trust gets spent.
#SRX #StorX #googledrive #googleworkspace #backup
Most storage pilots fail on the wrong evidence. A team uploads a few gigabytes, downloads them, confirms it works, and then cannot answer the question their director actually asks: what happens at month eighteen, at real volume, when somebody needs a file back in a hurry.
A pilot that answers the first question takes an afternoon. A pilot that answers the second one runs a real workload, at real size, for long enough to see a bad week.
We would rather you run the second kind, even though it is slower to a decision.
#SRX #DePIN
Enterprises do not adopt storage protocols. They adopt backup software, and the storage ends up wherever that software is pointed.
Which is why the integrations that matter are the ones inside tools teams already run — Acronis, Veeam, ICONIK, Workspace backup. The decision stops being "should we move to decentralised storage" and becomes "which target do we select."
A protocol nobody's tooling supports is a research project. The integration work is the adoption work.
#SRX #DePIN #BuiltonXDC
Node check-in.
Retrieval volume was up this week, mostly larger objects. A handful of nodes on slower connections dropped out of the fastest reconstruction sets. Files still assembled.
That is how the selection is meant to work. Slower nodes are not penalised for existing. They are just not the ones the client reaches first.
Writing to a distributed network is straightforward. Reading is where the architecture actually gets tested, because the client has to reach enough independent nodes, fast enough, to reconstruct the file.
For archival, backup and dataset retrieval, seconds are fine and the economics are clearly better. For workloads that need consistent sub-50ms reads, they are not, and we would rather say that now than have you discover it during a pilot.
The right test is your workload against our endpoint. Not our number against someone else's.
If your compute and your storage come from the same provider, you get convenience and you get a single dependency. Migrating later means moving both at once, which is a large part of why most teams never do.
Separating them costs something up front — two vendors, two bills, two sets of credentials. What it buys is the ability to change one without changing the other.
Whether that is worth paying for depends entirely on how likely you think it is that you will ever want to change either one.
GPU marketplaces and inference providers need somewhere to stage datasets and park model artifacts that is not the same vendor running the compute. Coupling the two means one procurement decision governs both.
Our S3-compatible endpoint means a pipeline that already writes checkpoints to object storage can write them to us instead by changing a URL and a set of credentials. No rewrite, no new SDK. That is the whole integration.
Training a model is a compute story. Almost everything around it is a storage story. Datasets have to be staged before the run and kept afterwards for reproducibility. Checkpoints are written throughout. Outputs, evaluations and logs accumulate for as long as anyone might need to audit what the model did.
Most of that data is written once and read rarely, but it cannot be deleted. That is the workload profile distributed storage is genuinely suited to — large, durable, infrequently accessed, and expensive to hold anywhere else.
#SRX #DEPIN
Hourly onchain proofs are the right instinct. Storage you can verify beats storage you have to trust.
The next question is who the providers are and where they sit. Verification gets stronger when the network is also independent and spread out.
That's the thinking behind #StorX: 2,000+ nodes across 50+ countries on #XDC.
On Filecoin Warm Storage Service, storage providers must prove once an hour that your data is there.
The proofs are checked onchain and take seconds to generate. Storing a copy costs $2.50 per TiB per month, and two copies are the minimum.
filecoin.cloud/warm-storage-…
Node check-in.
A few operators mentioned drive prices this week. Some are holding off on expansion until the market settles. Others are running what they already have and adding nothing new.
Capacity growth is slower than it was in spring. Availability is unaffected. The drives already in the network do not care what new ones cost.
The pitch for distributed storage is usually some version of "we use the world's spare hard drive space," as though that space costs nothing. It does not. The operator paid for the drive, pays for the power, and pays for the bandwidth.
What is actually true is narrower. The marginal cost of the next terabyte on a drive that is already spinning is lower than the marginal cost of the next terabyte in a facility that does not exist yet. That is the real economic argument.
We would rather make the narrower claim, because the narrower claim holds.
There are two ways to add storage capacity to a network. You can buy drives, build or lease a facility, provision power and cooling, and wait for the hardware to arrive. Or you can accept capacity from operators who already have drives running.
The first is slower than usual right now because of the supply queue. The second is limited by a different constraint — how many operators you can attract, and how reliably they stay online.
Neither model is free of constraints. They are just different constraints, and they do not tighten at the same time.
Enterprise SSD contract prices rose more than 25% quarter over quarter in Q1 2026. Nearline hard drives — the ones that hold most of the world's cold data — are in shortage at the same time.
If you run a data centre, that input cost eventually reaches your price list. Not immediately; long-term contracts and hedges absorb the first wave. But storage prices follow hardware prices with a lag, and the lag is not infinite.
We are not predicting what anyone will charge. We are pointing at the input cost and letting you draw the line forward yourself.
Western Digital and Seagate have both told investors that their hard drive production for 2026 is effectively sold out. Cloud providers booked the capacity in advance, with some commitments extending past 2027.
When manufacturing output is pre-allocated to a handful of buyers, everyone else pays the spot price for whatever is left. That is not a conspiracy. It is an allocation queue.
A distributed network does not stand in that queue the same way. Capacity joins when operators bring hardware that already exists — drives already bought, already spinning, already paid for.
#DePIN #SRX
Simon's right that the data is where the value is. The next layer down:
Every one of those data pools is stored somewhere. Most of it probably sits in data centers owned by the same companies bidding for it.
Data you want to sell shouldn't live with the buyer.
That's what StorX runs on: 2,000+ independent nodes in 90+ countries. #DePINUnion
Unpopular opinion:
Former DePINs might be some of the most undervalued AI plays right now.
Yes, DePIN had a lot of issues, and hence a very underwhelming token performance. The negative association is definitely understandable.
But what most people don't realize is that thanks to those token incentives, most of these projects are now sitting on incredible data pools. Exactly the kind of data pools the biggest frontier AI labs have insatiable demand for, since data is their single biggest bottleneck in winning the most important tech race humanity has ever seen.
Just to name a few:
@silencioNetwork - $SLC
@OVRtheReality - $OVR
@NATIXNetwork - $NATIX
@grass - $GRASS
And probably a bunch of exciting ones I don't even have on my radar yet (if so, please DM).
I know in fact that these are already working with leading AI labs or well-known big tech companies as actual paying clients, generating serious offchain revenue. More than most of your favorite shitcoins do. And if you do your research, you'll understand that it takes time for that offchain revenue to accrue, but there's strong commitment to route it back to their tokens.
I know it's hard, but instead of chasing memecoins or bidding the same 5 hyped onchain businesses everyone already knows, I can only strongly recommend digging deeper here.
Generational opportunities to be found in DePIN, or whatever you might want to call it nowadays.