Verified credentials

Verifying an Ewance credential takes one click. Understanding what the verification actually proves — and what it doesn't — takes about ten minutes of reading.

This page is that reading.

What's actually in the credential

Each credential is a W3C Verifiable Credential 2.0 document, also conformant with Blockcerts v3 and Open Badges 3.0. Those are the three open standards that have settled the question of "what does a portable, verifiable credential look like."

The credential contains, in machine-readable form:

• Subject identity — the candidate's name and stable identifier.
• Achievement — challenge title, discipline, deliverable type, rubric.
• Outcome — accepted, accepted-after-revision, or revoked (rare; see below).
• Submission hash — a cryptographic fingerprint of the candidate's deliverable. The deliverable itself stays private; the hash proves it hasn't been altered after issuance.
• Issuer identity and signature — Ewance, with a public key anyone can verify against.
• Issuance date — exactly when the credential was issued.
• Anchor reference — a transaction hash on the Base blockchain that ties the credential to a specific, permanent on-chain record.
• Team composition — solo, pair, or squad, with the candidate's role in the team.

All of this is signed. Tamper with any field and the signature fails.

What "verifiable" actually means

Five cryptographic checks run when you (or anyone) verifies a credential:

1. Schema check — is this a valid W3C Verifiable Credential / Blockcerts / Open Badges document?
2. Signature check — was this credential signed by Ewance's issuer key?
3. Issuer check — is Ewance's issuer key currently valid (not expired, not rotated out)?
4. Anchor check — does the on-chain anchor on Base match what the credential claims?
5. Revocation check — has this credential been marked as revoked since issuance?

If all five pass, the credential is valid. If any fails, the verifier returns the specific reason.

You do not need to contact Ewance to do this. The verification runs client-side in any modern browser, or programmatically via the Blockcerts verifier library. We aren't a dependency.

This is what people mean when they say a credential is "verifiable without trusting the issuer." You trust the cryptography — RSA / ECDSA signatures, Merkle proofs, the Base blockchain's public state — and the math does the work.

How to verify, in practice

Every credential has a public URL of the shape:

https://verify.ewance.com/c/{credentialId}

When you open that URL, you see:

• The candidate's name, the challenge, the discipline, the deliverable.
• A live "Verified" or "Invalid" indicator that updates as the five checks run.
• An optional "raw credential" export — the signed JSON-LD document — for offline verification.

That's enough for most hiring conversations. If you need to plug verification into an automated workflow (ATS, AI screening agent, internal portal), the JSON-LD document is portable: any Blockcerts-compatible verifier accepts it.

What the credential proves, exactly

• The candidate completed this specific challenge. Yes.
• Their submission was accepted against the stated rubric. Yes.
• They did this work themselves (or as part of the stated team). Yes — based on Ewance's review, which checks for plagiarism and substantive engagement.
• The credential record has not been altered after issuance. Yes — cryptographically.

What the credential does not prove

Being explicit so you don't over-read it:

• It does not prove general professional ability. A candidate who shipped a great market analysis may still be a poor cultural fit, a bad communicator under pressure, or unreliable on deadlines. The credential proves the deliverable, not the person.
• It does not prove the deliverable would survive contact with your real-world data. The challenge is a constructed scenario. The candidate's analysis is judged against the brief, not against your actual quarterly numbers.
• It does not replace a reference check. Standard recruiting hygiene still applies.
• It does not prove the candidate has the soft skills the role needs. Interview for those.

The credential is one strong signal, paired with the actual work product (which you read). Use the rest of your hiring process for the things the credential isn't telling you.

Revocation

A credential can be revoked if it's later discovered to have been issued in error — for example, if plagiarism is detected after the fact. Revocation marks the credential as no-longer-valid in the verification check. The credential record is not deleted (that would be cryptographically suspicious); it returns a "revoked" status instead of "valid."

We mention this for completeness. In practice, revocations are rare. Their existence is what makes the credential trustworthy at issuance — without a revocation mechanism, fraud would be unfixable, and the whole system would lose its weight.

If a candidate's credential shows as revoked, treat it as a serious signal. You're welcome to ask them about it; the platform doesn't share the specific reason publicly.

Integration with your hiring stack

Most teams use Ewance credentials in one of three ways:

1. Manually — open the verification URL during candidate review. One click. No setup.

2. In your ATS — paste the verification URL into the candidate's record. Future reviewers see it alongside the CV.

3. Programmatically — the JSON-LD credential is consumable by any Blockcerts-compatible verifier. Plug it into an automated screening pipeline or AI agent. The verification runs in milliseconds with no network call to Ewance.

A deeper API integration is on the roadmap. For now, the public verification URL covers the vast majority of recruiter use cases.

Next

To make these credentials work for you, you need to find the candidates whose work matches your role. That's covered in Searching for talent.