The early days of the internet were characterized by a dream that was like a philosophical stance; a “World Wide Web” with no owners that could be used by anyone. (Though infrastructure and control points still existed.) Over time, that dream turned to become a much more commercialized Web, with major portions consolidated in the hands of a few tech giants like Amazon, Google, and Facebook. Web3 was in some ways meant as a “reboot” of that original dream. A reboot powered by a single word, loaded with diverse meanings: “Decentralization”.
However, as the term has moved from whitepapers to marketing billboards, its meaning has become a bit blurred. Much of the time, decentralization is used to refer to technical aspects of elements referred to as crypto or Web3. On the general user side, many may believe that if a product involves a “token” or a “wallet” it is decentralized. This is a potentially inaccurate perception. In reality, decentralization is more like a spectrum than a binary setting. The question isn’t if an app is decentralized, but how much. And the core of such things may be technology based, but there’s other aspects that should be considered.
This post sketches a four-aspect map of decentralization that you can use to look past the branding into the actual way a product functions.
Four Lenses for Evaluating Decentralization
The dimensions that define this decentralization map come from four distinct lenses that may be related in some cases, independent in others. These are: technical, economic, governance, and legal. A product or service can be decentralized in one layer while remaining completely centralized in another. Three parts of this framework were presented in Decentralization for Web3 Builders: Principles, Models, by a16zcrypto back in 2022. That piece focused on technical, economic, and legal dimensions. I’ve adapted the framework here by treating governance as its own practical product-evaluation lens (closely related to but distinct from pure legal considerations). I focus primarily on the builder and user-experience side, while still acknowledging legal aspects where they affect product design, compliance, or user control.
Technical decentralization
The question here is, Where does the code live, and where does it execute? If the application relies on a central server (like Amazon Web Services) to function, it is technically centralized. A more decentralized protocol, such as Ethereum, runs instead on a global network of independent nodes. If one node goes down, or one government bans it, the code keeps running nonetheless.
Going deeper, we can ask where the system runs, who operates the infrastructure, whether users can independently verify state, and whether the product depends on centralized servers, RPC providers, bridges, or frontends.
Technical decentralization is not simply a question of whether a product “uses blockchain.” Most Web3 products are hybrid systems. The user interface, indexing, analytics, and many data services often run on traditional cloud infrastructure, while the blockchain handles trust-critical state and rules such as asset ownership, transfers, settlement, governance, or collateral logic. In that sense, the app usually does not run entirely on-chain. Rather, the most important state transitions are executed and verified by decentralized nodes, while the surrounding product experience remains partly off-chain. The deeper question is not “Is there a token?” but “Which parts of the product can keep working, be verified, or be accessed if the original company, website, API, or infrastructure provider disappears?” We’re going to re-visit this topic more deeply momentarily.
Economic decentralization
This lens asks, Who owns the tokens? If 90% of a project’s tokens are held by the founding team and three venture capital firms, the product is economically centralized. True decentralization requires a wide, fair distribution of ownership so that no single entity can manipulate the market or the protocol’s internal economy.
Governance decentralization
This question is about power. Who decides when the code is updated? If a single “Labs” company makes all the decisions, it’s a centralized hierarchy. In a decentralized model, these decisions are made by a distributed community of stakeholders.
Legal
I’m including this for completeness, though it’s not my core focus here. For a fuller reading on legal decentralization, the a16zcrypto paper author Miles Jennings suggests you see their full paper on the topic, Principles & Models of Web3 Decentralization.
More On the Tech Side
Economic and Governance decentralization are both policy type decisions. While they have their complexities in Web3 vs. traditional finance, it’s the technical bits and pieces that seem to get confusing. Some appear to think “decentralized” means a program of sorts just runs on a blockchain. This might technically be possible, but is generally unlikely. We need to go a bit deeper here.
Or maybe we don’t. Still, I’m going to because to be perfectly candid with you, this is one part that confused me at first when I first started working in this space. The first time you hear, “Decentralized app” it kind of begs the question, “OK, so how do you split up where this thing runs?” Part of the mind shift is that “distributed” architecture sounds similar. But it’s not. (“Distributed” means spreading the same work across many servers for speed; “Decentralized” means no single entity controls those servers”)
So, let me try to explain this as I wish someone had described it to me day one entering into Web3 world.
First, What Actually Runs “On The Blockchain”
A blockchain is essentially a shared computer that thousands of nodes all agree on. You’ve likely heard that part over and over. When people say an app “runs on the blockchain,” they usually mean a smart contract; a small program stored on-chain that validator and full-node software executes or verifies transactions according to the protocol’s rules. Think of it like a vending machine: you put in a coin, press a button, and the machine does exactly one predefined thing. No human in the loop.
But here’s the key thing… running code on-chain is extremely expensive. Every operation consumes gas because on-chain computation and storage must be verified by the network and included in shared state. So you wouldn’t, say, run a video game engine on Ethereum because the cost would be astronomical and the speed would be unusable. Technically, you could, but you wouldn’t due to cost. And at some point, as a practical matter your app would run out of gas. Literally in this case as there’s no practical way an app would be able to keep paying for execution. More precisely, individual transactions would run out of gas, so the cost of keeping the app running this way would become impractical.
Sometimes web, cloud, blockchain seems a bit mystical. But it still all comes down to operations executing on a CPU on a real box somewhere. And that costs electricity, dollars, etc. I think somewhere from the early 2000s until mid 2020s, “the cloud” metaphor felt ethereal to a lot of people even in technical spaces except maybe for those who owned P&Ls with hosting costs in their face. (Like magic floating resources or something. Which means sellers did a great job as it was marketed that way.) Lately, with AI CPU/GPU costs becoming more front and center discussions, it’s seeming to be a bit more concrete. That happens when the bills are more in your face. I think blockchain often gets the same treatment; people imagine pure math or digital magic instead of real computers agreeing on state, even when there’s been talk of electricity costs and so on.
So what do apps actually put on-chain vs. off-chain?
It comes down largely to state storage and transitions. Meaning, what data needs to be trustworthy and tamper-proof? In practice, most apps split themselves up:
On-chain (the smart contract): The critical logic and state. For a decentralized exchange like Uniswap, this means the rules for swapping tokens and the actual pool balances. For an NFT marketplace, it’s ownership records. This is the stuff that must be trustless; nobody should be able to secretly change it.
Off-chain (traditional servers): Everything else. The frontend website, the search functionality, price charts, user profiles, notification systems. This stuff doesn’t need to be decentralized. Some of it may still matter or be desired onchain for censorship resistance, privacy, or resilience, but again, as a practical matter this isn’t often done. At least not yet.
A real example to make this concrete
Take Uniswap, one of the most-used decentralized apps. The core Uniswap protocol contracts on Ethereum are designed to keep functioning independently of the Uniswap Labs website. Many core contracts are immutable, though surrounding components such as interfaces, routers, token lists, and governance settings can vary.
So when you go to app.uniswap.org, you’re loading a regular website hosted on regular servers. It’s the same as any ole’ web page, WordPress blog, whatever. The difference is that for some functions or data, that frontend reads from the blockchain and helps you build a transaction. Still, the front end itself is centralized. If Uniswap Labs (the company) takes that website down, the smart contracts still exist and still work. You’d just need another way to talk to them; a different frontend, a command line, or another app.
So the engine is decentralized. The dashboard is not. Or maybe it’s more precise to say, some parts of the engine and the data are decentralized.
Can a whole app live on-chain?
Technically yes, but it’s rare and limited. As mentioned, it would likely be very expensive and impractical. Some projects do store their frontend code on-chain or on decentralized storage like IPFS (a peer-to-peer file system) or Arweave (a permanent storage network). Fully on-chain NFT projects, for example, store the artwork itself as code in the smart contract rather than linking to an image on someone’s server.
But for anything complex, like a social media app, a game with rich graphics, running everything on-chain is impractical today. It would be like trying to run a modern website on a calculator. The costs and speed limitations are just too severe.
Let’s Look at a Typical architecture (most common):
- Frontend: A normal website (hosted on AWS, Vercel, or maybe IPFS for decentralization) that connects directly to the blockchain via libraries like ethers.js or web3.js and a wallet (MetaMask).
- Backend logic: Smart contracts on the blockchain (no traditional server needed for core functions; though it depends what you might mean by “core functions”).
- Data: Critical state (balances, ownership) on-chain; large data (images, metadata, logs) off-chain (IPFS, Arweave) with hashes on-chain for verification.
- Optional helpers: Indexing services (The Graph), oracles (Chainlink for external data), or a light centralized backend for UX (e.g., caching queries).
Result: We should really only put that which needs trustlessness on-chain (state transitions, ownership, rules). Everything performance-heavy or large stays off-chain. That’s why the value in these apps is often more about state storage and verifiable execution than running the entire app on-chain.
So what’s the general summary?
Most “decentralized apps” are really hybrid apps. They use the blockchain for the parts that matter most, like ownership, money, critical rules, but use traditional infrastructure for everything else. That’s not necessarily a bad thing, but it does mean the word “decentralized” is describing only part of the system.
The question you should always ask is: what specifically is decentralized, and does that cover the parts I actually care about being decentralized? If you care about reducing reliance on a company to hold your funds, well-designed on-chain smart contracts can help. Though it’s still the case that contract bugs, bad approvals, compromised wallets, admin controls, and oracle or bridge failures can still create risk. If you care about nobody being able to block your access entirely, you’d also need decentralized frontends. And that’s where most projects still have a gap. Or rather, it might not be fair to say it’s a gap. That’s a value judgment. It’s just how most things in fact work as a practical matter.
The “Kill Switch” and Administrative Controls
There is a very practical way for the general public to test how much an app is decentralized: looking at the “admin keys”.
In the traditional world, every product has a “kill switch”. A bank can freeze your account; a social media platform can delete your profile. They have absolute administrative control. In Web3, we look instead for immutable smart contracts: code that, once deployed to the blockchain, cannot be changed by anyone; not even the original developers.
However, many projects maintain “upgradeability” through admin keys. This allows developers to fix bugs or patch security holes, but it also represents a central point of failure. Think of a regulator forcing a developer to use their admin key to freeze a specific user’s funds. In such a case, the decentralization of that product is just an illusion. A more decentralized product reduces unilateral admin control through mechanisms such as multisigs, timelocks (a mandatory waiting period before any proposed change can take effect), transparent proposals, community votes, and eventually minimized or renounced privileges.
The “Bus Factor” and Human Resilience
In management theory, the “bus factor” question asks: How many people would have to be hit by a bus for the project to fail? Yes, it’s a morbid question, but also useful. Small startups and founder-led projects can have a very low bus factor if critical knowledge or authority sits with only a few people.
A decentralized product aims for a high bus factor. This means that the protocol’s survival should not depend on one specific company or one specific set of developers. If “Project A” is built by “Company X” but there are four other independent teams also building tools, interfaces, and upgrades for that same protocol, the project has achieved human decentralization. The goal is to build resilience. If the primary development firm goes bankrupt or is shut down by authorities, the protocol lives on because the knowledge and the power to maintain it are distributed across the globe.
Data Sovereignty and the Frontend Gap
There is a common “trap” in Web3.
The backend of an app is decentralized but the frontend (the website you interact with) is not. If you access a decentralized exchange through a single website (e.g., app.exchange.com), you are still using a centralized gateway. If that website is blocked or goes offline, most users believe the product is “gone”.
For true decentralization to exist, the interface has to be just but one of many ways to talk to the engine. The data (think of your balances, trades, and history) lives on the blockchain, not in the company’s database. As a result, you can use “community frontends” or even run your own local version of the website to access your funds. Instead of being a “tenant” on a company’s platform, you are a sovereign user of a public utility.
The Path of Progressive Decentralization
A final point to keep in mind is that decentralization is often a journey, not a starting point. This journey is known as progressive decentralization. In the early stages of a startup, being decentralized is actually a liability. It is slow, hard to coordinate, and impossible to fix bugs quickly. But as an app gains traction, it should become more decentralized across all dimensions. The idea of using progression has made sense in several places in the past. In low bandwidth environments, progressive rendering of most important screen elements made sense. For onboarding reasons, it’s often useful to allow for progressive disclosure of user information to ease initial sign-up. The general model can apply here as well.
Web3 products can follow a roadmap similar to this:
- Centralized alpha: The founders move fast and keep control to build the product.
- Community handover: As the product matures, the team distributes tokens and increases the “bus factor”.
- Full decentralization: The founding team steps back, and the protocol becomes a self-sustaining public utility governed by its users.
For a buyer or user, one goal may be to verify where a project is on this roadmap. Are they actually moving toward decentralization, or is “decentralized” just a permanent marketing tag used to dodge regulation? Many successful Web3 products never fully decentralize. And not everything has to. The point is to evaluate where the values are on a per project basis.
Conclusion: The Transparency Trade-off
Today, decentralization is more like a trade-off than a philosophical preference. You give up the speed and “customer support” of a centralized company in exchange for security, censorship resistance, and ownership. For the general public, “decentralized” should mean “unstoppable”. That, however, might be only an idea. Let’s say more practically that decentralized should at least imply meaningful resistance to unilateral shutdown, censorship, or rule changes.
Today, decentralization is more like a trade-off than a philosophical preference. You might give up the speed and “customer support” of a centralized company in exchange for security, censorship resistance, and ownership. For the general public, should “decentralized” mean “unstoppable”? That might be a core value, or not. Let’s say more practically that decentralization should likely at least imply meaningful resistance to unilateral shutdown, censorship, or rule changes. But as to where the core values are for decentralization? That will depend on the purpose of the app and customer use cases.
If a product can be stopped, censored, or unilaterally changed, it may still use Web3 infrastructure, but users should recognize that it’s not fully decentralized. Understanding these distinctions is a great step toward more fully understanding how these pieces fit together.