The Right to Be Forgotten vs the Right to Eternity: Where GDPR and Immutable Ledgers Collide — and What to Do About It

Two laws that cannot both be right

The letter there is no way to answer

Picture an ordinary morning at a company that has built its service on a blockchain. In the inbox, a message from a user. It is short and polite: “Please erase my personal data. Grounds: Article 17 GDPR.”

What happens next is invisible to the person at the other end.

The lawyer looks at the calendar: under Article 12(3) there is one month to respond, and where the request is complex the deadline can be extended by a further two. Three months at the outside. The engineer looks at the architecture and says the thing that usually brings an email thread to a halt: it cannot be erased. Not “difficult”, not “expensive”, not “we would need a sprint”. It cannot be done, because the record has already propagated to nodes the company does not own, and the entire value of that network lies precisely in the fact that records cannot be taken out of it. Immutability is not a side effect; it is what was paid for.

This is the point at which it is worth stopping, because this is where it gets interesting.

This is not an argument about how things ought to be done

Situations like this are usually described as a clash between technology and regulation: the law has fallen behind engineering, give it time and it will catch up. That framing is convenient, and wrong.

What actually collides is two rules in force, each of them operating right now.

The first is Article 17 GDPR, officially titled “Right to erasure (‘right to be forgotten’)”. Note the quotation marks: the “right to be forgotten” is not a free-standing right but an informal synonym. The legal term is the right to erasure. The Regulation has applied since 25 May 2018 and is directly applicable in every EU member state. Article 17(1) sets out six grounds for erasure, and the list is exhaustive: the data are no longer necessary for the purposes for which they were collected; consent has been withdrawn and there is no other legal basis; the data subject has objected to the processing and the controller has no overriding legitimate grounds; the processing was unlawful; erasure is required by law; the data were collected from a child in relation to the offer of online services.

The second rule is not a law but the physics of distributed systems, and it operates just as implacably. Data written to a blockchain are replicated across a multitude of independent nodes. Nobody holds a button that undoes an entry: in formal terms the chain can be altered, but doing so requires every node to update or delete its copy and to agree to the change, and in practice some copies will stay as they were. The property is of exactly the same order as the impossibility of unbreaking an egg.

As a matter of form the law of course beats the physics: a legal rule is not annulled by being hard to comply with. But that is precisely why the conflict does not resolve itself — the rule has to be complied with, and there is no way to do it.

Two regulators, two different answers

Tellingly, even the EU's own supervisory authorities answer the question differently — and their answers have hardened over time.

France's CNIL published a report on blockchain and the GDPR as early as 2018 and admitted it outright: where data have been written to the chain, an erasure request is technically impossible to satisfy. CNIL then proposed a way round it — put not the data themselves on the blockchain but a cryptographic proof of their existence, keeping the source data and the keys outside and destroying them on request. That, in CNIL's phrasing, can bring one close to the effect of erasure. But the same document carries an honest caveat: leaving aside certain cryptographic schemes, these solutions are not, strictly speaking, erasure — the data remain on the blockchain. And there is the conclusion that is rarely quoted: CNIL acknowledges the value of these solutions but doubts their ability to deliver full compliance with the GDPR.

The pan-European body, the EDPB, puts the position markedly more sharply in its guidelines on the processing of personal data through blockchain technologies (final version adopted on 7 July 2026). The key sentence: technical impossibility cannot serve as a justification for non-compliance with the requirements of the GDPR. The logic is simple and uncomfortable: data protection has to be built in at the design stage, which means that choosing an architecture from which nothing can be deleted is a decision you took in advance, not a force majeure event.

Hence the EDPB's general recommendation: as a rule, personal data should not be stored on a blockchain, and they have no place in the content of transactions. It is spelled out separately that plaintext, encrypted and hashed data are all equally inadvisable to write to the chain — encryption does not take data outside the scope of the GDPR.

The distance between the 2018 position and the 2026 one is the distance between “we understand that you cannot” and “the fact that you cannot is a consequence of your own choice”.

Why this is not only about blockchain

It is easy to conclude that the problem is a narrow one: don't build on a blockchain and there is no conflict. But the fault line runs wider than that.

It runs through any system in which long-term retention is a deliberate goal rather than a side effect. Through archives. Through backups, which, as enforcement surveys show, many companies simply exclude from erasure by default, without troubling to justify it. Through cryptographic erasure — the popular engineering move of destroying the key instead of the data and leaving the ciphertext where it lies. Through every attempt to substitute anonymisation for deletion.

And one more thing: the GDPR itself nowhere defines what “erasure” is. There is no definition in Article 17 and none in the recitals. A study prepared for the European Parliament by its research service, EPRS (PE 634.445, July 2019), notes this directly and adds that there are grounds for thinking physical destruction is not required: in Google Spain, removing the link from the search results, rather than the publication itself, was held to be sufficient. The newspaper stayed. The link disappeared.

So the argument is not about whose technology is better. The argument is about what the word “erase” means in the first place — and on the answer depends whether your architecture is lawful.

What comes next in this article

In what follows I take the conflict apart piece by piece, without trying to force it into a neat conclusion.

What Article 17 actually requires — all six grounds, all five exemptions, the real deadlines. What the Court of Justice of the EU held in Google Spain in 2014, and why its reasoning about information going out of date strikes permanent storage harder than it appears to. Where the territorial limits of the right to be forgotten lie after the 2019 judgment in Google v CNIL — and why the widespread claim that “the CJEU prohibited global erasure” is inaccurate.

Then the technical side: what cryptographic erasure is under the NIST standard, why the standard classifies it as “purge” rather than “destroy”, and the conditions under which it fails. Separately, why the EDPB treats both ciphertext and hashes as personal data, and which single construction, in the view of both CNIL and the EDPB, takes a record outside the scope of the GDPR.

And finally, what is at stake. A breach of Article 17 falls into the upper tier of fines under Article 83(5): up to 20 million euros, or, where the infringer is an undertaking, up to 4% of its total worldwide annual turnover for the preceding financial year, whichever is the higher of the two.

There will be no ready-made answer at the end — neither CNIL nor the EDPB nor the Court of Justice has one. There will be a map: where the ground is solid, where it is contested, and where it drops away.

The right to be forgotten: where it came from

The story of an auction notice

In March 2010 a Spaniard named Mario Costeja González lodged a complaint with the national data protection authority. The reason was prosaic to the point of awkwardness: typing his name into Google returned links to two pages of the newspaper La Vanguardia. The publications, dated 19 January and 9 March 1998, carried a notice of a property auction held to recover social security debts.

The recovery proceedings had been settled in full, and years earlier. Yet the man's name went on sticking to those two pages with every query — from a prospective employer, a business partner, a neighbour. In his complaint he wrote that the mention had become entirely irrelevant.

On 30 July 2010 the Spanish regulator, the AEPD, issued a decision that explains a great deal about how this right is built. The complaint against the newspaper it rejected: the publication had been lawful, made on the orders of the Ministry of Labour to give the auction the widest possible exposure. The complaint against Google it upheld.

The distinction here is not technical but substantive. The newspaper did exactly what it was supposed to do in 1998. A search engine does something else: it gathers a person's scattered traces into a single list and keeps that list to hand twelve years later.

What the Court of Justice said

On 13 May 2014 the Grand Chamber of the Court of Justice of the European Union gave judgment in Case C-131/12 — Google Spain SL and Google Inc. v AEPD and Mario Costeja González. The GDPR did not yet exist: the Court applied Directive 95/46/EC and Articles 7 and 8 of the Charter of Fundamental Rights of the EU.

The Court held four things, and not one of them was obvious.

First: what a search engine does is processing of personal data, and its operator is a controller. Not a neutral pipe, but the party answerable for the processing.

Second: EU jurisdiction reaches Google through its Spanish subsidiary, which sells advertising. Selling advertising space proved to be a sufficient connecting factor.

Third — and this is the crucial one. The operator must remove a link from the results of a search on a person's name even where the page itself remains untouched and even, as the case may be, where the publication on that page is lawful in itself. The search engine's responsibility is autonomous from the publisher's. The newspaper stays; the link disappears.

Fourth — the balancing test. What has to be examined is whether the person has a right that the information should, 'as things stand at that point in time', no longer be linked to their name. And, in terms, establishing that right does not require the inclusion of the link in the list of results to cause prejudice to the data subject. No damage need be proved.

Why the search engine in particular

The Court's reasoning explains the logic better than any paraphrase can. Paragraph 80 states that a search engine enables any user to obtain a structured overview of the information about a person and thereby to establish a more or less detailed profile of them. The effect is amplified by the fact that search engines make information ubiquitous.

Paragraph 93 is the doctrinal core of the whole construction. Even processing that was lawful to begin with, and of accurate data, may in the course of time become incompatible with the Directive itself where the data are no longer necessary for the purposes for which they were collected. That is so in particular where they appear inadequate, irrelevant or no longer relevant, or excessive — having regard to the time that has elapsed.

This is a rare thought in law: the truth about a person does not spoil, but its pertinence does. The 1998 notice did not become a lie. It simply stopped saying anything about who Costeja was in 2014. In paragraph 98 the Court referred expressly to the fact that the initial publication had taken place sixteen years earlier.

