The ultimate solution for the storage track? The past and present of data cloud storage.

Author: Ray Source: X, @RayAC1397

Abstract: Starting from the predecessor of the cloud storage track, this analysis examines the changes in the entire track and its history, followed by an analysis of the issues with Filcoin and Arweave, and finally, an examination of Irys's business model and a prediction of its valuation after the Irys TGE. Irys's FDV below 300 million is considered undervalued. As for whether it can maintain its leading position in the cloud track in the long term, attention needs to be paid to the alignment between business and tokenomics, as well as whether the core use cases can be successfully implemented.

Keywords: Cloud Storage Track Analysis, Filcoin Business Model Analysis, Arweave Business Model Analysis, Irys Project Introduction, Valuation Forecast, Irys Strategic Analysis

Text:

Chapter 1: The Evolution from Stone Walls to Cloud

In the distant Mesopotamian civilization, humanity first had the idea of storing information: our ancestors cleverly engraved information on "durable" stone tablets; during the Industrial Revolution, music, as a form of information, was stored on records; and in the computer age, people invented a series of information storage hardware such as tapes, hard disks, and CDs...

The way data is stored has always been a reflection of the progress of the times.

In 1956, IBM launched the Model 350, a machine as large as two refrigerators side by side, weighing nearly a ton, yet capable of storing only 5MB of data. People needed a crane to lift it into the machine room. Despite its extreme bulkiness, it was the first time "electronic storage" became a resource that businesses could pay for. This breakthrough changed the fate of information: it was no longer completely dependent on fragile paper that was difficult to maintain, but could exist on durable electromagnetic materials. In the following decades, hard drive manufacturers engaged in a silent war. Companies like SeaGate, Western Digital, and Hitachi continually improved the storage density of disks, allowing more and more magnetic particles to be arranged on each square inch of disk. Each technological iteration meant doubled capacity and decreased prices. By the 1990s, the popularity of personal computers and the rise of the internet made these hard drive manufacturers the cornerstone of the entire industry. In that era, storage was considered "raw material," and there was only one core market standard: whose storage solution was efficient, that is, cheap and good. However, as the scale of data storage began to grow exponentially, the primary demand of enterprises shifted to "how to ensure the stability and security of data." The operations of banks, airlines, and manufacturing companies relied on data, where even small mistakes could lead to huge losses. Thus, enterprise storage providers like EMC and NetApp emerged, selling a complete set of storage arrays and accompanying software. At this point, the business logic of the cloud storage track shifted from one-time services to long-term partnerships, with enterprise clients signing long-term service and guarantee contracts with service providers. For the first time, storage was classified as "business assets."

As the time approached the early 21st century, the internet and mobile waves began to facilitate the cross-border flow of data. Traditional enterprise storage solutions appeared cumbersome and expensive in the face of globalization demands. In 2006, Amazon launched the S3 service, abstracting storage into a simple API: developers no longer needed to procure data centers and disks; with just a few lines of code, they could write files to the cloud at any time. This "pay-as-you-go" model fundamentally changed developers' habits and allowed startups to access infrastructure comparable to that of large companies for the first time. The value of cloud storage lies not in its low cost, but in its flexibility and ecosystem. It transformed storage from a device into an "always-online service." Soon, Dropbox and Google Drive brought this experience to consumers. Users no longer needed to care about which computer their files were on; as long as they had internet access, they could seamlessly switch between their phones, tablets, and laptops at any time. The concept of storage was once again altered: data was no longer stored on physical devices, but belonged to humanity's own "cyberspace." From IBM's drum memory to EMC's storage arrays, and then to AWS S3's object storage, the evolution of data storage repeatedly confirmed a rule: each new leader's coronation occurred because it created, or rather satisfied, a new data usage demand. The first generation of hard drives solved the capacity issue, enterprise storage solutions met the need for "stability and security," while cloud storage aimed at the pain points of "flexibility and scalability." However, behind these histories, one characteristic has always remained unchanged: data ownership has been excessively concentrated in the hands of cloud vendors. In today's world where data is being assetized, this is clearly unacceptable.

At this point, Web3 begins to enter the game.

Chapter 2: Filecoin Miner Logic and the Idealism of Arweave

In the Web2 system, data ownership and control are highly centralized. Whether it is Facebook's social relationships or Amazon's transaction data, they are essentially controlled by the companies. Users may be "using" the services, but they never truly "own" anything. Companies ruthlessly profit from data, but users can only play the role of powerless lambs: when a personal account is banned, their data disappears along with it; when companies take down content due to compliance or political pressure, that information vanishes from the public space immediately.

