Do We Even Need a Blockchain to Stop Fake Diplomas?

Blockchain for Academic Credentials — Part 1 of 3: A Reality Check

Every few months, someone rediscovers a great startup idea: use blockchain to stop diploma fraud. Credentials get forged, employers can’t easily verify them, and blockchain is tamper-proof — so surely this is a match made in heaven.

I thought so too, until I actually looked at the landscape. Here’s the honest version.

The proof-of-concept phase ended five years ago

In Korea, this isn’t a frontier anymore. POSTECH issued blockchain-based degree certificates to its entire graduating class back in 2020, using a service called Broof. Korea University rolled out blockchain student ID cards with SKT and Hana Bank around the same time. Today the market is effectively led by RaonSecure’s OmniOne platform, which handles digital degree and admission certificates for major universities, digital badges, and — this is the important part — the national mobile ID infrastructure itself (mobile driver’s licenses, government employee IDs) runs on it.

Translation: a solo developer cannot walk into this as “the diploma verification startup.” The bottleneck isn’t code. It’s contracts with universities, references, and compliance — a sales and trust game, not an engineering one.

The real vulnerability isn’t what you think

Here’s the insight that reframes the whole problem.

When people say “blockchain stops forgery,” they’re imagining someone editing a PDF. But a plain digital signature already solves that — change one character and the signature breaks. You don’t need a chain for tamper-evidence.

The actual weak point is one level up: does this signing key really belong to Seoul National University? A forger doesn’t edit a real diploma; they issue a perfect, correctly-signed diploma from a key they claim is a university’s. Blockchain proves “some key signed this.” It does not prove “that key is genuinely the university’s.”

That last step — binding a key to a real-world institution — is a trust anchor problem. It’s governance, not cryptography. It’s why solo blockchain credential projects tend to stall: the hard part lives in a registry that a government or accreditation body has to maintain, and you can’t code your way around it.

The uncomfortable part: you may not need a blockchain at all

Modern credential standards — W3C Verifiable Credentials plus the OpenID4VC family — lean surprisingly little on chains. In a typical setup, the holder generates an identity locally (did:key), the issuer signs the credential, and revocation is handled by a status list published on a plain web server. Issuance, storage, and verification all work with signatures and a status list. No block in sight.

So framing a project as “a blockchain service” is, in this domain, already a slightly dated instinct. The signature does the heavy lifting. The chain is optional infrastructure for a few specific jobs.

So where does that leave blockchain?

Not nowhere — but in a narrower, more honest role than the pitch implies. There are exactly a few places a chain earns its keep: as a decentralized registry for issuer keys, as a tamper-evident anchor for credential hashes, and as an on-chain revocation source of truth. Which of those you use defines which kind of blockchain credential system you’re building — and they’re genuinely different architectures.

In Part 2, I’ll walk through how verifiable credentials actually work end to end — the trust triangle, and the DID / VC / VP data model. In Part 3, I’ll map out exactly where a blockchain fits (three distinct patterns) and the one thing you must never put on-chain.

If you’re evaluating this idea for a product, the takeaway is blunt: as a market, it’s crowded and gated by institutional trust. As a thing to understand and build, it’s one of the cleanest showcases of decentralized identity there is.

---

Tags: Blockchain, Verifiable Credentials, Decentralized Identity, Web3, EdTech