In the series of articles I’ve been writing since the beginning of the year, we have always focused on where a blockchain is headed: the block production mechanisms, consensus, peer-to-peer latency, etc. However, for this article, I want to go back to something much simpler and rather old: the first blocks of a blockchain.

Like everything else, a blockchain has a beginning: a first block, or a genesis block, so to say. Then another block gets added to it, and another. In time transactions modify balances, contracts change their states, and the network gradually builds a history of everything that has happened since its beginning. At first, keeping this history is not much of a concern because there is simply not that much to keep.

The situation becomes different after years of operation as the blockchain may have produced millions of blocks and processed billions of transactions, while every new block continues adding more information to what was already there. We usually consider this history permanent because once a block becomes part of the canonical chain, changing what happened becomes increasingly difficult.

Bitcoin is a good example of how physical this problem eventually becomes. Today, synchronizing Bitcoin Core requires downloading more than 740 GB of blockchain data. Ethereum is more complicated because of its changing state: depending on the client and the type of historical state being retained, an archive node can require multiple terabytes of storage, with some implementations requiring considerably more than others.

However, the machines storing this history do not grow together with the blockchain. Storage is limited and expensive, while the chain is expected to continue growing indefinitely. At some point, node operators therefore have to make a decision: how much of the past do they actually need to keep in order to follow the present?

Leaving the Earlier Blocks Behind

A node synchronized with the tip of a blockchain does not necessarily need every previous version of its state to continue running. What matters for most of its daily operation is the current state and the information required to verify the blocks that come next. And at this point, node operators make use of something called pruning. Instead of keeping all historical information indefinitely, a node can remove data that is no longer required for its operation of adding new blocks to the blockchain. Depending on the blockchain and the way the node is configured, this can significantly reduce storage requirements without preventing it from remaining synchronized with the network.

How aggressively this can be done also depends on the architecture of the blockchain. Bitcoin Core, for example, can reduce its storage requirement from hundreds of gigabytes to only a few gigabytes in pruning mode while still validating the blockchain. In Cosmos SDK chains, operators can go even further with historical state: the software can be configured to retain only two-to-three blocks.

Nevertheless pruning does not make the current consensus less secure. A properly configured pruned node does not become a weaker participant simply because it cannot answer a query about the state from several years ago. It can still verify the information required by the protocol and follow the current chain with the same consensus rules.

All in all, from the perspective of a node operator, the decision is understandable. The blockchain grows continuously but hardware does not and keeping information that is rarely queried comes with a real and high cost. The node therefore follows the chain towards its tip and gradually leaves some of the earlier state behind.

But this creates another question: what happens when we want to go back?

What Happened Five Years Ago?

Suppose we want to understand exactly what the blockchain looked like at a particular block five years ago. This is not necessarily an unusual request. Financial records may remain legally relevant for years, an old transaction may become part of a court case, or an application may need to prove what a particular account or contract looked like at the time an agreement was executed. In such cases, knowing the current state is simply not enough. We may need to inspect an account balance, the value of a contract, or some other part of the state exactly as it existed when that block was produced.

Thousands of nodes might have received and verified that block at the time. Yet, years later, many of those same nodes may no longer be able to answer our question. They can be perfectly healthy, synchronized with the latest block and independently verifying the network while no longer keeping the historical state we are looking for.

Here, we need to distinguish between a few concepts that are usually put together when we describe blockchains as permanent: immutability, availability, and verifiability.

Blocks and states are connected through cryptographic commitments. Merkle-based structures, for example, allow enormous amounts of blockchain state to be represented by a relatively small root commitment. This means that even if we do not store the historical state ourselves, someone who preserved it can later provide us with a particular piece of information together with the necessary proof. We can then check that proof against the commitment preserved by the blockchain and verify whether the information really belonged to that historical state. In other words, we may depend on someone else to provide the old data, but we do not necessarily have to trust them about what that data contains.

However, a commitment to information and the information itself are different things. Let’s say if I give you a file together with its hash: you can verify whether the file is the one I originally committed to. If every copy of the file disappears and only its hash remains, however, the hash cannot recreate the file.

