A technology can be useful and a disastrous investment at the same time. Railways and the internet changed the world, but both produced enormous financial bubbles that later caused sleepless nights for the people who financed them.

This essay is about a narrower question: how much of the value AI creates will be captured by the companies paying for the buildout, and how much will leak to customers through lower prices. AI does not need to fail for its investors to lose. It only needs to become cheap faster than they can earn their money back.

On some measures, the AI boom is approaching the 1999 dot-com bubble in terms of valuations, and it may be even larger when measured by the share of the economy’s investment it is absorbing. But this time, there is a fundamental difference: the economic life of the capital being built.

Physically, an AI chip can remain operational for years. Economically, its most valuable life may be much shorter, possibly as short as one to three years under heavy use, compared with dot-com-era fiber and telecom infrastructure that remained useful for decades. This is the most important and least settled assumption in this essay, and I will stress-test it below. The direction still matters for the infrastructure argument: dot-com fiber could be bought cheaply after the bust and operated profitably for years, whereas AI chips lose their highest-value uses much faster as newer generations arrive. They can be moved to lower-value workloads, but the buildout is still likely to leave behind a shorter-lived capital stock, even if the chips are not literally worthless.

The size of the bet

To understand what is going on, first we need to understand the numbers.

According to their latest guidance, Alphabet, Amazon, Meta, and Microsoft plan to spend roughly $695 to $725 billion in total capital expenditure in 2026: about $200 billion at Amazon, $180 to $190 billion at Alphabet, around $190 billion at Microsoft, and $125 to $145 billion at Meta. For the record: The companies do not break out a clean AI-only line; these are total capex figures.

For comparison, Sweden, a literal country with 10.6 million people, produced about $669 billion of GDP in 2025. Four companies now plan to out-spend the entire annual output of Sweden.

In addition to the enormous amount of money involved, AI infrastructure adds a utility-like layer to the technology industry: lots of physical investment upfront, uncertain returns later. Although these companies generate extraordinary profits and hold enormous cash reserves, the scale of AI investment is so vast that even this sector has increasingly turned to the bond market. The five largest hyperscalers, meaning Amazon, Alphabet, Meta, Microsoft, and Oracle, issued about $121 billion of US corporate bonds in 2025, roughly four times their annual average of $28 billion during the previous five years. Some of that borrowing funds ordinary business, but the surge lines up with the capex plans. By mid-2026, issuance had already passed $159 billion, and full-year forecasts sit around $230 to $240 billion.

The money is also starting to move in circles. Nvidia invests in its own customers, and those customers sign multi-year compute commitments worth hundreds of billions of dollars with the clouds that buy Nvidia’s chips. A growing share of the data centers is financed through special-purpose vehicles that keep the debt off the sponsors’ balance sheets. There is nothing illegal about any of this. But vendor financing and circular capital flows are the same patterns that made earlier infrastructure booms look healthier than they were.

The depreciation question

Earlier I said the most valuable life of an AI chip may be one to three years. That claim needs support, because the companies’ own books say otherwise. Microsoft and Google depreciate their servers over six years. Meta extended its servers and network assets to five and a half years in January 2025. If those schedules reflect economic reality, the infrastructure argument gets much stronger and this essay gets much weaker.

One data point cuts the other way. In February 2025, Amazon, which runs the largest cloud fleet in the world, shortened the useful life of a subset of its servers and networking equipment from six years back to five. The reason it gave was the faster pace of technology development in AI and machine learning. Amazon had spent the previous decade extending server lives. It is the first hyperscaler to walk one back, and it did so specifically because of AI.

Why does an accounting footnote matter? Because if the true economic life of AI hardware is shorter than the book life, depreciation is currently understated, which means today’s reported profits are overstated. Skeptics like Michael Burry (the investor who called the 2008 housing crash) argue the gap could reach roughly $176 billion of understated depreciation between 2026 and 2028, though that number cannot be verified from public filings. A JPMorgan stress test found a more modest effect: applying a three-year life to AI hardware would cut earnings per share and operating margins by roughly 6 to 8 percent for most hyperscalers, with Oracle as the bigger exception. That would hurt earnings without breaking them. Still, nobody is arguing that the chips will outlast their schedules.

Also, not all of this capex is chips. Alphabet said about 60 percent of its recent quarterly capex went to servers and 40 percent to data centers and networking, and buildings, power infrastructure, and fiber genuinely do last decades. The short-life problem applies to the silicon. The silicon just happens to be the biggest and fastest-growing slice.

The price is collapsing

Obviously, these companies are not spending this money merely so that you can generate an anime-style image of your cat for free. They need the infrastructure to earn an adequate return on their investment.

To increase their profits, they need to increase volume, improve margins, or ideally do both. The problem is that the price of model access is collapsing.

To take one benchmark-based comparison, from a16z’s “LLMflation” analysis: when GPT-3 became publicly accessible in late 2021, it was the cheapest widely available model capable of reaching an MMLU, or Massive Multitask Language Understanding, score of about 42, at roughly $60 per million tokens. By late 2024, the cheapest model clearing the same bar cost about six cents.

The price at that specific capability level has barely moved since 2024, but for a telling reason: the decline moved up the capability ladder. The same few cents now buy substantially higher benchmark scores. In fact, you no longer need a model provider at all to reach GPT-3’s level. Small models that beat it can run on an ordinary Mac with 16 to 24 GB of memory, where the marginal cost is mostly electricity.

As the price of a fixed level of benchmark performance approaches commodity levels, there are two broad ways to justify this massive investment: sell a more capable frontier model at a premium, or increase usage fast enough to offset falling unit prices. Ideally, they do both.

At a fixed capability level, a thousandfold fall in price would require a thousandfold increase in volume to preserve revenue. But revenue is not profit. Profit also depends on the cost of serving each token, the utilization of the infrastructure, depreciation, and financing costs.

It also matters why prices are falling. If prices fall because the cost of serving each token is falling just as fast, thanks to better hardware and better software, margins can survive the collapse. If they fall because competitors are undercutting each other, margins die with them. So far the evidence points more toward the first story: Epoch AI, which tracks these price declines, found no clear evidence that shrinking profit margins explain them. The second force is real too, though, because open-weight models put a ceiling on how much of the efficiency gains providers can keep for themselves.

Of course, as AI advances, people are using it for tasks that were not possible with GPT-3. Providers are not limited to selling more of the same capability. They can sell the newest model at a premium.

The problem is that each premium may be temporary.

The Intelligence Premium

The intelligence premium is the extra price customers are willing to pay for capabilities that cheaper or older models cannot yet provide.

Setting aside the other advantages of open-weight models (like privacy, if you self-host them), if two models can achieve the same task, who would choose to pay more?

The problem is that the premium has a short half-life. As competitors catch up and smaller models improve, yesterday’s frontier becomes today’s commodity, widely available at a fraction of the price. The premium does not disappear entirely, but it moves to the next capability level.

As I was finishing this essay, Moonshot AI announced Kimi K3, a 2.8 trillion parameter open-weight model that, by its own account, trails only the two strongest proprietary models. The weights become public on July 27 under a permissive license. Moonshot priced its own API at western frontier rates, but that hardly matters; once the weights are out, anyone can host the model, and the price competition starts there.

The market graded the announcement within hours. Shares of Zhipu, a rival Chinese lab, fell 22 percent by midday, and MiniMax fell 14 percent. Notice who paid the price: the other model companies. The chipmakers and the clouds kept selling.

This creates a difficult business model. AI companies must keep spending to reach the next capability level before the premium on the current one disappears. Standing still is not an option, because the product they are selling becomes cheaper even when it does not become worse.

The real question, then, is whether the premium lasts long enough, and is large enough, to recover the cost of producing the next generation of models and the infrastructure behind them.

The bull case

However, I want to mention two strong arguments on the other side, this time with the numbers behind them.

First, falling prices do not necessarily mean falling revenue. If lower prices make AI useful for far more tasks, demand may grow faster than the price declines. A model that costs ten times less can still produce more revenue if it is used a hundred times more. And demand really is exploding. Microsoft’s AI business passed a $37 billion annual revenue run rate in early 2026, growing 123 percent year over year. Google Cloud grew 63 percent in the same quarter, with a contracted backlog that nearly doubled to over $460 billion. Both companies say they are capacity constrained: they could sell more compute if they could build it faster.

Cheaper models do not just replace expensive ones in existing tasks; they make entirely new uses economical.

Second, the hyperscalers do not need to recover their investment only through model access. Microsoft can use AI to make Azure and Office more valuable. Amazon can sell more cloud capacity. Meta can improve advertising and engagement. Alphabet can protect or expand its search, advertising, and cloud businesses. In these cases, AI may generate returns indirectly, even if the price of the model itself keeps falling.

This makes the investment case stronger, but it also makes it harder to measure. A company can claim that AI protects revenue, increases productivity, or improves an existing product without showing how much of that value came from the infrastructure itself.

So let me say what would prove this essay wrong. Usage keeps growing faster than prices fall, year after year. Serving costs drop as fast as prices. Old hardware stays busy instead of idling. Indirect AI revenue shows up in cloud and advertising numbers in a way you can measure. The backlog and run-rate figures above are early evidence for that side of the argument.

This is where the short life of the premium becomes important again. The companies are not making one large investment and then collecting returns from it for decades. They are entering a cycle in which each new generation requires more capital, while the previous generation quickly becomes cheaper and less valuable.

The result may be a business that grows rapidly while producing disappointing returns on capital. This would not make AI a failed technology, but rather a difficult industry to invest in.

Who captures the value?

The history of technology is full of examples where users captured more value than the companies that built the infrastructure. Competition pushed prices down, capacity became abundant, and the economic benefits spread across the rest of the economy. The technology succeeded, but many of the investors who financed it did not.

AI may follow the same pattern. The models can become more useful, more widely available, and more important to the economy while the companies producing them struggle to earn returns that justify the capital invested. In fact, the faster AI improves and spreads, the faster older capabilities may lose their scarcity value.

There is more than one bet hiding inside “the AI trade,” though, and the economics differ. Chipmakers earn high margins for as long as the buildout continues, whatever the buyers’ returns turn out to be. Frontier model labs face the intelligence premium problem in its purest form: enormous training costs against a premium with a short half-life. The hyperscalers sit in the middle as both the gold diggers and the landlords; they dig with their own models, but much of their AI revenue comes from renting compute to the labs. And businesses with existing distribution, customer relationships, and profitable products can plug cheap intelligence into what they already run.

This is why the central question is not whether AI will change the world. It probably will. The question is how much of the value created by AI will be captured by the companies financing the buildout, and how much will be passed on to customers through lower prices.

If intelligence continues to become cheaper, the economic value of AI may rise while the market value of producing it falls.

That is the risk behind the current investment boom. The industry may be building something enormously useful, but too cheap to sell at the prices needed to justify what it cost to build.

Sources

• 2026 capex guidance: Alphabet Q1 2026 earnings call ($180-190B); Microsoft FY26 Q3 earnings call ($190B for calendar 2026, via CNBC); Amazon Q4 2025 results (~$200B); Meta Q1 2026 results ($125-145B).

• Hyperscaler bond issuance: M&G Investments, “Tech issues: The AI debt deluge hitting bond markets” (Bank of America data); H1 2026 issuance and UBS full-year forecast via press reports.

• Price decline at fixed capability: a16z, “Welcome to LLMflation” (2024); Stanford AI Index 2025; Epoch AI, “LLM inference prices have fallen rapidly but unequally across tasks.”

• Useful-life accounting: Amazon Q1 2025 10-Q (useful life change, six to five years); Meta 2025 10-K (5.5 years); Microsoft and Alphabet filings (six years); JPMorgan depreciation stress test via press reports.

• Sweden GDP: World Bank / IMF, 2025.

Agenda

🟥 Türkiye entered a new phase of crypto asset market data transparency.

MKK started publishing daily core market data reported by crypto asset service providers through KVMKS. As of 15 July, it was announced that 53 CASPs had completed their MKK membership processes, approximately 5.6 million investors had traded on platforms to date, and around 3.2 million investors had balances. *

🟥 MiCA is now fully in implementation across Europe.

With its 16 July 2026 update, ESMA’s Interim MiCA Register continues to bring authorised crypto asset service providers, whitepaper records, e-money token issuers and non-compliant entities into a single reference point. *

🟥 ESMA selected custody as one of the first major supervisory focus areas after MiCA.

ESMA launched a common supervisory action to examine the digital operational resilience of crypto asset service providers in their custody activities. Focus areas include key management, custody architecture, transaction controls, incident detection, smart contract risks and third-party dependencies. *

🟧 The European Commission continues to collect feedback for the MiCA review.

The targeted consultation aims to assess whether MiCA remains fit for purpose in light of its first implementation outcomes and market developments. The deadline is 30 September 2026. This process may lay the groundwork for MiCA 2 discussions around stablecoins, tokenisation, DeFi and service provider obligations. *

🟧 BIS is bringing stablecoins back into its core agenda.

