Turnkey development of a blockchain-based digital certificate system

Digital certificates: where authenticity verification breaks down

A paper form and a PDF with a seal differ from a forgery only in the quality of layout: the logo, manager's signature, and certificate number are transferred into an editor in ten minutes.

The number itself confirms nothing — it is not linked to the document's content, so changing the surname, qualification, or date does not alter a single verifiable value.

The center usually learns about a forged certificate from a third party, when the document has already been presented.

Document authenticity verification today rests entirely on humans.

The employer or regulator writes a letter to the training center, waits for a response, compares the scan with what is in the accounting system — and all this within a timeframe that rarely exceeds a couple of days.

Manual registry verification does not scale: ten requests per day can still be processed, a hundred turn into a queue, delays, and errors in data copying.

Record-keeping of issued certificates in a closed spreadsheet leaves no traces: a record can be edited or entered retroactively, and the file does not show who did it and when.

There is no revocation either — a revoked certificate continues to appear valid, because the document itself has no mechanism to notify the verifier of a status change.

In a dispute about the fact of issuance, the parties present different versions, and no one has an independent witness. Then come invalid permits for the employer, reputational costs for the center, and zero trust from the person to whom the certificate was shown. Below we discuss how this is addressed.

What the registry provides: issuance, revocation, and authenticity control

Issuance stops being file forwarding. A batch of certificates is formed as a package: the registry accepts records in a single operation, each receives a unique identifier and a cryptographic signature of the issuer.

A batch of several thousand documents is issued in minutes instead of days of manual assembly and distribution — while a log is kept of who signed what and when.

Certificate revocation works as a change of record status, not as deletion. The document remains in the registry marked "invalid", so the verifier sees the fact of revocation, its date, and the reason.

The history cannot be quietly rewritten: retroactive status substitution does not reconcile with the signature and other copies of the registry.

Verification by the recipient comes down to a single action — scanning a code on the document or following a link. The system compares the document fingerprint with the record and returns the status in seconds, without calls to the training center and manual confirmations. The verifier trusts not a letter from us, but the state of the registry.

We maintain compatibility with the open standard Open Badges so that certificates are accepted by external platforms and HR systems, not just our verification interface.

Practical effect: a document cannot be forged without the issuance key, the share of disputed certificates decreases, and manual verification and confirmation operations leave the process.

Formats of the digital certificate system: comparison of approaches

A public registry and a closed consortium differ not in ideology, but in who holds the validators.

If a certificate must be verifiable by any external recipient — a partner, regulator, buyer — a public network is used; if the circle of verifiers is closed, the consortium provides the same immutable log without publishing personal data.

When certificates are already issued from an existing database and there is nowhere to migrate them, only the document fingerprint is written to the registry, while the file itself remains in the internal system.

Such a hybrid scheme records the fact of issuance so that it cannot be retroactively altered and does not require rewriting the record-keeping.

Comparison of schemes

Implementation stages: from issuance audit to handover of regulations

The work order is structured so that each next step relies on the verified previous one.

First, we record how certificates are issued today, then transfer the process to a distributed registry, and only after testing on real data do we put the system into operation together with the regulations.

1. Issuance audit. We analyze the current process: who initiates issuance, what approvals the document goes through, where signatures are stored, and how authenticity is currently verified. The result is a role map and a list of bottlenecks; the scope of automation depends on it.

2. Data and role schema. We determine what exactly is recorded in the registry: certificate identifier, digital fingerprint of the content, status (valid, revoked, redeemed), holder data. We delineate rights — who issues, who revokes, who has read-only access.

3. Registry deployment. We set up nodes in the chosen configuration: a closed loop for internal document flow or a public network if the certificate must be verifiable by third-party organizations. We configure backup and monitoring.

4. Integration with the accounting system. We link certificate issuance with the existing process: application, approval, and signing remain in familiar interfaces, while the registry record is created automatically. Manual entry and discrepancies between databases are eliminated.

5. Testing on a real batch. We run issuance, revocation, and verification on a production volume of documents. We separately test failure scenarios: re-issuance, erroneous revocation, attempted forgery.

6. System acceptance. We compare the result with agreed criteria: issuance speed, share of operations without manual involvement, verification correctness. We record baseline metrics and the rollback procedure.

7. Handover of regulations. We provide instructions on issuance, revocation, and access recovery, and describe the update procedure and role model. Your specialists maintain the system independently.

What remains with the customer: registry, roles, and regulations

After launch, the system lives without us — and this is verified not by words but by a set of artifacts.

We hand over not access to the repository, but a working set by which your team itself issues, confirms, and revokes certificates, changes roles, and updates rules without stopping the registry.

