Do We Actually Need Blockchain?

Every few years, blockchain gets attached to something that already worked fine. Supply chains. Voting. Loyalty points. Digital identity. Even, at various points, someone's grocery list. The pitch is always the same: decentralization, transparency, immutability. And the quiet question that rarely gets asked out loud is: did this actually need any of that?
This isn't an anti-blockchain post. Some of the use cases genuinely are clever, and a few are close to essential for what they're trying to do. But "genuinely clever" and "necessary" are different questions, and conflating them is how you end up with a blockchain-powered to-do list. Let's actually separate them.

What blockchain is actually good at

Strip away the buzzwords, and blockchain solves one specific problem exceptionally well: letting mutually distrusting strangers agree on a shared, tamper-proof record, without a central authority.
That's it. That's the whole superpower. Everything blockchain is good at flows from that one sentence. Notice what it requires, strangers, distrust, and no acceptable central authority. If any one of those three isn't true in your situation, you probably don't need a blockchain at all.

A simple test

Before reaching for blockchain, it's worth honestly asking three questions:
1. Do you actually have multiple parties who don't trust each other? If your system only has one legitimate operator (your company, your government agency, your app), there's no trust problem to solve. A regular database, run by that one trusted party, is faster, cheaper, and easier to fix when something breaks.
2. Is a central authority genuinely unacceptable, not just inconvenient? Sometimes a central authority is fine (or even good). Your bank clears your transactions. Your government issues your passport. These aren't problems that need solving with decentralization; they're just how the world already works, with accountability built in through law and regulation.
3. Does the data actually need to be public and permanent? Blockchain's tamper-evidence and transparency are a feature, right up until you have data that legally must be corrected, deleted, or kept private. "Immutable" cuts both ways: you can't quietly fix a mistake, and you can't comply with a request to erase someone's personal information after the fact, either.
If your answer to all three is genuinely "yes" — multiple mutually distrusting parties, no acceptable central authority, and a real need for public permanence — blockchain might actually be the right tool. If even one answer is "no," you're probably better off with a normal database and a competent engineering team.

Where it actually holds up

A few cases genuinely pass this test:

• Cross-border payments and remittances, where no single national bank is trusted (or legally able) to sit in the middle of every transaction.
• Censorship-resistant money, for people living under capital controls or unstable currencies, where "the central authority" is precisely the thing being distrusted.
• Public provenance of digital ownership, proving who created or owns something, when no single company should be the arbiter (this is the more defensible version of the NFT pitch, stripped of the speculation).
• Decentralized finance protocols, where the entire point is removing a bank or broker from the loop, the middleman is the problem being solved, not a detail.

Notice the pattern: in every one of these, distrust of a central party isn't a hypothetical inconvenience, it's the entire reason the product exists.

Where it usually doesn't

And then there's the much longer list of things blockchain gets bolted onto anyway:

• Supply chain tracking, where a handful of large, already-trusted companies control the actual data entry points. A shared database with proper access controls does the same job, without the overhead, and without pretending that "trustless" applies when the same three corporations are the only ones writing to the chain.
• Voting, which sounds like a natural fit for "tamper-proof and transparent," but actually needs the opposite of blockchain's biggest feature: voter privacy. A permanent, public, unchangeable record of who voted for what is a nightmare, not a solution.
• Internal corporate record-keeping, where there's already one trusted authority (the company itself) and no realistic scenario where a shared, decentralized ledger among departments who already work for the same organization solves anything a normal database wouldn't.
• "Blockchain-powered" apps that never actually needed decentralization, where the real motivation was marketing, fundraising optics, or genuine enthusiasm for the technology rather than an actual trust problem being solved.

The tradeoffs people tend to skip past

Even when blockchain is the right call, it's worth being honest about what you're signing up for:

• Throughput and speed. Decentralized consensus is inherently slower than a single trusted server making a decision. This is a real, structural cost of removing the middleman, not a temporary limitation waiting to be optimized away.
• No undo button. Immutability protects against tampering, but it also means mistakes, bugs, and fraud are permanent once confirmed, unless the entire community agrees to intervene, which is itself a messy, contentious process.
• Energy or capital cost, depending on the consensus mechanism. Proof of Work spends electricity; Proof of Stake ties up enormous amounts of capital. Neither is free, even if the "fee" shows up somewhere other than your monthly server bill.
• User experience. Managing private keys safely is still a genuine, unsolved usability problem for average users, more than a decade after Bitcoin launched.

None of these are dealbreakers for the use cases that genuinely need decentralization. They're just costs that only make sense to pay if you actually needed what blockchain uniquely offers in the first place.

So, do we actually need it?

Sometimes, yes. When the entire point of a system is that no single party should be trusted to run it, blockchain isn't a buzzword; it's the only architecture that actually fits the problem.
Most of the time, though, the honest answer is: probably not, but it's an interesting technology regardless. A well-run, boring, centralized database — with proper backups, audits, and access controls — quietly outperforms a blockchain on speed, cost, and simplicity for the vast majority of applications people try to force it into.
The technology isn't the problem. The habit of reaching for it before asking what problem you're actually solving, that's the part worth being more careful about.