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 batch | Recipient's legal name |
| Issuer DID reference | Recipient's email |
| Issuance timestamp | Tenant-supplied external identifiers (student ID, etc.) |
| Anchor transaction ID | Analytics, 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:
- 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). - The
recipient.namefield on the credential's public verification page is redacted to "Redacted on recipient request" — the achievement, criteria, and issuer stay visible. - The signed JSON-LD artifact is preserved; the cryptographic proof still validates.
- A
credential.erasedwebhook fires so your backend can mirror the erasure. - 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 themselvesdpo— your Data Protection Officer acting on their behalfsupervisory_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:
- The signed JSON-LD document (the recipient has their own copy).
- The anchor transaction on Base (Base is a public chain not controlled by LearnCoin).
- 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.