A study dated 21 July 2026 discusses how stablecoins could strengthen digital dollarisation in emerging economies and create implications for monetary policy transmission and financial stability. *

🟧 BIS treats blockchain infrastructure as financial infrastructure.

It also frames blockchain fragmentation not merely as a technical issue, but as a market structure problem. The 6 July 2026 bulletin highlights that different consensus designs make different trade-offs between security, scalability and decentralisation, which can increase fragmentation across liquidity, assets and infrastructure. *

Subscribe now

🟥 EU sanctions directly targeted crypto services.

The 21st Russia sanctions package, adopted on 23 July 2026, introduces the possibility of third-country bans for crypto asset services and transaction bans on certain third-country crypto platforms. This shows that crypto infrastructure is becoming a more direct target in sanctions evasion risk. * *

🟧 The CLARITY Act reached another critical point in the US, but the timeline tightened.

The Senate is struggling to bring the crypto market structure package to a vote before the summer recess. The debate continues around stablecoin rewards, ethics provisions, consumer protection, and the SEC-CFTC jurisdictional perimeter. * *

🟧 The UK crypto regime moved into the operational preparation phase.

The FCA reminds firms that it has published final rules and guidance for the new crypto asset regime, that the authorisation gateway will open on 30 September 2026, and that the new regime will begin on 25 October 2027. * *

🟧 The federal-state jurisdiction fight over prediction markets is intensifying in the United States.

A federal court temporarily blocked enforcement of Minnesota’s prediction market ban. The CFTC, Kalshi and Polymarket argue that these products should be treated under the federal commodities derivatives regime, while states are trying to limit them under gambling regulations. This debate shows that jurisdictional boundaries between regulators remain unresolved for tokenised markets and event contract products. *

🟩 The Bank of England made its tokenised money agenda more explicit.

Andrew Bailey’s July speech made tokenised deposits, the Digital Securities Sandbox and the digital gilt link more visible in the UK. The Bank of England connects programmable payments with real economy problems through tokenised money design and synchronisation infrastructure. This suggests tokenisation is increasingly being viewed not only as a capital markets efficiency tool, but also as a way to address payment delays, fraud and trade processes. *

Post-MiCA EU market

New authorisations, non-compliant entities and which countries become more active under ESMA’s custody supervision should be tracked through ESMA’s Interim MiCA Register. * *

Türkiye KVMKS data

MKK’s daily KVMKS data may become Türkiye’s first regular public dataset for the crypto market in terms of investor count, investors with balances, total market value and CASP memberships. *

CLARITY Act

As the US Senate heads into summer recess, the September timeline for the CLARITY Act, the SEC-CFTC jurisdictional split and the stablecoin reward debate should be monitored. *

UK authorisation gateway

Ahead of the FCA authorisation gateway opening on 30 September 2026, platforms serving the UK should review their application strategy and cross-border service models. *

EU sanctions and crypto

How the EU uses its third-country crypto services ban tool will be critical for crypto platforms’ sanctions risk management. *

node101

Staying ahead in blockchain requires continuous learning. Blockchain Regulation Journal provides a concise monthly flow of the key information you need to know.

Over the past months, we have implemented a large-scale tracker and analyzer for the blockchain developer ecosystem. Until now, we have found over 950 thousand repositories and 450 thousand developers across 26 ecosystems.

In this article, we will briefly summarize what the data is telling us, and answer some of the most common questions such as where developer activity is concentrated or what is the most common trend in developer activities.

If you do not agree with our observations, you can find our live dashboard here:

blockchaindeveloper.report.

We also describe our methodology and limitations of the data, in case you want to learn more about the details.

BDR is currently in beta, and its coverage continues to expand. More than 100,000 repositories were added during the past two weeks alone. As new repositories are discovered, some historical figures may also be updated. Follow us for the latest dataset releases and analyses.

How many developers are in the ecosystem?

Interestingly enough, when we observe the number of active developers (i.e. committed at least once in the past 28 days) in the ecosystem, we see that the overall number did not decrease significantly over the past years.

Instead, since late 2024 numbers have remained around a stable baseline (about 25k) with some oscillations.

This graph is very encouraging since the common belief in the blockchain ecosystem is that the number of developers is mostly correlated to the token price. It is certain that the token price is not going very well over the past months, but the number of developers is remaining broadly stable. Can this mean the ecosystem is finally gaining resilience?

Other trends for active developers

Currently, the retention rate of developers is ~ 40%, meaning that 4 out of 10 of each developer remain active from the last month. This interpretation is also reflected in the churn shown below.

This figure suggests that even though the total number is not changing too much, fluctuations are quite high, and they are following a very similar trend for the past 2 years. This is a negative sign for maturity, showing that almost half of developers are working on blockchain for only around a month.

What does growth look like?

Another important point is the distribution of new developers joining the ecosystem.

Here, a similar observation follows the previous. Even though the fluctuations are much stronger, new developer growth also seems to be keeping inside some boundaries, which is again very important for the maturity of the ecosystem.

Of course, a natural question that follows is which ecosystems are attracting the most new developers.

Probably not many would be surprised to see EVM in the first place, but it is peculiar enough that the two close followers, Stellar and Polkadot, are actually approaching EVM’s new-developer count. This is particularly interesting when you realize that Stellar is actually a substantially different stack than EVM and it is actually using a different programming language.

How about the distribution across ecosystems?

Coming back to the active developers of blockchain, it is important to answer how many developers are actually shared across ecosystems.

This final graph shows that it is not only the number of developers stabilizing, but also developers that are working on multiple ecosystems at the same time. This may not be as positive as before, since ideally we would like to see old developers working on new technologies as the time passes. Nevertheless, it is still reassuring to see that the number is at least not decreasing.

What’s next?

In this brief text, we have shared a few figures for the global data.

If you are looking to better understand individual ecosystems or developers, you can find more analyses and ecosystem specific dashboards in blockchaindeveloper.report.

Data is important; to analyze, understand and improve.

Now that we have analyzed and understood, what’s next is to improve.

In my previous article, I discussed how regulations must be built on the principle of the “Separation of Powers” for local blockchain ecosystems to grow in a healthy and sustainable manner. Whether in the US, UK, EU, Turkiye, or Hong Kong, regulatory bodies need to position local exchanges, applications, infrastructure providers, and users to mutually feed into one another, rather than issuing unilateral, prohibitive mandates.

Therefore, for a healthy blockchain ecosystem, we must first correctly define our internal balances and “boundaries of power.” This means establishing a cluster where the powers of exchanges, custodians, and data providers are strictly separated, infrastructure is supported by domestic servers, and data sovereignty is secured through local blockchain infrastructure providers.

While properly defining this cluster is a valuable step, it alone will not suffice to breed digital asset companies capable of competing globally. A local separation of powers might prevent systemic collapses,like the FTX disaster,but it won’t inherently drive actors to enrich one another. For instance, while Turkiye boasts giants like Paribu and Midas capable of locking horns with global competitors, many local companies operating in niches like custody, infrastructure provisioning, zero-knowledge (ZK) tech, wallets, and neobanking clearly need support to reach international maturity. Global giants in these verticals, backed by foreign capital and commanding worldwide customer bases, operate within the Turkish ecosystem, absorbing the very nutrients local counterparts need to take root, thereby creating near indestructible monopolies.

This brings us to the core theme of today’s article How do we protect local actors against the destructive competition of foreign tech giants? More importantly, how can we transform these global behemoths into a “lever” that feeds our own domestic ecosystem?

The Small of Today, The Giant of Tomorrow

Take today’s giant exchanges as an example. What does it take to compete with platforms like Binance, OKX, Paribu, or Midas and grab a slice of their customer pie? You would need tens of millions of dollars in investment, massive teams, licenses, aggressive marketing campaigns, and countless other resources. It’s akin to trying to challenge Google in search, battle Apple and Samsung in mobile hardware, or take on Anthropic and OpenAI in the LLM landscape,an incredibly steep uphill battle.

On the flip side, the blockchain and cryptocurrency ecosystem is not composed entirely of exchanges and custodians. There are numerous emerging subsectors shaped around the needs of these heavyweights. RPC and data providers feed them blockchain data, validators supply white-label staking solutions, zero-knowledge products deliver privacy fixes, and various wallets build the user interfaces. Because their total trading or operational volumes are exponentially smaller, these sub-sectors often appear trivial compared to the main pillars. For example, while the global custody sector generates a staggering $500 billion in value annually, the RPC and blockchain data provisioning sector, a vital component of those very services, is currently hovering around just $4 billion a year.

To build a custodian today that can rival global incumbents, you must fight tooth and nail for a slice of that $500 billion pie against deeply entrenched solutions. Conversely, if you are a company investing in zero-knowledge technologies, a sector that has only recently hit a $20 billion market size, you can ride the wave as the industry multiplies tenfold over the next five years. By scaling alongside the market, the products you develop can turn you into a global player. This is exactly why we must nurture the “small of today, giant of tomorrow” companies within our ecosystem.

But how do we pull this off? Even in niche sub-sectors, global monopolies still exist. For instance, half of the total volume in validation is controlled by just a handful of massive firms, a pattern mirrored across other verticals. Major custody and exchange platforms in Turkiye currently funnel tens of millions of dollars annually to these foreign-sourced companies to access these critical tools. However, redirecting these capital flows to local alternatives would keep foreign currency within the country while paving the way for a self-sustaining blockchain cluster right here in Turkiye. By growing through domestic investments in their own products and services, today’s small enterprises will naturally become more competitive in international markets, securing a defining stake in the future of their industries as they expand.

Therefore, we must erect time-bound protective barriers for ancillary sectors whose global market sizes currently fluctuate between $50 million and $250 million. These are early-stage financial niches that will ultimately shape tomorrow’s technological architecture: Zero-Knowledge (ZK) cryptography, domestic validator networks, RPC providers, and privacy-centric cybersecurity products. Think of this as a smart, limited import substitution regime. We need to shield the Turkish market from the crushing competition of global monopolies so that our local data providers, validators, and encryption startups have the breathing room to flourish on home soil.

The Turkish Case Study ‘Today’s Global Giants Must Anchor in Turkiye’

Engaging in a direct war of resources and capital against global giants in trillion-dollar markets, like Layer 1/Layer 2 (L1/L2) blockchain networks, global payment rails, or Large Language Models (LLMs), is simply irrational. Imagine trying to impose import substitution on LLM companies that already boast millions of users, active enterprise subscriptions, and the protective backing of the US government and Senate. Proposing this would be short-sighted Turkiye would be starved of both the economic gains and the sheer efficiency these technologies unlock.

With these giants backed by trillions of dollars, how realistic is it for Turkiye to build an LLM from scratch to rival them with just a few billion dollars? While a slim chance exists, it only holds true if those LLMs solve hyper-specific problems current models cannot touch. Instead, Turkiye’s strategy here should be built around attracting international finance and global venture capital (VC) into the country.

However, letting these giants enter the Turkish market and access our local user base should not operate like an open-ended capitulation. The presence and licensing processes of global players in Turkiye must be explicitly tied to adding value to the local ecosystem, specifically through a Turkiye-In Country Value (TICV) model.

When the Big Fish Feeds the Small Fish

The magical instrument that bridges these two layers, the need for global financing and the protection of local niche sectors, is this very TICV model.

Let me map out the equation, and since this is a draft, I look forward to your feedback. Any global blockchain giant or AI powerhouse wishing to operate and secure a license in the Turkish market must maintain a high TICV score; otherwise, they face exclusion from state tenders. To boost this score, they would be required to open data centers in Turkiye, employ local engineers, and, crucially, procure products and services from our local ZK, RPC, and validator startups, the very niches we shielded under our protective umbrella.

Consequently, global capital transforms into a direct lever that fuels the growth and cash flow of our budding local startups.

Creating Tomorrow’s Global Players Today

Today, niches like ZK, validator networks, or decentralized cybersecurity are constrained within a global $50 million to $250 million band. However, over the next decade, they will evolve into massive, multi-billion-dollar core industries.

Because Turkiye will have implemented the right protective shields and TICV levers ahead of time, it won’t be a passive market playing catch-up when these niches balloon into giants. On the contrary, by regulating and safeguarding local actors today, the country will have rooted its own future billion-dollar global tech giants. Just as the seeds planted by a forced import-substitution regime due to past defense industry embargoes have blossomed into game-changing global enterprises today, it is entirely in our hands to create tomorrow’s champions in blockchain and cutting-edge tech from this moment forward.

In the previous articles, I explored how distributed systems evolved into blockchains [1], why and how blockchain architectures eventually became modular [2], how the access layer quietly shapes decentralization [3, 4], and how each generation of protocols inherits the constraints of the one before it [5]. Though with these discussions we approached the ecosystem from different view points, they all revolved around a common idea: blockchain architecture is about managing constraints rather than eliminating them.

One constraint, however, remained in the background and we only slightly mentioned it: time.