• Node configurations and network topology — startup parameters, replication scheme, backup requirements, and the procedure for restoring a node after a failure.
• Issuance and revocation scheme — certificate structure: which fields it stores, who initiates issuance, how the revocation reason is recorded.
• Role matrix — who issues, who confirms, who revokes, and who has read-only access; rights and explicit prohibitions are defined for each role.
• Access policies — key issuance and rotation procedure, validity periods, separation of duties, and actions in case of key compromise.
• Revocation regulation — grounds, step-by-step procedure, response times, and rules for notifying certificate holders.
• Operator instructions — typical scenarios with expected results: batch issuance, mass revocation, access recovery.
• Change log and management transfer procedure — what changed in the rules and when, who approved it, how to transfer administration to another team.

We test changes on a test loop: we verify role and revocation regulation changes on a copy of the registry and only then transfer them to production. We update the set together with the system — the documentation does not diverge from the actual configuration.

Case study: certificate issuance — metrics before and after

The certificate flow at the training center looked like this: applications were collected in spreadsheets, manually verified against orders, the form was printed and signed, and the registry was kept in a journal.

A batch of 800 documents stretched over 18–20 business days, an error in one field led to re-issuance, and disputed cases accumulated for months — it was easier for the HR department to call the center than to trust paper.

We broke the process into three parts: issuance, revocation, and verification.

Application data goes into the digital certificate registry, issuance rules are described by a smart contract, the document receives a unique identifier and content hash, and revocation is recorded as an event — there is no longer any need to confiscate the form.

Metrics before and after

The certificate format was assembled according to the open W3C standard for verifiable digital documents — it is read by external systems, so verification requires neither our participation nor access to the center's infrastructure.

How a blockchain registry differs from a database with an electronic signature

An electronic signature solves a narrow task: it confirms the authorship and integrity of a specific record. While the document is signed, substitution of its content is visible.

But the signature says nothing about the completeness of the log — the database owner can delete a certificate revocation record, add an issuance retroactively, or roll back the table from a backup, and the remaining signatures will remain valid. The verifier sees exactly what they were shown.

A blockchain registry is built differently: each record is linked to the previous one, and interference breaks the entire chain after it.

This is no longer "a forgery was found in one document," but "the log no longer reconciles." Copies of the log are held by independent participants, so a retroactive edit requires not access to the database, but the consent of the majority of replica holders.

The second difference is independent verification. The holder of a digital certificate, a counterparty, an auditor, or a regulator can independently verify the fact of issuance and revocation status, without querying our system and without trusting the operator.

The timestamp is recorded at the moment of writing, so "revoked before the incident" or "issued after" can no longer be arranged retroactively.

A regular database with a signature remains sufficient when there is a single issuer, the operator is trusted, and there are no disputes with third parties.

A registry is needed where certificates are presented externally and there is an interest in disputing them retroactively: diplomas and permits, certificates of origin, licenses.

An intermediate option is anchoring: a snapshot of the log is periodically published in a public registry, independent integrity verification appears, and the system load remains customary.

Technical questions asked before the start

Before starting, technical customers ask the same set of questions — the answers determine the architecture, not just the timelines. Below are short answers on the merits.

What to do with documents issued earlier?

Re-issuance is not needed. We calculate checksums for existing files and records and transfer them to the new registry with the original issuance dates and a migration note. Numbers and seals remain valid.

The description is compatible with the W3C verifiable credentials model — third-party verifiers read the documents without modifications.

Who retains the signing keys?

The keys are yours: they are stored in your secure module, we access them through roles with limited rights, and issuance follows a multi-signature scheme. The registry is public, data access is not tied to us, so changing the contractor does not require re-issuance.

How does the system behave during peak issuance?

Issuance proceeds in batches: hundreds of documents are collected into a single root fingerprint, so recording time grows non-linearly, and the queue with retries smooths out seasonal spikes.

Revocation is a separate record with a reference to the original and a reason: loss, data error, expiration.

Let's discuss the task: where a pilot issuance begins

A pilot issuance is a narrow loop, not a copy of the entire system: one or two certificate types, real recipients, a full cycle from issuance to authenticity verification and revocation.

This way we remove uncertainty about data and access rights on a small batch, rather than after launching the entire registry. To return with an estimate and an implementation plan rather than generalities, a minimum of inputs is needed.

• Certificate types and who is authorized to issue, confirm, and revoke them — roles and scope of authority.
• Field composition: what is printed on the form, what goes into the registry as metadata, what remains in the internal system.
• Current issuance process — how many approvals, where delays and manual data transfers occur.
• How authenticity is currently verified: call, letter, signed PDF, internal registry.
• Disclosure requirements: public registry or closed loop, which personal data must not be published.
• Integration points: accounting system, personal account, batch export — where we get data about graduates or batches.
• Pilot scope: approximate number of issuances, number of types, deadlines, expected verification load.

Then we work like this: deploy the loop in a test environment, run issuance, verification, and revocation on your scenarios, measure the issuance time of one record and the verification time, and test behavior on repeated presentation and on revocation.

Based on the pilot results, we return with an estimate and a scheme: scope of work by stages, implementation plan with checkpoints, roles in the registry, migration procedure for existing records, and a regulation for revocation. Describe the task — we will assemble a pilot for your process.