Even so, the Court handed out no blanket indulgence. On the judgment's formula, the individual's rights override, as a rule, both the economic interest of the search engine operator and the interest of the public in access to the information. But not always: if for particular reasons — because of the role played by the person in public life, for instance — the interference with their rights is justified by the preponderant interest of the public, the answer runs the other way.

How it became a provision of law

Almost two years later, on 27 April 2016, the GDPR was adopted — Regulation (EU) 2016/679, applicable from 25 May 2018. The logic of Google Spain acquired an article of its own in it.

Article 17 is headed "Right to erasure ('right to be forgotten')". Note the quotation marks inside the heading itself: the right to be forgotten is an unofficial synonym, a handsome name for newspaper headlines. The legal term is the right to erasure.

There are exactly six grounds, and the list is closed:

• (a) the data are no longer necessary for the purposes for which they were collected;
• (b) the person has withdrawn consent — and there is no other legal basis;
• (c) the person has objected to the processing and there are no overriding legitimate grounds (and against direct marketing an objection operates unconditionally);
• (d) the processing was unlawful;
• (e) erasure is required by EU or Member State law;
• (f) the data were collected from a child in relation to the offer of online services.

Article 17(2) is a direct inheritance from the Costeja case. Where a controller has made the data public, it must take reasonable steps to inform other controllers that the person is requesting the erasure of links, copies and replications. With an honest caveat: 'taking account of available technology and the cost of implementation'. This is not an obligation of result.

The deadline is set not in Article 17 but in Article 12(3): without undue delay and in any event within one month, with the possibility of an extension by a further two — three in all.

Five doors that stay open

The exceptions are listed in Article 17(3), and their wording matters: they apply 'to the extent that' the processing is necessary. An exception does not kill the request outright; it cuts a piece out of it.

Erasure is not required where processing is necessary:

• (a) for exercising the right of freedom of expression and information — journalism falls in here;
• (b) for compliance with a legal obligation, for the performance of a task carried out in the public interest, or in the exercise of official authority;
• (c) for reasons of public interest in the area of public health;
• (d) for archiving purposes in the public interest, scientific or historical research purposes or statistical purposes — but only where erasure is likely to render impossible or seriously impair the achievement of those objectives;
• (e) for the establishment, exercise or defence of legal claims.

Article 85 stands apart: Member States must by law reconcile data protection with freedom of expression, including processing for journalistic, academic, artistic and literary purposes. The right to be forgotten was never conceived as a tool for tidying up history — and point (d), on archives, records that plainly.

What it is for

The answer is simpler than it looks. Before the internet, forgetting was the default setting: newsprint yellowed, the bound volumes went down to the basement, a person moved to another town and began again. Nobody wrote this right down — it arose of itself, out of the imperfection of memory.

Search abolished the imperfection. The default now is perpetual recall, and selective recall at that: not a biography but its worst five minutes, lifted to the top line of the results. A debt settled in the nineties. A charge dropped by a court. A mistake made at nineteen.

Article 17 is an attempt to restore by legal means what nature used to provide. And it admits honestly that rights collide here: one person's right to a future against everyone else's right to know the past. The GDPR does not resolve that conflict once and for all. It only requires the balance to be struck — afresh each time, with an eye to how much time has passed and to who stands before us: a private individual, or someone whose role in public life the public is entitled to remember.

Immutability: why a blockchain cannot forget

An ordinary database is built so that a record can be amended. Where there is a row, there is an "update" command and a "delete" button. Blockchains were built by people who saw exactly that as a vulnerability: if a record can be changed quietly, then sooner or later someone will change it in their own favour.

The hash: a fingerprint that cannot be faked

At the base of it all sits the hash function. It is a mathematical mincer: you feed it anything at all — a line of text, a file, an entire book — and it always returns a short string of fixed length. It has three important properties:

• the same input always produces the same output;
• change a single character in the input and the output changes completely — not slightly, but beyond recognition;
• the input cannot be recovered from the output.

A hash is a fingerprint of the data. It does not store the data itself, but it certifies it unambiguously: given a file and its hash, you can verify in a fraction of a second that the file has not been swapped.

The chain: why editing one record breaks everything

Then comes the simple trick that holds the whole construction together. Each block of records contains the hash of the previous block. The second refers to the first, the third to the second, and so on.

Picture a ledger in which the fingerprint of the previous page is written at the top of every page. Doctor a figure on page 40 — its fingerprint changes — and it no longer matches what is written on page 41. To conceal the alteration you have to rewrite page 41. But then page 42 slips out of line. And so on to the last page.

That is why an individual record in a blockchain cannot be edited. All you can do is rewrite everything that follows it — and get those who hold copies of the chain to accept the new version. A study published by the European Parliamentary Research Service in 2019 calls the very word "immutability" misleading: where participants collude, data can be changed — it is extremely burdensome and expensive, but not impossible. The distinction matters: immutability is not a law of physics but a very expensive lock.

"Deleting your own copy" means nothing

The second half of the answer is hidden in the word "distributed". The chain of blocks does not sit on a single server but on a multitude of independent machines around the world, many of them holding a complete copy of the chain.

Hence a conclusion lawyers find uncomfortable: even if a controller sincerely wants to delete a record, it physically has no access to other people's copies. Its own it can erase — the rest remain. The others it can ask — they are under no obligation to listen. The EDPB puts it matter-of-factly: technically a change is possible, but it requires every node to update or delete its copy of the chain and to agree to do so; in practice the amendment does not reach all copies, and the original data remains available. That is the entire point of the design.

The French regulator CNIL recorded this as early as 2018: it is technically impossible to satisfy an erasure request once the data has been written into a blockchain. The European Data Protection Board (EDPB), in Guidelines 02/2025 — the final version adopted on 7 July 2026 — goes further: as a rule, storing personal data in a blockchain is not recommended, and it certainly should not be placed in the content of transactions. And, separately, so that no loophole is left: technical impossibility cannot be used to justify non-compliance with the GDPR.

Both regulators describe workarounds, and the outline is the same in each: what goes into the chain is not the data itself but proof of its existence — a pointer, a cryptographic commitment, or a keyed hash — while everything needed to verify that proof is kept outside. CNIL sets out an order of preference: a commitment first, then a keyed hash, then ciphertext. The EDPB is stricter: it puts plaintext, ciphertext and hash on the same footing and does not recommend writing personal data into the chain in any of these forms — their place is outside it. Encrypted personal data remains personal data; and even flawlessly implemented modern encryption will be defeated by time if the chain is kept indefinitely.

The one case in which both regulators agree that the data has ceased to be personal data is the perfectly hiding commitment: if both the original value and the auxiliary secret are deleted, the commitment left in the chain is useless — the original data can be neither reconstructed nor identified from it. About everything else, CNIL says precisely what is usually left out when it is quoted: strictly speaking, such solutions do not result in erasure, since the data still exists in the blockchain — and it adds that it questions their ability to ensure full compliance with the GDPR.

Arweave: permanence, not as a side effect

Bitcoin and networks like it are immutable incidentally — their job is to count money, not to keep archives. Arweave was built for storage and nothing else: you put a file in once, you pay once, and after that it simply sits there.

The economics run as follows. The payment is split in two: one part goes to the miner straight away, the bulk into a common endowment out of which those who store the data are paid years in advance. The calculation rests on storage getting cheaper: according to the Arweave yellow paper, over half a century the cost of a gigabyte-hour has fallen by an average of a little over 30 % a year, while the project's documentation maintains that half a per cent a year is enough to sustain the endowment indefinitely. The fee charged on upload is calculated at current prices as payment for two hundred years of storage in twenty copies.

Here something has to be said that does not appear in the marketing descriptions. Two hundred years is a pricing parameter, not a promise; the permanence rests on the assumptions that storage will keep getting cheaper and that the token price will not collapse. The protocol's own authors write plainly: they do not expect the network in its present form to produce blocks forever — after the final block the financial incentive to store data will give way to a social one, and the data itself, as they anticipate, will be taken up by a successor system. Nor does the protocol oblige a node to keep everything: each one decides for itself what to store, and durability is provided probabilistically and at the level of the network as a whole.

A second caveat is needed too. None of the European regulators' documents I have read examines Arweave separately — neither it, nor IPFS, nor any other permanent storage system. Everything that can be said about them along regulatory lines is the reasoning about blockchains carried over by analogy. The analogy looks solid: the same immutability, the same distribution, the same absence of a single "delete" button. But it is still an analogy, not a regulator's position.

And a third, which it would be dishonest to leave out: our own project writes its memory to Arweave, of all places. That does not make anything set out above untrue, but you are entitled to know that the author of this text is not a disinterested observer here.

The upshot is simple. The argument between the right to be forgotten and eternal memory is not an argument about who is too lazy to press a button. There is no button. The architecture does not provide for one, and that is deliberate.

Where exactly they collide

The "right to erasure versus immutability" conflict sounds abstract until you break it down into specific points. There are four: what happens to the data in legal terms, who answers for it, what a mistake costs, and how personal data ends up in a public chain in the first place.

Point one: the data goes in — and stays for good

