Live on Base with Ewance

See the certificates
Integration guides

GDPR erasure

How to honor a recipient's right-to-be-forgotten request without breaking the cryptographic proof.

GDPR Article 17 grants EU data subjects the right to request erasure of personal data. Blockchain's immutability is fundamentally incompatible with that — once something is on-chain, you can't delete it. LearnCoin's architecture threads this needle by keeping personally identifiable information off-chain from day one.

What goes on-chain vs off-chain

On-chain (Base, immutable)Off-chain (Supabase, tenant-scoped RLS, erasable)
Merkle root of a credential batchRecipient's legal name
Issuer DID referenceRecipient's email
Issuance timestampTenant-supplied external identifiers (student ID, etc.)
Anchor transaction IDAnalytics, delivery events, submission data
Recipient's pseudonymous urn:uuid:…Mapping from urn:uuid:… → recipient's real identity

The on-chain footprint contains no PII. It cannot be used to identify a specific recipient without access to the off-chain mapping table.

What erasure actually does

When you POST /v1/credentials/{id}/erase:

  1. The mapping row in LearnCoin's Supabase that associates the urn:uuid:… with the recipient's email and legal name is deleted (not soft-deleted — hard delete).
  2. The recipient.name field on the credential's public verification page is redacted to "Redacted on recipient request" — the achievement, criteria, and issuer stay visible.
  3. The signed JSON-LD artifact is preserved; the cryptographic proof still validates.
  4. A credential.erased webhook fires so your backend can mirror the erasure.
  5. LearnCoin logs the erasure action (tenant, credential, requester, timestamp) for your compliance records — this log itself doesn't contain PII.

The signed credential document the recipient already downloaded will still verify. That's a feature, not a bug: the proof isn't forgeable, so holding onto a legitimate copy of your own credential shouldn't be erased by a third party.

Processing an erasure request

1. Verify the requester

Before calling the API, verify the request is legitimate. Typical verification:

  • Email confirmation loop through the recipient's on-file email
  • Signed erasure request form
  • For EU regulated issuers: check against your DPO's process

Record the verification in your own system. verified_at becomes a field in your internal audit trail.

2. Call the API

POST /v1/credentials/{credential_id}/erase
Authorization: Bearer lrn_test_…
Content-Type: application/json
{
  "requester": "recipient",
  "verified_at": "2026-04-23T13:30:00Z"
}

Valid requester values:

  • recipient — the data subject themselves
  • dpo — your Data Protection Officer acting on their behalf
  • supervisory_authority — e.g. an Estonian AKI or Finnish Tietosuojavaltuutettu directive

Response:

{
  "id": "crd_01HXYZ…",
  "erased": true,
  "erased_at": "2026-04-23T13:46:00Z",
  "verification_status_after_erasure": "verifiable"
}

3. Erase on your side too

The LearnCoin-side mapping is now gone. You also need to erase from your systems:

await db.recipients.delete({ id: credentialRecipientId });
await analytics.erase({ recipientId: credentialRecipientId });
await emailLogs.erase({ to: recipientEmail });
// etc.

LearnCoin's erasure doesn't cascade into your database — you own the recipient's identity on your side.

4. Respond to the recipient

Confirm in writing that their data has been erased. Cite the erased_at timestamp. GDPR requires a response within 30 days of the request.

What doesn't get erased

  • The signed credential document the recipient downloaded or that a third party already verified. Cryptographic proofs are immutable on purpose. The document's contents no longer uniquely identify the recipient in combination with LearnCoin's records, because the mapping is gone.
  • The on-chain anchor transaction. This only contains the Merkle root — no PII — so GDPR doesn't require its erasure.
  • The credential's achievement, criteria, and issuer metadata on the verification page. These are about the achievement, not the recipient.

Edge cases

What if the recipient also wants the credential revoked?

Revocation and erasure are independent. Revocation is the issuer saying "I no longer endorse this credential"; erasure is the recipient saying "remove my PII." A recipient can request erasure without affecting the credential's validity — the public verification page just shows Ada Lovelace becomes Redacted on recipient request.

If the recipient also wants the credential rescinded (e.g. because of a grading dispute), combine:

await fetch(`${URL}/credentials/${id}/revoke`, { /* reason, reason_code */ });
await fetch(`${URL}/credentials/${id}/erase`, { /* requester, verified_at */ });

What if the issuer goes out of business?

The recipient's downloaded credential still verifies. The Merkle anchor is on Base and LearnCoin doesn't control Base. The issuer's DID document is served from the issuer's own web property (did:web:yourschool.edu if self-hosted) or from LearnCoin (did:web:learncoin.me) — the former survives the issuer's exit; the latter survives LearnCoin's exit (we fork all verification libraries onto the barcelova GitHub org precisely for this reason).

What if LearnCoin goes out of business?

The three things needed for verification are:

  1. The signed JSON-LD document (the recipient has their own copy).
  2. The anchor transaction on Base (Base is a public chain not controlled by LearnCoin).
  3. The issuer DID document (served from learncoin.me, but we've forked all critical verification libraries so the proof still checks without LearnCoin's infrastructure running).

GDPR erasure doesn't change this. A credential erased at LearnCoin is still verifiable from a recipient's own saved copy.

The recipient's rights

  • Right to erasure (Article 17) — supported. POST /credentials/{id}/erase.
  • Right to access (Article 15) — the signed credential IS the recipient's data. They can download it via their verification page or ask the issuer.
  • Right to rectification (Article 16) — credentials are immutable once signed. The correction pattern is: revoke + re-issue, not edit.
  • Right to portability (Article 20) — the JSON-LD document is portable by design. It works in any Blockcerts-compatible wallet.

Your own DPA / records of processing

LearnCoin acts as a data processor; the issuing institution is the data controller. A standard DPA is available on the Institution tier. On Developer / Starter tiers the Terms of Service acts as the processing contract.

For your Records of Processing Activities (ROPA):

  • Purpose: Issuance, verification, and revocation of academic/professional credentials.
  • Categories of data: Recipient pseudonymous ID (urn:uuid), display name, email, achievement metadata.
  • Recipients: LearnCoin (processor), Base blockchain (public, Merkle roots only).
  • Retention: Off-chain PII until erasure requested; on-chain data permanent.
  • Transfers: Data stays in EU (Supabase EU region, GCP KMS europe-west3).

Escalation

For GDPR questions outside what the API covers — DPA negotiation, supervisory authority inquiries, breach notifications — email [email protected] with [GDPR] in the subject. Response SLA: 24 h business days.

On this page