We usually encounter it as latency, block times, confirmation or settlement delays, and RPC response times. These metrics are often treated as isolated performance indicators, optimized independently and used to compare one blockchain with another. Yet they all describe the same underlying phenomenon. So, before asking why one blockchain is faster than another, we should first ask a more fundamental question.

Can a decentralized system ever have a single present, or is latency simply the price of many participants trying to share the same reality?

One Network, Many Presents

Raphael’s The School of Athens portrays dozens of philosophers gathered in the same hall, discussing the same ideas, yet no two figures occupy the same position. Some argue, others observe, a few teach, while several remain immersed in their own thoughts. Knowledge emerges because independent viewpoints gradually converge through dialogue.

A blockchain network behaves in a remarkably similar way: When we describe a blockchain, we usually imagine it as a single system progressing through time. A transaction is submitted, a block is produced, and everyone observes the same new state. But no one really experiences that moment simultaneously.

• A validator proposing a block observes the transaction before another validator on the other side of the world.

• An RPC node may already serve the updated state while an indexer is still reconstructing it.

• A wallet continues displaying an old balance even though the transaction has already been finalized.

• A blockchain explorer may report confirmation seconds before another explorer catches up.

Everyone interacting with the blockchain temporarily lives in a different version of the network’s present. The further information (the new state) has to travel across the nodes, the longer these differences mentioned above persist. Unlike The School of Athens, where independent perspectives eventually converge through discussion, blockchain networks converge through protocol.

Latency is the observable consequence of this reality. At that point, the challenge is not just making systems faster but understanding that decentralized systems cannot make every participant share the same present at the same moment.

Consensus Does Not Synchronize the Present

You may ask that consensus protocols are mechanisms that allow validators to agree on the state of the blockchain, so why is the present not synchronized? While you are technically correct, this description does not necessarily answer what consensus protocols accomplish.

Consensus protocols were never constructed to synchronize the present, they have been here for synchronizing the past.

When validators exchange votes, propagate blocks, or verify signatures, they are not attempting to make every participant observe events simultaneously. Such a goal is physically impossible in a globally distributed network. Instead, consensus establishes a common history after enough information has propagated throughout the system. This distinction matters because the network is always in motion while consensus takes place. Messages arrive at different times, packets follow different routes, and validators observe slightly different versions of the world for brief periods. Consensus gradually resolves these differences into a shared history that everyone can later agree upon. And this is why confirmation / settlement periods are introduced in blockchains.

In other words, a blockchain does not maintain one universal “now.” It continuously transforms many local observations into one globally accepted “then.”

The Present Moves Further Away

Even after consensus has been reached, a finalized block does not immediately become visible to users. RPC nodes update their internal state, databases process new information, indexers reconstruct events, caches refresh their contents, and applications request the latest data before a wallet finally displays an updated balance.

This difference explains why users often perceive blockchain performance very differently from protocol metrics. A network may produce blocks in milliseconds and finalize transactions fast and efficiently while applications still appear slow because the surrounding infrastructure has not yet reflected the new state.

Yet, we should not perceive it as a failure of decentralization. Every additional layer that separates users from consensus introduces another interval during which information continues to travel: this is an architectural reality. The protocol reaches certainty first, the user reaches it later.

How Do We Encounter It in Real Life?

This distinction becomes much more visible in financial systems.
Imagine an automated trading strategy reacting to a sudden price movement. The algorithm decides to buy because the latest market data indicates an opportunity. Yet, both the price update and the order itself need time to travel through the network before they become part of the system’s shared state. And by the time the transaction is executed and the rest of the network observes it, the conditions that motivated the trade may already have changed. The algorithm was reacting to the latest present it could observe.

Traditional software too experiences delay, but the architecture is fundamentally different:

• A centralized trading platform maintains a single authoritative database, meaning there is only one version of reality. Participants can reduce latency simply by moving closer to that authority.

• High-frequency trading firms, for example, colocate their servers inside exchange data centers because every microsecond between their systems and the exchange’s matching engine matters. The closer they are to the source of truth, the earlier they observe new information and the sooner they can react.

Blockchains deliberately reject this model. There is no single server to stand next to and no database that instantly defines reality for everyone else. Every validator must first receive the same information before agreement can emerge, and every participant waits for that agreement to propagate throughout the network. Latency therefore becomes a shared architectural constraint rather than a private competitive advantage.

Can We Eliminate Time?

Modern blockchain architecture dedicates enormous effort to reducing latency. These designs are usually referred to as real-time blockchains and some of the ways they achieve it are as follows:

• Consensus algorithms reduce communication rounds.

• Peer-to-peer protocols optimize block propagation.

• Validators improve network connectivity.

• RPC providers deploy regional infrastructure closer to applications.

• Layer 2 systems execute transactions before settlement.

• Indexers continuously optimize how quickly the new state becomes queryable.

Each of these improvements shortens a particular delay but none is enough to remove time itself. Even the fastest blockchain cannot escape the physical reality that information cannot exist everywhere simultaneously. Messages still traverse continents and requests travel through networks, participants still receive events in different orders. Every optimization reduces waiting somewhere while preserving the underlying relationship between distance and time. Even though through these improvements the constraint becomes smaller, it remains still.

Conclusion

Distributed systems taught us that information cannot exist everywhere at once. Blockchains inherited this limitation while removing the trusted operator capable of resolving disagreement externally. As a result, decentralized systems exchange a single universal present for something more subtle: many local presents that gradually converge into one shared history. Latency is basically the name we give to that convergence time.

Perhaps this is why blockchain architecture has never truly been about making systems faster. Every generation of protocols has attempted to shorten the interval between action and certainty, yet none has succeeded in eliminating it entirely. Time remains embedded within every consensus round, every propagated block, every RPC request, and every application waiting for the latest state.

The blockchain, then, is not a machine that moves through one shared moment but a network continuously negotiating its own present.

TL;DR

🟥 Akbank, Garanti BBVA, and Yapı Kredi were granted crypto asset custody authorization

The Capital Markets Board (CMB) favorably responded to the authorization requests of Akbank, Türkiye Garanti Bankası, and Yapı ve Kredi Bankası to operate as crypto asset custody institutions. This decision indicates that Turkey’s crypto asset market has entered a new phase through institutional custody infrastructure. The involvement of the three major banks in custody suggests that topics such as secure custody, operational standards, and regulated financial infrastructure will become more central in the VASP (Crypto Asset Service Provider) ecosystem. * *

🟥 The market is being reshaped as the MiCA transition period approaches its end in Europe. ESMA’s interim MiCA register makes authorized crypto asset service providers and related registrations visible at a single reference point across the EU. Binance announced that it withdrew its MiCA application in Greece and will seek authorization in another EU country. *

🟥 The CMB’s active VASP list has decreased to 56 institutions. Bithero and Minka appear to have moved to the liquidation process category. The list is still temporary, and the CMB specifically states that inclusion on the list does not mean authorization. *

🟥 Stablecoins are once again at the center of regulatory attention. A new BIS study suggests that reading stablecoin transfers as simple payments can be misleading, as the majority of flows are embedded in more complex financial transactions like trading, lending, arbitrage, liquidity provision, and settlement. *

🟧 Institutional players are prominent in the MiCA license race. Ripple announced that it received preliminary approval for a CASP license under MiCA from Luxembourg’s CSSF. Following full approval, the company aims to offer regulated crypto asset and payment services to banks, fintechs, and corporations across the European Economic Area. *

🟧 Malta announced a regulation discussion for DeFi. The MFSA published a discussion paper on decentralized finance. The text brings up topics such as the scope of MiCA, financial crime risks, software-based organizational models, the guardian agent approach, and the management of risks arising from smart contracts. *

🟧 Citi Institute’s Tokenization 2030 report estimates the 2030 base scenario for tokenized assets at $5.5 trillion, with an optimistic scenario at $8 trillion. According to the report, early adoption is expected to concentrate in public debt instruments, liquid collateral, and publicly traded securities. *

🟧 Perpetual futures are moving to regulated markets in the US. The path opened by the CFTC for Coinbase and Kalshi suggests that a portion of offshore volumes could be drawn into supervised structures in the US. This also initiates a new debate regarding traditional exchanges, leverage limits, and investor protection. *

🟧 Banks and regulated financial institutions are becoming more visibly involved in crypto services in Europe and Spain. BBVA’s launch of Bitcoin and Ether trading and custody services in Spain indicates that banks are approaching crypto asset services with a more open strategy following MiCA. *

Money runs on a kind of shared belief. A banknote is paper that a whole country has agreed to treat as valuable, and that agreement holds only as long as people expect it to keep holding. Most of the time this is invisible. You get paid and you spend without thinking about why the paper works. But in some places that belief has started to thin, and people have quietly moved the part of their money they actually trust somewhere else. What follows is about what happens when a currency keeps its legal status and loses its real job, and about the technology that made walking away from it almost effortless.

Money runs on trust

Almost all sovereign nations and territories issue their own currency: the Turkish Lira in Türkiye, the Peso in Argentina (each the local currency of its country). Although the banknote itself holds no intrinsic value, it is accepted within a territory because it can obtain goods or services, and it can do so because it is issued by the legitimate institutions of a state that people trust.

In financial markets, trust often matters as much as fundamentals. In addition to data, people react to their confidence in the institutions interpreting and acting on that data. But what happens if people start to lose that trust? Maybe they begin converting the national currency into another one in their heads, all the time. Maybe the rent on your home gets negotiated in a foreign currency. Maybe your salary is no longer even in the same currency your father was paid in 20 years ago.

In economics, this phenomenon is called “dollarization.” Dollarization happens when residents of a country use a foreign currency (mostly the US dollar) instead of, or alongside, the domestic currency for saving, pricing, transactions, or even as legal tender. Dollarization is, at its core, a response to mistrust. The legal currency and the trusted currency aren’t always the same, and the gap between them is where monetary power actually sits.

The old friction, and the new rails

The history of dollarization has two sides: before crypto and after.

The old version did its job really well, mostly by being a headache to anyone who wanted to switch currencies. You had to pay more than the market rate, maybe walk into an exchange office, face capital controls, or give up on earning interest unless you held a foreign account.

Then stablecoins came. A stablecoin is a crypto token designed to hold a fixed value, almost always pegged one to one to the US dollar, so one unit is meant to be worth a dollar at any time.

None of the frictions above exist with a stablecoin. You don’t have to state a reason for your transfer, and no one can delay it without explanation. You can save in a more trusted unit, and you can shield your savings from the local currency’s collapse. Stablecoins basically collapsed all that friction into a phone.

Case study: Türkiye

It was obvious that this new system would accelerate dollarization, and that is exactly what happened. We have a case study here: Türkiye.

Türkiye experienced one of the worst inflation rates in its history after the pandemic. But what hurt the Turkish economy more than the inflation itself was the gap in the data between the official numbers and third-party numbers.

Over the five years following the pandemic, official statistics suggest that consumer prices increased by roughly sevenfold, while the estimates of ENAG (an independent Turkish inflation research group whose figures run well above the official ones) point to an increase of approximately twenty-eightfold. The implied price level under the ENAG methodology is therefore about four times higher than that implied by the official figures.

The result: between April 2023 and March 2024, stablecoin purchases in Turkey were equivalent to 4.3% of GDP, with total purchases of $38 billion against a GDP around $907 billion. That is the highest share of stablecoin purchases relative to GDP of any economy in the world. For comparison, the second and third places go to Thailand at 1.3% and Georgia at 0.7%.

So in short, since 2018 the Lira has lost over 80% of its value against the dollar, and inflation was near 65% as of 2024. The behavioral response predates crypto: Turkish residents hold over $100 billion in foreign currency deposits, having long shifted savings into gold and hard currency.

As we said earlier, stablecoins are just the newest, lowest-friction version of an exit people were already taking.

Living in two currencies

Regardless of the data above, people didn’t abandon the Lira in their daily lives. Instead, they split their money into two: local currency for what the law forces (salary, taxes, rent on paper, daily spending), and digital dollars for what they actually trust (savings, anything cross-border). The currency survives legally while dying as a store of value. This is the move that turns “Turkey bought stablecoins” into “here’s what dollarization 2.0 actually looks like.”

A state can issue the money and force people to pay their taxes in Lira, but it cannot force them to believe in it. Monetary sovereignty is more than the legal right to issue a currency: it is also the effective capacity to govern economic behavior through that currency, which requires that the public actually wants to hold it.

How it drains an economy

But how does this hurt the national economy?

To understand this, we have to understand how deposits work. When you put money in a bank account, the bank holds only a fraction of it as reserves and lends against the rest, which is how credit gets created in the economy. As savings leave for stablecoins, the bank has fewer deposits to lend against, and credit tightens. On top of that, when your savings sit in the domestic banking system, they tend to circulate back into the local economy: banks park part of them in government bonds, reserves stay with the central bank, and the interest you earn is taxed at home.

