Development of soul-bound credentials with on-chain verification

Soul-bound credentials: where regular tokens break

A classic failure looks like this: an organization issues a diploma or clearance with a regular token that can be transferred.

The token goes to a third party — it is sold, gifted, moved to an intermediary's wallet — while the record in the credential registry continues to appear valid.

The verifier sees a correct signature and current status, but the record no longer belongs to the person who took the exam and passed certification.

Then the verification itself breaks.

A transferable token has no indication that it remains with the original recipient, so it is impossible to distinguish the original from a copy by a single record — a call to the organization, a letter to the academic department, and waiting for a response are required.

This is exactly where diploma and clearance forgery lives: forging the form and seal is no longer necessary; it is enough to buy or inherit a transferable token.

Soul-bound credentials close this at the level of the credential itself: the record is bound to the recipient's address, and the transfer operation is reverted by the contract logic — the credential becomes non-transferable.

In such a scheme, the credential registry stores not the current owner but the history of issuance and revocation, so the status always reflects reality: issued, revoked, replaced upon recertification.

Authenticity verification happens without calling the organization — by the presenter's address and the state of the record.

We will examine how this works and where the boundary lies between a transferable token and a non-transferable credential.

What a non-transferable credential in a registry provides

The record in the registry is bound to the owner at the contract level: the token has no transfer method, so the credential cannot be resold, assigned, or copied to someone else's wallet.

The right is confirmed by the signature of the address owner, not by a certificate from the organization.

Verification takes one contract call: the verifier sees the address, issuance fact, date, and current status. Document verification time drops from several days of correspondence to seconds — there is no need to request confirmation from the issuing party.

If the registry is deployed on the public Ethereum network, any third party can verify the record, including someone who does not report to you.

Next — which class of failures is eliminated: forgery, re-issuance of the same diploma, a "lost" original, retroactive status editing.

Any change is a separate entry in the event log, not an edit of a row in a database, so a dispute is resolved by history: who issued it, when, and whether the record has been revoked.

Record administration comes down to the issuance operation: one transaction instead of manually maintaining registries, reconciliations, and sending confirmations. Revocation is also one record, after which verification immediately shows invalidity.

There is a single source of truth, so discrepancies between the internal database and external confirmation do not arise.

Credential issuance and verification modes

Credential issuance hinges on two forks: how to write records to the registry as the number of holders grows, and who has the right to verify status — anyone or only an approved party.

The choice affects the load on the registry and compatibility with the customer's accounting systems, HR loop, and partner interfaces.

The modes are not mutually exclusive: the holder keeps one address, and credentials of different types are issued in different ways. The closed loop covers sensitive attributes; the public layer is enabled when an external audience of verifiers appears.

Implementation stages: from requirements audit to handover

The order of work is built around one question: who, and on what basis, confirms that a credential belongs to a specific address. Until this is fixed, any code is a guess.

Therefore, we start with a requirements audit, not with a smart contract, and only then assemble the data schema and verification loop.

1. Requirements and roles audit. We fix who issues a credential, who has the right to revoke it, what is considered grounds for issuance, and by what procedure an error is disputed. We examine scenarios: whether the registry has one issuer or several, and whether verification is needed without contacting an external service.
2. Data schema. We determine what lives in the contract (ownership, revocation flag, type) and what is moved to off-chain metadata. We describe the "address — identifier — validity period" link so that the reading party gets an answer in one call, rather than by joining three sources.
3. Test loop assembly. We deploy an isolated network, test issuers, and the same scripts that will go into the production environment. We run a batch issuance and record the time: it later becomes a benchmark for handover.
4. Forgery attempt testing. A separate block of scenarios — transferring a credential to a third party, re-issuing to the same address, substituting metadata after issuance, revocation and its visibility to the verifier. Each scenario is closed by a test; the share of covered paths is the readiness criterion.
5. Handover preparation. We assemble the revocation regulation, the procedure for working with the issuer's keys, the metadata update scheme, and the procedure for rolling out new versions without losing already issued credentials.
6. Handover to operation and team training. We hand over the deployed loop, accesses, documentation, and an analysis of incidents that may occur in the first months. We conduct training on the team's live scenarios — from issuance to revocation.

This order provides predictability: by the time of handover, the customer has a working loop, a set of forgery tests, and people who understand what to do in case of a failure.

Configuration, schemas, and issuance regulations

The artifact package is assembled in parallel with development, not after delivery.

The point is that issuance, verification, and revocation of soul-bound credentials can be run by your team: the role schema and access policies are described so that a new administrator gets into the process in a day, rather than deciphering the contract code.