This distinction applies to blockchain history too. Cryptography can allow us to verify historical information once we obtain it, but cryptography cannot make unavailable information available.

In other words, immutability does not automatically imply availability.

Who Keeps the Past?

Of course, historical blockchain data does not normally disappear simply because ordinary nodes prune it. There are archive nodes specifically maintained to preserve historical state, while indexers, explorers and RPC providers make different parts of that history accessible to applications and users.

But this changes the decentralization problem in an interesting way. There may be thousands of nodes capable of independently verifying what happens on a blockchain today, while only a much smaller number of machines can answer what an account looked like five years ago. Those archive operators cannot simply invent another historical state and convince us that it is legitimate thanks to the cryptographic commitments.

They can, however, choose not to provide it at all.

This means that historical integrity and historical availability have different security models. Consensus and cryptography protect us against someone changing the past, while access to that past still depends on someone continuing to store and serve it. In that sense, the older parts of a blockchain can gradually become more centralized in their availability even though they do not become more centralized in their truth.

This is not necessarily a problem. Requiring every node to preserve every historical state forever would mean that the hardware requirement for participating in a blockchain would continuously increase simply because the network survived another year. After decades, operating an ordinary node could require storing an enormous amount of information that has almost no relevance to current consensus. Therefore, for a blockchain expected to operate indefinitely, some form of forgetting is almost unavoidable.

Conclusion

We often treat permanence as if it were one property of a blockchain, but it is actually the result of several different guarantees. A blockchain can make its history extremely difficult to modify without requiring every participant to preserve every historical state forever.

If every node were required to carry everything the network had ever known, the cost of participating would increase indefinitely with the age of the blockchain. Pruning prevents this by allowing the majority of nodes to concentrate on verifying the present while a smaller part of the infrastructure preserves the past.

This creates a trade-off that is easy to overlook. As history gets larger, its integrity can remain protected by the blockchain while its availability becomes dependent on fewer participants. And those participants cannot easily lie about what happened but they may eventually become the only ones left who can show us.

Then, the question becomes not whether a blockchain can preserve its history forever, but who will still be there to provide it when we want to look back?

For the past few years, developers have often been discussed as if they were changing teams. AI was attracting talent, money and attention; crypto was losing all three. It made for an easy story, especially when every week seemed to bring another model release while the blockchain market was still recovering from its last cycle.

GitHub shows how large the AI shift became. In 2023, contributors to public generative AI projects increased 148% from the previous year. By August 2025, more than 1.1 million public repositories were importing an LLM SDK. AI moved quickly from a specialist field into the everyday software stack.

The less obvious question is what happened to blockchain development during the same period.

The data behind Blockchain Developer Report tells a more durable story than the headlines suggest. BDR’s average count of recently active GitHub accounts rose from roughly 20,400 in 2022 to 21,900 in 2023. It climbed to almost 28,000 in 2024 and reached 29,700 in 2025.

Most of that growth arrived in 2024. The pace slowed the following year, but activity remained far above its 2022 level. Public blockchain work did not disappear as AI took off. More of it became visible.

Two technologies spreading in different ways

AI adoption travels easily across the software industry. A support platform can add a language model to summarize tickets. A finance product can use one to read documents. A developer tool can generate tests or explain an unfamiliar codebase. None of these products needs to become an “AI company” for its repository to carry a visible AI dependency.

Blockchain enters a codebase differently. It tends to appear through smart-contract languages, protocol clients, wallets, cryptographic libraries and chain-specific SDKs. The work is often more tightly connected to the architecture of the product. Adding an LLM API to an existing application may take an afternoon. Introducing account abstraction, a proving system or a new execution environment usually demands a deeper commitment.

That difference matters when we try to read developer attention from GitHub. AI can spread horizontally across almost every category of software while blockchain continues growing inside a smaller technical domain. One trend does not have to consume the other.

The same developer may also contribute to both. Someone working on wallet infrastructure can use an AI coding assistant, build an internal agent or add an LLM-powered interface to the product. GitHub will record the repositories and dependencies, but it will not tell us that the developer has crossed from one professional identity into another.