Article 17 GDPR is straightforward. There are six exhaustive grounds on which a data subject may demand erasure: the data are no longer needed for the purpose they were collected for; consent has been withdrawn and there is no other ground; an objection to the processing has been raised and the controller has no overriding legitimate grounds (against direct marketing an objection is absolute); the processing was unlawful; erasure is required by law; the data were collected from a child in connection with an offer of information society services. If any of the six applies, the controller must erase "without undue delay". Article 12(3) converts that into a calendar: one month, extendable by a further two.

Now picture the data written into a blockchain. The month runs on, and there is nothing to erase — the architecture makes no provision for deletion, it makes provision for addition.

CNIL — the French regulator, which worked through this subject in a report of September 2018 — put it plainly: it is technically impossible to satisfy an erasure request once the data have been written into a blockchain. CNIL then described a workaround: if what sits in the chain is not the text itself but a cryptographic commitment, a keyed hash or a ciphertext, then destroying the source data and the verification elements off-chain can "move closer to the effect of erasure". And it immediately added a qualification — with the exception of certain commitment schemes, these solutions are not, strictly speaking, erasure, since the data continue to exist in the chain. CNIL's own verdict on its own recommendation: we acknowledge the value of these solutions, but we doubt their ability to deliver full GDPR compliance.

Almost eight years later the EDPB — the European Data Protection Board — took a harder line. The final version of Guidelines 02/2025 (adopted on 7 July 2026) contains a sentence that shuts down the industry's main line of defence: technical impossibility cannot serve as a justification for non-compliance with the GDPR. The reasoning runs like this: Article 25 requires data protection "by design", that is, at the point when the means of processing are chosen. You chose immutable storage — that was your choice, not force majeure.

Hence the EDPB's general recommendation: as a rule, personal data should not be stored in a blockchain, and should not be placed in the content of transactions. Paragraph 104 goes further and sets three formats side by side — plaintext, encrypted data and hashes: recording personal data in the chain in any of these forms is not recommended; their place is off-chain.

That last point surprises engineers more than anything else. "But I encrypted it" is no answer: the EDPB points out that encrypted personal data remain personal data. And it adds something rarely considered at the design stage: even flawlessly implemented modern encryption will be defeated by time if the chain is kept indefinitely.

Point two: who is the controller here

The GDPR rests on the assumption that every unit of personal data has at least one controller — that the data subject knows whom to address a request to. A study prepared for the European Parliament's Panel for the Future of Science and Technology (EPRS, PE 634.445, July 2019; author: Michèle Finck) calls this the first of two root conflicts: a blockchain replaces a single actor with a multitude of players, and the absence of any consensus on how controllership is to be determined makes responsibility impossible to allocate.

CNIL did try to allocate it. Controllers are those participants with write rights who decide to submit data for validation: a natural person, where the processing relates to a professional or commercial activity; a legal person, where it records personal data in the chain. Miners are not treated as controllers: they merely validate transactions, without determining purposes and means. Someone who bought bitcoin for their own account is not a controller either — the personal-activity exemption applies there.

But the construction breaks down at the next step. Miners, on CNIL's view, may turn out to be processors. And a processor, under Article 28 GDPR, acts on the basis of a contract with the controller. How do you conclude a contract with an anonymous miner on a public network, who does not himself know whose transaction he is including in a block? CNIL acknowledged the practical difficulty and answered honestly that it is engaged in "in-depth thought" on the question. The report offers no ready construction.

The second trap: if several participants carry out processing with a shared purpose, they all risk becoming joint controllers under Article 26. CNIL advises designating one of them in advance, or creating a legal entity. Both assume that the circle of participants is known in advance and that there is someone to act on their behalf.

Worth remembering: in Google Spain (C-131/12, Grand Chamber, 13 May 2014) the Court of Justice of the EU held the operator of a search engine to be a controller — someone who merely indexes other people's pages and has nothing to do with the original publication. And the search engine's responsibility turned out to be autonomous: it must remove a link even in cases where the publication on the source page is itself lawful. The Court was not looking for whoever would be most convenient to hold answerable; it was looking for whoever determines the purposes and means. Applied to a distributed ledger, that same logic gives no good answer. It gives plenty of bad ones.

Point three: the cost of getting it wrong

A breach of the right to erasure falls into the upper of the two tiers of fines. Article 83(5)(b) covers the rights of data subjects under Articles 12–22 — and Article 17 sits within it in full. The ceiling: EUR 20 000 000, or 4% of total worldwide annual turnover for the preceding financial year.

Three details that usually get distorted. The formula is "whichever is higher": you take the greater of the two figures, not the lesser. The percentage is calculated on turnover, not profit, and on worldwide turnover, not European. The percentage threshold applies to an undertaking; for non-undertakings, only the absolute figure applies.

There is mitigating machinery as well. Article 83(3): where there are several infringements in the context of linked operations, the total shall not exceed the amount set for the gravest infringement — fines do not stack. Article 83(2) lays down an exhaustive list of eleven mandatory factors; among them the nature and duration of the infringement, intent or negligence, action taken to mitigate the damage, the degree of responsibility having regard to Articles 25 and 32, previous infringements, cooperation with the supervisory authority, the categories of data, and any benefit gained. The ceiling here is the upper bound of that weighing exercise, not a tariff.

The order of magnitude in practice comes from Google v CNIL (C-507/17): CNIL fined Google EUR 100 000 for refusing to comply with an order to de-list links across all domain extensions. On 24 September 2019 the Court of Justice ruled that Google is not obliged to de-list worldwide — the versions corresponding to all the Member States are enough, together with measures that effectively prevent or at the very least seriously discourage access when a search is made from within the EU. But the same judgment, at paragraph 72, carries a caveat that is often lost: EU law does not prohibit global de-listing either — a national supervisory or judicial authority is free to order it under national standards of fundamental rights protection.

Point four: how the data get there

Here I have to be careful. The regulators' documents I have studied do not offer a catalogue of incidents with named networks and dates — they describe mechanisms, not a chronicle. So mechanisms are what I will set out.

The first and most underrated: participant identifiers. CNIL regards public keys as data that cannot be minimised in substance, with a retention period equal to the lifetime of the chain itself. Which means that even a chain holding not a single byte of "substantive" personal data is already storing personal data — for ever.

The second: the hash as personal data. Engineering intuition says "a hash is irreversible, therefore it is anonymous". WP29, in Opinion 05/2014 — as the EPRS study cites it — answered that simply applying a hash function does not automatically turn personal data into anonymous data; hashing more often yields pseudonymous rather than anonymous data — a useful security measure, but not a method of anonymisation. The reason is arithmetical: if the set of possible inputs is known and finite — every email address in existence, say — then working through it takes a machine less time than brewing a cup of coffee, in an observation by Edward Felten that the same study quotes. Salted hashes do not rescue the position; keyed hashes give stronger guarantees. The EDPB confirms it: a hash will be considered personal data, as will any other identifiers present — with one caveat: if the algorithm is unbroken and the secret key or the salt has been deleted and has not leaked, it should no longer be possible to link the hash back to the source data.

The third: the right to rectification, turned against the data subject. On CNIL's approach, rectification is carried out by writing the updated data in a new block — but the first, erroneous transaction stays in the chain. Formally, the right has been honoured. In practice, incorrect data about a person are stored for ever, side by side with the correct data.

The one architecture that both regulators accept as a way out is a cryptographic commitment under a perfectly hiding scheme. CNIL notes in a footnote that once the witness and the committed value itself have been deleted, the commitment becomes anonymous to the point where it can no longer be regarded as personal data. The EDPB agrees, at paragraph 53: the commitment left in the chain is useless — the source data can neither be recovered nor identified. It is a narrow door, but it is there.

What the regulators say

The argument over whether people may be written into permanent storage is not confined to engineers. In Europe there are three documents this argument tends to come back to: a report by the French regulator CNIL, a study prepared for the European Parliament by its own research service, and guidelines from the European Data Protection Board (EDPB). Their status differs — two supervisory authorities and one piece of expert work — but reading them in sequence is instructive: over almost eight years the position has hardened rather than softened.

CNIL, 2018: "technically impossible" — and what to do about it

The French regulator is the place to start. In September 2018 CNIL published a report, "Blockchain and the GDPR: Solutions for a responsible use of the blockchain in the context of personal data" — a detailed analysis, by a supervisory authority, of how the GDPR maps onto an immutable ledger.

One line from it gets quoted more than any other: CNIL states that it is technically impossible to grant a request for erasure once the data has been written into a blockchain. The quotation usually stops there — which yields the convenient conclusion that "the regulator has admitted deletion is impossible, so we need not delete".

But what comes next in CNIL's text is quoted less often. The regulator describes a way round the problem: if what goes into the chain is not the text itself but a cryptographic commitment, a keyed hash or a ciphertext, then by destroying the source data and the verification elements off-chain the controller can move "closer to the effect of erasure". And it immediately enters a caveat: apart from certain commitment schemes, these solutions are not, strictly speaking, erasure, because the data continues to exist in the blockchain. Its overall assessment: CNIL acknowledges the value of such solutions but doubts their ability to deliver full compliance with the GDPR.