• Deployment configurations — network parameters and contract addresses, issuance volume limits, metadata formation rules, binding to the verifier's domain.
• Role schema — who issues, who confirms, who revokes; multisignature thresholds and the rule by which authority cannot be reduced to a single key.
• Access policies — which personal data remains outside the public registry, what goes on-chain, which employees see the full set of attributes.
• Revocation regulation — grounds for annulment, response time, procedure for notifying the holder, and the status of already issued pass copies.
• Verifier instructions — step-by-step validation: signature request, owner verification, revocation status check, actions in a disputed situation.
• Maintenance documentation — how to update the attribute schema, change keys, migrate when the standard changes, what to record in the change log.
• Recovery plan — the procedure for actions in case of compromise of the issuance key and for mass re-issuance of previously issued documents.

Each document is tied to a specific role that uses it, so the package is checked at acceptance together with the contract — by scenarios, not by the mere presence of files.

Case study: a diploma registry with revocation and verification

How it was

Diplomas were issued on paper and as PDFs, and authenticity was confirmed by a written request to the academic department: a response took up to three business days, and during graduation season the queue grew.

Support spent almost half of its working time on identical "confirm the diploma" requests — including cases where the record should already have been revoked due to a data error.

What was built and what it delivered

The qualification record is issued as a soulbound token to the graduate's address: it is not transferable or sellable, and the metadata contains the specialty, year, and hash of the paper original.

Issuance is tied to the role of an authorized employee, each record is a separate transaction on Ethereum, so the verifier reads the status directly from the public registry, without requests or integrations on our side.

Revocation of a credential is not deletion but an event: the record is marked revoked, verification returns a rejection with a reason, and the history remains available for audit.

An erroneous diploma stops being confirmed within a minute, while legitimate records of the same graduate are not affected.

How soul-bound credentials differ from regular tokens

A regular token is a property title: it is transferred, sold, and pledged, and its value is determined by the market. Soul-bound credentials are structured differently — they are a record tied to the owner's account: a diploma, certificate, clearance. Their meaning lies precisely in non-transferability: such a record cannot be transferred or sold.

The transfer prohibition is hardcoded into the contract itself: there is no public transfer method, and workaround calls, including transfer via operator approval, are reverted by the transaction.

In familiar standards like ERC-721, transfer is a mandatory part of the logic; here it is deliberately removed and replaced with an unconditional rejection.

Binding to an account means that the record exists only in pair with the owner's key, and loss of access to the key makes it unreadable for the verifier.

Therefore, the scheme is designed with re-issuance by the issuer: the previous record is marked invalid but does not disappear — the issuance history is preserved.

Revocation and lifetime are what a regular token lacks. The contract stores the record state: active, revoked, expired. Revocation does not erase data but records an event in the registry, so the verifier sees both the current status and the issuance fact itself.

The validity period is set at issuance — upon its expiration, verification returns a negative result without contacting the issuer.

The verifying party needs only one registry read: owner's address, status, term. We include the issuer and revoker roles, a pause during an incident, and an event log — this is exactly what turns the record from an artifact into a working clearance tool.

Revocation, privacy, migration: technical concerns

Technical concerns around soul-bound credentials come down to four: loss of a key by the owner, revocation of an already issued credential, the volume of data going to the public part, and registry migration without re-issuance.

Each is addressed by a mechanism built into the architecture in advance, not by manual correction after the fact.

How do you revoke a credential if it is already in hand?

Revocation is a separate operation: the status in the registry changes, but no one rewrites the document itself.

The verifying party checks the presented credential against the fresh state of the registry, so a revoked document stops validating as soon as the verifier has access to the network. The right of revocation is assigned to the issuer, not the owner.

What data becomes public and how is the registry migrated?

Only the cryptographic fingerprint and technical tags go to the public part — personal data and document contents remain in the issuer's private storage.

Registry migration is a move without re-issuance: a new address, transfer of state roots, and mapping of old identifiers to new ones, so credentials in hand continue to pass verification.

Let's discuss the task: what to prepare for the conversation

To come back with an estimate of the scope of work rather than clarifying questions, a few inputs are enough for the first conversation.

They set the architecture for issuance and verification of soul-bound credentials — from the registry model to the revocation procedure — and we use them as a basis to assemble an implementation plan and team composition.

• Issuance scenarios: to whom and upon which event a credential is issued, who acts as the issuer and signs the transaction.
• Registry model: a separate contract for each type or a factory, where metadata is stored — on-chain or off-chain, with a hash on the chain.
• Revocation and re-issuance: who has the right, what happens to previously issued tokens, whether a credential is restored after loss of access to the wallet.
• Verification procedure: who verifies — an in-house service, third-party wallets, or an external integration via API.
• Privacy: which fields cannot be published in the public registry and whether confirmations without revealing the data itself are needed.
• Infrastructure and accesses: test network, signing keys, multisignature roles, to whom ownership of the contract transfers after delivery.
• Acceptance criteria: which checks must pass before issuance and on what data set we fix the result.

Then we proceed step by step: we compare the inputs, show the scheme, and come back with an estimate, implementation plan, and team composition for your loop. Describe the task in free form — we will clarify the rest ourselves.