The product
Three guarantees,
by design.
Permanent storage. Portable verification. Provable on a public blockchain. Every credential carries all three — every time.
End-to-end architecture
01 — Permanent
Storage that outlives the platform.
Most blockchain credential platforms record a hash of your certificate on a public chain — and stop there. The actual credential, the PDF, the data that makes the hash meaningful — all of it sits in the vendor's own database.
When that database goes away, the hash on the chain becomes a number with nothing on the other end of it.
Perpetual stores the whole thing.
On the blockchain
Cryptographic hash of the batch
Public. Immutable. Verifiable forever.
On permanent storage
Signed JSON + rendered PDF + issuer profile
Encrypted at rest, distributed worldwide, paid for once.
When a verifier checks the credential, they don't ask us. They walk the proof against the public chain, and they fetch the artifact directly from the storage network. If we are not in the path, we cannot be a single point of failure.
Why this storage layer specifically
Why we chose Arweave for storage.
We use Arweave for the permanent storage layer. Most decentralised storage networks are designed for distribution and retrieval — files come and go, and someone has to keep paying to keep them online. That's a fine model for some things, but not for credentials.
Disappears with the vendor.
A subscription stops, the database is decommissioned, and the credentials it indexed quietly stop verifying.
Persists only while someone is paying.
IPFS is a protocol for finding data; the data only lives if a pinning service is actively keeping it online. When pinning lapses, the credential is gone.
Paid once, archived for 200+ years.
An endowment funds storage indefinitely. No pinning, no recurring bill, no service that needs to stay alive for the data to remain accessible.
And we store the artifact, not just the link. Most platforms — even the ones that use decentralised storage at all — store only the signed JSON. The rendered PDF, the version a human actually reads, lives in the vendor's database. We store both: the signed credential a verifier reads, and the PDF a recipient prints. Both are permanent. Both survive us.
02 — Portable
Verification you don't control.
A Perpetual credential is a signed file that the recipient owns. They can store it locally, attach it to an email, upload it to LinkedIn, or hand it to a verifier. Anyone, anywhere, can verify it without ever touching the Perpetual website.
- The verifier resolves the issuer's identity from the issuer's own domain (using DID:web).
- The verifier fetches the on-chain transaction directly from the public blockchain.
- The verifier walks the cryptographic proof embedded in the credential.
- The verifier fetches the original artifact directly from the permanent storage network.
- The verifier checks the revocation list, also published on the issuer's domain.
At no point does the verifier ask Perpetual for permission, presence, or uptime.
Paste a credential or URL — the reference verifier for the standard
Open-source library — run your own verifier in any environment
Custom in-house tools
Anything that implements BlockCerts v3 or W3C VC 2.0
If we shut down tomorrow, every one of these still works.
03 — Provable
Cryptographic proof on a public chain.
Every batch of credentials we issue is hashed into a Merkle tree. The root of that tree is anchored on Ethereum — the largest public proof-of-stake blockchain — in a single transaction.
That transaction is immutable. Once written, it cannot be altered, deleted, or backdated by anyone — including us, including governments, including future Perpetual employees with administrator access. This is the property that makes blockchain anchoring meaningful.
- Computes the credential's hash
- Walks the Merkle proof embedded in the credential
- Confirms the resulting root matches the on-chain transaction
- Confirms the issuer's signature using their published DID
If all four steps pass, the credential is mathematically proven to have been issued by the claimed organisation, at the claimed time, with the claimed content. It requires Ethereum, the W3C standards, and open-source cryptography libraries — not Perpetual.
Ethereum mainnet
The largest public proof-of-stake chain. Every credential is anchored on Ethereum mainnet — verifiable by any third-party BlockCerts verification portal, without relying on Perpetual.
We use public chains deliberately. Many credential platforms run on private or permissioned blockchains because the costs are lower and throughput is higher. Those aren't really blockchains in the sense that matters here — they're databases with extra steps, controlled by whichever consortium runs the validators. A private chain can be turned off. A public chain cannot.
Standards
The open standards we ship on day one.
W3C Verifiable Credentials 2.0
The global specification for digital credentials
BlockCerts v3
MIT-originated standard for blockchain-anchored credentials
MerkleProof2019
The cryptographic proof embedded in every credential
DID:web
The issuer identity model
CredentialStatusList2017
Open revocation handling
Comparison
What you don't get with other platforms.
| Perpetual | Anchored-only platforms | Vendor-database platforms | |
|---|---|---|---|
| Hash anchored on public chain | ● Yes | ● Yes | — No |
| Full credential on decentralised storage | ● Yes | — No | — No |
| Rendered PDF on decentralised storage | ● Yes | — No | — No |
| Verifiable on third-party tools | ● Yes | Varies | — No |
| BlockCerts v3 native | ● Yes | Partial | — No |
| Survives vendor shutdown | ● Yes | — No | — No |
Product FAQ
Common questions.
What happens to my credentials if Perpetual shuts down?
They keep working. The on-chain anchor stays on the public blockchain. The signed credential and PDF stay on the permanent storage network. Any verifier — including the public BlockCerts verifier — continues to verify them. That's the entire point of the architecture.
Where can I verify a Perpetual credential?
Anywhere that implements BlockCerts v3 or W3C Verifiable Credentials 2.0. The public BlockCerts verifier at blockcerts.org is the most common starting point. The BlockCerts mobile wallet works on iOS and Android. The cert-verifier-js library lets you run your own verifier in any environment. And for the most rigorous check, the Ethereum and Arweave transaction IDs in every credential can be inspected directly on public block explorers — no application required.
Who controls the data?
The recipient holds the signed credential file. The on-chain anchor is on a public blockchain run by hundreds of thousands of independent validators. The artifacts are on a permanent storage network run by no single company. We don't control any of it.
What about GDPR? Can a credential be deleted?
Yes. We support cryptographic erasure ("crypto-shredding"): personal data is encrypted before being written to permanent storage, and the encryption key is held in our regional database. When a deletion is requested, we delete the key — making the on-storage data permanently unrecoverable, even though the bytes themselves remain. The on-chain hash never contained personal data to begin with.
What's the carbon footprint?
Negligible. Modern proof-of-stake blockchains use roughly 99.95% less energy than the older proof-of-work chains the bad reputation comes from. Permanent storage is paid for once at upload, with no continuous draw. Per-credential energy is on the order of fractions of a single kWh. Full numbers and citations on our Sustainability page.
Can I migrate from another platform?
Yes. We support import of credentials from BlockCerts-compatible platforms, and we can re-anchor them under your issuer DID. Talk to us about your specific situation.
What does revocation mean for a permanently-stored credential?
Revocation is a separate signal published on the issuer's domain (under CredentialStatusList2017). The credential file itself remains on permanent storage — that's by design, so the verifier sees the revocation rather than just a missing credential. Verifiers always check both.