But if you hold stablecoins, Tether or Circle (the private firms that issue the biggest dollar stablecoins) holds the reserves and keeps the Treasury interest. You end up financing US bonds and a private issuer instead of your own country’s banks.

Case study: Argentina

This is where our second case study comes in: Argentina. The Peso lost roughly 95% of its value against the dollar over the five years through 2025. Until April 2025, individuals were allowed to buy only up to USD 200 per month through official banking channels, and even that access was limited in practice by a complex web of restrictions.

So a parallel market formed: the “blue dollar,” historically a cash street trade requiring physical pesos and personal trust. The crypto era’s contribution: Argentina’s P2P (peer-to-peer) USDT market effectively replaced the informal blue-dollar exchange that previously required physical cash and personal trust networks.

Why better numbers won’t bring people back

So where does this leave a country whose people have quietly moved their savings onto someone else’s rails? The temptation is to expect a reversal. Argentina lifted the cepo (its web of currency controls) in April 2025; for the first time in six years people could buy dollars freely, and monthly inflation fell from triple digits a year to low single digits. Turkey’s inflation, too, came off its worst. If dollarization were only a response to bad numbers, better numbers should pull people back.

They probably won’t. Trust is slower to rebuild than a currency is to stabilize. A decade of watching savings evaporate teaches a lesson that one good year does not unteach, and the lesson has already hardened into infrastructure: dollar bank accounts, dollar wallets, dollar QR payments. When a state’s answer to dollarization is to build rails for the dollar, it ratifies it.

The new dollarization

This is the new dollarization. There is no collapse, no formal surrender, and no central bank disappears. People earn in the local currency, calculate in dollars, and save in stablecoins, treating the national money as something to pass through rather than hold. The banknote keeps its legal status and loses its real job. A currency does not have to die to lose. It only has to become the money people are paid in, and not the money they believe in.

It does not have to stay this way

None of this is permanent, even if it looks that way from inside it. Dollarization has receded before. Peru spent the 2000s and 2010s quietly winning its savers back into the sol, and Israel did something similar a decade earlier. Both took the same unglamorous route: many years of low inflation and a slow, deliberate effort to build deep local-currency savings and bond markets, run by a central bank that stopped surprising people.

What is worth noticing is what did not work. The governments that tried to force the dollar out by decree, by converting dollar deposits or banning foreign-currency accounts, mostly made things worse. Bolivia and Mexico both tried versions of this in the 1980s and pushed money offshore and out of the formal banking system instead. You cannot legislate belief back into a currency any more than you can legislate it out. What brought people back, where anything did, was time spent being credible.

So the path home exists, but it runs through years rather than headlines, and it asks a government for the thing that is hardest to fake: a long stretch of being boring and trustworthy at the same time. For now the dollar rails are laid, and a generation has learned to earn in one money and save in another. Whether the next one unlearns it depends on whether the local currency can spend long enough being unremarkable.

Tokens are often treated as inevitable pieces of blockchains and decentralization, mostly argued to be the only solution for designing a Sybil-resistant public network. Though this explanation is for sure very compelling, does it really represent the full picture?

In reality, blockchains need many different types of tokens, and unfortunately today’s systems mostly optimize for only one or two potential use cases of them.

In this article, we will look into various types of tokens that blockchains use, inspect their differences, and discuss how these concepts are mishandled in today’s blockchains.

What was the original token?

The first one, Bitcoin, was a financial token before anything. It was clearly proposed as a replacement to “money”, and it was aiming to become the next digital currency. Although Bitcoin is still in the process of adoption today, it actually achieves very well what we expect from a financial token in the technical sense.

First of all, we need a financial token to be public and accessible, so that it can be accepted as payment in most of the world. We ask it to have an inflation rate that is deterministic and bounded, meaning that the amount of tokens that we have will not decrease in ratio overnight in an amount that we cannot know beforehand.

Bitcoin is clearly holding all of these merits, and thus technically, it constitutes a technically effective alternative to conventional monetary assets. Thus, we can say Bitcoin was very successful as a design in terms of a financial token.

This success was the reason that almost all successors of Bitcoin used the exact same design for very different goals, which is the topic of this article.

The first mistake: Gas Token

Firstly, the need for a gas token emerged.

Since each TX on a blockchain consumes some real energy and funds, we need a way to make sure no one uses the network excessively, or at least pays for doing so. In other terms, the gas token creates a mechanism to “rate limit” users and prevent spamming.

Naturally, the existing financial token of the system, e.g. BTC in Bitcoin or ETH in Ethereum, was a very suitable choice for this need. Without any modifications, some amount of this native financial token of the network was required to be paid with every TX, which was then either distributed to miners / validators or burned.

This design was not only convenient, but also seemed as a very clever idea: By constantly forcing the system to burn some amount of token in every TX, an upward pressure over the token price is created. Basically, this design resulted in a direct relation between the total usage of the network and the price of the underlying token. However, the reality is not this simple.

Why should we not use BTC or ETH for gas?

Firstly, the gas token actually has a very different structure than a financial token. It is also asked to be available, but it does not need to be “tradable”. A financial token makes sense only if it is exchanged in various financial systems, but this is not true for the gas token. Ideally, we want the gas token’s price to be fixed, or very slowly changing, so that the amount of computation power that we can buy today does not change tomorrow. Of course, based on the demand a network can become more expensive, but this should only require more gas tokens to be paid by users.

In contrast, the financial token needs to be very adaptive to external factors. If a major political figure makes a statement about blockchain, we expect the price of ETH to change immediately, but why does the amount of computation we can do also get affected?

Maybe this problem seems like a small one, but it actually creates one of the biggest barriers while designing everyday software on top of blockchain. The volatile price of the gas token forces developers to actually think and optimize for their token purchases’ time and place, which should definitely not be the job of a backend engineer!

A natural solution is of course using a stable token, like USDC, to pay for the gas fees, which seems like satisfying the technical requirements at first sight. However, even though USDC solves the UX problem, it weakens the decentralization and neutrality of the network if access to blockspace depends on a centralized asset.

Simply, the main idea is that using the same token both as a “money” or financial instrument, and also as a rate-limiting device is a problem in its essence. Networks should optimize themselves to have a different type of a rate limiter. As it is far from this article’s subject, we do not detail some solutions here, but readers interested can read more about gasless blockchains or novel rate-limiting systems in public networks.

And this was just the “smaller” problem…

Unfortunately, gas tokens are not the biggest problem of blockchains today. A more urgent matter is the very security of the consensus, which is assumed to be provided through an economic security token.

An economic security token is the token that is used to stake & slash in Proof of Stake type consensus models, which is, excluding Bitcoin and a few others, the most commonly used consensus design in today’s systems. Of course, almost all PoS blockchains use their financial & gas token also as their economic security token…

The technical differences between the economic security token and financial token are not as easy to describe as before. Since, by its name, we also expect both to have some economic value attached, they seem to be covering similar topics. However, there is a big difference between a regular financial asset and a security mechanism.

While dealing with finances, economics is the only thing that matters. For a purely financial asset, volatility is mainly a market risk. For a consensus-security asset, volatility becomes a security problem.

If you allow the security of a network to change as freely as an open market, this creates a huge risk over the consensus. More precisely, if the asset used for staking is also freely traded, attackers may be able to hedge or partially offset slashing risk through external markets.

Of course, in reality things are slightly more complex, so we did not see any consensus attack on ETH so far. However, the core problem that the entire security of a network depends fully on volatile tokens remains intact.

No secure network in the world should lose half of its security overnight because a celebrity sent a tweet.

Then, what?

So should we conclude that blockchain is on thin ice, and there is nothing to be done now to save us?

Luckily, no. Starting with social consensus, there are a lot of mechanisms that secure blockchains with more complex techniques. However, this does not mean that we should not aim for the better.

Future network designs should find better ways to solve these many problems that we have about tokens. In this article, we have named only three types of significant tokens, but this is a long list, and using a single design for all, is for sure not the best choice possible.

We should design tokens around what blockchains actually need, instead of designing blockchains around the tokens we want to sell.

Blockchain history is often described as a competition between different visions:

• Bitcoin vs. Ethereum

• Monolithic chains vs. modular architectures

• Layer 1s vs. Layer 2s

• Execution vs. settlement

• Sovereignty vs. scalability

Even though this framing is not wrong and has many followers behind, it is incomplete. Blockchains usually emerge from the limitations of the systems that came before them. They inherit their assumptions, react to their constraints, and then reorganize the design space around a different answer. In this sense, blockchain evolution is also a story around succession. And in this article, I dwell on that.

Every successful blockchain architecture eventually creates the conditions for its own successor. To be more precise: the system grows, infrastructure accumulates around it, users depend on it, liquidity concentrates within it, and in the end the architecture becomes an environment. New systems are then forced to define themselves in relation to that environment.

Though it might seem interesting, this pattern is older than blockchain technology. According to Greek mythology, after replacing his father Uranus and becoming ruler of the cosmos Kronos learned of a prophecy that one of his own children would eventually overthrow him. Kronos, in order to prevent this future, ate them as they were born.

This myth is usually interpreted as a story about power and fear, it also has implications for succession. The thing that replaces the old order eventually becomes the order that the next generation must confront with. We see this pattern in many areas and blockchain architecture is one of them. Every successful solution herds dependencies and eventually those dependencies become constraints for the systems that follow.

Security, Logic, and the First Constraints

The first generation of blockchains was designed around a single requirement as discussed before: agreement without trust. Bitcoin solved this problem with a simple approach: every validating participant independently verified transactions, maintained the same state, and followed the same consensus rules. Nothing was assumed and everything was verified everywhere. Yet this primitive design had many costs: throughput remained limited because every participant repeated the same work, storage requirements accumulated over time, and every transaction competed for the same finite block space.

Looking at these tradeoffs now, one might think that they are not acceptable and we should not have gone this way. However, it needs to be remembered that the objective was not performance that time; it was trust minimization. For the first time, a distributed system could maintain ownership and state without relying on a central operator. The architecture succeeded and only because it succeeded, its constraints we know today became visible.

The reason why Ethereum emerged was not because Bitcoin failed. Before Ethereum went live the problems discussed in the blockchain ecosystem were not coordinating a distributed ledger, it was already solved by Bitcoin. People were interested in coordinating logic and executing it worldwide. With Ethereum, applications could now exist directly within the system itself. Smart contracts expanded what could be built on-chain, but they also expanded the amount of computation the network needed to perform.

So, the state grew faster and hence execution became more expensive. This new system on top of many coordination costs of the previous generation introduced new ones of its own. Yet once again, new architecture succeeded.

When Architecture Becomes Environment

And this is actually where the evolution of the blockchain technology becomes interesting with numerous topics, discussions around bandwidth, latency, storage, execution throughput, etc. These constraints are live and being discussed constantly but successful systems eventually encounter another category of constraint: becoming the environment itself.

We know that a protocol with a few thousand users can change rapidly and yet, one securing billions of dollars cannot. Every modification affects applications, infrastructure providers, validators, governance processes, liquidity distribution, and operational workflows simultaneously. The architecture becomes embedded inside a larger structure that depends on its stability. At that point, changing the system becomes harder than building a new one. The environment surrounding the protocol begins to influence what changes are possible.

New architectures originate from accumulated constraints, not from failures as commonly known. Layer 2s emerged because executing everything on the base layer became expensive; modular architectures emerged because execution, consensus, settlement, and data availability responded to different scaling pressures; and finally app-specific chains emerged because different applications required different execution environments.

Each of these inherited assumptions from previous systems while attempting to remove a particular bottleneck. In this sense, successors are rarely external to the architectures they replace. They are usually produced by them and the limitations of one generation become the design goals of the next.

The Kronos Problem

Blockchain ecosystems often behave as if every new generation is a betrayal of the previous one. Bitcoin communities can treat Ethereum as unnecessary complexity. Ethereum communities can treat alternative Layer 1s as compromises. Layer 1 ecosystems can treat Layer 2s as fragmentation. Modular systems can treat monolithic systems as outdated.

All in all each generation once it becomes established, starts defending the assumptions that made it successful. This is understandable to some extent but it is also where the Kronos story becomes useful. Kronos’ fear is not to a stranger but to his own children, the successor comes from within the structure he created.

Blockchain architectures have a similar relationship with what follows them. New systems often emerge from the people, constraints, and design problems of previous systems. They are not completely separate worlds.

The Constraint Moves

One of the recurring patterns throughout blockchain history is that constraints do not disappear, they are like a sliding window.

• Bitcoin concentrated coordination around global verification.

• Ethereum concentrated coordination around shared execution.

• Layer 2s moved execution elsewhere but introduced new coordination requirements around settlement and interoperability.

• Modular systems separated responsibilities but increased the number of interfaces between them.

Every architectural improvement solves a visible bottleneck and reveals another scaling the system and relocating the constraint. Then, a new generation begins forming around whatever becomes visible next.

This is why blockchain evolution often resembles a redistribution of constraints rather than their elimination.

Conclusion

Kronos devoured his children because he feared being replaced. But blockchain architectures behave differently, not consuming their successors and creating the environments from which those successors emerge.

