“The most secure computer is one that is unplugged. The most convenient computer is one that automatically trusts everything. Neither extreme is useful.” – Craig Everett
Every computer system exists somewhere along a spectrum between security and convenience.
A highly secure system is often inconvenient. It requires manual verification, deliberate configuration, and careful control over what software is allowed to run. A highly convenient system does the opposite. It automates decisions, reduces friction, and delegates complexity to other people, services, and infrastructure.
Neither approach is inherently correct. The appropriate balance depends on what the system is trying to accomplish.
Over the past three decades, the Web evolved into one of the most effective information distribution systems ever created. Domain names replaced IP addresses. Certificate authorities replaced manual verification. Package repositories replaced maintaining software internally. Cloud providers replaced operating infrastructure. Browsers replaced dedicated applications.
Each step made the system easier to use. Each step also introduced new trust assumptions.
For information systems, this trade off is often reasonable. For financial systems however, it deserves closer examination.
At this point it is worth making an important distinction. The Internet and the Web are not the same thing. The Internet is the underlying communications network that allows computers to exchange data.
The Web is a collection of technologies built on top of that network: browsers, the NPM supply chain, Github, Javascript frameworks, cloud-hosted applications, browser extensions, and the trust relationships that connect them.
Many of the security issues commonly associated with the Internet are actually properties of the Web.
This distinction matters because modern cryptocurrency infrastructure is frequently discussed as though it exists outside the traditional technology stack. In reality, much of the industry has adopted it wholesale.
Bitcoin introduced cryptographic ownership without banks. Ethereum introduced programmable settlement without traditional financial intermediaries. Yet the vast majority of users interact with these systems through browser wallets, web applications, cloud-hosted infrastructure, software supply chains, and the same trust architecture that powers ordinary websites.
The result is a curious contradiction. The settlement layer seeks to remove trust. The access layer continually reintroduces it.
This article argues that the question facing digital finance is no longer whether blockchains can replace traditional financial infrastructure. The more important question is whether financial infrastructure can be built on top of the Web’s convenience-first trust model at all.
To answer that question, we must first understand how the Web distributes trust, why those design decisions made sense for information systems, and why the same decisions become more
problematic when applied to money.
Financial Infrastructure Requires a Unique Trust Model
Most users do not verify certificates, audit source code, operate their own infrastructure, or inspect network traffic. The Web allows them to delegate those responsibilities to browsers, software vendors, cloud providers, and countless other intermediaries. In return, the system
becomes dramatically more convenient to use.
That convenience can come at a cost, but it is a manageable one. A news website can tolerate occasional outages. A video platform can recover from a security incident. Even large-scale disruptions are usually temporary inconveniences rather than existential failures.
Conversely, the purpose of financial infrastructure is not simply to move information from one place to another. It is to establish ownership, transfer value, and provide assurances that those
records remain accurate even when participants have strong incentives to manipulate them.
The distinction is important because money attracts adversaries in a way information rarely does. A compromised social media account may create embarrassment. A compromised financial account creates immediate economic opportunity. Every trust assumption becomes a target because every trust assumption can potentially be monetised.
Financial infrastructure evolved around this reality. Whether through banks, clearing houses, custodians, or exchanges, the objective has always been to maintain accurate ownership records in an environment where participants have strong incentives to manipulate them.
Cryptocurrency emerged from the same observation. Bitcoin’s contribution was not merely digital money. It was a different answer to the question of trust. Instead of relying on institutions to maintain ownership records, users could verify ownership through cryptography and consensus. Ethereum extended this concept by allowing financial agreements to be enforced by code rather than intermediaries.
At the settlement layer, these systems represented a meaningful departure from traditional finance. The surrounding ecosystem of applications did not follow the same ethos.
As cryptocurrency adoption grew, the industry largely embraced the existing tools of the Web. Browser wallets became the primary interface. Decentralised applications became websites. Software was distributed through conventional package repositories. Infrastructure moved into cloud environments. User access became dependent on browsers, domains, certificates, and the same software supply chains used throughout the rest of the internet.
Cryptocurrency removed trust from one layer of the stack while inheriting it almost everywhere else.
This does not mean the experiment failed. It does, however, raise an important question. If financial infrastructure requires a different trust model than information systems, how much of the Web’s architecture can be inherited before those differences begin to matter?
Answering that question requires examining the trust relationships embedded throughout the Web itself.
The Web Is Built on Delegated Trust
When a user visits a website, the experience appears straightforward.
A name is entered into a browser, a connection is established, and information is exchanged. Most users never think about the systems involved because, most of the time, those systems work exactly as intended.
Behind every successful connection is a chain of organisations and technologies that must all behave correctly. Domain registrars maintain ownership records. DNS providers translate names into network addresses. Certificate authorities authenticate identities. Browser vendors decide which authorities are trusted. Cloud providers host applications. Network operators move traffic between them.
The Web functions because users trust these intermediaries to perform their roles honestly and competently.
That trust is rarely explicit. Most users do not know who their DNS provider is. Few could name a certificate authority trusted by their browser. Fewer still inspect the certificates presented by
websites they visit. Instead, the Web relies on delegated trust. Verification is performed by systems on the user’s behalf.
The challenge is that every delegated trust relationship becomes a potential point of failure. History provides numerous examples.
In 2011, the Dutch certificate authority DigiNotar was compromised. Attackers were able to issue fraudulent certificates for major internet services, including Google. Browsers accepted those certificates because they originated from a trusted authority. The cryptography itself remained sound. The intermediary responsible for trust did not.
The incident was severe enough that browsers ultimately removed DigiNotar from their trust stores entirely.
A similar lesson emerged years later when major browser vendors stopped trusting certificates issued by Symantec after repeated concerns regarding certificate issuance practices. At one point,
one of the largest certificate authorities in the world lost the confidence of the ecosystem it was supposed to secure.
The same pattern can be seen beyond certificate authorities. DNS hijacking attacks have repeatedly redirected users toward malicious destinations while preserving the appearance of legitimacy. Cloud outages have disrupted access to services used by millions of people
simultaneously. Compromised hosting providers, registrars, and infrastructure operators have all demonstrated that the reliability of the Web depends on far more than the software running on a
user’s machine.
None of these examples prove that the Web is broken. In fact, the opposite is true. The Web functions remarkably well considering its scale. What they do demonstrate is that the Web was designed around managing trust rather than eliminating it.
The original promise of blockchain technology was the reduction of trust requirements. Yet when blockchain systems are accessed through websites, browsers, domains, certificates, and cloud-
hosted infrastructure, many of those trust relationships reappear elsewhere.
The Web does not remove trust from a system. It distributes trust across many systems.
The Modern Web Software Stack Is a Supply Chain Attack Surface
The Web’s approach to software development follows the same pattern seen throughout the rest of its architecture, complexity is managed by moving it somewhere else.
Instead of writing every component from scratch, developers rely on package repositories. Instead of manually reviewing every dependency, package managers retrieve them automatically.
Instead of building and distributing software themselves, developers rely on automated build systems and deployment pipelines
A modern web application may contain hundreds or thousands of dependencies. Most developers have never read the majority of the code they deploy. In many cases, they are not even aware of every dependency included in their application. Trust is delegated to package maintainers, automated tooling, and the broader software ecosystem. The problem is that when compromise does occur, the scale can be enormous.
One of the earliest high-profile examples occurred in 2018 with the NPM package event-stream. The package was widely used and maintained by a trusted developer. After ownership was transferred to another contributor, malicious code was introduced and distributed to downstream users. The attack did not require breaking encryption, exploiting a vulnerability, or compromising infrastructure. It succeeded because users trusted a component of the software supply chain.
Several years later, attackers compromised ua-parser-js, a package downloaded millions of times each week. Malicious versions were published through legitimate distribution channels and subsequently installed by developers performing routine software updates. Once again, the attack spread through mechanisms designed to make software distribution easier and more convenient.
The most concerning example emerged in 2024 with the attempted compromise of xz Utils, a compression library used throughout the Linux ecosystem. Unlike previous incidents, this attack was not opportunistic. The attacker spent years building credibility within the project before introducing a sophisticated backdoor intended to target SSH authentication systems
What made the incident remarkable was not merely its technical sophistication but that it demonstrated how software supply chain attacks scale.
Historically, compromising one thousand organisations required compromising one thousand organisations. A successful supply chain attack can achieve similar reach by compromising a single trusted dependency.
Attackers increasingly target the systems responsible for building, distributing, and updating software rather than the software itself. Package managers, CI pipelines, and automated deployment systems dramatically improve productivity, but they also allow compromised code to spread rapidly through trusted distribution channels. The same mechanisms that make software development efficient can amplify the impact of a successful compromise.
The question is whether the same assumptions are appropriate when the software being distributed is responsible for securing financial assets.
Many cryptocurrency projects describe themselves as trustless while being built and distributed through software ecosystems that depend heavily on trust. Wallets, exchanges, decentralised applications, and supporting infrastructure are often assembled from hundreds of third-party packages maintained by people the end user will never meet and cannot realistically audit.
The blockchain may eliminate the need to trust a bank. The software stack surrounding the blockchain however, often replaces that trust with trust in maintainers, repositories, and automation systems.
The next question is how these assumptions manifest in practice. To understand that, it is necessary to look at how most users actually interact with blockchain systems today.
Ethereum’s User Experience Is Built on the Web
If Bitcoin introduced cryptographic ownership and Ethereum introduced programmable settlement, how do most users actually interact with those systems?
For most people, the answer is simple: through a web browser.
A typical Ethereum user installs a wallet such as MetaMask, visits a website, connects their wallet, and begins interacting with decentralised applications. From the user’s perspective, they
are interacting directly with Ethereum. In reality, they are interacting with a browser extension running inside Chrome, Firefox, Brave, or another browser. That extension communicates with a web application delivered through DNS, authenticated through certificate authorities, built from modern software supply chains, and often hosted on cloud infrastructure.
As a result, the user’s experience of Ethereum is shaped as much by the Web as it is by the blockchain itself.
This distinction is easy to overlook because the blockchain portion of the system generally works well. Ethereum continues producing blocks regardless of whether a website is online, and smart contracts continue executing regardless of whether a frontend is available. Most users, however, do not interact with consensus directly. They interact with the software that sits between them and the blockchain.
The consequences of that design have become increasingly visible over time. In December 2023, attackers compromised the Ledger Connect Kit, a software component used by numerous decentralised applications. Ethereum itself was unaffected. No consensus failure occurred and no cryptographic primitive was broken. Instead, attackers targeted software distributed through the surrounding web ecosystem. Users of affected applications were presented with malicious transaction requests, which the blockchain subsequently executed exactly as instructed.
Incidents such as this are common because attackers generally focus on the easiest path available to them. Wallet drainers, phishing campaigns, fake websites, and malicious browser extensions
rarely target the blockchain directly. They target the layers surrounding it. Compromising Ethereum requires overcoming one of the largest distributed computing systems in existence. Compromising a frontend may require access only to a domain name, hosting provider, software dependency, or browser extension.
This creates an unusual situation. Many cryptocurrency systems are strongest at the layer users see least and weakest at the layer users interact with most.
The reason is not difficult to understand. Websites are easy to deploy, browser extensions are easy to install, and users already understand how to navigate the Web. During cryptocurrency’s early growth, these tools provided the fastest path to adoption.
What began as a practical decision gradually became part of the industry’s architecture. As a result, many blockchain systems now rely on technologies built around delegated trust and convenience at the access layer, even when the settlement layer was designed to minimise them.
Those dependencies extend beyond the browser itself and into the infrastructure that supports much of the ecosystem.
Cloud Infrastructure Reintroduces Centralisation
One of the most common criticisms of traditional financial infrastructure is that it relies on centralised points of control. Cryptocurrencies emerged largely as a response to this reality. The
goal was not simply to create digital assets, but to create systems capable of operating without requiring permission from a central operator.
At the protocol level, many blockchains achieve this remarkably well. The infrastructure surrounding them often does not.
Over the past decade, internet infrastructure has become increasingly concentrated around a small number of providers. Amazon Web Services, Microsoft Azure, Google Cloud Platform, and Cloudflare collectively support a substantial portion of the modern Web. These services reduce operational complexity, improve reliability, and allow organisations to scale rapidly. The tradeoff is that they become critical dependencies.
Many decentralised applications rely on cloud-hosted frontends, centralised RPC providers, content delivery networks, and cloud-based development infrastructure. As a result, a blockchain can maintain decentralised consensus while much of the surrounding ecosystem remains dependent on a relatively small number of providers.
This distinction has become visible during several major outages. In November 2020, an Infura outage disrupted access to numerous Ethereum applications and wallets. Ethereum itself
continued producing blocks and processing transactions, yet many users suddenly found themselves unable to interact with services they believed to be decentralised.
The incident highlighted an important distinction between decentralisation at the protocol layer and decentralisation at the access layer. A system may remain decentralised internally while still
depending on centralised infrastructure to reach its users.
The same pattern appears throughout the broader internet. Outages affecting Cloudflare, AWS, and other major providers have repeatedly demonstrated how many seemingly independent services ultimately depend on the same underlying infrastructure. When enough organisations rely on the same provider, that provider becomes a systemic point of failure.
Traditional finance has long recognised this as concentration risk. Regulators routinely examine whether critical infrastructure depends excessively on a single service provider because the failure of that provider can threaten the stability of the wider system.
A decentralised application that relies on centralised infrastructure may still be decentralised in important respects, but its operational resilience remains tied to the availability and policies of those providers. Cloud providers operate within legal jurisdictions, comply with regulations, respond to court orders, and retain the ability to suspend services or terminate accounts. This is not a criticism of cloud providers; it is simply the reality of centralised infrastructure.
These tradeoffs are understandable. Cloud computing optimises for convenience, scalability, and operational efficiency. Financial infrastructure, however, places greater emphasis on resilience,
independence, and minimising critical dependencies.
As long as cryptocurrency ecosystems remain heavily dependent on centralised cloud infrastructure, they will continue inheriting many of the same structural risks that decentralised systems were originally intended to reduce.
Security and Convenience Are Opposing Forces
The common thread running through the previous sections is that many of the Web’s most successful innovations were motivated by convenience. Complexity was delegated to browsers, infrastructure providers, software repositories, and automated systems. Those decisions made the Web dramatically easier to use and helped it scale globally.
These decisions were not mistakes. They helped transform the Web into one of the most successful information systems ever created by reducing friction and making software easier to build, distribute, and use.
The challenge is that convenience often involves delegating responsibility to another system, service, or intermediary. A browser validates certificates on the user’s behalf. A package manager
resolves dependencies on the developer’s behalf. A cloud provider manages infrastructure on an organisation’s behalf. Complexity does not disappear; it is simply moved elsewhere.
For many applications, this tradeoff is entirely reasonable. If a streaming service experiences an outage or a social media platform suffers a bug, the consequences are usually temporary and manageable.
Financial infrastructure operates under different constraints. Money creates direct incentives for attack, which means every dependency, intermediary, and trust relationship becomes a potential target.
This helps explain why many major security incidents do not involve failures in cryptography or consensus mechanisms. Attackers rarely defeat modern encryption directly. Instead, they target software supply chains, credentials, update mechanisms, domains, cloud infrastructure, and browser-based applications. In practice, it is often easier to attack the systems surrounding a secure system than the secure system itself.
A useful thought experiment is to imagine the most secure possible computer. It would have no internet connection, no automatic updates, no third-party services, and no cloud dependencies. Such a system would also be nearly useless. At the opposite extreme lies the maximally convenient system, where software updates automatically, dependencies are resolved automatically, and infrastructure is managed automatically. That system may be highly productive, but it also introduces a large number of dependencies that must be trusted.
Neither extreme is practical. The challenge is finding an appropriate balance between security and convenience.
The modern Web has generally erred on the side of convenience, and for information systems this has often been the correct choice. The cryptocurrency industry has largely inherited those same assumptions through its use of browser wallets, web applications, cloud infrastructure, and modern software supply chains.
This does not mean convenience should be abandoned. Financial systems must remain accessible if they are to achieve widespread adoption. It does mean, however, that convenience should not
be confused with security. A system is secure not because it is easy to use, but because its security assumptions remain valid even when attackers have strong incentives to challenge them.
The Web succeeded by making trust practical. Whether the next generation of financial infrastructure should continue relying on that model remains an open question.
What a Blockchain-Native Financial Stack Would Look Like
If the preceding sections are correct, the problem is not the Internet itself. The problem is the assumption that financial infrastructure must be built using the Web.
If the problem is the Web’s trust model rather than the Internet itself, then the question becomes what financial infrastructure would look like if it were designed to minimise dependence on that model.
Much of the cryptocurrency industry has recreated traditional web architecture around a decentralised settlement layer. A blockchain-native financial stack would begin from different assumptions.
Rather than asking how financial infrastructure can be integrated into the Web, it would ask how dependence on the Web can be reduced. Identity could be tied directly to cryptographic keys rather than domain names. Wallets could operate as dedicated applications rather than browser extensions. Software distribution could rely on explicit trust relationships rather than globally shared dependency repositories. Applications could communicate directly with blockchain
networks instead of multiple layers of web infrastructure.
The objective is not to eliminate every intermediary or trust assumption. No system can achieve that. The objective is to reduce them, ensuring that the remaining dependencies are deliberate,
visible, and necessary.
This reflects a different design philosophy. The Web was built to make trust practical and information easy to distribute. Financial infrastructure has different priorities. It must place greater emphasis on resilience, independence, and minimising critical dependencies.
The significance of distributed ledgers was never simply the creation of digital assets. Their contribution was the replacement of institutional trust with cryptographic verification. Ownership
no longer required a bank, settlement no longer required a clearing house, and consensus no longer required a central operator.
The next step may be applying the same philosophy to the infrastructure surrounding the blockchain itself.
The long-term success of cryptocurrency will not be determined solely by the security of its consensus mechanisms. It will also depend on whether the industry continues building on the Web’s trust model or develops infrastructure designed specifically for the requirements of digital ownership and financial sovereignty.