The idea of a clean migration assumes that developers choose one industry and leave the other behind. Modern software work rarely looks that tidy. Technologies overlap. Tools travel faster than job titles, and a developer’s public contributions may cover several parts of the stack in the same month.

AI may even be helping more blockchain experiments reach GitHub. It has become easier to understand an unfamiliar SDK, draft a basic contract interface, generate tests or translate documentation into working code. That lowers the cost of trying something new.

It does not remove the hard parts. Security reviews, protocol design, production maintenance and ecosystem knowledge still take time. AI can shorten the path to a first prototype without guaranteeing that the prototype becomes a lasting project.

That distinction begins to show up inside the BDR data.

The base widened faster than it deepened

The total number of recently active accounts grew, but the composition of that activity changed.

At the end of 2022, BDR’s “one-time” category represented 74.1% of active accounts. By the end of 2025, its share had reached 78.3%. Over the same period, the “full-time” share moved from 13.9% to 11.3%. The average number of full-time accounts was almost unchanged between 2024 and 2025.

These are contribution-frequency categories, not job titles. Even so, the direction is useful. The broad edge of the ecosystem expanded faster than its higher-frequency core.

There are plenty of ways for occasional activity to enter the public record. A developer may build a hackathon project, test a new SDK, contribute to a grant prototype or integrate a wallet into an existing application. Some will return. Others will leave the repository untouched after the first working version.

That early activity still has value. Experiments create feedback, reveal documentation problems and put tools in front of new developers. Every durable contributor starts somewhere.

The harder work begins after the first repository appears.

For ecosystem teams, the useful question is no longer simply how many developers showed up. It is how many found a reason to continue. Did they return after the event ended? Could they get help when the sample code failed? Was there a real project waiting beyond the tutorial? Did maintainers review their contribution while it was still relevant?

Hackathons and grants are good at creating a visible spike. Documentation, issue triage and responsive maintainers are what turn that spike into a working community.

The BDR trend suggests that blockchain has not lost its ability to attract experimentation. The next challenge is converting more of that experimentation into repeated contribution.

Growth creates a retention problem

A larger entrance can hide a weak middle.

When an ecosystem is small, bringing in new developers feels like the obvious priority. As the top of the funnel expands, the constraint moves elsewhere. More people encounter incomplete documentation. More prototypes reach the point where they need security advice, infrastructure credits or a maintainer’s attention. More grant recipients have to decide whether the second version is worth building.

AI may increase that pressure. If coding tools make the first prototype cheaper, ecosystems will receive more experiments of uneven quality. The teams that benefit will be the ones that can recognize promising work early and give it a path forward.

That path does not need to be elaborate. A useful starter issue, a reply from an experienced maintainer or a clear production example can matter more than another broad developer campaign. Small pieces of support arrive at exactly the moment when someone is deciding whether to keep going.

The measurements should follow that journey. First contributions are worth tracking, but so are returns after 30, 90 and 180 days. Ecosystems should know how often an account moves from a single contribution into regular work, begins contributing across repositories or starts reviewing the work of others.

Those transitions describe an ecosystem’s depth better than a launch-week total.

The next BDR analysis can make them visible. It can follow account-level cohorts over time, distinguish established repositories from newer additions and examine how many blockchain contributors also appear in public AI projects. That would replace the abstract idea of a developer migration with observable behaviour.

For now, the public record already tells us something useful.

AI became one of the fastest-growing areas of software development without bringing public blockchain work to a halt. BDR recorded a much larger active-account measure in 2025 than it did in 2022. The pace eased, and the higher-frequency segment did not expand as quickly as the wider base, but developers continued to build, test and publish.

The opportunity is no longer just to prove that blockchain developers are still here.

It is to give more of them a reason to stay.

Data and sources

Blockchain figures use the Blockchain Developer Report export generated on August 10, 2026 and cover the completed calendar years 2022–2025. Annual values are arithmetic averages of daily trailing-28-day active-account snapshots. BDR is a node101 product; its definitions and collection approach are described in the BDR methodology. Historical figures are retrospective and may update as public repositories are discovered or classified.