Every successful design accumulates infrastructure, assumptions, operational practices, and dependencies. These structures enable adoption and allow ecosystems to grow. Yet they also define the boundaries within which future evolution takes place.

The next generation appears because every architecture eventually encounters problems it was never designed to solve. Blockchain history may therefore be understood not as a competition between independent systems, but as a chain of inherited constraints.

Each generation expands the design space, then becomes part of it. And somewhere within the environment it created, the next architecture begins to form.

TL;DR

🟥 MiCA-licensed firms are becoming visible across Europe. ESMA published an updated version of the Interim MiCA Register, consolidating records of authorised crypto-asset service providers across the EU in one place.*

🟥 Stablecoins are now a monetary policy and financial stability topic, not just a crypto topic. BIS Paper 170 highlights that stablecoin flows can have meaningful effects on FX markets and may increase monetary sovereignty risks, especially in emerging economies.*

🟧 The United Kingdom is setting a joint direction for tokenisation. The FCA and the Bank of England published a shared vision for tokenisation in UK wholesale markets and are seeking industry feedback.*

🟧 The Bank of England clarified the boundaries and requirements of DLT. The DLT Innovation Challenge 2025 Final Report was published, with key focus areas including settlement finality, scalability, network and asset control, and interoperability.*

🟥 The UK sanctions track targeted crypto directly. The UK announced sanctions relating to HTX, with reporting emphasising suspected links to Russia-connected financial networks and potential sanctions evasion.*

🟧 The US market structure debate reignited. The Digital Asset Market Clarity Act of 2025 passed the House in July 2025. In May 2026, the debate focused on topics such as the boundaries of yield-like rewards on stablecoins. The matter moved through negotiations in the Senate.* *

🟧 US derivatives are moving onto a regulated path. With steps by the CFTC, a regulated route is opening for bitcoin perpetual futures in the US, which could gradually pull offshore derivatives volume into onshore, supervised structures.*

ZKProofs are amazing in general, but they are especially handy when it comes to blockchains. They allow private operations on shared states, make anonymous transactions possible, or achieve very high scalability even with very slow blockchains. Thus, blockchains are adopting it more and more, and today, there are even blockchains focused solely on ZKProof verification.

Nevertheless, the reality is not always this simple, and there is a huge problem of using any blockchain as it is to verify ZKProofs. The problem is not about potential attacks or the costs associated, but a direct risk in the consensus layer underlying.

In this article, we will discuss the current state, what is the problem, and what are potential solutions.

Background - Why is ZK adopted more?

It is no secret that ZK is used more and more by blockchains, or even constitutional applications. The obvious advantage is privacy, where ZK offers a nice way to build privacy preserving apps in many different use cases. Another important point is the scalability, where verifying a ZKProof is usually cheaper than repeating a computation as it is.

Let us look a bit more into the last point: Normally, ZKProof verification is known to be expensive, and even on a strong machine, verification can take a few hundred milliseconds. This may not sound like much, but compared to most EVM applications, this is much more than what it takes to execute a single smart contract call.

However, ZK has a huge advantage, which is that when working with zk-SNARKs (a specific type of ZKProofs), the verification time is independent of the computation size. This means that any computation can be verified in the exact same constant time, regardless of how hard the initial process was.

This is the basic observation behind ZK rollups or ZK based distributed applications. Instead of making the blockchain verify a lot of small proofs, these networks combine their ZKProofs into a single, all verifying ZKProof. Then, since zk-SNARKs have a constant verification time, the verification cost per proof decreases, and many TXs are “settled” on the blockchain simultaneously.

What did this result in?

Realizing this huge performance advantage, a lot of blockchains started using ZK based optimizations. The first and most well-known was of course Ethereum, where most of the TX volume moved from the original Ethereum to rollups in a very short time.

This transition resulted in blockchains becoming mainly responsible only for ZKProof verification, instead of general computation. Individual TXs are still and will always be used, of course, but as ZK matures more and more, performing everyday operations natively becomes more and more rare.

However, usage of a general-purpose blockchain for ZKProof verification actually creates a previously unconsidered risk on the consensus.

The Hidden Peril

ZKProofs are usually honest, meaning that no rollup cares to send an invalid ZKProof on chain. Thus, validators get the exact same result after each verification call: “The proof is correct”.

You may think here that this is also what we have with regular TXs. No one has infinite funds to burn on gas, so almost all TXs happening on Ethereum are somewhat valid. The crucial difference is that these TXs change the Ethereum state in a previously unknown way.

For instance, assume that you are sending money to a friend on Ethereum. It is very possible that you did not have enough balance or the TX was flawed in some other sense, so verifying your TX was valid is crucial. Nevertheless, the validator may easily suppose that you are just sending honestly, since you have nothing to gain from burning your gas fees on a meaningless TX. However, even with this assumption, the computation that validators need to perform does not really change. Your TX does not include your or your friend’s balance after the execution, and the only way of updating the state correctly is to perform the actual computation, which is the same as verifying your TX.

Now coming back to the ZK case. In ZKProofs, the state is updated independently from the verification phase. Basically, you send a proof and the new state to the chain, and only if your proof verifies, the chain updates the state as you wished. However, the verification part of the computation reveals nothing about this state update, and it is very possible for a validator to just assume your proof was honest, and update the state without verifying it.

To solidify with a real life example, think of ZK rollups. All the proofs of a rollup are sent by a single public key, and it is immediate to verify that this proof was generated by them. Since rollups are always honest and their proofs always check in, a validator can simply bypass the verification process when it sees this public key, and update the state directly.

Simply, the fundamental problem of ZK is being too easy to verify. This is just a fun way of saying it, of course. Formally, the imbalance between costs of ZK verification and the ease of understanding the state afterwards causes this dilemma. The validator has a lot to gain from not verifying a ZKProof, and they have very little to gain from verifying it. They can just assume it was valid and update state accordingly, which works perfectly in many cases.

This creates a massive risk for the consensus layer of the network. As validators have means and reasons to escape from expensive verification costs, the chain evolves into a state where no one actually verifies anything. The consensus layer works perfectly, but it secures nothing.

Native Solution Ideas

The simplest solution is to offer false proofs. If a rollup, realizing this potential attack on their system, introduces false proofs regularly, then validators will be forced to verify each proof, since they do not know which ones are valid. This is actually very similar to Solana’s solution with their Proof of History model: The random timing of invalid hashes forces validators to verify each hash taken in a history proof. Note that this is just an analogy, and Solana consensus does not include any ZK.

However, this native solution has two obvious problems. The first is the costs associated with sending false proofs, since the network still takes gas fees even when the proof is not valid. (Realize here that sending a very-easy-to-see false proof is also a problem, so a correct execution must send something that is very similar to a ZKProof and only understood at the very last possible minute). Thus, without defining clearly what a false executor would gain from doing so, it is very hard to convince people to just burn their gas fees on something that is useless for them individually, but just securing the chain in the long run.

The second problem is the potential vote stealing of validators. This is more subtle, so let’s look a bit closer at.

Why do I verify at all?

As said before, ZKProof verification is too costly compared to directly updating the state. Think that there exists a magical oracle, that just verifies proofs on your behalf, and sends a bit (true / false) as the answer. Why do you verify at all?

Unfortunately, networks should be designed for validators trying to optimize their costs, and a validator, seeing that it is impossible to be slashed by not doing the verification, can be very tempted to use such a service. Moreover, any realtime RPC can actually be seen as this service, and a clever client can use information across the gossip network to build a mock-verifier that just steals what others think on the proof. Even a small clue is enough to conclude the state of the proof, and errors can be tolerated occasionally: Even if a validator verifies something incorrectly, since only having two options for each proof, it is very easy to find the problem before the next block ends. So if the error is rare enough, verification costs of the ZKProof can be avoided totally.

Here, note again the important difference between regular EVM contract calls. Most contract execution happens just to understand how to update which state, which also depends on a lot of the existing information on the state. The case is not the same with ZK, and the only information that we need from that expensive computation is a single bit, telling us if the proof was valid or not.

So what does this tell us?

The attack scenarios described here are not immediate. They are definitely a real risk, especially on the long run, but ZK is not that much adapted yet. Nevertheless, we should think now if we want to avoid this in the future, so this is definitely something that must be discussed.

Moreover, there are already a lot of potential solutions offered to this problem. Some simple ideas may be introducing additional slashing for invalid verification or using commitment & reveal schemes to force validators to vote before seeing anyone else’s vote. Decreasing costs of verification is also a huge relief on the attack.

I guess the main idea of this article is that changing very simple parts of a design can break things fundamentally. Verifying a ZKProof instead of Solidity computation looks like an equivalent case: Both of them are just code. Yet, only one results in drastic effects in the consensus layer, which may even result in a fully centralized network in the long run.

In a nutshell, do not use concepts as it is, but think a little harder before you adopt a change. Is your architecture ready for this update, or did you just oversimplify?

The world’s largest exchange, the largest custodian, the largest validator, and the largest RPC data provider… FTX, once the “largest” of everything, caused one of the greatest tragedies in the crypto industry with its collapse. This downfall was not merely a result of poor management or accounting errors; it was the manifestation of a systemic risk where a chain of minor errors escalated into a catastrophic crisis.

In the FTX model, the exchange (platform), custodian, market maker (Alameda), and data providers (validators and RPC providers) were all tied to a single center. The entity holding the keys to the assets was the same as the entity matching the orders; furthermore, the largest validator of the most important blockchain networks where these assets resided and the infrastructure providing the data flow were also part of the same structure.

The history of financial markets is a history of crises created by unchecked power and the regulations written in their aftermath. For this reason, the separation of the “Legislative, Executive, and Judicial” branches, the indispensable building blocks of modern states, manifests itself clearly in traditional capital markets through the trio of: The Exchange, Clearing Settlement-Custody, and Data Providers. To protect investors and eliminate systemic risk, the Capital Markets Board of Türkiye (CMB) separates these three branches with sharp lines. Borsa Istanbul is merely a platform where orders are matched; Takasbank handles the clearing of assets, and the Central Securities Depository (MKK) handles ultimate custody. Data providers like Bloomberg compete with other industry stakeholders to ensure accurate data flow. No single actor can exercise absolute dominance over the entire system. These actors are legally prohibited from having organic commercial ties; the law protects this non-affiliation, and the CMB strictly enforces it.

The “Rings of Power” in Crypto: Exchange, Custodian, and Data Providers

As Türkiye establishes its legal framework for Crypto Asset Service Providers (CASPs), it must replicate the “Exchange, Clearing-Custody, and Data Provider” structure of traditional markets. Establishing “Exchange, Custodian, and Data Provider” branches for the crypto market and drawing rigid regulatory boundaries between them is essential to secure not just the interfaces, but the very capillaries of the system.

The standards set by the CMB for platforms and custodians in current CASP regulations are highly valuable. However, for these standards to be fully effective, the principle of “organic and theoretical separation” must not be compromised. To ensure the system is not susceptible to FTX like crises, it is imperative that a crypto asset trading platform has no organic ties, overlapping ownership structures, or background privileges with the custodial entity. The platform should remain solely a technology provider and matching engine, while custodial services are carried out by independent, insured entities isolated by the CMB. Otherwise, in a moment of crisis, the impulse for a platform to finance its own operational risks with funds from the custodial vault cannot be prevented.

The Ecosystem’s Blind Spot: Data Providers and the RPC Providers

Regulatory discussions often revolve around the financial ratios of exchanges and custodial infrastructures. Yet, there is a critical third pillar that forms the infrastructural backbone of the ecosystem, currently residing in a “gray area” outside of regulation: Data Providers and RPC (Remote Procedure Call) Infrastructure Providers.

RPC nodes serve as the communication bridge between a user’s wallet (or an exchange’s interface) and the blockchain itself. Updating price feeds, displaying user balances, or sending a transfer order to the network depends entirely on the health of this infrastructure. The fact that data and infrastructure providers are not yet defined as service providers in current regulations leaves the Turkish crypto sector vulnerable to external shocks and asymmetric risks.

Currently, CASPs procure their RPC and data provider needs from foreign companies, mostly registered in offshore jurisdictions. To put it clearly: you are accessing the Ethereum blockchain through data centers located in the deserts of Dubai, owned by a company registered in the Cayman Islands.

The Impact of Foreign Dependency on Systemic Health: The “October 10 Incident”

One does not need theoretical hypotheses to understand the disasters that lack of oversight and foreign dependency in data provision can cause; the “October 10 Incident,” etched into the industry’s memory, is the most concrete proof.

On October 10, a day of extraordinary stress and sudden volatility in global markets triggered by President Trump’s announcement that he might cancel a planned meeting with President Xi, major foreign RPC providers, used by almost all local platforms, resorted to capacity throttling and filtering to protect their own systems. Consequently, access to blockchains from the country nearly ground to a halt. This paralyzed operations in Türkiye and paved the way for the victimization of hundreds of thousands of investors. Orders that could not be executed, crashing global cryptocurrencies, and the access crisis resulted in the transfer of tens of millions of dollars worth of assets held in Türkiye to foreign entities.

