Introduction

1.1 Problem Statement and Relevance

Ethereum has been referred to as infrastructure for several years now — within the ecosystem itself, in the analyses of consultancies, and increasingly in the explanatory materials of regulators. Objections to this attribution do arise, pointing to the volatility of valuations, the complexity of the system, and the speculative character of a market in which billions in positions can unwind within hours. The objection from speculation bears directly on the question of infrastructure suitability, because in Ethereum the valuation of the native asset is tied to the security of the system, and no such linkage exists among established infrastructures. The objection cannot be resolved, however, as long as no one specifies what degree of independence from its own valuation a system must exhibit in order to qualify as infrastructure. The attribution therefore stands largely unchallenged, even though its examination has no point at which to begin.

The term encompasses a bundle of properties that goes beyond the designation itself. What is meant is durability over decades, neutrality toward participants, the impossibility of unilateral shutdown, and suitability for uses that no one anticipated when the system was built. Whether the word is used makes no difference. What does make a difference is that actors already behave as though these properties were in place. J.P. Morgan launched a tokenized money market fund in May 2026 that operates exclusively on Ethereum and grew from two hundred million to nearly seven hundred million dollars in roughly one month. Crédit Agricole issued, through its custody subsidiary, a MiCA-compliant euro stablecoin on the same chain, in productive operation and not as a pilot. Institutional investors orient their allocations to the expectation that the network will still exist in ten years, citing a decade of uninterrupted availability across fifteen protocol upgrades. Legislators, in turn, draft regulatory frameworks such as the European regulation on markets in crypto-assets, which already contain a decision as to whether a given thing constitutes an application, a platform, or an infrastructure. All of these actors examine carefully, but their examination extends only to the current state of the system. The assumption about its permanent continued existence eludes examination and is made by each actor at their own discretion.

The costs of a mistaken assumption fall on both sides. If the trust proves unfounded, the failure strikes all accumulated positions simultaneously at every level, while the escape routes have already been abandoned in the course of integration and the interconnection achieved can be reversed only at considerable cost. If the rejection proves unfounded, access is lost to a coordination layer that cannot simply be built anew under network effects, and the design of its rules, its conditions of access, and its neutrality guarantees falls to others. Both misjudgments are costly, and neither can be avoided without a standard.

Such a standard does not yet exist. The term “fundamental digital infrastructure” circulates in all these debates as a predicate that is granted or withheld, without anyone ever having determined what properties it requires. The present work first constructs the standard and then applies it to a system that continues to develop actively.

1.2 Gap

The state described in the preceding section might be dismissed as a peculiarity of public discourse, were the research to supply the missing standard. It does not. There exists a developed theory of infrastructure, there exists an extensive body of blockchain research, and there exists an established practice for assessing infrastructure systems — but each of these three bodies of knowledge does something other than what the research question requires.

Infrastructure theory has been applied to blockchain without its conceptual apparatus having been systematically applied to any individual system. The relevant works describe their subject using the vocabulary of infrastructure research and provide the groundwork on which an assessment could build.¹ They do not arrive at an assessment because they lack the means to do so. What is missing are operationalized criteria, what is missing are thresholds, and what is missing is a procedure that forms a judgment from individual findings.

Blockchain research possesses a mature toolkit for measurement, but one that targets different properties. Its methods capture the degree of decentralization of a system or the question of whether an organization should consider adopting this technology.² That decentralization does not coincide with infrastructure suitability is shown by the global financial messaging system SWIFT, which is operated by a single organization and yet counts as fundamental infrastructure of international payments. A method that measures decentralization thus captures a property from whose degree suitability cannot be inferred.

The established practice for assessing infrastructure systems, finally, presupposes what the subject does not offer. Its criteria are directed at an operating organization that takes on investment commitments and is subject to oversight. Chapter 3 examines this presupposition against seven reference infrastructures and shows that it is the rule there, but not a condition of the infrastructure function. A system whose rules emerge from the consent of independent participants and for whose continued existence no authority stands guarantor escapes these criteria, without this implying anything about its suitability.

The gap is thus defined. Theory supplies concepts without an evaluative standard, blockchain research supplies standards for different properties, and established practice supplies criteria for a type of system to which the subject does not belong.