AI figures come from GitHub’s Octoverse 2023 and Octoverse 2025.

Zero-Knowledge was definitely one of the biggest topics of blockchain once, and we have seen many great projects developing their technologies. Yet, there is very little data on what is the state of ZK’s adoption today.

As a part of our developer analysis in blockchaindeveloper.report, we inspected what is the state of ZK developers as of August of 2026, and we present our findings below, for general and each ZK ecosystem.

Active Developer Comparison to All-Time Metrics

The zero-knowledge ecosystem had so far just a little less than 29 thousand repositories created, with 33 thousand developers who have tried ZK technologies in total. However, only 1341 of these developers are active as of August 2026.

This means that currently 4.0% of developers in the ZK ecosystem are still active, which is not a promising overall ratio at all. Moreover, the overall global active developer share for blockchain developers (which is again the number of active devs over all-time devs) is 27.9%, showing us that the ZK ecosystem is not doing very well even inside the blockchain ecosystem in general.

However, it is important to notice that the biggest drop in this ratio is caused by old ZK technologies that do not currently host any active developers, so this does not necessarily mean that the ZK ecosystem is losing traction, but only some ancient big ZK projects are now not very strong.

This final conclusion is also supported by ecosystem specific data that we share in later sections.

Distribution of Activity in the ZK Ecosystem

When we look over the historical charts, we observe that most of the repository count in ZK is generated by two ecosystems: Starknet (12k repos) and Circom (7k repos). Alone, the two explain 70% of all repository count. Their role is similar in the total developer count as well.

However, we see that activity is considerably more distributed, with Midnight and Starknet leading, followed by Aztec and Circom.

This observation leads us to two important conclusions: The first is that even though the two biggest ecosystems of ZK are not as active today, they still own an important developer segment. The second is that some of the newest ZK ecosystems are actually matching the old favorites in activity, which is very positive news for new technologies.

Now, let us move on to some ecosystem specific analyses to better understand the situation.

Ecosystems in the Order of Active Developer Count

Midnight

TL;DR 1367 all-time repos, 1127 all-time devs, 544 active devs

To summarize simply, we can say that Midnight is rapidly gaining traction. Their active developer count has increased very rapidly in the past 2 months, and now they own the biggest active ZK developer segment. So far, their 2-months retention is also very high with 91.8%.

Another interesting metric of Midnight is the increase in the number of returning and reactivated developers in their chart:

This graph indicates that the recent increase of Midnight is not only made-up of new developers, but older Midnight developers are also returning to the ecosystem.

One final graph to share is the multi-ecosystem distribution of Midnight developers.

The graph shows that about half of Midnight developers are working only in the Midnight technology, which is also very high compared to most of other ZK ecosystems.

Overall, we can say that Midnight is trending fast at the moment, but the sustainability of their growth will be seen in the later months of 2026.

Starknet

TL;DR 12398 all-time repos, 13678 all-time devs, 393 active devs

Starknet is the biggest ecosystem of ZK in terms of all-time repos and devs, but their active developer count has been decreasing since the beginning of 2026. The trend is even more clear when we look at their all-time data:

Nevertheless, there is also enough evidence to believe that this stop is finally ending, and Starknet active developer count is reaching a stable point. The high retention of 80.5 % also supports this idea.

Moreover, Starknet developers have one of the highest tenure levels of the ecosystem:

Here, we observe that Starknet has many established and emerging developers in its ecosystem, also supporting the idea of a stabilizing ecosystem. Note that last 2 weeks are not a fully accurate representation since the tenure data is often updated retrospectively.

Moreover, just like Midnight, Starknet ecosystem also hosts a significant portion of single-ecosystem developers, which is especially important considering they are an Ethereum L2.

To conclude, we can say that the Starknet ecosystem is looking to be stabilizing since the beginning of 2026. Later months will determine if Starknet will be able to protect its developer base.

Aztec

TL;DR 3203 all-time repos, 2862 all-time devs, 164 active devs

Aztec’s charts are quite surprising. Until the last month, we see that Aztec’s active developer count was having a steady growth, reaching 400 active developers in total, which is higher than Starknet’s current numbers. However, there was a sharp decrease last month, causing Aztec to drop up to 100 active devs.