The technical breakdowns during the crisis were as follows:

• Access Barriers and HTTP Errors: Foreign infrastructure providers implemented aggressive Rate-Limiting on queries originating from regions like Türkiye to ease server load. Users faced HTTP 404 and HTTP 429 (Too Many Requests) errors and saw their balances as zero. Investors in Western Europe and North America were prioritized over those in Türkiye, proving that foreign dependency in data provision carries a heavy price.

• Critical Latency Spikes: Query response times, which should normally range between 50 ms and 150 ms, spiked to over 5000 ms or resulted in direct timeouts. This paralyzed arbitrage mechanisms and price-update bots.

• De Facto Censorship and Mempool Disconnection: At the most critical stage, orders for margin top-ups or urgent position closures could not be transmitted to the Mempool (the blockchain’s waiting room). The prioritization of global VIP customers and central geographies by foreign providers meant that the orders of Turkish investors were effectively blocked from entering the network a form of de facto censorship.

However, companies capable of providing all the data required by CASPs have already emerged in Türkiye and are serving globally. By utilizing the services of Turkish Data Providers located within the country, both CASPs and the national economy can access services that offer:

• No risk of censorship or access denial.

• No risk of data sovereignty violations.

• The retention of tens of millions of dollars in foreign exchange within the country.

• High-priority, native-language support instead of low-priority foreign support.

• Full compliance with the regulations of Turkish courts and regulatory authorities.

Policy Proposal: The “Data Sovereignty Branch” Must Be Recognized

To eliminate systemic risks and complete the CMB’s vision of “separation of powers,” data providers must be brought into a legal framework. For the sustainability of the Turkish ecosystem, three fundamental rules are proposed to regulators:

I. Definition and Licensing of Service Providers Companies providing data flows, RPC services, and wallet integration infrastructure should be defined as “Crypto Sector Infrastructure and Data Providers” in CMB communiqués. These institutions should be subject to minimum standards for cybersecurity, redundancy, and SLAs (Service Level Agreements/Uptime guarantees). Rather than defining these companies as CASPs (like custodians or exchanges), it would be more appropriate to define them similarly to the electronic money service provider licenses issued by the Central Bank of the Republic of Türkiye (CBRT).

II. Domestic Entity Requirement Providers offering critical infrastructure services to CASPs operating in Türkiye must be required to be joint-stock companies (A.Ş.) incorporated in Türkiye. This ensures a legally accountable entity is in place in the event of service interruptions or intentional restrictions.

III. Data Sovereignty and Local Server Requirements The sovereignty of financial data is a component of national security. It should be mandatory for RPC servers that process the transaction data of Turkish users, transmit them to the blockchain, and maintain the infrastructure to be physically hosted within the borders of Türkiye. This step ensures compliance with the PDPL (Personal Data Protection Law / KVKK) and prevents the system from being affected by foreign-sourced interruptions during international crises or global internet bottlenecks.

Outro

The principle of “Don’t trust, verify,” which lies at the heart of blockchain philosophy, applies not only to software code but also to the institutional architecture of the market. The health of a sector depends on creating an ecosystem where actors can audit one another and no single institution can unilaterally determine the fate of the system.

A model where the branches of exchange, custody, and data provision are strictly separated, supported by local servers and data sovereignty, will contribute to the vision of transforming Türkiye from a mere “consumer base” into a secure “Financial Hub” in the global crypto market. It must not be forgotten: those who entrust their infrastructure to others will always find their financial independence hanging by a thread.

TL;DR

🟥 The UK crypto perimeter is becoming clearer. The FCA opened consultation on draft perimeter guidance setting out which activities will require authorisation under the new regime, and pointed to a September 2026 application timeline. *

🟥 UK also tightened enforcement on the ground. The FCA ran its first multi agency operation against illegal peer to peer crypto trading in London and issued stop notices at eight locations. *

🟧 UK legislation is being fine tuned. HM Treasury published a draft amending instrument for the Cryptoassets Regulations 2026, aiming to provide more clarity for stablecoin payments and remove barriers in certain use cases. *

🟧 Europe put tokenisation at the centre of its payments strategy. The Eurosystem published a comprehensive payments strategy that includes its approach to tokenised settlement assets, including tokenised deposits and stablecoins. *

🟧 Europe is sharpening its financial stability lens. The ECB Macroprudential Bulletin discussed euro stablecoins and detailed risk channels such as reserve structure and stress transmission through the banking system. *

🟧 The US is drawing a line on broker dealer expectations for on chain user interfaces. An SEC Trading and Markets staff statement explained how certain interfaces that help users prepare crypto asset securities transactions using self custody wallets may be assessed under broker dealer registration requirements. *

🟧 A US prudential signal on stablecoins. The FDIC approved an NPRM to implement GENIUS Act requirements and standards for permitted payment stablecoin issuers, covering reserves, redemption, capital, and risk management. *

🟧 Australia is preparing for a licensing era. ASIC published an 18 month implementation roadmap for the Digital Assets Framework Act and set out a standards and guidance timeline leading to a 9 April 2027 start. *

🟧 Dubai is framing retail access to crypto derivatives. VARA announced a new rulebook framework for exchange traded derivatives that includes suitability checks, leverage limits, and margin controls. *

🟧 Kenya launched public participation on VASP rules. The National Treasury opened a nationwide consultation on the draft Virtual Asset Service Providers Regulations 2026. *

April: Bite sized updates

Türkiye

🟧 A tax compliance signal with long runway but high operational impact. OECD’s updated CARF plan indicates Türkiye’s 2028 target, pointing to future requirements around client matching, reporting data models, and audit trail quality. *

🟧 Remote identity verification and electronic contracting rules were extended to cover CASPs. A change published in the Official Gazette expanded the remote onboarding framework and electronic contracting standards to crypto asset service providers, pushing onboarding and record retention closer to capital markets standards. *

🟧 Yapı Kredi received SPK establishment approval for a crypto asset platform. *

Next month watchlist

UK: CP26/13 consultation deadline is 3 June 2026. *

UK: Watch how the draft amendments to the Cryptoassets Regulations 2026 affect stablecoin payments, especially cross border and B2B scenarios. *

US: Track the FDIC GENIUS Act NPRM comment process and coordination with other banking authorities. *

EU: Follow how the Eurosystem payments strategy translates into technical implementation steps for tokenised deposits and stablecoins. *

People keep asking me the exact same question about Bitcoin, mostly because our traditional financial labels just do not stick to it. Is it a commodity? Is it money? Is it some emerging type of reserve asset?

In my opinion, the honest answer is that Bitcoin touches all three categories, but with major caveats. No wonder the debate never ends. I believe everyone is staring at the exact same asset but looking through a completely different lens.

The Commodity Illusion

When I look at Bitcoin from a legal and functional standpoint, it closely resembles a commodity. It trades based on pure scarcity. Unlike a stock, there is no CEO, no quarterly earnings, and no cash flow. You are not buying into a business model. Instead, you are buying into a hard-capped supply that anyone can verify on-chain. In my view, it acts a lot more like gold than a corporate bond.

But calling it a commodity has never felt like a perfect fit to me. Traditional commodities like oil, copper, or wheat actually get consumed. They get burned in engines or baked into bread. Bitcoin completely lacks that physical industrial demand.

People hold it purely on the belief that a decentralized, scarce digital asset will only become more valuable over time. So yes, I think it fits the commodity bucket better than most other labels, but it is a truly bizarre one.

The Ultimate Test of Money

The money argument is where things always get complicated. Die-hard holders insist Bitcoin is money, and I admit they have a valid point. You can self-custody it, send it globally without a bank, and even spend it in a few places.

But from my perspective, real money is the yardstick we use to organize our daily lives. We price debt, pay rent, and negotiate salaries in dollars or euros, not satoshis. You might trade Bitcoin, but you still think in your local fiat currency. I always argue that this mental unit of account is the true test of money, a test Bitcoin has not passed yet.

You can actually see this dynamic play out inside the crypto ecosystem itself. When traders want to take on risk, they buy Bitcoin. When things get shaky, they flee to dollar-pegged stablecoins. Ironically, in a market built to escape the fiat system, I see the greenback acting as the ultimate ruler.

The Dollar and the Debt Plumbing

This brings me to the dollar. Its dominance is not just a byproduct of US military or economic might anymore. It is a massive network effect. Global trade is invoiced in dollars, commodities are priced in it, and the financial plumbing is built entirely around it. It is a self-reinforcing loop. Companies use dollars because their suppliers do, and governments hold them because the markets are incredibly deep. Bitcoin is expanding within this world, but I do not see it displacing the dollar anytime soon.

Treasuries highlight this contrast even further. I often see people lump cash and US debt together under the “dollar system,” but they play entirely different roles. Dollars are for spending. Treasuries are what nation-states, central banks, and mega-corporations hold for safety, yield, and scale.

Treasuries are the ultimate collateral. You can trade them in massive block sizes without moving the market, and they actually pay you to hold them. This is a critical feature that I feel Bitcoin advocates often downplay. A true institutional reserve asset needs to be a stable, yield-bearing bedrock. Treasuries fit that bill perfectly. Bitcoin does not.

Digital Gold and the Reserve Debate

However, Treasuries carry counterparty risk because they rely on the US government to pay its debts. For the traditional financial world, that trust is rock solid. But it inherently ties the asset to a state-based system. To me, Bitcoin’s entire appeal is its complete divorce from that system. There is no issuer, no central bank, and no promise to pay.

To traditional investors, that lack of backing makes it terrifyingly abstract. To others, especially in an era of weaponized finance and ballooning sovereign debt, I believe that is precisely the selling point.

This is exactly why the “digital gold” narrative refuses to die. Gold matters because it is scarce and it is nobody else’s liability. When trust in fiat wavers, gold shines. I think Bitcoin taps into that exact same psychological vein.

Obviously, gold has a massive head start. Central banks understand it, it has a millennia-long track record, and it does not drop 10% on a random Tuesday. If you try pitching Bitcoin to a conservative pension fund committee, you will quickly see why gold still reigns supreme in traditional circles. But Bitcoin has modern advantages: it travels at the speed of light, divides infinitely, and does not require armed guards or heavy vaults. The overlap between the two is very real.

What About the Rest of the Market?

You might be wondering why I spent this entire piece focusing solely on Bitcoin when there are thousands of other crypto tokens out there. It is a fair question. The decentralized market is huge and constantly evolving.

However, the way I see it, Bitcoin still holds the absolute lion’s share of the market, easily representing around 70% of the true macroeconomic mindshare and capital in this space. For now, the strongest, most resilient arguments regarding monetary policy and reserve assets strictly belong to Bitcoin.

As the ecosystem matures, I expect we will start seeing similar conversations evolve around other major tokens. But today, if we are talking about disrupting gold or challenging the dollar system, Bitcoin is the only asset truly sitting at that table.

Ultimately, I view Bitcoin as a hybrid. It is a commodity in the eyes of the law, “gold” in the minds of investors, and sits somewhere between a speculative bet and a reserve asset on a global level. It has not overthrown the fiat system yet. But it has forced the old system to respond to something entirely new: a scarce, borderless, digital asset with no issuer and no off-switch.

Digital sovereignty is usually discussed as control: where systems run, who operates them, and under which jurisdiction they exist. But in globally distributed systems, control is not the only question. The system can be independent, yet access to it can still depend on infrastructure that is not.

Blockchains Solved Trust, Not Access

In Down the Rabbit Hole series, I discussed the fact that blockchains were designed to solve a specific problem: coordination across participants that do not trust each other. However, this coordination property applies only to the internal mechanics of the network. The layer in between the users and blockchain, the interaction, requires a different kind of coordination.

RPC operations such as submitting a transaction or querying state are not directly part of consensus. In principle, any participant can connect to any node and engage with the network directly: the network does not impose any restrictions on how it is accessed. So, applications and users rely on interfaces that expose the network in a structured way, abstracting away the underlying nodes and standardizing how requests are handled. These interfaces do not alter the protocol but define how the protocol is reached. As a result, the system removes trust from verification while leaving access dependent on the infrastructure that mediates interaction.

The Hidden Centralization: RPC Layer

In practice, this access layer does not remain distributed in the same way as the underlying network. That is, while the protocol allows any participant to connect to any node, most interactions are routed through a limited set of RPC providers. These providers operate large-scale infrastructure, maintain highly available nodes, and expose standardized endpoints that applications can easily integrate with.

However, in time, they became the default interface to the network because of the operational-level decisions. Running and maintaining nodes at scale requires resources, coordination, and reliability guarantees that individual participants often choose not to manage themselves. From the perspective of applications, this abstraction simplifies interaction: instead of managing connectivity, synchronization, and performance, they rely on a stable interface that behaves predictably.

