Certificate Hash Verification

Pro feature

Learnomy records a tamper-evident fingerprint for each certificate, so an employer who scans the certificate's QR code lands on a public page that proves the credential has not been altered since it was issued.

This is not a public blockchain. Fingerprints are written to a local, tamper-evident registry on your own site. Nothing is submitted to a public chain today. Some internal option, class and CSS names still contain the word "blockchain" for backward compatibility, but the feature is a hash registry and must not be sold to buyers as blockchain anchoring.

What you can do

Anchor every certificate automatically the moment it is issued, so its fingerprint is recorded without any manual step.
Anchor an already-issued certificate on demand from the admin, for certificates that were issued before you turned the feature on.
Show a "Tamper-evident hash verified" or "Certificate hash recorded" badge on the public certificate verification page, below the standard certificate details.
Let an employer scan the certificate's QR code and confirm the credential is genuine and unchanged, with no login and no account.
Keep the anchor as a permanent historical record even after a certificate is revoked or expires -- the verification page reports the revoked status while the original anchor stays in place.
Read the anchor status over the REST API, so the mobile app or an external verifier can check a certificate programmatically.

Certificate hash verification first view

How to use it

Step 1 -- turn on certificate hashing

There is no admin screen for this switch yet. Anchoring is turned on through the Certificates Pro settings endpoint - send POST /wp-json/learnomy-pro/v1/certificates-pro/settings with {"blockchain":{"enabled":true}} as an administrator. The setting is stored in the learnomy_pro_blockchain option and read on every certificate issue.

Step 2 -- issue a certificate

When a student earns a certificate while the feature is on, Learnomy computes a SHA-256 fingerprint of the certificate's fixed fields (its UUID, the student, the course, the issue date, and the Ed25519 signature from the free plugin) and records it in the anchor registry. Nothing else changes in your normal certificate flow.

Step 3 -- anchor older certificates (optional)

Certificates issued before you enabled the feature are not anchored yet. Anchor one on demand by calling the admin anchor endpoint for that certificate. A certificate that is already anchored is left as-is (the endpoint returns an "already anchored" response rather than re-anchoring).

Step 4 -- verify a certificate

Open the certificate's public verification page at /verify/{uuid}/, or scan the QR code printed on the certificate, which points to the same page. Below the standard certificate details you will see:

Tamper-evident hash verified -- the certificate's current data still matches the fingerprint recorded at issue time.
Certificate hash recorded -- the certificate is anchored, but its current record could not be matched (for example the certificate row is missing, or its data changed). The anchor still proves when it was issued.

A shortened form of the fingerprint is shown next to the badge.

Settings and options

Enable certificate hashing -- stored in learnomy_pro_blockchain (enabled) and set through the Certificates Pro settings endpoint; there is no wp-admin control for it. When off, no new certificate is anchored and no badge appears.
Automatic vs manual anchoring -- with the setting on, new certificates anchor automatically at issue. Existing certificates are anchored one at a time through the admin anchor endpoint.
Where the anchors are stored -- version 1.0 keeps the fingerprints in a local, tamper-evident registry (a non-autoloaded WordPress option). The registry holds up to 500 entries; when full, the oldest entries are evicted as new ones are written. Sites that need more should plan for the dedicated table backend noted in the code. The public API is designed so a future release can submit fingerprints to a public timestamping service (OpenTimestamps) without changing how you use the feature.
Revoked and expired certificates -- a recorded fingerprint is immutable and is never removed. When a certificate is revoked or expires, Learnomy records a revocation overlay so the verification page and the Open Badges assertion report the credential as no longer valid, while the anchor remains as historical proof of the original issue.

For developers

Class Learnomy_Pro\Extensions\Certificates_Pro\Blockchain (internal name retained for backward compatibility):

anchor_certificate( object $certificate ): array -- computes the SHA-256 fingerprint and writes the registry entry (hash, anchored_at, certificate_id).
verify_anchor( string $uuid ): array -- returns anchored, and when anchored also hash, anchored_at, and verified (true when the current data still matches the recorded fingerprint).

Anchor lifecycle wiring (Certificates_Pro\Extension): anchoring runs on the free learnomy_certificate_issued handler when learnomy_pro_blockchain[enabled] is set; the verification-page badge is appended via the free learnomy_certificate_verify_after action.

REST (namespace learnomy-pro/v1):

GET /certificates/{uuid}/verify -- public. Returns the verification payload including a blockchain block (anchored, hash, anchored_at, verified) when the certificate is anchored.
POST /certificates/{id}/anchor -- admin only. Anchors a certificate; returns HTTP 409 already_anchored if it already has a fingerprint.
GET /certificates/{id}/anchor-status -- admin only. Returns the current verify_anchor() result.
GET|POST /certificates-pro/settings -- admin only. Reads and writes the Credly and certificate-hash settings; this is where blockchain.enabled is turned on (the key keeps its legacy name).

Stored per-certificate markers: lrn_cert_blockchain_hash_{id}, lrn_cert_blockchain_at_{id} (recorded at anchor time), and lrn_cert_revoked_{id} (the revocation overlay read by the verify page and the Open Badges assertion).