We do not know the exact reason for this drop. One possible explanation may be that being a privacy-first ecosystem with institutional projects, many Aztec repos are still private, and we will see a retroactive increase in Aztec’s numbers in the coming weeks as these repos go public. Of course, data cannot relate to any cause directly.

However, it is also interesting to compare these results with multi-ecosystem segmentation.

We observe that while the count of single-ecosystem developers of Aztec decreases much less, multi-ecosystem developers are the main cause of the decrease in Aztec’s charts. The fact that Aztec hosts many more multi-ecosystem developers than the two previous ecosystems also implies the importance of this difference.

Knowing that the total active developer count of the blockchain has also witnessed a significant drop in the last month, we can conclude that Aztec is affected by this change more than others, as its ecosystem co-exists with the general blockchain as well.

Coming months will show whether this decline is temporary or part of a longer-term trend.

Circom

TL;DR 7300 all-time repos, 8373 all-time devs, 132 active devs

Now, let us look into one of the oldest ZK technologies that is still in use.

The same surprising picture of Aztec meets us also in Circom’s charts. We see that in the past month, Circom experienced a drastic drop, from 600 active devs (ecosystem high) to 132. The most optimistic explanation is again the frequency of institutional projects in Circom, and that these numbers will be updated retroactively with later pushes.

However, another possibility may be that Circom is finally leaving its place to the new technologies of ZK. Being slower and less-convenient than many, it is not a surprise for developers to start leaning towards newer technologies these days. The low retention rate (40.4%) of Circom also supports this idea.

Not surprisingly, as Circom does not have its own network, most Circom developers are also multi-chain, which is also another correlation between Circom and Aztec.

As an important difference, we can also notice that single-ecosystem developers of Circom are also leaving for the past weeks, with almost no single ecosystem developer left currently.

Of course, such a recent update is not a trend, and this does not mean anything definitive on Circom.

Succinct SP1

TL;DR 617 all-time repos, 1789 all-time devs, 59 active devs

And as a final bonus, let us look at the 5th most active ecosystem of ZK, which is also unique among the others above being a zkVM instead of a programming / circuit language.

At first, we can also easily mistake Succinct being also very similar to Aztec and Circom, as it has lost many developers in the past weeks. However, the high retention rate of Succinct (70.3%) makes us wonder if we were too quick to jump into this conclusion.

Indeed, the developer segmentation charts may be pointing to a different conclusion:

Indeed, until very recently the big majority of Succinct’s ecosystem is made up of multi-ecosystem developers. During the past month, these devs left, while single ecosystem developers of Succinct showed a significant improvement.

This chart may actually be showing us that Succinct is finally getting its own ecosystem, and later Succinct development will be much more stable.

Conclusion

The ZK ecosystem is clearly going through a transition rather than a simple decline. While much of its historical developer activity was concentrated around older technologies such as Starknet and Circom, current activity is becoming more distributed, with newer ecosystems beginning to capture a meaningful share of active developers.

The strongest signal in the data is this shift in where developers are building. Midnight has grown rapidly, Starknet appears to be approaching a more stable developer base, while Aztec, Circom, and Succinct show more volatile recent patterns that will need additional months of data before drawing strong conclusions.

Overall, ZK remains an active but changing part of the blockchain developer ecosystem. The next stage of its growth will likely depend less on the size of its historical developer base and more on which ecosystems can attract developers, retain them, and turn short-term interest into sustained activity.

Thank you for reading this report. You can reach us at hello@node101.io for any questions, or inspect all the metrics yourself in blockchaindeveloper.report.

You are not a suspect, and nobody is watching a screen. A camera on your route home photographs your car anyway, and the image becomes a searchable record: plate, make, color, time, place. On its own, that record says almost nothing about you, and it won’t stay on its own for long.

The structure is simple, which is exactly what makes it consequential. Each layer takes a piece of ordinary behavior and turns it into something an institution can act on.

Strictly speaking, a score is only an input. The output is the interest rate, the insurance premium, the rejected application, the investigative priority. “They know your price” means that these systems can translate fragments of your behavior into consequences you never see being calculated.

