Can You Delete a DID? GDPR Article 17 vs. an Append-Only Chain

No, and Solidus has no erasure workflow, no appointed Data Protection Officer, and no completed Data Protection Impact Assessment. The term is not-built. Nothing here is legal advice.

What Article 17 actually gives you

A legal right, in the EU, to ask an organisation holding your personal data to delete it, and in most cases it must comply.

It is narrower than "the right to be forgotten" sounds. It applies when data is no longer needed for its original purpose, when consent was the only basis and you withdraw it, when processing was unlawful, and on a handful of other listed grounds, not simply whenever someone changes their mind. And it is not absolute: an organisation may refuse where the data is needed to meet another legal obligation, to defend legal claims, or for public-interest archiving.

The tension, which belongs to the whole industry

A blockchain's value comes from being append-only. You cannot quietly rewrite history without destroying the property that made the record trustworthy.

Article 17, read literally, asks for exactly that. Writing personal data onto an immutable ledger and then promising to erase it on request is close to a contradiction in terms.

This is not a Solidus problem. It is everyone's, and the standard answer, which we did not invent, is architectural: never write erasable personal data on-chain at all. Keep public keys, pseudonymous identifiers and cryptographic commitments on-chain, where nothing needs erasing because nothing personal was written; keep anything that must be deletable off-chain, where a real delete exists.

Whether we actually do that, check it rather than trust it

Resolve a real identifier and read the whole record:

$ curl -s -X POST https://rpc.solidus.network -H 'Content-Type: application/json' \
    -d '{"jsonrpc":"2.0","method":"solidus_didResolve","params":["did:solidus:testnet:46Hzv2Ek4MXwj1Kenvix4tWCPr1J"],"id":1}'

Live, 2026-07-31. It contains an identifier, a controller, one public key, the relationships that key serves, an empty service array, an active flag, timestamps and a version hash. No name, no email, no document, no attribute. The control, an unknown identifier, returns null, so that is a real record and not a default.

For this record, the design goal holds and you can confirm it yourself.

What that does not establish: one record is not every code path, and service is empty here but can hold a URL, which may reveal more than a key does. We have not had an independent review confirming the property holds everywhere, and we are not claiming one.

So what happens when you want a DID gone?

You can deactivate it.

A tombstone is not a deletion, and the difference is the entire point of this page.

Deactivation is a new state recorded on an append-only chain, not the removal of what came before. Resolution stops serving the document; the history of the identifier having existed, and of the key it carried, is not erased by that operation: that is what "append-only" means.

We are describing this from the chain's stated design, not from an independent audit of block history. No such audit exists.

The practical reading: an identifier you deactivate stops being usable and stops resolving. It does not become as though it had never been.

The two claims we keep apart, deliberately

Defensible: "the architecture is designed so that personal data never has to be erased from the chain, because it was never written there." That is a real design choice, consistent across our specification documents, and, for the record above, observably true.

Not defensible, and nobody here may say it: "Solidus is GDPR compliant" or "Solidus honours Article 17 requests."

Because:

No Data Protection Officer has been appointed. Our own compliance roadmap lists it as a step for "before EU launch", a future milestone, not a completed one.
No Data Protection Impact Assessment has been completed, including for the biometric data our verification flows collect.
The GDPR items on our own internal compliance checklist are unchecked.
No data-subject erasure workflow exists that you, a regulator, or our own not-yet-appointed officer could point at and test.