In other words, as early as 2018 the regulator was saying not "this is allowed" but "we can see your workaround and we are not convinced it counts".

The practical part of the report is quite specific, though. CNIL ranked the recording formats in descending order of preference: a cryptographic commitment first, then a keyed hash, then a ciphertext. Plaintext or an unkeyed hash — only in exceptional cases. The data itself belongs off-chain; what goes into the chain is only proof that the data existed. Separately, CNIL acknowledged that concluding an Article 28 processor agreement with the miners of a public network is difficult in practice, and said it was giving the question further in-depth thought.

The study for the European Parliament, 2019: leave the law alone, issue guidance

A year later came the study "Blockchain and the General Data Protection Regulation" (PE 634.445, July 2019, by Michèle Finck), prepared by the European Parliamentary Research Service for its panel on scientific and technological foresight. It is the work of an outside expert rather than the position of Parliament as an institution — but it is this study that reduced the conflict to two assumptions built into the GDPR.

The first: every piece of personal data has at least one controller against whom a claim can be brought. A blockchain replaces the single responsible party with a multitude of participants — and the lack of agreement about which of them is the controller makes responsibility hard to allocate.

The second: data can be amended or erased. A blockchain is deliberately built to make unilateral amendment as hard as possible — that is the whole point of the technology.

The study's conclusion is nonetheless mild: the GDPR does not need changing. The Regulation was drafted to be technology-neutral and rests on principles rather than on descriptions of particular systems. What is needed is not amendments to the law but guidance from the regulator — dedicated EDPB guidelines, codes of conduct, certification mechanisms.

One further observation from it is worth remembering: Article 17 of the GDPR does not define what "erasure" means at all. There is no definition either in the text of the article or in the recitals. In Google Spain, meanwhile, removing links from search results was held to be sufficient — even though the newspaper page itself stayed where it was (although the applicant had not asked for more). That is an argument that destruction as a physical act is not a mandatory element of the right. The case law is inconsistent, though: in Nowak the CJEU spoke of erasure precisely as destruction.

EDPB, 2026: "technically impossible" has ceased to be an argument

The guidance the 2019 study called for arrived almost six years later. Guidelines 02/2025 on processing of personal data through blockchain technologies: version 1.1 was adopted on 8 April 2025, and the final version 2.0 on 7 July 2026, after public consultation.

The tone has changed radically. The key sentence (paragraph 50):

"The EDPB emphasises that technical impossibility cannot be invoked to justify non-compliance with GDPR requirements"

Technical impossibility does not excuse non-compliance. The logic is simple and hard to rebut: data protection by design (Article 25(1)) applies at the point where the means of processing are chosen. If you have chosen an architecture in which deletion is impossible, then you created that impossibility yourself, and it is your problem, not a mitigating circumstance.

The general instruction is harsher still (paragraph 48): storing personal data in a blockchain is, as a rule, not recommended, and it should not appear in the content of transactions. Paragraph 104 puts plaintext, ciphertext and hash on the same footing: recording personal data on-chain in any of these forms is not recommended — their place is off-chain. Recommendation 11 carries the thought to its conclusion: if there is no technical solution guaranteeing deletion or anonymisation once the retention period expires, then personal data should not be put into the chain at all.

The difference between CNIL in 2018 and the EDPB in 2026 is one of principle. CNIL was describing how to live with a blockchain. The EDPB's answer is: mostly you cannot; if you do not need the chain's strict integrity property, use a different tool.

Does a hash count as personal data

This is where the intuitions of engineers and lawyers diverge most sharply. An engineer sees a hash as an irreversible one-way transformation: you cannot get the original string back out of it. The regulator looks at it differently — what interests it is not whether the function can be reversed but whether the record can be linked to a person.

The EDPB's position (paragraph 52) is blunt: a hash will be regarded as personal data, as will any other identifiers present. There is a caveat there too: once the secret key or the salt has been deleted, the hash should no longer be linkable to the source data — but only for as long as the algorithm remains unbroken and the key and salt uncompromised. On encryption the wording is equally unambiguous (paragraph 51): encrypted personal data remains personal data, and encryption does not remove obligations under the GDPR. A separate point is added about time: even perfectly implemented modern encryption will be broken if the blockchain is kept indefinitely.

This is not a new position. Back in 2014 the Article 29 Working Party, in Opinion 05/2014, classified hashing as pseudonymisation rather than anonymisation: a useful security measure, but not a method of anonymising. Salted hashes do not deliver anonymity either. These formulations are known chiefly from the quotations in the EPRS study, which itself draws on the Working Party's opinion; the study says the same thing: applying a hash function does not, in itself, turn personal data into anonymous data.

An example makes the reason clear. A hash need not be "decrypted"; it can be guessed. If the set of possible inputs is limited, it is enough to hash them all and compare. There are on the order of five billion email addresses in the world — for a computer that is no task at all. A hash of a phone number or a date of birth is trivially recovered by brute force, because the space of values is small. The irreversibility of the function protects nothing here.

The one construction both regulators describe in the same, positive terms is the cryptographic commitment. CNIL, in a footnote to its report: with a perfectly hiding scheme, deleting the witness and the committed value itself renders the commitment anonymous to the point where it can no longer be regarded as personal data. The EDPB (paragraph 53) echoes this: once the source data and the witness have been deleted, the commitment remaining in the blockchain is useless — the source data can neither be recovered nor learnt.

Where the regulators have no answer

It is worth calling things by their names.

There is no definition of "erasure". Article 17 does not supply one. The study prepared for the European Parliament acknowledges as much. The whole construction of "we destroyed the key, so consider it erased" rests not on a rule but on the absence of one.

There is not a single instrument recognising cryptographic erasure as compliance with Article 17. There is an engineering standard (NIST SP 800-88r2 places cryptographic erase among purge-level techniques, not destroy). There is CNIL's cautious "approaching the effect". There is the CJEU's judgment in SRB, in which, judging by the legal commentary, a contextual turn has begun to emerge. But there is no binding document stating that "destroying the key = deletion". More than that, the EU-wide review of enforcement under Article 17 — the EDPB's CEF 2025 report, with 764 controllers surveyed — does not mention crypto-erasure once. The supervisory authorities there do, however, criticise directly the substitution of anonymisation for deletion: the widespread practice whereby controllers apply basic pseudonymisation or partial masking and present it as deletion does not meet the requirements of the GDPR.

There is no answer on permanent storage. None of these documents considers Arweave, IPFS or similar systems separately from blockchains. Any conclusions about them are extrapolation, not a regulator's position.

There is no solution to the miner problem. CNIL acknowledged that a processor agreement with the validators of a public network is difficult to conclude in practice and said it was reflecting on the matter; the report contains no ready answer.

The upshot is awkward but honest: the regulators have described what may not be done in far more detail than how it may. The only architecture both endorse outright is to keep the data off-chain and put only proof of its existence into the chain. Everything else is territory where there is either no position at all, or one that amounts to "we doubt this counts".

Solutions that do not work

When someone first runs into the contradiction between blockchain and the right to erasure, an idea that looks like salvation tends to arrive fairly quickly. Usually it is one of six. None of them survives scrutiny in full: some have been taken apart by regulators directly, others break on their own construction. Let us go through them in order, because understanding why a workaround fails is more useful than another list of prohibitions.

"We only put a hash on the chain"

The most popular solution and the most widespread misconception. The logic runs like this: a hash is a one-way function, the original data cannot be recovered from it, so what sits on the blockchain is no longer personal data but a meaningless string.

Regulators see it differently. The EDPB puts it plainly in Guidelines 02/2025: a hash will also be considered personal data — as will any other identifiers that may exist alongside it. The Article 29 Working Party said back in 2014 (Opinion 05/2014 on Anonymisation Techniques, WP 216) that hash functions are a useful security measure but not an anonymisation technique — I am citing this from a study prepared for the European Parliament that quotes the opinion; I have not opened the primary source myself. The study itself (PE 634.445, Michèle Finck, July 2019) adds the same point in its own voice: hashing more often yields pseudonymous rather than anonymous data, and applying a hash function does not automatically turn personal data into anonymous data.

The technical reason is simple and unwelcome. The one-wayness of a hash protects against recovering an arbitrary input, but not against brute-forcing a known set. If you hash an email address, a telephone number or a date of birth, the set of possible inputs is finite and entirely manageable. Edward Felten, quoted in the same study, observed that brute-forcing a known set of inputs takes a computer less time than making a cup of coffee. Salted hashes, on the WP29 position cited there as well, do not deliver anonymity either — salt makes a mass attack harder but does not make the data anonymous. A keyed hash ("peppered") gives stronger guarantees, but it too remains a pseudonym for as long as the key exists.

CNIL's practical conclusion from 2018: if something must go on the chain, then in order of preference — a cryptographic commitment, then a keyed hash, then ciphertext. The EDPB guidance keeps only the top of that list: a pointer, a commitment or a keyed hash are acceptable on the chain, while ciphertext is placed in paragraph 104 on the same footing as plaintext — writing personal data in that form is not recommended. A bare unkeyed hash on a public blockchain the EDPB considers generally insufficient.

"We encrypt — and then destroy the key"