Yet this is another structural asymmetry. The network itself remains distributed but the paths through which this network is reached become increasingly concentrated. Requests are served, transactions are propagated, and the system appears to function as expected. But the distribution of responsibility is no longer aligned between the protocol and its access layer.

A system that is decentralized in its core can still exhibit centralization at its edges. And since interaction depends entirely on these edges, their structure begins to define how the network is experienced in practice.

Why It Matters Now

This structure does not immediately create visible problems. RPC providers operate close to the core network, maintain synchronized nodes, and optimize for availability. Applications, without needing to manage underlying complexity., send the requests with low latency, their transactions get propagated efficiently. This model prioritizes performance by concentrating infrastructure where it can be maintained most effectively. These providers deploy the nodes in regions with strong connectivity to the peer-to-peer network, often within large cloud environments that provide predictable uptime and scalability.

However, access paths to the blockchain networks begin to overlap especially under stress. Since infrastructure is deployed in similar environments, relies on similar providers, and operates under similar constraints; though the protocol distributes responsibility across independent participants, the access layer tends to align around a narrower set of dependencies.

Under normal circumstances, this alignment is invisible. But as the world becomes on-chain over time as we see today, the architecture and its flaws become visible. Latency increases when requests travel across longer distances, rate limits appear when demand concentrates on shared endpoints, and hence failures do not remain isolated when infrastructure dependencies overlap; they propagate across providers that rely on the same underlying systems. At that point, the distinction between a protocol issue and an access issue becomes less clear from the outside.

The network has evolved, but the way it is reached has not. As Maxim Gorky once wrote, “In the carriages of the past you can’t go anywhere.” The protocol moved toward decentralization, and yet the access layer remained aligned with earlier models.

Sovereignty as Presence

At this point, sovereignty is no longer a question of control over the system itself, but of position within it.

Blockchains do not require local ownership to function, their state is maintained globally and operation does not depend on any single region. Their conditions under which they are accessed change over regions. When access depends entirely on external infrastructure, the interaction becomes indirect. Requests are routed through distant systems, shaped by their latency, limited by their capacity, and exposed to their failure modes. These constraints are not part of the protocol at all, yet they have the power to define how the protocol is experienced.

Introducing local infrastructure does not change the protocol but changes this vicious relationship. Running nodes within a region alters how that region connects to the network. Requests no longer need to traverse the same paths, depend on the same providers, or align with the same infrastructure assumptions. The interaction layer begins to reflect the environment in which it is used, rather than an external one.

At the same time, this is not only an access-level change. Additional nodes contribute to the peer-to-peer layer, introduce new propagation paths, and reduce the concentration of network activity around specific regions. The topology shifts slightly because participation changes, leading to a less uniform system.

In this sense, sovereignty is not defined by ownership of the system but by whether participation introduces new structure or remains dependent on an existing one.

A region that relies entirely on external access does not shape the network; it follows it. A region that introduces its own infrastructure does not control the network, but by changing how it connects and participates, it becomes part of how that structure is formed.

Web3, or the next internet if not too bold to say, needs to have many different layers: storage, communication, light client, oracle, prover network… But the first one, that has started this whole journey, was the consensus layer.

But how much did we build so far, how much is still to be done, and how close we are to completing it?

The Reason

Consensus is the idea of representing a common opinion online. It is required to allow multiple parties to interact and come to a conclusion in a reasonably short time. Starting from Bitcoin to Ethereum, most blockchains focus on this first layer of Web3.

In an ideal consensus layer, we must be able to:

1. Trustlessly order events happening on the network,

2. Prevent any censorship of any transaction,

3. Work in real time, meaning there is no significant delay in between interactions.

The reason behind these needs is to prevent single entities from controlling all the online interactions. As long as actions are ordered in a decentralized way, without any trust assumptions or censorship, we can make sure that the information is not controlled by a single party. Of course, other layers are also a must, but let us focus only on consensus for this article.

Note here that the consensus layer does not need to do any high performant computation. Of course, some amount is necessary to allow state updates, but we do not necessarily need the consensus layer to perform heavy actions on-chain. In the long run, client side computation and prover networks are designed to free the consensus layer from high workload.

This point is somewhat controversial, and many still argue blockchains can enable enough computation power without any zero-knowledge or fraud proof-like solution. To me, this is not a question of can, but rather should. In perfect designs, each layer must be specialized for a single end-goal, and consensus and computation are very different concepts. Moreover, no single computer can perform as efficiently as a distributed computation protocol.

Nevertheless, consensus networks need to be performant, even if they are not responsible for the entire computation. The hard question is, how to enable efficient systems with perfect decentralization?

The Current Status

Over the last years, we have seen significant development in this consensus area, especially in performance and decentralization of the network.

The performance of the network depends on a lot of parameters: number of transactions the network can handle per second (TPS), the total computation (or equivalently verification) power the network can provide (GPS - gas per second), and of course, the update frequency of the state (block time & finality).

It is a fact that no blockchain is as fast as a single high performance server at the moment (or even slower than a common PC usually), but the improvement is drastic. Only ten years ago, finality that lasted less than ten minutes and TPS higher than 100 would be considered amazing. Now, we can achieve subsecond block time and hundreds of thousands of TPS, which is much better than we have imagined.

Nevertheless, improvement is a must. Some interesting areas to work on may be:

1. Multi-block producer schemes, where all validators of the network are used in parallel to generate blocks, not a single one for each slot,

2. Sharding and distribution of sources, to parallelize the workload to multiple nodes simultaneously,

3. Local consensus designs, where not the entire network is used for each decision, but subdivisions are made based on local trust assumptions.

There are already promising projects working on each subject, so my guess is that the performance of the consensus layer is close to becoming perfect in the near future.

Elephant in the Room: Decentralization

Decentralization is the bigger problem: Most people still argue that Bitcoin is the most decentralized decision mechanism we have had so far (I do not argue fully, but it has some truth in it). To clarify a little more, we have 3 important problems that we still couldn’t solve:

First Problem: Censorship

Even if a complete censorship of a transaction is not feasible, it is possible for strong entities to delay the execution of chosen actions in our current designs. Eventual censorship resistance is a strong property, but we need to make sure that all parties have similar delays while waiting to get included in the network. The important observation here is that even a small delay may result in a drastic outcome in sensitive use cases, e.g. finances.

This problem is hard to solve since validators are real entities and subject to law and authority. Thus, the consensus needs to find a way that validators can act freely while also being held responsible for their actions. More than anything, this is actually a privacy problem, which can only be solved with private consensus designs (or private blocks).

Second Problem: MEV (maximal extractable value)

This is the name of validators wrapping TXs with opposite orders to make a net profit from it. For instance, if a significant amount of Bitcoin is purchased on the chain, the validator may buy just before this TX, and sell immediately after, to make a net profit. The concept is much bigger than finance, since basically any information change on the network can be used for some sort of gain by validators, who have earlier access to this information than the rest of the world (information asymmetry).

I do not say all sorts of MEV is dangerous or must be prevented. The problem is more that we do not have a competitive design against it, i.e. you are subject to MEV on all of your actions if you are not able to pay enough fees for private channels. This decreases the mass adoption of blockchains significantly and makes the UX even worse. In any case, information asymmetry is dangerous, as it allows centralization of power in the long run.

Third Problem: Centralization of the validator set

Right now, our decentralization ideas are all based on some sort of economical value, either computation power or blockchain tokens. The more money you possess, the more say you get to have on the network. It is not trivial to see how this can even be changed at all, since everything comes to money in the end. However, a nice property that the chain may provide would be somehow including geographical distribution in the backbone of the consensus, so that the network is incentivized to be as distributed as possible in the world. Right now, this is mostly achieved through external incentivisations (e.g. delegation programs), which does not provide any long term security.

In a different perspective, consensus mechanisms should be able to capture the distribution of opinions in the real world better than just modeling it with economical incentives. Blockchains are right now based on the idea that each party is only trying to maximize its short term gain, which is not always true in real life. Can a better modeling be designed?

Conclusion

I think the main idea of this whole story is that: We do not care about decentralization as much as performance at the moment.

This is sad, but I guess normal, since no new technology can replace the older without matching the bare minimum. Until very recently, the performance was not close to being enough, but this is not true anymore.

Thus, I hope we will see bolder development on the decentralization of the consensus layer in the coming future.

Or else, what is the difference between web 2 and 3, right?

People think privacy in a single direction, but this is not very accurate.

Privacy is a complex tool, and it is very possible that you use it less effectively just because you miss some important angle of it.

TL;DR Use cryptography better to make your application cooler.

Through this article, we will touch 5 key takeaways that are usually missed by application owners.

Let’s explore them.

First of all, private data

Private data is simple: It is what you get when you encrypt something.

Regardless of your storage, once you encrypt with a secure key, it becomes private. Once encrypted, you can keep it in your own PC or upload it to the blockchain, there is no difference.

This point is important: You do not need to keep your data private, but only your encryption key. This is a very common mistake: You cannot assume something is more secure just because the access is not straightforward. This is not how cryptography works (check out Kerckhoffs’s Principle).

1^st Takeaway: Keep your encryption key secure, not your data.

Yet, plain encryption is not really flexible, and it has limited use cases. For instance, if you are interested in storing your files, documents, or photos; a very good solution can be to encrypt them with a key and upload it to the blockchain. This makes sure that as long as you keep your key, you can access your files anywhere any time.

This use case has 2 obvious flaws:

The first is that only you can execute on your data. You cannot really share your files with anyone or run an algorithm on it. If you are interested in only storage, no problem, but not many products are that simple. Let’s move on from this problem for now.

The second is that the key is a single point of failure: If you lose your key, everything is lost. Or if someone steals it, then they can access all files you have uploaded so far with it.

How to keep your key secure?

There is no perfect answer, but there are 2 practices that you should be well aware of to improve the problem.

One; Key rotation with deterministic key generation.

Do not use the same key over and over again, rotate it regularly. The observation here is that if different data points are secured with different keys, then the losing of a single key constitutes a smaller risk.

However, deriving and securing a random key each time can be costly. Moreover, if all keys are stored in the exact same way, then the security of the overall system does not really improve. Hopefully, cryptography again comes to the rescue.

It is actually enough if you have a master key that is only used during key rotation, and each other key that you use is a single way derivation of it: For instance, you can take the hash of your original key plus the hash of number of keys you had so far while deriving your next key. Since the master key is only accessed to regenerate keys, it is much less exposed, thus much more secure than each individual encryption key.

For instance, you can keep the master key in an offline device all the time, and only access it without an internet connection when you want to generate the next key rotation. Moreover, even if a temporary key is accessed, only some portion of data is at risk, since it is impossible to find other keys from the accessed one.

This solution requires you to store only a single key, as before, but decreases risk of theft dramatically. All thanks to hash functions.

2^nd Takeaway: Hash functions are great, and you probably do not use them enough. Key generation is a simple but powerful example.

Two; Public Key Encryption

In most systems, encryption is much more common than decryption. You may need to encrypt something each day, but you only decrypt when you want to reaccess it. So the question is, can we design a system to only use the key during decryption, but not encryption?

Yes, this also does exist! This is called public key encryption, which is very similar to signature in some sense (the exact opposite in fact). You have your private key, that you only use to decrypt your data, but all your encryption is done with the public key. In fact, even someone else can encrypt it for you!

This is quite useful. First of all, it decreases the amount of key usage you need. You get to be able to encrypt anything without risking your key at all. Moreover, you can even make your users or friends encrypt something for you.

3^rd Takeaway: You only need a key to decrypt, not encrypt. Use this for more flexible architectures.

How about private execution?

Private execution is an oxymoron as a term: Any execution you do is private if you do not share the data. But in the blockchain context, this actually means that you are able to make someone work on your data, without revealing your data to them. Small but important detail.

This is possible mainly with FHE (fully homomorphic encryption), MPC (multi party computation) or TEE (trusted execution environment). All these solutions have pros and cons; details really do not matter for this article. But beware of something important.

Even though private execution sounds cool, it is not a must in many cases. It addresses two very specific problems:

1. You are not able to perform the computation on your own, and you actually need someone else’s machine. Examples may be AI or genetic algorithms, not common in standard applications.

2. The computation should be done on multiple parties’ data simultaneously, without any party sharing their own. For instance, you want to learn the mean of some shared variable, but without knowing anyone’s specific data point (This is an amazing MPC use case by the way).

The point is that: If you are designing your own application, you probably do not need these two. Private execution is really an institutional use case more than anything, so the fact that it is not always practical is not a huge problem. I describe a powerful solution in the next chapter.

Nevertheless, in full honesty, no privacy solution is perfect without any private execution. Common examples are voting and blockchain payments. Faster FHE (that we will see in a relatively short time I argue) will enable amazing new use cases; but again, do not wait for them.

4^th Takeaway: Private execution is amazing, but not necessary in most cases. Keep reading to learn what is the alternative.

Finally, private proofs

As always, it all comes to zero-knowledge.