1.3 Question

The question to which the present work responds reads as follows:

Does Ethereum’s architecture meet the requirements that must be placed on a fundamental digital infrastructure?

Anyone who asks this way presupposes that the requirements are fixed against which a system is to be measured. They are not fixed, and the determination of the requirements therefore precedes the assessment of Ethereum. Only once they are in place can the question be decided at all.

The question targets the structure of the system and what that structure accomplishes. It asks how Ethereum is built, what follows from the way it is built, and whether that meets the requirements. Whether Ethereum prevails over other systems is not part of this question, because a system’s prevailing depends on circumstances that remain external to its structure. An architecture can meet every requirement and still fail to prevail. This work makes no statement about Ethereum’s establishment.

The system to be assessed is changing while the assessment is under way. Ethereum is being developed along a roadmap whose proposals emerge from a process in which independent developers negotiate, revise, and occasionally reject them in an open procedure, without any authority issuing them. The protection of cryptographic methods against quantum computers, whose computing power could break the signatures in use today, has been under research for years. New resource estimates, among them a white paper by Google Quantum AI from March 2026, have given the threat additional weight.³ The Ethereum Foundation has maintained its own post-quantum research team since January 2026 and is testing initial building blocks in early implementations.⁴ The post-quantum transition is running as a parallel long-term strand with a target horizon around 2029, while the roadmap for the coming years remains driven by scaling and usability. What the proposals will change concerns the core of the system: how participants reach agreement on a shared state, how the system executes code, and how an individual user can verify whether the result is correct.

A judgment about the system as it exists today loses its validity to the extent that these proposals are implemented, because they bear on the very thing that was judged. A judgment about the future system, conversely, says nothing about what a user can rely on today, because it presupposes conditions that do not yet exist. The work therefore answers the research question twice — once for the current state and once for the target state that the system would reach under full implementation of its roadmap. It names neither a point in time for full implementation nor a probability.

The order in which the two answers are given follows from the subject. The transition builds on what exists, and anyone who does not understand how Ethereum works today cannot assess what the proposals will change. The assessment of the current state therefore accomplishes two things: it answers the research question for the present, and it describes the system in such a way that the assessment of the target state can build on that description.

1.4 Methodological Approach

Since no existing procedure makes the requirements of fundamental digital infrastructure amenable to examination, the work constructs the standard itself. It derives twelve criteria from the concept of fundamental infrastructure — from the question of what a system must exhibit in order for others to be able to rely on it lastingly. The derivation follows an established procedure of concept formation, which develops each criterion individually from the concept and derives its validity from the derivation.⁵

The twelve criteria are fixed before they are tested against seven established infrastructures: the power grid, the Internet, the road network, the financial messaging system SWIFT, the satellite navigation system GPS, cloud infrastructure, and the legal system. These systems reveal whether a criterion holds up against actual infrastructure and whether it captures properties that real infrastructures share. The probative force of the examination rests on the diversity of the seven systems, for a criterion that holds up against the physical power grid as well as the institutional order of law has been tested across the breadth of these cases.

Each of the twelve criteria is assessed on a four-level scale ranging from full compliance to an open finding. The twelve criteria stand in a hierarchy in which some function as thresholds. If such a criterion fails, this already limits the achievable overall judgment, however well the remaining eleven perform. Where a load-bearing requirement fails, strength elsewhere does not offset it. From the twelve individual findings, the overall judgment emerges through fixed rules whose application a second examiner can reproduce with the same material and arrive at the same result.

Three features of the answer follow from this design. The answer to the research question is graduated and does not reduce to a simple yes or no, because the overall judgment recognizes a spectrum of categories. The answer for the current state rests on measured states of the system as it runs today. The answer for the target state rests on specifications, prototypes, and research designs whose implementation is still pending. The target state, finally, is described in terms of the capabilities that the fully realized system would provide, because such a description outlasts changes to the roadmap, whereas a list of planned features would grow stale.

1.5 Position, Neutrality, and Scope

