Testnet started with a broad question: can decentralised storage be performant and cost-effective enough for hot data?
The original Shelby architecture explored that question in an open, decentralised environment. The model was deliberately ambitious: prove that distributed participation did not have to mean cold storage, slow retrieval or economics that only worked for archival data.
As more teams engaged with Shelby, the shape of demand became clearer. The strongest pull came from AI and other compute-intensive workloads. For those teams, storing data cheaply and retrieving it quickly was only the starting point. They needed that data to support changing compute environments, with predictable performance, clear placement controls and an operating model that made economic sense.
The lesson from Testnet was not that decentralisation was unnecessary. It was that decentralisation could not be the first constraint.
For the workloads we were increasingly seeing, performance had to be predictable. Data placement had to be controlled. Customers needed clarity around where their data lived and who could access it. The economics also had to work for the teams actually running the workloads, not only at the protocol level.
Distribution still mattered, but it had to serve the workload rather than define it.
Testnet gave us a clearer order of operations. Rather than expand the network first and learn customer requirements later, Private Beta starts with the workload.
The amount and shape of distribution should follow the workload. Private Beta lets us understand where broader distribution adds value before expanding the network model around assumptions.
Private Beta starts with the workload.
The core platform is ready for that next stage. The question now is how Shelby should evolve around real customer requirements.
A smaller number of customers are being onboarded deliberately, each bringing a different data path, compute environment and operating model. That gives us a way to understand the constraints that are difficult to reproduce in a public test environment: what performance actually matters, where data needs to sit, how compute locations change and what teams need in order to trust the system.
AI is rapidly expanding what teams need from the data layer. GPU infrastructure is changing quickly, agent interactions are creating new access patterns, and workloads increasingly cross environments. Rather than design the next layer around assumptions, we want customer workloads to shape it.
The longer-term question around decentralisation has not disappeared. It has become more precise: where does distribution add value, and under what conditions can it be introduced without compromising performance, control or economics?