<100 subscribers

From the Myth of Prometheus to the Blockchain
“Prometheus gave fire to humanity. What did humanity give itself when it created the blockchain?”

How to apply The Intelligent Investor strategy to crypto
Benjamin Graham’s investment strategy can absolutely be applied to crypto, if approached with discipline and analytical thinking. Projects that demonstrate real utility, intrinsic value, and a margin of safety can offer significant long-term upside.

It’s not just a bull run, it’s the opening act of a world that’s changing
You forget that last time you promised yourself, “If the market comes back, this time I’ll be smarter.” Well, this is that time.

From the Myth of Prometheus to the Blockchain
“Prometheus gave fire to humanity. What did humanity give itself when it created the blockchain?”

How to apply The Intelligent Investor strategy to crypto
Benjamin Graham’s investment strategy can absolutely be applied to crypto, if approached with discipline and analytical thinking. Projects that demonstrate real utility, intrinsic value, and a margin of safety can offer significant long-term upside.

It’s not just a bull run, it’s the opening act of a world that’s changing
You forget that last time you promised yourself, “If the market comes back, this time I’ll be smarter.” Well, this is that time.
Share Dialog
Share Dialog


Sometimes it takes a shock to reveal the truth behind the slogans. On Monday, October 20, 2025, a sudden AWS outage was enough to plunge half of the planet’s daily digital life into darkness. Applications stopped responding, users could not log in, companies froze, and in an instant the Web felt fragile. Yet the real shock was not the collapse of Web2 infrastructure, but the fact that parts of Web3 were pulled down with it. In a space that constantly speaks about resilience, decentralization and autonomy, a difficult question emerged. How can a supposedly unstoppable infrastructure be dragged down by the same centralization model it claims to replace?
The incident served as a mirror. It did not expose a weakness in blockchain as technology, but the gap between vision and execution. While the core of blockchain protocols is indeed resilient and decentralized, the majority of applications built on top of them still depend on centralized points of control. This hidden dependency surfaced in the most direct and undeniable way.
Blockchain, as an idea, was born to operate independently from centralized systems. However, when the applications that rely on it are built on a chain of centralized services, the end user does not actually experience decentralization. In this chain you find RPC providers, indexers, cloud servers and APIs acting as silent intermediaries. As long as these critical points remain concentrated in the hands of a few providers, a single failure can trigger a domino effect. This does not diminish the value of blockchain, but it clearly shows that the architecture the industry is building today is incomplete.
What happened is not proof of failure. It is proof that we are in a transitional stage. Web3 is still young, and like every technological revolution, it goes through phases where old and new structures coexist. The problem arises when we treat this hybrid stage as final. The truth is that we have not yet reached the destination, and acknowledging that reality is a sign of maturity, not weakness.
Most Web3 projects speak passionately about decentralization, freedom, resilience and new power structures. But behind the marketing, the picture is more revealing.
Many crypto apps still rely on:
Centralized cloud (AWS, Google Cloud, Azure)
Centralized RPC providers
Centralized APIs
Centralized sequencers
Centralized indexers and off-chain infrastructure
When one server went down, the illusion collapsed along with Web2. The idea that “everything is on-chain and therefore unbreakable” proved to be incomplete.
A blockchain network can continue functioning even while everything around it is failing, because it runs on independent nodes that share responsibility. However, most Web3 experiences do not interact directly with the protocol. They rely on layers of intermediaries. If those intermediaries are hosted on a single cloud environment, the resilience of the decentralized layer remains unused. Even many L2s that promise scalability and freedom depend on centralized sequencers. If those sequencers go offline, everything freezes until the server returns.
The lesson is not that Web3 is “broken,” but that Web3 requires more conscious architectural choices. It must be built so that a disruption in one layer does not paralyze the entire user experience. Critical functions must be decoupled from single points of failure so that resilience becomes real, not theoretical.