The work maintains analytical neutrality toward its subject, to which it explicitly commits. Negative findings are as welcome as positive ones, and its procedure is open to inspection. This serves a dual purpose. The end result is a judgment, and the work simultaneously gives the reader the means to judge for themselves. The work therefore remains useful even when the reader does not follow its judgment.

It addresses corporate decision-makers, institutional investors, technical architects, political decision-makers, and critical academics who, as a rule, do not know Ethereum from the inside. This choice determines the register of the work. It explains what such an audience needs explained and presupposes no prior knowledge that circulates only within the ecosystem itself. It is self-published and without external peer review, which is acknowledged openly here. Precisely because no reviewing authority stands between the work and its reader, the work makes its procedure transparent at every point and leaves the reader to judge its cogency.

The standard the work applies extends as far as what can be read off the system itself. What is measurable within the protocol, it can assess. What lies outside remains out of reach. This includes the quality of the data that enter the system from outside, whose accuracy the protocol itself does not ensure, as well as the regulatory environment and social acceptance, which co-determine actual use. This limitation is intentional, because the work assesses what it can measure and states what it cannot measure. Equally, it examines the infrastructure itself and not the applications built on top of it. The line between the two follows a single question: does an application affect the suitability of the infrastructure? A service whose share in securing the network touches the thresholds of the consensus mechanism belongs in the assessment. A service that builds on the infrastructure without acting back upon it does not. Section 2.3.4 draws the line through examples.

The work also separates the current state from the future state and answers the research question for each separately, for the reasons the section on the research question has given. The current state has a data cutoff date: 27 March 2026. The cutoff binds only the assessment data, while the framing information in the introduction extends to the editorial deadline. The figures describing it are snapshots of a system that is continually changing, while its structure and the structural findings that follow from it remain more stable. For the argument, therefore, what matters is the order of magnitude in which a figure falls and the direction it indicates, not its precise value on a given day.

From all of this follows what the work is not. It is not a technical manual explaining how to build on Ethereum, and not investment advice. Nor is it a forecast of the price of the native asset or of the future adoption of the system. Why prevailing lies outside the question is explained by the section on the research question.

1.6 Structure of the Work

The answer to the research question is built up across the following six chapters, each taking up where the previous one left off. First the standard is constructed, then it is applied to the present and to the future, and finally both findings are brought together. The reader thus has before them the sequence of the following chapters, which the next paragraphs describe in turn.

The first two chapters construct the standard. Chapter 2, Theoretical Framework and Methodology, first clarifies what makes an infrastructure fundamental and develops from that clarification the evaluation framework, the twelve criteria. Chapter 3, Infrastructure Contextualization, holds the already derived criteria against seven established infrastructures, tests whether the criteria withstand confrontation with actual infrastructure, and makes explicit what the procedure cannot accomplish. At the end of these two chapters stands a tested instrument that can be applied to Ethereum.

The two following chapters apply it, twice to the same subject at different points in time. Chapter 4, Current State Assessment, describes today’s Ethereum in a coherent account and then assesses it along the three dimensions of the evaluation framework — Structural Foundation, Qualitative Load-Bearing Capacity, and Resilience and Sovereignty — arriving at an overall judgment for the present. Chapter 5, The Target State, applies the same instrument to the Ethereum that would result from full implementation of its roadmap, and likewise arrives at an overall judgment. Both chapters work with the same standard, so that their findings can be directly compared.

The final two chapters synthesize and look ahead. Chapter 6, Delta, Limits, and Overall Assessment, places the two findings side by side, examines the difference between the current and the future state, assesses whether and which limits remain with the system across both points in time, and subjects the evaluation framework to scrutiny for what no criterion captures. In this final step, the work turns its own standard against itself and makes visible where it reaches its limit. At the end of this chapter, the research question is answered. Chapter 7, Implications, steps out of the evaluative role of the preceding chapters and thinks the answer further — toward its consequences for those who build on the system, trust it, or regulate it, and toward an outlook whose tone opens up. The outlook takes in once more the time of writing and research. Thus the work returns at its close to where the foreword began: to the voice of the one who posed the question.

At the end stands the answer to the question of whether Ethereum’s architecture meets the requirements of a fundamental digital infrastructure. How it turns out is decided by the chapters that lead to it.