This is a technique with a name and a standard: cryptographic erase. NIST SP 800-88r2 (September 2025) defines it as the sanitisation of keys, rendering recovery of the decrypted data infeasible. As engineering, it is honest.

But note the classification: NIST places cryptographic erase at the purge level, not destroy. This is not physical destruction, and the standard makes no secret of it — the ciphertext stays on the medium.

Legally, the EDPB is more direct still: encrypted personal data remain personal data, and encryption does not remove the obligation to comply with the GDPR. And it adds something that is fatal for eternal storage: even flawlessly implemented modern encryption will be defeated by time if the chain is kept indefinitely.

It is worth pausing on the threshold itself. Identifiability is not measured in absolutes: the question is whether a record can be linked to a person "by means reasonably likely to be used" — that is how the EDPB describes the test in its section on the right to erasure. And "reasonably likely" is a quantity tied to a moment in time: what today takes the resources of a state tomorrow fits the budget of anyone curious. Data that will sit for a hundred years has to be assessed against that horizon, not against its resilience on Monday morning.

To this the standard adds its own down-to-earth caveats. Cryptographic erase does not apply if sensitive data has ever sat on the medium in the clear. It should not be relied on if the medium was backed up or the keys were escrowed — unless the organisation reliably knows how and where those keys were stored and who managed them. Unwrapped keys may remain in memory and in the registers of the encryption engine. And the earlier, now withdrawn revision of the standard names one more nuisance: the result cannot be verified — after erasure there is nothing to compare the contents of the medium against.

There is a counter-argument as well, and I will give it fairly. The Court of Justice of the EU's judgment in Case C-413/23 P (EDPS v SRB, 4 September 2025) established a relative approach: the same pseudonymised data may be personal for whoever holds the key and not personal for a recipient who cannot re-identify it. This is the strongest argument available today in favour of cryptographic erase. But it concerns how data is classified in the hands of a recipient without the key, not the proposition that a controller who has destroyed the key has complied with Article 17 in respect of the ciphertext still in its possession. And a caveat: I have not checked the text of that judgment against the primary source.

"Our network is private, outsiders cannot get in"

A private or consortium blockchain does remove part of the problem: the set of participants is known, procedures are easier to agree, there is no public access. The EDPB writes explicitly that public blockchains should be used only where public access is necessary for at least one of the purposes of the processing — citing Article 25(2) GDPR on personal data not being made accessible to an indefinite number of people by default.

But the privacy of the network answers the question of access, not the question of immutability. If a record cannot be taken off the chain, it stays there regardless of how many people can see that chain — ten thousand or ten. The right to erasure does not turn into a right to restrict access simply because the audience has narrowed.

Second: a private network does not dispose of the question of who the controller is. On CNIL's reasoning, participants with write access become controllers — a legal entity that records personal data on the chain is a controller, no question about it. If several participants carry out processing with a common purpose and have not determined in advance who is responsible, they all risk being joint controllers under Article 26 GDPR. In a consortium that is not a mitigating circumstance but a description of the typical situation.

"We will fork the chain and clean the record out"

A radical idea: if a record cannot be deleted, rewrite the history in full from the relevant block and ask the network to move to the new version.

Technically this is possible — and that is precisely why it does not work as a legal mechanism. A fork requires the network's agreement. Which means that giving effect to one individual's right depends on the goodwill of a multitude of independent participants who owe that individual nothing. The GDPR, meanwhile, gives the data subject the right to approach the controller and obtain a result "without undue delay" — under Article 12(3), within a month, and at most with a further two-month extension. A mechanism that requires coordinating the entire network for every individual request does not fit those deadlines and does not scale in principle: it is designed for a rare emergency, whereas erasure requests are routine.

On top of that, a fork breaks the very property the blockchain was chosen for. If history can be rewritten on demand, the evidentiary value of the chain disappears. What is left is a system that no longer offers guarantees of immutability yet still carries all the costs of distributed consensus.

"The data is anonymised" and "we simply will not delete"

The last two options are worth taking together, because in practice the second often hides behind the first.

The EDPB's report on enforcement of the right to erasure (764 controllers surveyed) records this as a widespread practice: controllers rely on anonymisation as a substitute for definitive deletion. And it finds that in a number of cases only basic pseudonymisation or partial masking is applied — a process that does not meet the GDPR's requirements for deletion. The same report notes that many exclude backups from deletion by default, without justifying why.

"Anonymised" is not a matter of self-certification. The test is substantive: if the data can still be linked to a person "by means reasonably likely to be used" — and that is exactly how the EDPB describes the threshold in its section on the right to erasure — then no anonymisation has taken place, whatever the internal documentation calls it.

The "do not delete and hope" option rested until recently on CNIL's 2018 wording: it is technically impossible to satisfy an erasure request when the data has been written to a blockchain. From which the conclusion was drawn — if it is impossible, then there is no obligation.

The EDPB has removed that support. Guidelines 02/2025 (final version 2.0 adopted on 7 July 2026) say it plainly: technical impossibility cannot serve as a justification for non-compliance with the GDPR. With reference to Article 25(1) — data protection by design applies as early as the stage at which you determine the means of processing. Which is to say that an architectural decision that made compliance with the law impossible is your choice, not force majeure.

The stakes are not abstract. Infringements of data subjects' rights under Articles 12–22 fall into the upper tier of Article 83(5): up to EUR 20 000 000, or, where the infringer is an undertaking, up to 4% of its total worldwide annual turnover for the preceding financial year, whichever is higher — that is, the greater of the two figures is taken.

All six approaches share one common denominator: each of them changes the accessibility of the data, and none of them answers the question of what to do with the data itself. The only architecture in which regulators allow the status of personal data to come to an end is a perfectly hiding commitment: once the original data and the witness have been deleted, the commitment left on the chain is, in the EDPB's formulation, useless — the original data can neither be recovered nor recognised. But that is no longer a way round the problem; it is a different way of designing, adopted before the first block is written rather than after.

Cryptographic erasure

Picture a safe set into concrete. You cannot pull it out, you cannot blow it open, you cannot carry it away. What you can do is melt down the only key. The contents stay inside forever — but there is nothing left to open them with.

That is cryptographic erasure, also known as crypto-shredding. The idea is almost indecently simple: the data sits encrypted from the very beginning, and when the time comes to "delete" it, what gets destroyed is not the data but the key.

What the standard says

The method has a canonical definition — NIST SP 800-88r2, "Guidelines for Media Sanitization" (September 2025). Verbatim:

"cryptographic erase (CE): A purge sanitization technique in which key sanitization is applied to one or more keys providing confidentiality protections for the encrypted target data, making recovery of the decrypted target data infeasible."

Note the word purge. NIST's classification includes a Destroy level — physical destruction of the medium, where all that remains of a drive is shavings. Cryptographic erasure does not reach it. This is the purge level, and NIST is honest about the caveat: "The encryption itself acts to sanitize the data" — encryption performs the erasure itself, but only if the conditions set out in the document are met. The ciphertext physically remains on the medium.

It is also worth knowing that the previous edition of the standard — SP 800-88r1 of 2014, still cited by nine articles and blog posts on crypto-shredding out of ten — was withdrawn on 26 September 2025 and fully superseded by r2. If someone shows you a reference to r1 as the standard in force, they read the document a long time ago.

The conditions under which it works

NIST does not say "destroy the key and sleep soundly". §3.2 of the standard lists strict preconditions, and every one of them is a potential point of failure.

Strength of the cryptography. Citing ISO/IEC 27040: the algorithm and mode must provide at least 128 bits of security strength, and the entropy of the random number generator must be no less than the key length. ECB mode is expressly prohibited.

The data was never held in the clear. If sensitive information was written to the medium unencrypted even once, cryptographic erasure will not remove it — it clears out keys only, not the data itself.

Every copy of the key destroyed. Not one, but all of them — including keys lower down the hierarchy. The recommended technique is zeroisation in accordance with ISO/IEC 19790.

No key left in memory. A subtle point that is usually missed: if a wrapped key was ever unwrapped and placed in RAM or in a crypto engine register, those traces have to be cleared too. NIST allows that this may require a hard reset or powering the device down for a period of time.

The weak points — honestly

The method is elegant, but it has vulnerabilities that the standard states openly and marketing material usually keeps quiet about.

The cipher may not hold. This is not paranoia but an explicit NIST caveat: if cryptographic weaknesses in the algorithm are found in the future, or computing capabilities (quantum computing, for instance) make key recovery realistic, the data becomes accessible again — and in such cases "CE may not be an acceptable sanitization technique".

From which an unpleasant consequence follows: the "harvest now, decrypt later" attack. A copy of the ciphertext taken before the key was destroyed lives forever and bides its time. Against physical destruction of the medium such an attack is pointless. Against cryptographic erasure it is a perfectly workable strategy.

The EDPB frames the same thought in relation to blockchain: even the most modern encryption, perfectly implemented, will be defeated by time if the chain is kept indefinitely. For an ordinary corporate drive that will be scrapped in a few years, the margin of strength is more than sufficient. For a record intended to last centuries, that same margin means nothing.

Backup copies of the key. The most prosaic and the most frequent trouble. NIST: cryptographic erasure cannot be relied upon for media whose keys have been backed up or escrowed, unless the organisation has a high degree of confidence in how and where those keys were stored and managed outside the medium.

