Where the Blockchain Actually Sits
Blockchain for Academic Credentials — Part 3 of 3: The Patterns
Across Parts 1 and 2, a theme kept surfacing: most of a credential system runs on digital signatures, and the blockchain only shows up in a few specific places. This final part makes that precise. “Blockchain diploma verification” isn’t one architecture — it’s three, depending on where you put the chain.
Pattern A — Hash anchoring (the Blockcerts approach)
The credential itself stays off-chain. What goes on-chain is only a hash of the VC — or a Merkle root of a whole batch of them. To verify, you recompute the hash and check that it exists on-chain.
What the chain buys you: tamper-evidence and a trustworthy issuance timestamp. What it costs: almost nothing — one hash per batch. This is the lightest possible use of a blockchain, and historically the most common (MIT’s Blockcerts pioneered it).
Pattern B — DID / key registry (did:ethr)
Here the chain holds the issuer’s public keys and their rotation history. The point is key resolution without a central server: anyone can look up “what is Seoul National University’s current signing key?” on-chain, and trust that the history of changes is tamper-evident.
The credential itself is still off-chain. The chain is acting as a decentralized PKI — a public directory of who-signs-with-what. This directly addresses part of the trust-anchor problem from Part 1, though the initial “this DID really is the university” binding still has to come from somewhere authoritative.
Pattern C — On-chain credential as a Soulbound Token
Now the credential is the chain object. You mint it as a non-transferable token — ERC-5192 (Soulbound), a locked variant of ERC-721. The chain becomes the credential registry itself.
This is the most “crypto-native” pattern, and the most tempting for developers coming from an NFT background, because a diploma is conceptually a non-transferable NFT. But there’s a hard constraint: you cannot put personal data in the token. The token holds only a hash and a URI; the actual credential data lives encrypted off-chain, with the token pointing to it. Revocation becomes a mapping in the contract (tokenId → revoked).
If you already work with ERC-721, this is the pattern that maps most directly onto what you know — you’re essentially building a locked NFT with a hash pointer and a revocation mapping.
The one rule you can’t break
Whatever pattern you choose: never put personal data on-chain. Names, birth dates, grades — none of it.
Blockchains are immutable and public. The moment you write personal data, you’ve created something that can’t be deleted and is visible to everyone, forever. That’s a direct violation of Korea’s Personal Information Protection Act and the EU’s GDPR. The chain gets only three kinds of thing: hashes, revocation status, and public keys / DIDs. The real data always stays off-chain, encrypted, under the holder’s control.
Putting it together
Step back and the picture is clean. The credential lifecycle — issue, sign, hold, present, verify, revoke — is carried mostly by signatures. The blockchain is optional infrastructure that slots into three narrow jobs: anchoring hashes (A), resolving issuer keys (B), or acting as the credential registry itself (C). Pick based on what you actually need, not on the assumption that “blockchain credentials” requires putting everything on a chain.
And the honest bottom line from Part 1 still holds: as a market this space is crowded and gated by institutional trust, but as a system to understand and build, it’s one of the clearest, most rewarding showcases of decentralized identity you’ll find. If you’re going to build a demo, Pattern C on top of the W3C VC model is where the learning is densest.
Tags: Soulbound Tokens, Blockchain, Verifiable Credentials, Ethereum, Decentralized Identity
