The Limitations Nobody Puts on the Slide

Most "blockchain limitations" lists stop at the same four items: it's slow, it uses a lot of energy, wealth concentrates over time, and losing your key means losing your money forever. All true, and all worth knowing, but they're also the limitations that get repeated so often they've become background noise.
There's a second tier of problems that get discussed far less in beginner-friendly content, mostly because they require a bit more context to explain. They're arguably more interesting, because they're not really about blockchain being "too slow" or "too expensive", they're about blockchain running into problems that have nothing to do with computation at all: trust, law, and human coordination.

Blockchains are blind — the oracle problem

A blockchain can verify anything happening inside itself with total confidence: did this signature match, is this coin already spent, does this balance add up. What it cannot do, at all, is know anything about the outside world. It has no way to check the weather, a sports score, a flight delay, or a stock price on its own.
This matters enormously once you start building smart contracts that need real-world data, a crop insurance contract that pays out if rainfall drops below a threshold, or a DeFi loan that gets liquidated if an asset's price crosses a line. Someone, or something, has to feed that outside information in. That "something" is called an oracle, and it quietly reintroduces the exact trust problem blockchain was supposed to eliminate: now you have to trust whoever — or whatever — is reporting the price.
This isn't a hypothetical weakness. A large share of DeFi hacks are actually oracle manipulation attacks: an attacker takes out a massive, temporary "flash loan," uses it to briefly distort the price of an asset on a low-liquidity exchange, tricks a lending protocol's oracle into believing that distorted price is real, and drains the protocol before the price snaps back, all within a single transaction. The blockchain itself works flawlessly the entire time. The vulnerability was never in the chain; it was in what the chain was told to believe.

Cross-chain bridges are the industry's weakest point

There are now hundreds of separate blockchains, and inevitably, people want to move assets between them, Bitcoin into an Ethereum-based app, Ethereum into a faster chain for cheaper trading, and so on. The software that makes this possible is called a bridge, and bridges have become, by a wide margin, the single most exploited category of infrastructure in the entire crypto industry.
The Ronin Bridge hack in March 2022 — connected to the NFT game Axie Infinity — saw attackers drain roughly $625 million by compromising just five of the bridge's nine validator signatures, later attributed to North Korea's Lazarus Group. A few weeks earlier, the Wormhole bridge lost around $326 million after an attacker found a flaw that let them mint wrapped Ether on Solana without actually depositing anything on the Ethereum side. Three of the five largest crypto hacks in history involve a bridge.
The underlying issue is structural, not incidental: a bridge has to somehow convince Chain B that something genuinely happened on Chain A, and every method for doing that — a small set of trusted validators, a light client, a multi-signature wallet — introduces a new point of centralization and a new attack surface, layered on top of two blockchains that were each individually secure on their own.

"Code is law" sounds great until the code is wrong

Smart contracts are marketed on the idea that the rules are enforced automatically, with no need for a judge or an appeals process. This is genuinely powerful — right up until the code itself contains a bug, at which point "the code is the law" stops being a feature and becomes the entire problem.
The clearest example remains The DAO, a 2016 Ethereum-based investment fund that raised roughly $150 million from the public. A flaw in its contract logic let an attacker repeatedly withdraw funds before the contract could update their balance, ultimately draining around $50–60 million worth of Ether — about a third of everything the fund held. There was no bank to call, no customer support line, and technically, the attacker hadn't broken any rule the code itself enforced; they'd simply found a rule the code's authors hadn't intended.
The resolution was arguably more revealing than the hack itself: Ethereum's community chose to hard fork the entire blockchain, rewriting history to return the stolen funds — directly contradicting the "immutable, no one can reverse it" pitch that blockchain is usually sold on. A minority who disagreed kept using the original, un-forked chain, which still exists today as Ethereum Classic. Immutability, it turns out, is a technical property right up until a large enough group of humans collectively decides it isn't.

MEV — the invisible tax nobody votes on

Here's a subtler problem that barely gets discussed outside of technical circles: whoever gets to decide the order of transactions inside a block has real power, and real profit opportunity, entirely within the rules of the system.
This is called Maximal Extractable Value (MEV). In practice, it looks like: a miner or validator (or a specialized bot working with them) sees a large trade about to go through on a decentralized exchange, inserts their own trade immediately before it to benefit from the price movement, and another one immediately after to lock in the profit — a "sandwich attack." None of this breaks a single protocol rule. It's not hacking. It's simply exploiting the fact that whoever assembles the block gets to choose the order, and order has value.
Estimates of total MEV extracted across Ethereum alone run into the billions of dollars over the network's history. It's a quiet, structural tax on ordinary users that has nothing to do with fees, gas costs, or any of the limitations usually put on a slide — and it exists precisely because removing a trusted central authority also removes any neutral referee for transaction ordering.

Immutability and privacy law don't actually get along

Most privacy regulations — Europe's GDPR is the best-known example — give individuals a legal "right to be forgotten": the right to demand that a company permanently delete their personal data. Blockchain's entire value proposition is the opposite of that: once something's written to the chain, it's specifically designed to be impossible to delete.
This isn't a solvable engineering bug — it's a genuine, unresolved legal-and-technical standoff. Projects have tried workarounds (storing personal data off-chain and only a hash on-chain, for instance), but a hash of your name still permanently, publicly proves a specific piece of data about you once existed and was tied to a specific wallet, which regulators in several jurisdictions have argued may still count as personal data under the law. Nobody has fully resolved this tension yet, and it's a real reason enterprises are cautious about putting anything even loosely tied to a real person's identity on a public chain.

The pattern underneath all five

None of these are really problems with hashing, consensus, or cryptography — the "hard" parts blockchain is usually praised for get this right. Every one of these limitations shows up at the seams: where the chain has to talk to the outside world (oracles), where two chains have to talk to each other (bridges), where code has to anticipate every possible human intention in advance (smart contract bugs), where someone still has unchecked power over ordering (MEV), or where a technical guarantee collides head-on with a legal one (privacy law).
Blockchain solved the trust problem inside the ledger extraordinarily well. It turns out the much harder problems were always going to be the ones sitting right at its edges.