So here is the argument I want to make. One industry has already built the infrastructure that turns ordinary life into machine-readable records. Another turns those records into scores, and institutions increasingly let the scores set the terms of participation: what you pay, what you can rent, how closely you get examined. The cases below each carry one step of that claim, and together they point at a single question: who holds the right to score whom.

The machine that turns movement into data

The capture layer comes first, and it already runs at scale. Flock Safety sells automated license plate readers that operate, by the company’s own count, in more than 6,000 US communities. The cameras record vehicles passing through an area, and participating agencies can grant one another access or run searches across the wider network, depending on how sharing is configured.

The public-safety argument deserves a fair hearing, since plate readers do recover stolen cars, locate missing people, and help police find suspects, and a powerful tool can still be a legitimate one.

The search logs, however, told a fuller story once officials and journalists started reading them. An Illinois audit in 2025 found that Customs and Border Protection had accessed data originating in the state, which sat uneasily with a law restricting such use in immigration and abortion-related investigations. In Texas, a sheriff’s office searched cameras for a woman whose family said she had undergone a self-administered abortion. The logged reason referenced the abortion itself; the sheriff later described the search as a welfare check.

Flock paused its pilot programs with federal agencies and added new restrictions. Even so, several cities cancelled their contracts.

The cameras themselves never changed. Infrastructure justified by stolen cars had quietly become capable of answering questions about immigration status and reproductive health, because the record stayed neutral while the queries carried the intent. That settles the first step of my claim: capture at scale exists, and its purpose travels with whoever writes the query. The harder question is who converts records into decisions.

Two layers, not one machine

Companies like Flock make the physical world legible by converting events into data points. Companies like Palantir make those data points actionable, connecting scattered records into decision-ready profiles. Banks, insurers, employers, and government agencies then turn the profiles into decisions about actual people.

Palantir has supplied software to US immigration enforcement for more than a decade. In April 2025, ICE awarded the company roughly $30 million to develop ImmigrationOS, including tools for enforcement prioritization and self-deportation tracking. By September, another $30 million order sat inside a broader contract vehicle worth up to $157.5 million, one that explicitly referred to “identification and targeting for enforcement.”

One industry watches, another interprets, and the institutions downstream make the consequences real. Keep that division of labor in mind, because it later decides whom a person could even complain to when a score goes wrong.

Why scoring exists

Before going further I should concede the strongest objection to my argument: scoring exists for defensible reasons. Since lending to strangers requires estimating risk, standardized credit models made those estimates more consistent while letting lenders evaluate people who arrive without personal connections or collateral. Insurance cannot function without pricing the probability of loss. Fraud systems have to tell an ordinary payment apart from a stolen card.

My objection begins where a score travels beyond its original purpose, resists inspection, and produces consequences nobody can meaningfully challenge. The next two cases show exactly that migration.

When the score leaves home

In 2024, reporting revealed that General Motors had been sharing data collected through its OnStar Smart Driver feature with consumer reporting agencies used by insurers. The data covered speeding, hard braking, nighttime driving, and precise location, in some cases collected every few seconds.

The Federal Trade Commission alleged that GM’s enrollment process was misleading and that many drivers never gave informed consent. Some of those drivers said the resulting reports affected their insurance rates. GM discontinued Smart Driver, and in January 2026 the FTC finalized an order barring the company from sharing certain location and driving-behavior data with consumer reporting agencies for five years.

A feature presented as driver coaching had become an input for underwriting, and no grand plan was required to get there. Once a useful dataset existed, another industry found a price for it. For my argument the details matter less than the direction of travel: the score left home, and nobody who generated the data watched it go.

From score to price

A 2023 decision by Türkiye’s data protection authority shows the next step with unusual clarity. A car rental company’s website described a decision-support algorithm for first-time customers, one that weighed the applicant’s Findeks credit score, recent credit applications, payment performance, debt ratio, and even the socioeconomic profile of the neighborhood where they lived.

The company denied conducting the disputed Findeks inquiry. The authority found otherwise: access to the customer’s Findeks report had been made a condition of receiving the rental service, and it imposed an administrative fine.