Every technology faces moments like this. Moments when convenient narratives collapse and only the core truth remains. Today’s Web3 has vision and ambition, but in many areas it still stands on Web2 foundations. This is not a reason for disappointment. It is a reminder that decentralization is not a checkbox. It is a continuous process of choice and design. If the community truly wants resilient networks, it must build architectures that do not depend on a single cloud provider or on a company that controls a critical server.
The positive side is that the direction already exists. Protocols are evolving, modular architectures are emerging, decentralized data layers are maturing and the technological base grows stronger year after year. The incident is a reminder that the goal has not yet been achieved, but it remains absolutely attainable.
The solution is not found in slogans, but in specific practices. A truly resilient Web3 requires distributed infrastructure, multiple execution layers that are not tied to a single provider, decentralized data storage, and an L1 that serves as the ultimate source of truth. With this approach, even if something breaks at one layer, the network and its users can continue to operate.
The technology already exists. What is missing is a mindset shift. We must not simply use blockchain, but integrate it in ways that honor its core philosophy. Moving from Web2 dependency to Web3 resilience is a multi-year effort, but it is a necessary step if we want digital systems that do not collapse every time a data center goes dark.
The solution is not to reject Web3, but to build it properly.
The future must include:
Layered architectures instead of monolithic stacks
L1 as the ultimate settlement layer
Modular execution layers without single points of control
Multi-cloud strategies instead of one-cloud dependence
Decentralized storage (IPFS, Arweave) instead of cloud buckets
On-chain identity, messaging and governance
The Web3 that survives will be the Web3 that stays online even when a server fails.
The AWS blackout was a message, not just an incident. Before we build the future, we must recognize the limits of the present, because Web3 has not failed. It is in the stage where it is letting go of its Web2 crutches and learning to stand on its own. The journey will have obstacles, but it is worth it, because the destination is an internet that is more open, more free and more resilient than anything we have seen so far.
The next step is to build with architecture and awareness, not assumptions. If we want a Web3 that does not fall when a server falls, we must design systems that respect decentralization in practice. The future is there, waiting for those who will build it with intention and consistency.
Sometimes it takes a shock to reveal the truth behind the slogans. On Monday, October 20, 2025, a sudden AWS outage was enough to plunge half of the planet’s daily digital life into darkness. Applications stopped responding, users could not log in, companies froze, and in an instant the Web felt fragile. Yet the real shock was not the collapse of Web2 infrastructure, but the fact that parts of Web3 were pulled down with it. In a space that constantly speaks about resilience, decentralization and autonomy, a difficult question emerged. How can a supposedly unstoppable infrastructure be dragged down by the same centralization model it claims to replace?
The incident served as a mirror. It did not expose a weakness in blockchain as technology, but the gap between vision and execution. While the core of blockchain protocols is indeed resilient and decentralized, the majority of applications built on top of them still depend on centralized points of control. This hidden dependency surfaced in the most direct and undeniable way.
Blockchain, as an idea, was born to operate independently from centralized systems. However, when the applications that rely on it are built on a chain of centralized services, the end user does not actually experience decentralization. In this chain you find RPC providers, indexers, cloud servers and APIs acting as silent intermediaries. As long as these critical points remain concentrated in the hands of a few providers, a single failure can trigger a domino effect. This does not diminish the value of blockchain, but it clearly shows that the architecture the industry is building today is incomplete.
What happened is not proof of failure. It is proof that we are in a transitional stage. Web3 is still young, and like every technological revolution, it goes through phases where old and new structures coexist. The problem arises when we treat this hybrid stage as final. The truth is that we have not yet reached the destination, and acknowledging that reality is a sign of maturity, not weakness.
Most Web3 projects speak passionately about decentralization, freedom, resilience and new power structures. But behind the marketing, the picture is more revealing.
Many crypto apps still rely on:
Centralized cloud (AWS, Google Cloud, Azure)
Centralized RPC providers
Centralized APIs
Centralized sequencers
Centralized indexers and off-chain infrastructure
When one server went down, the illusion collapsed along with Web2. The idea that “everything is on-chain and therefore unbreakable” proved to be incomplete.
A blockchain network can continue functioning even while everything around it is failing, because it runs on independent nodes that share responsibility. However, most Web3 experiences do not interact directly with the protocol. They rely on layers of intermediaries. If those intermediaries are hosted on a single cloud environment, the resilience of the decentralized layer remains unused. Even many L2s that promise scalability and freedom depend on centralized sequencers. If those sequencers go offline, everything freezes until the server returns.
The lesson is not that Web3 is “broken,” but that Web3 requires more conscious architectural choices. It must be built so that a disruption in one layer does not paralyze the entire user experience. Critical functions must be decoupled from single points of failure so that resilience becomes real, not theoretical.

Every technology faces moments like this. Moments when convenient narratives collapse and only the core truth remains. Today’s Web3 has vision and ambition, but in many areas it still stands on Web2 foundations. This is not a reason for disappointment. It is a reminder that decentralization is not a checkbox. It is a continuous process of choice and design. If the community truly wants resilient networks, it must build architectures that do not depend on a single cloud provider or on a company that controls a critical server.
The positive side is that the direction already exists. Protocols are evolving, modular architectures are emerging, decentralized data layers are maturing and the technological base grows stronger year after year. The incident is a reminder that the goal has not yet been achieved, but it remains absolutely attainable.
The solution is not found in slogans, but in specific practices. A truly resilient Web3 requires distributed infrastructure, multiple execution layers that are not tied to a single provider, decentralized data storage, and an L1 that serves as the ultimate source of truth. With this approach, even if something breaks at one layer, the network and its users can continue to operate.
The technology already exists. What is missing is a mindset shift. We must not simply use blockchain, but integrate it in ways that honor its core philosophy. Moving from Web2 dependency to Web3 resilience is a multi-year effort, but it is a necessary step if we want digital systems that do not collapse every time a data center goes dark.
The solution is not to reject Web3, but to build it properly.
The future must include:
Layered architectures instead of monolithic stacks
L1 as the ultimate settlement layer
Modular execution layers without single points of control
Multi-cloud strategies instead of one-cloud dependence
Decentralized storage (IPFS, Arweave) instead of cloud buckets
On-chain identity, messaging and governance
The Web3 that survives will be the Web3 that stays online even when a server fails.
The AWS blackout was a message, not just an incident. Before we build the future, we must recognize the limits of the present, because Web3 has not failed. It is in the stage where it is letting go of its Web2 crutches and learning to stand on its own. The journey will have obstacles, but it is worth it, because the destination is an internet that is more open, more free and more resilient than anything we have seen so far.
The next step is to build with architecture and awareness, not assumptions. If we want a Web3 that does not fall when a server falls, we must design systems that respect decentralization in practice. The future is there, waiting for those who will build it with intention and consistency.
No comments yet