Put plainly. The key lives in a KMS. The KMS is replicated across three regions. There is a nightly KMS backup. There is an escrow copy held by a second administrator in case the first one leaves. There is a virtual machine snapshot taken at the moment the key was unwrapped in memory. You have pressed "destroy key" — and it is still in five other places. The erasure effect is nil, and meanwhile the report confirming that the user's request has been fulfilled has already gone out.

The result cannot be verified. This is perhaps the most underrated problem. The withdrawn r1 edition described it without euphemism: after cryptographic erasure the medium holds ciphertext whose contents are unknown, and there is nothing to compare it against; and if an organisation cannot verify that CE worked, a different, verifiable method should be used.

The current r2 requires the procedure to be documented against ten mandatory items, then immediately adds something sobering: "CE's effectiveness as a purge sanitization technique does not depend on documentation". Effectiveness does not depend on the paperwork. The paperwork is about traceability, not about the fact.

And a separate word about external key managers: the medium simply cannot see what happens to the key inside the KMS. It sent a command. What happened next is a matter of trust in somebody else's system.

Irreversibility as a risk. Destroying a key cannot be rolled back. An operator error, a script failure, a malicious act — and the data is lost for good, with no possibility of recovery whatsoever. And if the architecture calls for a separate key per user, then with a million users you are managing a million keys, every one of which has to be stored securely somewhere and destroyed at the right moment.

Why this is recognised as erasure — and whether it is

Two things need to be separated here: engineering recognition and legal recognition.

On the engineering side, everything is in order. Cryptographic erasure is described in NIST SP 800-88r2, rests on ISO/IEC 27040, ISO/IEC 19790 and ISO/IEC 24759, and related techniques are set out in IEEE 2883-2022. It is a recognised sanitisation method with clear conditions of application.

On the legal side it is far murkier, and that is worth saying outright. To begin with, the term "erasure" is not defined in Article 17 GDPR — neither in the text of the article nor in the recitals of the Regulation. Hence the divergence in practice: the Article 29 Working Party, in its opinion on cloud computing, allowed for destruction of the hardware; the Austrian supervisory authority, in a decision of 5 December 2018, accepted anonymisation as a way of giving effect to the right to erasure; the UK regulator has long applied the concept of "putting beyond use" — the data is not physically deleted, but it is taken out of circulation. No understanding shared by all member states has emerged.

None of these approaches, however, is about cryptography. There is no separate recognition of cryptographic erasure in European law, and the EDPB is a reminder of something pointing rather in the opposite direction: encrypted personal data remains personal data, and encryption does not cancel obligations under the GDPR.

One detail is telling: the largest European review of enforcement practice on the right to erasure, covering 764 controllers, examines backups and anonymisation — yet cryptographic erasure does not appear as a separate category. The method engineers write so much about simply does not exist as yet for the supervisory authorities.

The gap between "technically sound" and "legally counted" is real here, and so far there is nothing with which to close it.

How we have built it

From here on, this is about engineering. I will describe how memory storage and deletion work in CODE, why we chose this design, what the alternatives were, and where the honest compromises remain. Without any claim that we have solved a problem regulators still consider unsolved.

The ground rule: no plaintext ever reaches permanent storage

A user's dialogue with the assistant lives in three layers. The operational layer holds the context of the current session. The semantic layer holds embeddings in a database with vector search. The permanent layer is Arweave.

The critical fork sits at the boundary of the third layer. Everything bound for permanent storage is encrypted before it is sent: AES-256-GCM, client-side encryption, and only ciphertext goes out over the network. The key is held in two places: with the user, and in a managed key store (KMS). The chain itself holds no name, no text, nothing that can be read without the key.

Why this rather than simply "don't put personal data on a blockchain"? Because then there is no product left. The whole point of permanent memory is that the archive outlives the service, the company and me. Keeping it only on our own servers would make eternity contingent on whether we are still paying for hosting in 2040.

Erasure = destruction of the key

An erasure request does not attempt to wipe data from Arweave. That is physically impossible, and pretending otherwise would be a lie.

What is destroyed instead is the key: the user's copy and the copy in the KMS, including derived keys and every backup we can reach. What remains in the chain afterwards is ciphertext that nobody, ourselves included, can read. Our internal register keeps a record of the bare fact: something existed, was written on such a date, was erased on such a date. Without content.

The technique is called cryptographic erasure. It has a standard — NIST SP 800-88 (current revision r2, September 2025; the previous r1 was formally withdrawn on 26 September 2025, and nine out of ten articles and blog posts on crypto-erasure still cite it). The definition it gives: sanitisation of the keys protecting encrypted target data, rendering recovery of the decrypted data infeasible.

An important detail that usually gets glossed over: NIST classes this technique at the Purge level, not Destroy. It is not physical destruction. And the standard grants it no blanket approval: it sets out the preconditions under which the technique may be used at all, and separately lists the cases in which it cannot be relied upon.

What the alternatives were

Three options we considered and rejected.

Write nothing to permanent storage at all. Strictly speaking, this is the EDPB's position: as a general rule, storing personal data on a blockchain is not advisable, and storing it in transaction content even less so. The position is well founded. But it amounts to abandoning the idea of the project. We chose not to abandon it, and to describe the risks honestly instead.

Store a hash instead of ciphertext. It looks cleaner, but it does not solve the problem. The EDPB puts it plainly: the hash too will be considered personal data — as will any other identifiers alongside it. It does allow a caveat: once the secret key or the salt has been destroyed, it should no longer be possible to link the hash back to the original data — provided the algorithm is not broken and the key and salt have not been compromised, have not leaked and were chosen correctly. Strong conditions. The data protection Working Party as far back as 2014 called hashing a useful security measure but not a method of anonymisation — that is how a European Parliament study reports its position. The reason is arithmetic: brute-forcing a known set of inputs (every email address in the world — of the order of 5 billion) takes a machine less time than brewing a cup of coffee. The phrasing is Edward Felten's.

Cryptographic commitment. This is the one scheme regulators explicitly describe as offering a way out of personal data status. CNIL, in a footnote to its report, and the EDPB, in paragraph 53, say the same thing: with a perfectly hiding scheme, deleting the witness and the original value leaves nothing in the chain but a useless trace, from which the original data can be neither recovered nor learned. Technically it is the best option, and in CNIL's order of preference it ranks above both a keyed hash and ciphertext.

We do not use it — yet. The reason is mundane: a commitment is good for proving existence, but not for restoring an archive. What a user needs is not the fact that "your conversation existed" but the conversation itself. Ciphertext can be given back; a commitment cannot. This is a deliberate trade of privacy for usefulness, and I would rather say so out loud than hide it behind the word "innovation".

Where the compromises remain

There are four of them, and I do not consider any of them closed.

The ciphertext stays for ever. The data does not disappear; only its accessibility changes. Hence the "harvest now, decrypt later" scenario: a copy taken before the key was destroyed lives on indefinitely. NIST notes this itself: if weaknesses in the algorithm are discovered, or quantum computing arrives, the data may become recoverable — at which point crypto-erasure may turn out to be an unacceptable sanitisation technique. The EDPB puts it more bluntly: even perfectly implemented modern encryption will be defeated by time if the chain is stored indefinitely.

Copies of keys are a blind spot. The standard requires the destruction of every copy of the target key and of every key below it in the hierarchy, including copies unwrapped into memory and registers. And it gives a separate warning: where keys have been backed up or placed in escrow, crypto-erasure should not be relied upon — unless the organisation knows with a high degree of assurance how and where those keys were stored and how they were managed. Within our own perimeter we can guarantee this. For a user who has kept a copy of the key, we cannot.

The result cannot be verified. After crypto-erasure the contents of the media are unknown and there is nothing to compare them against — the usual verification of erasure simply does not apply. That is how the withdrawn revision of the standard described it, prescribing a switch to a verifiable method in such cases. For permanent storage we have no verifiable method.

The legal status is unconfirmed. This is the most honest thing I can say. Encrypted personal data remains personal data — that is the EDPB's own wording. The enforcement review of the right to erasure published in February 2026 (764 controllers surveyed) does not mention crypto-erasure once — neither as an approved practice nor as a prohibited one. What supervisory authorities in the same review do criticise is the substitution of anonymisation for erasure. And the EDPB insists separately: technical impossibility cannot serve as an excuse for non-compliance.

Which means our architecture is not shielded by anyone's guidance. It is shielded only by the fact that it does the most that is technically possible and does not lie about what it does not do.

What follows from this in practice

We design so as not to end up in the position of "we have the data and there is nothing we can do with it". The user is told exactly what happens: erasure destroys the key, the ciphertext remains, it cannot be read, and nobody can offer guarantees on a horizon of decades — not us, not NIST, not the EDPB.

There is exactly one engineering answer here, and it is a dull one: build the capacity for anonymisation in at the design stage, rather than looking for it after the first erasure request arrives. That is precisely what the EDPB requires. Everything else is about where the line runs between "we did everything that can be done" and "we promised more than we can deliver". The first is engineering. The second is marketing, and there will be none of it in this text.

