An essay
Perpetual means perpetual.
A credential should outlast the company that issued it, the platform that hosted it, and the device it was earned on.
We named ourselves after that idea — and we built the platform to deliver it.
Verified credential
01 — The expectation
A credential is supposed to last a lifetime.
Think about the credentials that matter most in your life. A degree. A professional licence. A certification that opens a career door.
These are not subscriptions you cancel next year. They are achievements you carry with you. They are supposed to be permanent.
And yet — almost every digital credential issued today is fragile.
The credential the recipient earned does not really belong to them. It belongs to whichever company is currently keeping the lights on.
02 — The architecture choice
What is the longest-lasting digital thing in the world?
Not the cloud. Not enterprise software. Not even the web itself.
The longest-lasting digital things in the world today are the values that live inside public blockchains. The first transaction on Bitcoin's chain, recorded in January 2009, is still readable on every node of the network sixteen years later. The earliest Ethereum transactions are similarly intact. The chains have not been turned off. They cannot be turned off.
These networks are not products. They are not maintained by a company. They run on infrastructure spread across hundreds of thousands of independent operators in dozens of countries. The economics that keep them running are baked into the protocols themselves.
If a credential is anchored on infrastructure like that, the credential outlives the company that issued it.
That is the architectural choice Perpetual is built around.
03 — The wedge
Where most platforms stop.
Many credentialing platforms now claim to be "blockchain-backed." Most of them mean only that a hash is recorded on a public chain. The original credential — the one a verifier needs in order to compare against the hash — lives in the platform's own database.
When the platform disappears, the hash on the chain becomes a number with nothing on the other end of it. The credential is not really verifiable, because the artifact the hash refers to is gone.
This is the gap Perpetual closes. We put both halves on infrastructure no single company controls — the cryptographic anchor on a public chain, the credential and the PDF on a permanent storage network. Either half by itself proves nothing. Both halves together survive us.
04 — The architecture, in plain language
Five steps. Each one independent of us.
- 1
The issuer signs the credential.
Using their own cryptographic key, controlled by them, published under their own domain.
- 2
The credential goes to permanent storage.
The signed file, plus the rendered PDF a human can read, plus the issuer's public profile.
- 3
The hash goes to the public chain.
A single transaction anchors a Merkle tree summarising thousands of credentials at once.
- 4
The recipient receives a signed file they own.
Not a row in a database. Not a URL that depends on us. A file.
- ✓
Anyone can verify, on any tool, forever.
The verification reads from the public chain and the storage network directly. We are not in the path.
05 — The promise
If Perpetual shuts down tomorrow:
Every credential we ever issued is still anchored on the public blockchain.
Every signed credential file and PDF is still on the permanent storage network.
Every issuer's identity is still resolvable from their own domain.
Every recipient still owns their signed file.
Every verifier — including the public BlockCerts verifier — still works.
Nothing depends on Perpetual being alive. That is the design constraint we built around.
06 — Why the name
Perpetual.
We needed a name that would carry the architectural promise into the brand.
Perpetual means without end. It is the simplest, most direct word for what we are trying to make true: a credential that exists, verifiable, indefinitely, regardless of what happens to us or to anyone else along the way.
The name is a constraint as much as a label. Every product decision we make has to honour it.
If a feature would make a Perpetual credential less perpetual — for example, by introducing a dependency on our continued operation — we don't ship it.