Is this deployment concentration the same thing as "Ethereum's network itself being decentralized or not"?
No — and that's the point most likely to get misread. Ethereum's consensus layer — who can propose blocks and validate transactions — is currently maintained by hundreds of thousands of independent validators, and the degree of decentralization at that layer has nothing to do with contract deployment concentration. What the research exposes is a different kind of concentration at the application layer: "who can deploy a Smart Contract" (anyone) and "who actually deploys and controls the vast majority of them in practice" (a handful of entities) are two entirely separate questions. The former is a protocol rule; the latter is the actual ecosystem shape that emerges from using that rule — the two can hold true simultaneously without contradicting each other. Ethereum's base layer can remain highly decentralized while control over the contract application layer is highly concentrated, and that's precisely the gap the research team chose to highlight.
Why did it evolve this way? Isn't there any mechanism to limit how many contracts a single entity can deploy?
Ethereum's protocol has no such limit, and isn't designed to have one — the only cost of deploying a contract is gas, and in principle anyone can deploy without limit. That's part of the "permissionless" design philosophy itself; capping deployment counts would contradict that core principle. The concentration that emerges is, at its core, a natural result of economic incentives: the factory contract pattern lets a single development team write code once and serve millions of users at scale (batch NFT minting, batch Token issuance services, for example) — that's an efficiency consideration, not deliberate monopolization.
What actually deserves attention isn't "whether deployment counts are capped," but "whether transparency is sufficient." In the study, 6 of the top 10 deployer contracts had publicly verified source code, but 4 unverified contracts still controlled 4.78 million child contracts combined — that's the real governance gap worth addressing: not banning large-scale deployment, but requiring that large-scale deployers' code be publicly auditable.
How can an ordinary user actually check whether a contract uses a proxy pattern, or whether control is overly concentrated?
The most direct first step is looking up the contract address on Etherscan and checking the "Contract" tab for a "Read as Proxy" or "Is this a proxy?" indicator — if Etherscan auto-detects it as a proxy, it typically displays the corresponding implementation contract address, which you can then trace further to see its deployer and recent upgrade history. The second step is checking the contract's "Code" tab to confirm whether the source code is verified — an unverified contract means users can only see compiled bytecode, not readable logic, which makes risk assessment significantly harder.
The third and most commonly overlooked step is checking who actually holds the upgrade privileges — if the controlling address is a regular externally-owned account (EOA) rather than a multisig wallet, an upgrade decision could theoretically be executed with a single Private Key, a completely different risk tier from a contract governed by a multisig requiring multiple co-signers to approve an upgrade. This information typically has to be pieced together on Etherscan by cross-referencing the "Read Contract" function with past transaction history — no single page will simply tell you "this contract is safe or unsafe."
If I discover the protocol I use depends on a large number of undocumented contracts, what should I do — or not do?
There's no need to panic-withdraw immediately, but it's worth treating this discovery as a signal to do one more layer of homework rather than ignoring it. First, check whether those undocumented contracts have verified source code — if verified, at least the logic is publicly inspectable, a much lower risk than a fully opaque, unverified contract. Second, look at whether this protocol has had past security incidents and whether its audit reports actually cover these peripheral contracts, or only the core contracts listed in official documentation — if the audit scope is noticeably narrower than the actual dependency list, the real risk you're carrying may be higher than what the audit report's surface-level assurance suggests.
Third, this isn't a call to avoid every protocol that uses proxy or factory patterns entirely — in practice, nearly all mainstream DeFi protocols use these patterns, and avoiding them completely isn't realistic. A more practical approach is to add "is this protocol's core contract control concentrated in a single key" to the same checklist as the questions you're probably already asking — TVL size, number of audits — rather than relying on just those latter two.
Ethereum is often described as a "permissionless, anyone-can-deploy" decentralized platform, and that's technically true — anyone genuinely can deploy a Smart Contract. But cut into the question from a different angle — who actually controls these contracts — and the on-chain data tells a different story. As of the end of 2024, Ethereum mainnet hosted 41.1998 million alive smart contracts, and just 11 deployer addresses were directly responsible for deploying 20.5 million of them — exactly 50%. Widen the lens to the top 100 deployers and that figure climbs past 80%. This comes from a large-scale empirical study by researchers at KTH Royal Institute of Technology, analyzing over 41 million contracts and 11 billion inter-contract interactions — one of the largest public studies of Ethereum contract deployment concentration to date.
This level of concentration is driven by the "factory contract" pattern — a contract that can programmatically deploy thousands of child contracts via the CREATE or CREATE2 opcodes, without requiring a manually initiated transaction each time. The study found that 83 of the top 100 deployers are themselves contracts rather than human-controlled accounts, and the single most prolific factory contract alone deployed 4.3 million child contracts — 10% of all alive contracts. This is why "a huge number of contracts" and "a huge number of developers or operators" turn out to be entirely different things — a massive contract count can trace back to a tiny number of operating entities.
Eight of the top 10 deployers primarily deploy "proxy contracts" — a design where child contracts delegate their execution logic to a centralized implementation contract via the DELEGATECALL opcode, rather than storing the logic themselves. The upside is easy upgradeability: update the implementation contract once, and every child contract's behavior changes in sync, with no need to migrate them individually. The cost is centralized control — if the deployer's key or admin privileges are compromised, an attacker could in principle manipulate every child contract that depends on that implementation contract at once. This isn't theoretical: in the 2025 Zoth protocol exploit, attackers used a compromised deployer wallet's admin privileges over proxy contracts to deploy malicious delegate logic, resulting in $8.4 million in stolen funds.
The research team also examined whether two major DeFi protocols — Uniswap and Lido — fully disclose, in their official documentation, the contract addresses their systems actually interact with on-chain. The results: among the external contracts Uniswap's documented contracts actually interact with, 18 turned out to be in-protocol but undocumented. Lido's gap was even larger — 25 of 78 related dependency contracts didn't appear in official documentation at all. In other words, even a highly trusted, thoroughly audited flagship protocol can have on-chain contract dependencies that are more complex and less transparent than what its official documentation shows.
If your assets sit inside a DeFi protocol, you're trusting not just that protocol's own code, but every underlying contract it depends on — dependencies that may not even be fully disclosed in the protocol's own official documentation. Before depositing assets into any protocol, beyond checking whether it's been audited, it's worth asking a sharper question: is its core contract an upgradeable proxy? If so, who controls the upgrade privileges — a single key, or a multisig? These answers are usually visible on the contract's Etherscan page, under the "Contract" tab — a more precise question to ask than simply "is this a contract on Ethereum" when judging how decentralized a protocol actually is.