One right, many countries

The right to have your data deleted does not exist in a single version. Different jurisdictions have different rights — different grounds, different exemptions, a different price for getting it wrong. A service whose users sit in Berlin, Los Angeles, Shenzhen and São Paulo faces not one requirement but four, and they do not line up.

A caveat straight away: what I have checked most thoroughly is EU law — the text of the articles, two judgments of the Court, the scale of the fines. For California, China and Brazil I have verified the erasure provisions themselves: number, title, construction. Response deadlines, territorial scope and the size of the penalties there I have not checked against primary sources. Below I rely on what has been verified, and where it has not been, I say so plainly rather than filling the gap with an elegant phrase.

What is known for certain: the European Union

In the GDPR this is Article 17 — "Right to erasure ('right to be forgotten')". Note the quotation marks inside the title itself: "right to be forgotten" is an unofficial synonym. The legal term is right to erasure.

There are exactly six grounds, and the list is exhaustive: the data are no longer needed for the purpose they were collected for; consent has been withdrawn and there is no other legal basis; an objection has been lodged under Art. 21(1) and the controller has no overriding legitimate grounds (an objection to direct marketing under Art. 21(2) applies unconditionally); the processing was unlawful; erasure is required by law; the data were collected from a child in the context of an online service.

The deadline for replying is set not in Art. 17 itself but in Art. 12(3): "without undue delay and in any event within one month of receipt of the request", with a possible extension of a further two months where the request is complex. One month, then; three at most.

There are five exemptions as well, and their formula is surgical: "shall not apply to the extent that processing is necessary". Not "the request is refused", but "to the extent that". Freedom of expression and information. Compliance with a legal obligation and the exercise of official authority. Public health. Archiving in the public interest, scientific and historical research, statistics — but only where erasure would render the achievement of those purposes impossible or seriously impair it. And the establishment or defence of legal claims.

The fine for infringing a data subject's rights falls under the upper tier of Art. 83(5): up to EUR 20 000 000 or, where the infringer is an undertaking, up to 4 % of total worldwide annual turnover of the preceding financial year, whichever is higher — the greater figure is the one that counts. Not of profit; of turnover.

The boundaries of the right: what Luxembourg showed

Two judgments of the Court of Justice have mapped the contours of this right more precisely than the text of the Regulation does. The first was handed down under Directive 95/46 — the GDPR's predecessor — but it was that judgment which set the frame within which Art. 17 was later written.

Google Spain (C-131/12, 13 May 2014). Mario Costeja González, a Spaniard, discovered that a search on his name returned links to two pages of the newspaper La Vanguardia from January and March 1998 — an announcement of the forced sale of his property over social security debts. The debt had been settled in full many years earlier. The Spanish regulator rejected his complaint against the newspaper (the publication was lawful, made on the instructions of a ministry) and upheld his complaint against Google.

The Court held something that still surprises a great many people: the link must be removed "even, as the case may be, when its publication in itself on those pages is lawful". The newspaper stays, the link disappears. The search engine's liability is autonomous from the publisher's. And the applicant is not required to prove any damage suffered. At paragraph 93 the Court set out a doctrine of obsolescence: even processing of accurate data that was lawful at the outset may "in the course of time" become "incompatible with the directive" — with the Directive as it then stood — once the data become "inadequate, irrelevant or no longer relevant, or excessive".

From the same judgment comes a limit, stated outright: the data subject's rights override "as a rule", but the balance depends on the nature of the information, its sensitivity and on "the role played by the data subject in public life". A public figure is protected less well.

Google v CNIL (C-507/17, 24 September 2019). The French regulator demanded de-referencing across all of the search engine's domains worldwide and fined Google EUR 100 000. The Court held that there is no obligation to de-reference globally, but that it must be done on the versions corresponding to all EU Member States, together with measures that "effectively prevent or, at the very least, seriously discourage" access from within the EU.

And here is the detail that retellings regularly lose. Paragraph 72: EU law does not require global de-referencing, but "it also does not prohibit such a practice" — a national supervisory or judicial authority is free to order it under national standards. The line "the CJEU banned global erasure" is wrong.

Comparing jurisdictions

Here I am obliged to be precise about what exactly has been verified. For California, China and Brazil I have checked the provisions themselves: article number, title, the construction of the right, the list of exemptions. Response deadlines, territorial scope and penalties I have not, and in the table those cells stay empty.

Two lines from these laws are worth pulling out separately, because they go straight to our subject. The second paragraph of Art. 47 PIPL: where the retention period prescribed by law has not expired or erasure is technically difficult to achieve, the handler must cease all processing other than storage and security measures. And in Brazil's LGPD the technical constraint is built into the obligation itself: Art. 16 requires data to be deleted once processing ends "no âmbito e nos limites técnicos das atividades" — within the scope and the technical limits of the activity. Neither qualification has a direct counterpart in Art. 17 GDPR. The European text simply makes no provision for the answer "we cannot".

I will not go on completing the table from memory. A mistake in an article number or a response deadline is not a stylistic slip; it is something a person might rely on in a real decision.

What a service operating everywhere at once should do

The practical conclusion, fortunately, depends less on the completeness of the table than one might expect.

Design for the strictest regime. If the architecture can withstand Art. 17 GDPR — its one-month deadline, its duty to notify other controllers about copies and links, and a fine that for an undertaking is calculated on worldwide turnover — it will in all likelihood withstand less demanding requirements too. The reverse does not hold: taking a service built for a lenient regime and bringing it up to GDPR usually means rewriting the storage layer.

Do not rely on "technically impossible". The EDPB, in Guidelines 02/2025 (final version 2.0 of 7 July 2026), puts it bluntly: "technical impossibility cannot be invoked to justify non-compliance with GDPR requirements". With a reference to Art. 25(1) — data protection by design applies at the stage where you choose the means of processing, not afterwards.

Treat encrypted data as personal data. Another direct quotation from the EDPB: "encrypted personal data is still personal data and encryption does not remove the need for GDPR compliance". And from the same document, a warning worth pinning above the architecture whiteboard: even flawlessly implemented modern encryption "will be overtaken by time if the blockchain is retained indefinitely". The EDPB treats a hash as personal data too — "the hash will also be considered personal data" — with the caveat that the link to the source data is severed only if the secret key or the salt has been deleted, the algorithm has not been broken, and neither key nor salt has leaked. A 2019 European Parliament study, citing Opinion 05/2014 of the Article 29 Working Party, calls hashing "a useful security measure but not a method of anonymisation": what you get is pseudonymous data, not anonymous data.

Distinguish "inaccessible" from "erased". The CNIL described this back in 2018. By destroying the key and the off-chain data you can "move closer to the effects of data erasure". But immediately after: "Excluding the specific case of some commitment schemes, these solutions do not, strictly speaking, result in an erasure of the data, insofar as the data would still exist in the blockchain". The exception matters and is often lost: with a perfectly hiding commitment, where both the witness and the committed value itself have been destroyed, the CNIL accepts that the record has ceased to be personal data. In every other case, coming closer is not the same as complying, and the CNIL itself "questions their ability to ensure a full compliance with the GDPR".

One regime instead of a matrix of regimes. The temptation is understandable: really delete for Europeans, go easier on everyone else. In practice that means maintaining several erasure paths, each with its own bugs, and constantly working out whose user is in front of you — by country of registration? by IP address? by citizenship? One strict path for everyone is cheaper and more reliable. It also disposes of the question from C-507/17: if you delete everywhere, the dispute over territorial scope does not exist for you.

There is a downside, and it is worth being honest about it. A single strict regime means giving up data that in some jurisdictions may lawfully and usefully be kept. Some will see that as unnecessary cost. The argument in favour: the cost is predictable and paid once, at design time, whereas a fine is a percentage of turnover and arrives without warning.

What to do if you are building this

The decision that matters is made once, on paper, before the first line of code. Article 25(1) GDPR requires data protection "by design" from the moment the means of processing are determined, and the EDPB in Guidelines 02/2025 (version 2.0, 7 July 2026) closes the one remaining loophole outright: "technical impossibility cannot be invoked to justify non-compliance with GDPR requirements" (para. 50). Telling a regulator "we cannot erase it, we are on a blockchain" is not an argument. It is an admission that the architecture was designed wrongly.

What never goes into immutable storage

The EDPB's position (para. 48): "in general, it is not advisable to store personal data on the blockchain, and it should not be stored in the content of transactions". Paragraph 104 sharpens this and puts three formats on the same footing: plaintext, encrypted and hashed data — none of the three is recommended for writing to the chain, and all three should be kept off-chain.

This is the point at which engineering intuition most often goes wrong. Encryption does not take data outside the scope of the regulation: "encrypted personal data is still personal data" (para. 51). The EDPB treats a hash as personal data too (para. 52) — with the caveat that once the secret key or the salt has been deleted, the link to the original data is lost, provided the algorithm has not been broken and the key and salt have not leaked. The point is not a new one: back in 2014 the Article 29 Working Party, in Opinion 05/2014 — as cited in the EPRS study — called hash functions "a useful security measure but not a method of anonymisation"; salted hashes do not deliver anonymity, and a keyed hash gives stronger guarantees but still does not make the data anonymous.