The shift here is easy to miss. Information developed to assess borrowing risk had crossed into an unrelated market; the question thus stopped being whether someone would repay a loan and became whether they could rent a car at all.

This, concretely, is how scoring becomes pricing and what my title means. One system estimates risk, and another uses the estimate to alter the terms of participation. Even incentives follow the same logic, because a discount for accepting monitoring doubles as a surcharge for refusing it. As a result, privacy starts to resemble a luxury good.

The speculative next step: liquid people

Nothing described so far requires a blockchain. Its role comes later, and because this is the most speculative part of my argument, let me be explicit about which parts are documented and which are projection.

The documented layer is data capture and scoring. The experimental layer already exists in miniature: in 2020, entrepreneur Alex Masmej raised about $20,000 by selling $ALEX tokens, promising holders 15 percent of his income for three years along with access and voting privileges connected to his career.

The projected layer goes further. Blockchains can make credentials portable, and tokenization can create tradable claims on the income, access, or reputation attached to them.

Portability by itself could do real good. It could help a refugee prove qualifications after losing access to the institution that issued them, or let a freelancer carry a work history between platforms. A portable credential and a liquid market are different things, though. Portability lowers the cost of reusing information, while tokenization goes a step further and lets claims built on that information be divided and traded.

Design this badly and a person’s worst year stays legible indefinitely. Tie a market to reputation and a temporary controversy shows up as a visible selloff; falling confidence damages opportunities, and the lost opportunities then look like confirmation of the market’s judgment. At that point the price stops measuring reputation and starts producing it.

Rights on paper, review in practice

Contesting these systems is possible, at least on paper. The GDPR restricts certain solely automated decisions with significant effects. In its SCHUFA judgment, the EU’s highest court held that a credit score can fall within those rules when the recipient relies on it decisively, and its later Dun & Bradstreet judgment required an explanation meaningful enough for a person to understand and challenge the decision, making clear that trade secrecy offers no blanket excuse for refusing access. Türkiye’s KVKK gives people a comparable right to object when exclusively automated analysis produces an adverse result.

The harder problem, however, is practical. To exercise any of these rights, a person has to know that a score was used, identify who is responsible for it, and obtain review before the consequence becomes irreversible. Each of those steps can fail when data providers, model operators, and decision-makers are separate organizations. A right exercised after the apartment, the job, or the loan is gone therefore arrives too late to prevent anything.

Who gets to score whom?

Still, none of this makes the outcome inevitable, and I want to be precise about what I am defending. Purpose limits, inspectable scores, correction rights, selective disclosure, and review before consequential decisions could preserve the benefits of scoring without creating a permanent market in human worth.

Rather than separating data from no data, or blockchain from no blockchain, the dividing line separates systems that help people prove something about themselves from systems that let others turn those proofs into control over their future. The deepest inequality of the coming decades, I suspect, will hinge less on who owns the data than on who holds the right to score everyone else.

Sources

• Flock Safety, “Customers Own and Control Their Flock Data”, and Frequently Asked Questions.

• Associated Press, “License plate camera company halts cooperation with federal agencies among investigation concerns”, August 25, 2025.

• Forbes, Flock Safety company profile, updated March 3, 2026.

• Wired, “ICE Is Paying Palantir $30 Million to Build ‘ImmigrationOS’ Surveillance Platform”, April 2025.

• Forbes, “ICE Awards Palantir Another $30 Million for ‘Voluntary Return’ Program”, September 30, 2025.

• Federal Trade Commission, “FTC Finalizes Order Settling Allegations that GM and OnStar Collected and Sold Geolocation Data Without Consumers’ Informed Consent”, January 2026.

• Türkiye Personal Data Protection Authority, Board Decision No. 2023/1234, July 20, 2023.

• Roll, “Hi, my name is $ALEX”, 2020.

• Court of Justice of the European Union, SCHUFA judgment, Case C-634/21, December 7, 2023.

• Court of Justice of the European Union, Dun & Bradstreet Austria, Case C-203/22, February 27, 2025.

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?