As a result, the call for decentralized storage emerged. In 2015, the IPFS project proposed a new idea: to find files using "content hashes." This means that any node that stores the file can respond to requests, solving the problem of "single point storage risk." However, people soon realized that having technology alone was not enough; without economic incentives, nodes would not be willing to store data long-term. Thus, Filecoin was born, adding Tokenomics to IPFS: miners provide storage space to earn $FIL, and the Filecoin protocol uses complex space-time proof algorithms to verify whether the data has been genuinely stored. From a design perspective, its fundamental proposition is "to turn storage into an open market," which indeed works on the supply side: as long as there are token rewards, a large number of miners can be organized to participate in ecological activities. However, what they did not consider is that the market has not only supply but also demand. At this point, a large number of free riders appeared. The incentives of Filecoin mainly focus on "providing capacity and timely proof," and miners are naturally more concerned about economic benefits rather than how to serve users. Thus, a large number of free riders emerged. You will see a structural scissors difference: the supply side is extremely active, while the demand side does not grow in sync. This scissors difference quickly transmits to the product level. A team that requires stable read and write will first ask three questions when evaluating Filecoin: what to prepare before writing, what the uncertainty range of retrieval delay is, and who to hold accountable if something goes wrong. On the other hand, in terms of writing, real business data often comes with continuous updates, while Filecoin's semantics naturally lean towards "fixed-length, periodic, and renewal" cold storage, requiring developers to build additional indexing, version mapping, and renewal strategies. When it comes to retrieval, another problem arises: if one decides to create their own CDN and caching, the marginal benefits of using Filecoin will be infinitely reduced; if relying on third-party gateways or service providers, the service relationship becomes "semi-centralized," and the responsible party will question why not directly go to the cloud. The final link is the boundary of responsibility: on-chain proof cannot directly account for product experience. For enterprise customers, even a mere 1% uncertainty is enough to exclude Filecoin from critical links. The path dependency brought about by incentive design is also reflected in the payers. In an ideal open market, payers should be the users. However, when the early real demand is insufficient, the ecosystem has to rely on incentives to stimulate demand (for example, offering more favorable on-chain conditions for certain datasets). This can temporarily boost transaction volume, but it is hard to prove that there is indeed "spontaneous, willing to pay continuously" demand. Over time, the financial model on the supply side operates around "block subsidies, collateral, and confiscation," while the willingness to pay on the demand side fluctuates around "whether there are subsidies and quotas," and the two systems have not truly coupled together. This is also why in many successful cases, you will see news about "big data on-chain," but rarely see a closed-loop narrative of "high-frequency retrieval, continuous reuse, and upper-layer product profitability."

Almost simultaneously, Arweave proposed another solution: users pay a one-time storage fee, and the network promises long-term preservation. Founder Sam Williams drew inspiration from history and sociology: if the past can be erased, then social memory will no longer be reliable. The value of this approach is self-evident: once certain values are altered or deleted, social trust will be eroded.

Arweave monetizes "future storage" through a one-time payment, with the network continuously replicating and preserving data over a long period, which is its most appealing aspect. However, when placed in the context of products and business, another set of questions arises. The first is the tension between "permanence" and "iteration." The vast majority of applications are not written once and never updated; instead, they are constantly revised, rolled back, and A/B tested. The correct use of Arweave is to treat each change as new content written in and indexed to point to the latest version. Technically feasible and not complex in engineering, the challenge lies in application design: users want to see the latest version, not spend time understanding an immutable time chain. The second issue is the ethical problems arising from permanent storage. An open network inevitably hosts gray and illegal content; the Arweave protocol cannot delete it but relies on the self-regulation and filtering of gateways, front ends, and indexing layers, which puts developers in a dilemma regarding "responsibility attribution": if you take on filtering work, you become the responsible party; if you do not, you risk losing customers. The third issue is the idealization of the economic system. Arweave's promise relies on two simple long-term assumptions: that the unit cost of storage continues to decline and that the network maintains replication strength over a sufficiently long period. While these assumptions are likely to hold true at a macro level, for a single product manager, the immediate cash flow pressure is challenging to resolve, as it entails a large one-time write fee, and even calculating interest can be daunting. Over time, Arweave's business has been confined to a very small niche market, and its valuation has struggled to achieve a breakthrough.

Chapter 3: AI and Cloud Storage, Data is Dancing

After Filecoin and Arweave opened the door to Web3 cloud storage, the cloud storage track was neglected for a long time. During this gap, Irys emerged. The core question it raises is: why can't data move by itself? Since the moment data is written to storage is essentially an "event", why can't this event immediately trigger logic? If the network itself can bear the execution environment, then data is no longer just dormant files, but units that can drive applications. The design basis of Irys is precisely this. It no longer focuses on updates around Filecoin's "mining logic" and Arweave's "permanent storage", but instead combines storage with computation, proposing the concept of "programmable data chains". Writing data immediately triggers it, with the data carrying logic entering the network and being directly executed by Irys's execution environment (IrysVM). For developers, this means shifting from a "two-step" operation to a "one-step" operation—writing is calling.

As mentioned earlier, every evolution of storage in the past half century has been driven by the creation of new demands. Therefore, I believe that Irys's forward-looking nature is particularly important in the AI era. AI models require large amounts of data, and they need trustworthy sources and verifiable execution. Traditional storage locks data in cold warehouses and then hands it over to off-chain logic for processing, which is not only cumbersome but also leaves gaps in trustworthiness. The envisioned data form of Irys is self-driven data: they can automatically "feed models," come with billing and permission rules, and can collaborate across organizations without needing to rely on third-party custodians.