A public chain is permitted by the EDPB (para. 49) only where public access is necessary for at least one of the purposes of the processing — with reference to Article 25(2) on data not being made accessible to an indefinite number of people by default.

What may go in

The target architecture set out in para. 54: on the chain, only a form that serves as proof of existence (a pointer, a cryptographic commitment, a keyed hash); the data needed to verify that proof sits off-chain, at a high level of confidentiality. As far back as 2018 CNIL gave an order of preference: commitment → keyed hash → ciphertext.

The single point at which both regulators say the data ceases to be personal is the perfectly hiding commitment. Once the witness and the committed value itself have been deleted, the commitment on the chain is, in the EDPB's formulation (para. 53), "neither possible to recover nor to recognise the original personal data". Everything else approximates the effect of erasure; it is not erasure.

Keys

Crypto-erasure is a recognised engineering technique (NIST SP 800-88r2), but it is classified as purge, not as destroy. The standard sets out conditions that are easy to fail:

• never write sensitive data in the clear, not once — otherwise there is nothing to erase;
• strength of no less than 128 bits, ECB mode prohibited;
• zeroisation of every copy of the key and of every key below it in the hierarchy; expanded keys held in memory and in registers may require a hardware reset;
• if the keys have ever gone into a backup or into escrow, crypto-erasure can be relied on only where there is high confidence about where and how those copies were stored and managed;
• an external KMS is a blind spot: the medium cannot see whether the key has in fact been zeroised.

And a separate awkwardness, described in detail in the withdrawn first revision of the standard (r1, §4.7.2): the result of crypto-erasure cannot be verified — afterwards the contents of the medium are unknown, and there is nothing to compare them against.

Hence the practice: one key per data subject, a key register with identifiers, a separate zeroisation procedure with confirmation, and not a single copy of a key in storage you do not control. EDPB Recommendation 11 closes the logic: if there is no mechanism guaranteeing erasure or anonymisation once the retention period expires — "then no personal data should be stored on the chain".

The privacy policy

Three things it has to name outright.

First, the controller. CNIL advises identifying it in advance: set up a legal entity or designate a participant. Otherwise every participant risks being a joint controller under Article 26.

Second, an honest description of what goes into immutable storage and why that is irreversible. Not "we will erase your data on request", but what exactly is erased, what remains and in what form.

Third, the legal basis. EDPB Recommendation 9: consent should not be used as a basis where the architecture offers no way to erase the data.

Responding to an erasure request

The deadline is set not by Article 17 but by Article 12(3): one month from receipt, extendable by a further two where the requests are complex or numerous.

The sequence: check the ground (the list in Article 17(1) is closed — exactly six); genuinely erase the off-chain part, backups included — in the EDPB's 2025 enforcement overview the supervisory authorities noted specifically that many controllers exclude backups from erasure by default, without justification; zeroise the key or the witness; check the exceptions in Article 17(3) — the phrase "to the extent that" means an exception applies only in so far as the processing is necessary, and does not block the request in its entirety. Where the data has been made public, Article 17(2) requires reasonable steps to inform other controllers of the erasure of links, copies and replications.

And tell the applicant the truth about what remains. The same EDPB overview is openly critical of erasure being passed off as de-identification: "in some cases, they only apply basic pseudonymisation or partial masking".

Records

The standard requires every crypto-erasure to be documented: §3.2.5 lists ten items — and states plainly, in the same place, that the effectiveness of the technique itself does not depend on the documentation. What depends on it is your defence. On top of the NIST list, keep a working minimum geared to the erasure request: the date of receipt and of the reply, the ground, what was erased and where, the key identifier and the fact of zeroisation, who authorised it, the results of the DPIA. Article 83(2) expressly counts measures to mitigate damage and cooperation with the supervisory authority among the factors to be taken into account — while an infringement of the rights under Articles 12–22 falls into the upper tier of penalties: up to EUR 20 million, or for an undertaking up to 4% of total worldwide annual turnover of the preceding financial year, whichever is the higher of the two.

The right to be forgotten and the right to be preserved

We have been examining the two rights separately — as though they were opposing sides of an argument in which one has to win. But they share a root, and that is worth saying plainly.

Both rights are about the same thing: a person's control over their own trace. The right to demand erasure and the right to demand preservation are not opposites. They are one and the same capacity to dispose of one's own history, turned in different directions. What stands opposed to both is not the other one, but the situation in which somebody else decides: a platform, an heir, a ranking algorithm, a retention period buried in someone else's privacy policy.

One person in different years

The story of Mario Costeja González concerns a man whose property was being auctioned off against social security debts. The notices ran in La Vanguardia on 19 January and 9 March 1998. The proceedings, as he later stated in his complaint, had been settled years before. Yet a search on his name in Google went on returning those pages, and in its judgment of 13 May 2014 the Court of Justice of the EU noted that sixteen years had passed since publication.

Sixteen years is the key figure, not decoration. The Court set out the idea that holds the whole construction together: even the processing of accurate data that was lawful to begin with may in time become incompatible with the directive — and what applied then was Directive 95/46; the GDPR had not yet been written — if the data are no longer needed: they become inadequate, irrelevant or excessive "in the light of the time that has elapsed".

Not "the data turned out to be false". And not "the publication was unlawful": the complaint against the newspaper had been rejected by the Spanish regulator back in July 2010 — the notices were printed on the orders of the ministry, to give the auction the widest possible publicity. The Court came at it from another direction: the link is removed from search results irrespective of the source — "even, as the case may be, when its publication in itself on those pages is lawful".

What changed was the person. More precisely, the distance between the person and his past.

Anyone who asks for a single link to be taken out of the results almost always has a second half to the request — that something should remain. Photographs. Letters. The things they said to their children. A request to delete one page is not a request to erase yourself entirely. It is a request that one page should stop being the first thing anyone learns about you.

That is the heart of it. The wish to disappear and the wish to remain are not two different kinds of people. They are one person with different relationships to different pieces of their own biography. And those relationships shift: what is shameful today may in twenty years be simply a fact. What looks trivial today may later turn out to be the only thing left of someone close.

Why the system should not decide for the person

In that same judgment the Court of Justice did something important: it did not require proof of harm. The right to erasure is recognised "without it being necessary in order to find such a right that the inclusion of the information in question in that list causes prejudice to the data subject".

A person is not obliged to explain why they want to vanish from search. Not obliged to produce a certificate of suffering. It is enough that they want it — and from there the balancing of interests takes over, and as a general rule their rights outweigh both the search engine's commercial interest and the public's interest in the information. Except where there are particular reasons — the role played by the person in public life, for instance.

This construction — a presumption in favour of the person, not of the system — matters more than any technical detail. It means that by default the person decides.

The reverse side works the same way. If someone wants their correspondence, their voice, their way of thinking to outlive them, they are likewise not obliged to justify it to the architecture of a repository. They should not have to prove that their life is significant enough to be kept.

But this is where the uncomfortable part begins.

A choice cannot be given by halves

The right to choose exists only if both options are technically feasible. And here an honest conversation runs into a wall.

The EDPB, in its blockchain guidelines (version 2.0, adopted on 7 July 2026), puts it bluntly: technical impossibility cannot serve as a justification for failing to comply with the GDPR. And then comes a direct recommendation: as a general rule it is not advisable to store personal data on a blockchain, and where there is no technical solution guaranteeing erasure or anonymisation once the retention period expires, personal data should not be stored on the chain at all.

CNIL said the same thing more gently back in 2018: it is technically impossible to satisfy an erasure request once data have been written to a blockchain. The effect of erasure can be approached — by destroying a key or an off-chain commitment — but, save for certain cryptographic commitment schemes, "strictly speaking, this does not result in the data being erased, since the data still exist in the blockchain".

What follows from this in practice? A system that promises eternity and can forget nothing offers no choice. It offers one option and calls it freedom. A system that deletes everything on a schedule offers no choice either — it has simply made the other choice on your behalf.

A genuine choice requires an architecture in which the decision about the fate of particular data is taken before they are written, not afterwards. That is unwelcome news for engineers: you cannot put everything in one place and sort it out later. But it is the only arrangement in which both "forget me" and "keep me" remain real options rather than marketing promises.

What to take away

Erasure and preservation obey different physics. You can delete what sits under somebody's control; you can preserve what has passed beyond the control of any single participant. These two properties do not coexist in one repository — and so the decision has to be taken in advance, at the stage when the data have not yet been written anywhere.

The question, then, is not "which will win — oblivion or eternity". The question is whether the person managed to choose before the architecture chose for them.

There is no answer that works for everyone. Regulators did not look for one in the text of the law: a study prepared for the European Parliament back in 2019 concluded that the GDPR did not need amending — the regulation was written to be technology-neutral — and that what was needed was guidance. The guidance arrived: the EDPB issued its blockchain guidelines in April 2025 and the final version in July 2026. And it turned out to be not a compromise but a requirement: if an architecture allows data neither to be erased nor to be anonymised, then personal data have no place in it.

But one thing can be said firmly. Every time a system decides for a person — to forget them or to remember them — it takes away what both rights actually are. Not memory and not oblivion. Authorship of one's own story.