ZK is very common as a term in our ecosystem, but not many discuss its real potential. Being able to prove something in private is not a privacy solution, it is a completely different paradigm.

For instance, you may need to complete your ID verification in many contexts. But in very few, your actual data is relevant. The only thing you need is a proof that you have some information on your ID, like age, and nothing more.

ZK fills this gap. It allows us a way to design a system without any data at all. Data is not shared, it is not encrypted, it is not a secret. It is simply not there.

The main difference to conventional privacy tools is that most ZK systems have information theoretical privacy, meaning that they literally do not contain the information inside. This means that no attacker, even with quantum computing or an ultimate computer, can never ever get your data out of your proof. This is thanks to entropy and information theory.

So whenever you need to do something with your data, ask yourself this question: Do you really need the data itself, or you are just trying to get a conclusion from your data?

5^th Takeaway: Do not use your data, unless you absolutely have to.

Wrap up

Privacy is a complex concept. It is much more than we can describe in a short article.

The main point was that we do not use the technology we have as much as we can. So stop waiting for the next breakthrough, and discover the options you have in hand.

That’s why we are here to help.

🟥 The global compliance agenda shifted toward stablecoins. FATF stressed that stablecoins, especially in peer to peer transfers involving self custody wallets, increase the risk of sanctions evasion and money laundering. * *

🟥 OECD published countries’ transition targets for automatic information exchange under the Crypto Asset Reporting Framework. The list indicates that Türkiye is targeting the 2028 wave for starting international exchange of cryptoasset reporting data. This points to medium term preparation needs for exchanges and custodians around client identity matching, transaction data standardisation, and audit trail quality. *

🟧 Crypto infrastructure gained stronger access to banking rails in the US. Kraken Financial announced it received a Federal Reserve master account and will gain direct access to US payment infrastructure. * *

🟧 Positive signals in US derivatives markets. CFTC Chair Mike Selig said the agency is close to policy steps that would pave the way for crypto perpetual futures in the US in the coming weeks. *

🟧 Regulators in the Gulf are escalating warnings against unlicensed marketing. Dubai VARA issued an investor and marketplace alert related to two entities advertising under the MEXC brand. *

🟧 Stablecoin integration accelerated in institutional payment flows. Mastercard announced it agreed to acquire BVNK to connect on chain payments with fiat payment rails and improve interoperability. *

🟩 The DLT capital markets thesis became more tangible. Bank of Canada and partners announced they completed a real world tokenised bond issuance and settlement experiment. *

March

Türkiye

🟧 SPK Decision 18/617 extended CASP timelines, the new date has not been announced yet
With its 26 March 2026 Decision 18/617, SPK extended the timeline for platforms to sign custody agreements with custody institutions and submit them to the Board, and extended the operating authorisation timeline for CASPs listed on the Operating Entities List. The decision says the new schedule will be determined after custody institutions are authorised and custody services become widely and effectively available to platforms. * *

🟧 Remote identity verification and electronic contracting rules were extended to cover CASPs
A communiqué amendment published in the Official Gazette on 28 February 2026 extended the framework for remote identity verification and establishing contracts electronically to cryptoasset service providers, alongside investment firms and portfolio management companies. This means CASPs will need to standardise remote onboarding, electronic evidence generation, and record retention processes. * *

🟧 A new channel and workflow went live for CASP opinion requests, with stronger TSPB coordination

TSPB General Letter No 939 announced a workflow where opinion requests from CASPs listed on the Operating Entities List are first submitted to TSPB, consolidated where similar, and then forwarded to SPK based on an Opinion Assessment and Request Form. This introduces a process framework to make industry feedback more structured and improve submission quality. *

🟧 CARF readiness is a long runway signal with high operational impact, Türkiye is in the 2028 plans
OECD’s commitment list shows Türkiye’s target for its first CARF information exchange as 2028. This may require medium term preparation across exchanges, custodians and institutions around client matching, data models, reporting fields, and audit trail evidence. *

Global

🟥 FATF is making technical and governance controls across the stablecoin ecosystem more explicit. The report highlights expectations such as issuers being able to stop interactions with high risk addresses in secondary markets, stronger screening, and more robust customer due diligence at redemption. * *

🟧 The UK continues to adjust the client assets rulebook at handbook level as the broader crypto regime develops. In Quarterly Consultation Paper No 51, the FCA proposes consequential changes to keep the CASS framework workable for cryptoasset activities and the new regime. *

🟧 Scotland passed a bill that clarifies digital assets within property law. It will enter into force after Royal Assent. *

🟧 Pakistan said it formalised a statutory crypto regulatory authority through the Virtual Assets Act, including penalties for unlicensed activity. *

🟧 Sanctions compliance and Iran linked flows remain a core narrative in the US. Binance told a US Senate probe it found no evidence of accounts sending crypto directly to Iran and said it conducted a review. *

🟧 US political rhetoric is sharpening around stablecoin regulation and the banking lobby. Trump’s comments blaming banks reignited debate on the stablecoin framework and broader market structure discussions. *

🟧 US national cyber strategy explicitly mentioned support for crypto and blockchain security. This pushes product security and supply chain security for crypto infrastructure further into mainstream state policy. *

🟩 BIS published a paper on tokenomics and chain fragmentation. For institutional readers the takeaway is that security and scaling costs are structural, and a multi chain market may be durable. *

Next month watchlist

UK: as CP26 8 deadlines approach, watch how crypto related client assets changes are shaped. *

CARF: in 2028 wave jurisdictions, scope and reporting data fields should become clearer over time. *

US: once CFTC guidance lands for perpetual futures, exchange design and risk frameworks will likely update quickly. *

node101

Staying ahead in blockchain requires continuous learning. That’s why we publish in depth articles every week, covering topics from DeFi mechanics to scaling solutions.

The Divine Gap

In Michelangelo’s Creation of Adam, two hands reach toward each other. One extends with certainty, the other responds, almost meeting it. They are close, but they never touch.

It is a small detail, easy to overlook at first glance. Yet the entire scene is defined by that distance.

A similar structure appears in blockchains, although it is less visible.
On one side, there is the protocol. It operates as designed: blocks are produced, transactions are processed, and the system maintains its internal consistency. From the perspective of the network itself, nothing is missing. The state evolves, consensus is reached, and the chain continues forward.
On the other side, there is the user attempting to interact with this system. A transaction is submitted, a state is queried, a response is expected.

Between these two sides lies a layer that is often treated as secondary: the access layer, commonly exposed through RPC endpoints. It does not participate in consensus, nor does it define the rules of the system, but it determines whether those rules can be reached in practice.

When this layer performs well, it remains invisible. Interaction feels immediate, and the system appears cohesive. However, when it fails, the separation becomes apparent. Requests stall, responses do not arrive, and the system, although still functioning internally, becomes inaccessible from the outside.

The Illusion of Decentralization

Blockchains are often described as decentralized systems, and at the level of consensus, this description largely holds. Thousands of nodes participate in validating transactions, maintaining state, and securing the network.

However, interaction with these systems does not happen through direct connections to random nodes. In practice, most users and applications rely on a small set of RPC providers to access the chain.

This introduces a different structure, one that is less visible but equally important.
While computation and verification may be distributed, access is frequently concentrated. A large portion of requests flows through a limited number of endpoints, often hosted on similar infrastructure, in similar regions, and sometimes even within the same cloud environments.
From the outside, the system appears decentralized. From the point of access, it behaves differently.

This distinction does not immediately create problems under normal conditions. Systems operate smoothly, requests are served, and the abstraction holds. But it defines how the system behaves under stress. When access is concentrated, failure does not remain local: it propagates.

The Silence of the Chains

When users experience outages, the immediate assumption is that the chain itself has stopped.

In many cases, this is not accurate. The network may still be producing blocks. Validators may still be reaching consensus. State transitions continue to occur. Internally, the system remains active.

What changes is the ability to reach it.
During periods of high demand, RPC providers may begin to rate limit requests. Under infrastructure failures, endpoints may become unavailable. When multiple providers rely on similar underlying systems, these failures can occur simultaneously rather than independently.

The result is a system that is operational but inaccessible. Users retry transactions. Applications fail to load state. Interfaces appear frozen. From the user’s perspective, the chain is down. But in practice, it is not.

When infrastructure is uniform, failures tend to align. Instead of isolating issues, the system experiences them collectively. What appears as a protocol-level outage is often a reflection of shared dependencies at the access layer.

Architectural Darwinism

If access determines whether a system can be used, then its design cannot be treated as an afterthought. The question becomes not only how to maintain consensus or increase throughput, but how to ensure that the system remains reachable under varying conditions.

In environments where participants operate independently, systems do not fail in isolation. They fail according to the structure of their dependencies. When those dependencies overlap, failure becomes correlated.

Reducing this correlation requires diversity.

Provider diversity ensures that infrastructure does not depend on a single class of service. Geographic distribution reduces exposure to regional disruptions. Hardware diversity introduces variation in performance characteristics and failure modes. Network diversity separates routing paths and connectivity assumptions.

These dimensions do not increase performance in isolation. Though a system built on similar components may appear efficient, it shares the same points of weakness. But a system built on diverse components distributes those weaknesses, allowing parts of it to remain functional when others are not. In this sense, resilience is not a property of scale alone, but of structure.

Decentralization, when viewed through this lens, is not defined only by the number of nodes participating in consensus. It is shaped by how independently those nodes, and the systems that expose them, can operate when conditions change.

Closing the Distance

The protocol continues to do what it was designed to do. It produces blocks, processes transactions, and maintains state without interruption. What changes is whether that system can be reached.

The distance between a functioning protocol and a reachable one is small in implementation, but significant in effect. It does not appear in consensus algorithms or execution environments, yet it determines whether the system is usable at all. This distance is not removed by increasing throughput or optimizing performance alone. It is addressed through how the surrounding infrastructure is designed, distributed, and maintained.

Debates about decentralization usually start in the wrong place.

They ask whether centralization or decentralization is better, as if one must defeat the other. Real systems do not work that way. The real question is where decisions should live.

The systems that scale best usually do one thing well: they keep local decisions close to local knowledge, and they centralize only the rules that must be shared. That is the whole argument. Decentralization is not an ideology. It is a way to keep useful knowledge from being destroyed.

Centralization Is Weak for a Deeper Reason

Most critiques of centralization focus on censorship or power. Those matter. But there is a deeper weakness: the center cannot see the system as clearly as the people inside it.

From the top, reality arrives as reports, dashboards, and KPIs. On the ground, it arrives as context. A supplier sees a shipment risk before the spreadsheet does. A support team knows customers are angry about delivery timing, not product quality. An operator notices a pattern no formal report captures.

That is the real problem. Central planning does not fail only because it lacks data. It fails because the most valuable knowledge is local, tacit, and short-lived. By the time it reaches the center, part of it is already gone.

Why the Center Goes Blind

To govern at scale, the center has to flatten messy reality into comparable metrics. That makes control possible. It also creates blindness.

For instance, a company may obsess over one customer satisfaction score and pressure suppliers to improve it. Meanwhile the actual problem may be simple: delivery windows do not fit local routines. The metric is visible. The cause is not.

Time makes this worse. Central systems move on reporting cycles. Reality does not. In fast-moving environments, late knowledge is often just wrong knowledge. Asking for more data does not always help. Sometimes it only produces slower interpretation and more confidence in the wrong picture.

What the Solution Actually Looks Like

The answer is not chaos. The answer is distributed decision-making under shared rules.

Local actors should make the decisions that depend on local knowledge. The center should define the standards that keep the whole system compatible.

That distinction matters. Distributed control without coordination becomes fragmentation. Central control without local discretion becomes stupidity at scale. Good systems sit in the middle: they let people closest to the problem act quickly, while common rules keep everyone aligned.

This is already how many strong systems work. The rules are shared. The execution is distributed. That is not a compromise. It is usually the only way to scale without destroying the information the system depends on.

What This Means for Blockchain

This is what blockchains should be about. Not blind anti-centralization. Better coordination.

The interesting promise of a blockchain is not that it removes all trust. It is that it redesigns trust. The rules can be shared, execution can stay distributed, and verification can be public. In that sense, blockchain extends a pattern that already works elsewhere: centralize the rule set, distribute the activity.

But that promise can fail in practice. A system can look decentralized and still concentrate power.

For instance, transaction ordering can turn local informational advantages into extraction. Staking can quietly harden influence over time. So the real question is not how decentralized a system looks on paper. It is where decision power, operational dependence, and extraction power actually sit.

The Real Test

The best systems do not centralize decisions. They centralize rules.

That is why the real question is not whether decentralization is morally superior. The real question is what kind of coordination problem a system is trying to solve.

When knowledge is local and fast-moving, decisions should stay local. When failures are systemic and rules must be common, centralization at the rule level becomes necessary.

The best design is rarely maximum decentralization. It is the design that preserves local knowledge, coordinates behavior, and limits unnecessary concentration. Central planning is impossible not because people are stupid, but because no center can know enough, fast enough, in the form that matters.