On the other hand, the powerful aspect of Irys is that it integrates storage, execution, and verification into the same underlying protocol. This means that data written by different protocols can be directly read and reused by each other, even driving more complex application logic. As the number of nodes increases, the overall value of the network will naturally grow, as the discoverability and composability of data continue to enhance. To understand this, one can think of Ethereum. When it introduced smart contracts, many people did not understand how this was different from regular on-chain transfers, until financial applications such as Uniswap, Aave, and Compound emerged, and people realized that smart contracts are the seeds of infinite narratives. Irys is actually doing something similar, only the subject has shifted from "finance" to "data." Although data is too abstract and not as intuitive as money, once the ecosystem accumulates, developers will find that they can continue to build directly on others' data outputs without having to rely on external oracles or redundant collection. This narrative is actually quite similar to the path AWS took back in the day. AWS did not win solely through "cheap storage," but rather by locking developers completely into its ecosystem through a whole suite of SDKs, consoles, and APIs. Once you use one or two services within AWS, you will quickly be attracted by the convenience of the entire AWS system. If Irys executes its collaboration correctly, for example, if "high-quality data" can only be accessed when written to Irys, it will also form a similar value lock. At that time, the data on Irys will not just be assets of a certain protocol, but the fuel of the entire ecosystem, and this positive cycle will ultimately feed back into the data network itself and the value of the tokens.

Chapter 4: Valuation and Market of Irys

It is important to understand that while ideals are good, reality is often harsh. Having a forward-looking project does not guarantee success. The first challenge Irys faces is cold start. Without real demand, meaning enough applications willing to consume this "programmable data," it will degenerate into another cheap storage solution. The second challenge is compatibility. Developers have deeply relied on interfaces like EVM, IPFS, AWS, and any new paradigm will increase the learning costs. For Irys to open up the situation, it must achieve a sufficiently smooth "zero-threshold usage." The third challenge is governance. Once data can trigger logic, it brings new attack surfaces: fraudulent data for insurance scams, malicious triggering consuming resources, copyright and privacy disputes. Centralized clouds rely on laws and permissions to resolve issues, while decentralized protocols must provide answers in terms of mechanisms and governance; otherwise, it will be difficult to gain institutional adoption. Therefore, whether Irys is a deity or a demon can only be judged after it goes live on the mainnet. Let’s look forward to whether it can, like AWS back in the day, make the abstraction elegant enough and run the template scenarios beautifully enough to encourage developers to replace their existing assembly solutions with it. From a historical perspective, this is the key point of whether all infrastructures can overthrow the old giants and become the "next generation leaders."

If it were me, I would focus on the following three paths:

1. The first application scenario. All infrastructure in history has iconic application scenarios to prove its value. S3 relies on Flickr and Dropbox; Snowflake relies on real-time analysis scenarios in finance and retail.

Similarly, Irys must deliver one or two killer scenarios, such as a real-time incentive system for health data or an automatic settlement mechanism for DePIN devices.

2. Lower the migration threshold. Developer habits are the hardest to change. Why has EVM become a de facto standard? Because it allows people to reuse old tools and languages in a new environment. Irys should avoid "re-educating the market" and instead maximize compatibility with existing habits in terms of interfaces, SDKs, and development experience.

3. Establish governance tools or ecological rules. Once data can trigger logic, it will inevitably lead to attacks and disputes: false data to obtain rewards, malicious triggering consuming resources, and the gray area of copyright ownership. If Irys can provide tools at the mechanism level for "verifying data sources", "limiting malicious triggers", and "embedding copyright and privacy logic", it can gain trust in both ToB and ToG scenarios. The intensity of the cloud competition should not be underestimated. Cloud vendors are still behemoths, assembling solutions remains flexible and cheap, and off-chain proof models are even less costly. However, history has repeatedly proven that true breakthroughs do not emerge from fighting within the old framework, but rather when a new habit is created and becomes the standard, the framework is reshaped. Irys needs to solve this core issue to become the industry leader.

In terms of valuation, as of the time I am writing this, the circulating market capitalization of $FIL is 2 billion, with an FDV of 4.7 billion; the circulating market capitalization of $AR is 400 million, almost fully circulated. At the same time, the circulating market capitalization of $Prove, the ZK rolldown infrastructure Succinct launched on BN, is 200 million, with an FDV of 1.1 billion. Considering that Irys has two major concepts of AI + cloud storage, although the market is currently booming with AI concepts, due to the significant uncertainties in the macro environment, it is difficult for the market to give a premium.

I believe the valuation after IrysTGE is as follows:

1. Low Open: 300 million – 500 million FDV;

2. Normal: 800 million – 1.2 billion FDV

Considering the author's low risk tolerance:

1. If the business progresses smoothly and can form a flywheel closed loop with Tokenomics, and the valuation level is below 300 million FDV, I will buy directly. If FDV reaches around 500 million, I will buy with a small position; if it exceeds 500 million, I will remain cautious.

2. If the business progresses poorly, or if the tokenomics cannot align with the business, I will remain observant and shift the weighting of my trend judgments from fundamentals to technicals.