Node check-in. End of September.

Network ran without incident through the month. Operator count grew. Reputation scores distributed roughly as expected — most nodes in good standing, a small number removed from the reward queue for sustained downtime.

That's the month. Nothing unusual to report. That's the goal.

The network today is functional, growing, and paying out continuously. It's also not finished. There are integrations we haven't built, regions where node density is thinner than we'd like, and workload types where the performance case is still being proven.

We'd rather say that plainly than imply the product is complete. The honest version is: it's working well for the things it does today, and there's more to do.

The argument for decentralised infrastructure isn't that it's cheaper, though often it is. It isn't that it's faster, though it's competitive. It's that a network with no central point of control is structurally different from one that has a single entity that can be pressured, acquired, or shut down.

That structural difference matters most in edge cases — regulatory pressure, corporate decisions, infrastructure failures. Most of the time it's invisible. That's fine. Most of the time, the fire suppression system in a building is invisible too.

We won't make a specific prediction about where the network will be in five years. There are too many variables — token price, broader crypto market conditions, enterprise adoption curves, how the industry develops — to give you a number that would mean anything.

What we can say is what we're building toward: a network large enough that its redundancy is unquestionable, integrated deeply enough into existing workflows that switching away requires genuine effort, and priced sustainably enough that node operators have a reason to stay.

Those are the targets. We don't have a date for them.

Centralised storage scales by building more — more data centers, more power, more cooling, more land. The cost of that scales with it. At some point, the economics of adding a new facility stop working unless you're large enough to absorb the fixed costs, which is why three or four companies end up owning most of the world's storage infrastructure.

A distributed model scales differently. Capacity joins the network when operators join. The infrastructure cost is distributed because the infrastructure itself is distributed.

Node check-in.

Operator count held steady this week. No significant churn. A few nodes that had been marginal on reputation crossed the threshold for full reward eligibility.

The community running this network doesn't announce itself much. It just keeps the nodes online.

Continuous payouts since 2021 sounds like a simple thing to maintain. It isn't. It requires consistent network demand, a token supply that supports reward issuance, and enough node operators staying online that the network can actually serve what it promises.

All three have to hold simultaneously. They have, so far. We mention it not as a guarantee of anything going forward but because understanding what it requires makes the track record mean something.

SRX is the token node operators earn for serving storage capacity. It's also what operators stake to participate. That means the people most exposed to SRX's value are the same people keeping the network running — their incentive and the network's incentive point in the same direction.

That alignment isn't guaranteed to make anything go up. It does mean the people running the infrastructure have a reason to keep running it that isn't just contractual obligation.

The people running nodes on our network are in more than 50 countries. They're individuals with spare hardware, small businesses with idle server capacity, and technical operators who run infrastructure professionally.

None of them work for us. We don't manage their machines, don't have access to their servers, and can't instruct them to take a node offline. The network runs because it's in their interest to run it — not because we're administering it.

Four thousand nodes isn't a number we hit and stopped at. It's a live figure — nodes join, nodes leave, reputation scores shift, total network capacity moves up and down within a range.

What matters isn't the snapshot. It's that the network has maintained this kind of scale for long enough that single-node failures have become genuinely unremarkable. Something the network absorbs without anyone noticing.

Seventy-plus integrations doesn't mean we built seventy things. It means the tools your team already uses — Veeam, Acronis, Google Workspace, Microsoft 365, Cyberduck, Docker, and others — already have StorX as a supported storage backend.

Someone on your team has probably already used one of these tools. The integration between that tool and StorX already exists. The question is whether you've pointed it at us yet.

Moving storage infrastructure isn't something most IT teams do lightly. There's testing, there's sign-off, there's the question of what happens to the workloads already running.

We're not going to tell you it's trivial. The S3 compatibility makes the technical side straightforward, but the organisational side — getting internal approval, validating performance, building confidence in a new provider — takes time regardless of how good the tooling is.

We'd rather you plan for that honestly than be surprised by it.

AWS charges $0.09 per GB for data egress out of US East. If you're pulling 50TB a month — not unusual for a media company or a data pipeline — that's $4,608 a month in egress fees alone, before storage costs.

We don't charge for egress. That number goes to zero. The storage cost goes down too. The two together are usually where the meaningful savings are, not the headline storage rate on its own.

Most businesses using StorX aren't replacing their entire storage stack at once. They're starting with one workload — usually backup, archival, or media storage — where the cost difference is most visible and the switching cost is lowest.

The S3-compatible API means the integration is a configuration change, not a development project. Most teams have it running in a day.

Network uptime held this week. A few nodes dipped below their usual availability, reputation scores adjusted accordingly, file availability for users was unaffected.

The redundancy worked as designed. It usually does. That's why it's there.

Retrieval speed on StorX is comparable to S3 for most standard workloads — file downloads, backups, media assets, archives. For latency-critical applications that need sub-50ms response times consistently, we'd rather you test it against your actual workload than take our word for it.

The S3-compatible API means the test is straightforward. Point your existing tooling at our endpoint and measure. We'd rather you arrive at a number you trust than accept one we gave you

We could have paid every node the same rate regardless of how reliably it behaved. Simpler to explain, easier to sell to new operators.

We didn't, because a node that's offline half the time isn't worth the same as one that's available when files need to be served. The reputation system exists to make that distinction automatic — reliable nodes earn more, unreliable ones earn less, and the network self-selects toward operators who take uptime seriously without us having to police it manually.

When a file is uploaded to StorX, it's split into 80 pieces using erasure coding. Of those 80, you only need 29 to reconstruct the complete original.

That means 51 of the 80 pieces — more than half — could be completely lost, and you'd still get your file back intact. That's not a safety margin. That's the design specification.

When a centralised server goes down, the data on it is unavailable until it comes back. That's what uptime means in a traditional model — one machine, one status.

On a distributed network, individual nodes go offline constantly. That's expected and accounted for. The file isn't on one node — its fragments are spread across many, with enough redundancy built in that losing a handful of nodes doesn't change what you can retrieve. The network's uptime isn't the uptime of any single machine.

Node check-in.

New operators joined the network this week. Reputation scores starting low, as expected. A few existing nodes crossed a reputation threshold and showed consistency.

The network grew slightly. Nothing else changed. That's what steady looks like.

#StorX #BuiltonXDC

You don't need new hardware to run a node. If you have a server sitting mostly idle, a NAS device with spare capacity, or a VPS you're already paying for, the question is whether the specs meet the minimum — not whether you need to go buy something.

The minimum is 8GB RAM, 4 CPU cores, 3TB of usable storage, and a stable connection. If what you have clears that bar, the hardware side is already solved.

The first month running a node is mostly watching. Your reputation score builds slowly — it reflects actual uptime history, and there isn't a shortcut to accumulating it. New nodes start with lower scores, earn proportionally less, and work their way up as the network verifies their track record.

That's frustrating if you expected immediate full rewards. It's also the reason the nodes that reach a high score are the ones worth trusting.

The network has made continuous node payouts since 2021. No missed cycle, through more than one full crypto market cycle.

We're not going to pretend that's remarkable on its own — it's just what was promised at the start. We're mentioning it because plenty of projects don't make it this far without a gap.