Blockchain technology is promoted as a tool for transparency, trust, and decentralization. Its defining feature is immutability: once data is written to a blockchain, it cannot be altered or removed. This paper argues that immutability makes blockchain fundamentally incompatible with the right to be forgotten, a privacy right recognized in the GDPR, the Indian DPDP Act, and similar data protection laws worldwide. A blockchain that stores personal data creates a permanent record that no individual can delete and no court can order removed. We examine the legal collision between immutability and erasure rights, identify real blockchain applications that already violate data protection law, and argue that blockchain is not a privacy technology. It is a permanence technology. Permanence and privacy are opposites.
What blockchain immutability means for the right to be forgotten. Legal collision between permanence and erasure. Real applications already in violation.
1. Introduction
The right to be forgotten is the right of an individual to request deletion of their personal data. It is enshrined in Article 17 of the GDPR, Section 8(6) of India’s Digital Personal Data Protection Act, and equivalent provisions in California, Brazil, Japan, and South Korea.
The right is not absolute. It must be balanced against other interests: freedom of expression, public interest, legal obligations. But the principle is clear. Individuals should have a mechanism to remove their data from systems that no longer need it, no longer have consent to hold it, or never had a lawful basis to collect it.
Blockchain technology makes this mechanism technically impossible.
A blockchain is an append-only ledger. Data written to the chain is permanent. There is no delete function. There is no administrator who can remove data. There is no court order that can alter a block once it is confirmed by consensus.
This is not a bug. It is the point. Blockchain’s value proposition is that no single party can alter the record. But if the record contains personal data, then no single party can remove it either. Not the individual. Not the data controller. Not a court. Not a regulator.
The technology that promises trust through transparency creates a permanent surveillance record from which there is no escape.
flowchart LR
A["Data written to blockchain"] --> B["Replicated to all nodes"]
B --> C["Immutable record"]
C --> D{"Erasure requested"}
D -->|"GDPR Article 17"| E["Cannot delete"]
D -->|"DPDP Act Section 8(6)"| F["Cannot delete"]
D -->|"Any court order"| G["Cannot delete"]
E --> H["Permanent violation"]
F --> H
G --> H2. How Personal Data Enters a Blockchain
Personal data can enter a blockchain in several ways.
2.1 Direct Storage
Some blockchains store data directly on-chain. Early implementations stored medical records, identity documents, and legal contracts as on-chain data. Each record is replicated to every node in the network. Each node holds a copy forever.
2.2 Hashed References
More common is the storage of hashed references to off-chain data. A hash of a document is stored on-chain. The document itself is stored elsewhere. The hash proves the document existed at a specific time. If the off-chain document is deleted, the hash remains. The hash may not be personal data itself, but it is a permanent fingerprint of data that was once considered personal.
2.3 Transaction Metadata
Every blockchain transaction contains metadata: sender and receiver addresses, timestamps, amounts, and sometimes arbitrary data fields. Addresses are pseudonymous but can be linked to real identities through exchange records, IP logs, or transaction pattern analysis. Once linked, the entire transaction history becomes a permanent record of an individual’s financial behavior.
2.4 Smart Contract State
Smart contracts store state on-chain. If a smart contract processes personal data, that data becomes part of the blockchain’s permanent state. A contract that records land titles, medical consent, or identity verification stores personal data that cannot be deleted without breaking the contract.
block-beta
columns 2
block:DIRECT["Direct Storage"]
columns 1
D1["Medical records on-chain"]
D2["Identity documents"]
D3["Legal contracts"]
end
block:HASHED["Hashed References"]
columns 1
H1["Document hash on-chain"]
H2["Off-chain document deleted"]
H3["Hash remains permanently"]
end
block:TX["Transaction Metadata"]
columns 1
T1["Sender / receiver addresses"]
T2["Timestamps and amounts"]
T3["Linked to real identities"]
end
block:SC["Smart Contract State"]
columns 1
S1["Land titles"]
S2["Medical consent"]
S3["Identity verification"]
end3. The Legal Collision
3.1 GDPR Article 17
Article 17 of the GDPR grants individuals the right to obtain deletion of personal data under specific conditions: the data is no longer necessary, consent is withdrawn, the data was unlawfully processed, or a legal obligation requires erasure.
A blockchain cannot comply with any of these conditions for data stored on-chain. The controller cannot delete the data. The processor cannot delete the data. No node operator can delete the data without breaking consensus.
3.2 The DPDP Act (India)
Section 8(6) of India’s Digital Personal Data Protection Act 2023 grants individuals the right to erasure of personal data. The Data Fiduciary (the entity that determines the purpose and means of processing) is obligated to erase data when consent is withdrawn or when the purpose is fulfilled.
A blockchain-based application operating in India cannot comply with this obligation for on-chain data. The Data Fiduciary can erase off-chain data. It cannot erase on-chain data. The obligation is impossible to fulfill.
3.3 The Regulatory Response
European data protection authorities have issued guidance acknowledging the tension between blockchain and the right to erasure. The French CNIL has suggested that data stored on-chain with encryption and key destruction may approximate erasure if the key is destroyed and the encrypted data becomes irrecoverable. But this is an approximation. The encrypted data still exists. It is still personal data under the law. It is merely inaccessible until encryption is broken.
The guidance is a political compromise, not a technical solution. It acknowledges that strict compliance is impossible and offers a mitigation that may or may not survive a court challenge.
block-beta
columns 3
block:GDPR["GDPR Article 17"]
columns 1
G1["Right to erasure"]
G2["Data no longer necessary"]
G3["Consent withdrawn"]
G4["Unlawful processing"]
end
block:DPDP["DPDP Act India"]
columns 1
D1["Section 8(6)"]
D2["Data Fiduciary obligation"]
D3["Erasure on consent withdrawal"]
D4["Purpose fulfilled"]
end
block:BLOCK["Blockchain Reality"]
columns 1
B1["No delete function"]
B2["No administrator"]
B3["No court can alter"]
B4["Impossible to comply"]
end
GDPR -->|"Cannot"| BLOCK
DPDP -->|"Cannot"| BLOCK4. Real Applications Already in Violation
Several blockchain applications already process personal data in ways that conflict with erasure rights.
4.1 Credential Verification
Blockchain-based credential systems store educational degrees, professional certifications, and identity documents on-chain or as on-chain hashes. A graduate who wants their degree removed from a public blockchain has no mechanism to do so. The university that issued the credential cannot remove it. The platform that hosts the verification cannot remove it.
4.2 Supply Chain Tracking
Blockchain supply chain systems record the movement of goods, often with metadata identifying producers, handlers, and locations. A farmer whose name and location are recorded on a supply chain blockchain cannot request deletion. The data is part of a permanent audit trail. The audit function and the privacy right are in direct conflict.
4.3 Land Registries
Several governments have piloted blockchain land registries. Property records include owner names, addresses, and transaction histories. A landowner who sells a property cannot have their name removed from the historical record. The blockchain preserves a permanent link between person and property.
4.4 Medical Records
Early blockchain healthcare projects stored patient data on-chain or as on-chain references. A patient who withdraws consent for data processing cannot have the on-chain record deleted. The immutable ledger defeats the consent withdrawal.
5. The Permanence Problem
The core technical problem is that blockchain’s value derives from immutability. If data can be deleted, the chain can be altered. If the chain can be altered, trust in the chain’s integrity collapses.
But privacy rights require the ability to delete. The two requirements are in direct opposition.
5.1 Proposed Solutions and Their Failures
Off-chain storage with on-chain hashes. Store personal data off-chain. Store only a hash on-chain. If the off-chain data is deleted, the hash remains but points to nothing.
This is insufficient. The hash is a fingerprint. It proves the data existed. In some interpretations, the hash itself is personal data because it is inextricably linked to the original data. Deleting the data but preserving the hash is incomplete erasure.
Encryption with key destruction. Encrypt data before storing on-chain. If erasure is requested, destroy the encryption key. The data becomes unreadable.
This is insufficient. Encrypted personal data is still personal data. The data subject has no guarantee that the key was actually destroyed or that the encryption will never be broken. Quantum computing threatens current encryption standards. Data that is encrypted today may be decrypted in 10 or 20 years.
Redactable blockchains. Some newer blockchain protocols allow blocks to be modified or removed through governance mechanisms.
This defeats the purpose. A blockchain that can be edited is not a blockchain in the sense that users and regulators have been promised. It is a database with extra steps. If immutability is sacrificed, what remains of the value proposition?
flowchart LR
subgraph "Mitigation Strategies"
A["Off-chain storage + on-chain hash"]
B["Encryption + key destruction"]
C["Redactable blockchain"]
end
subgraph "Why They Fail"
D["Hash is permanent fingerprint"]
E["Encrypted data is still personal data"]
F["Sacrifices immutability, loses purpose"]
end
A --> D
B --> E
C --> F6. The Irreconcilable Conflict
The conflict between blockchain immutability and the right to erasure is not a technical problem awaiting a solution. It is an irreconcilable conflict between two design goals that cannot coexist.
A system can be immutable. Or it can respect the right to be forgotten. It cannot do both.
The industry response has been to minimize the conflict. To suggest that off-chain storage, encryption, or zero-knowledge proofs can bridge the gap. These are mitigations. They are not solutions. They reduce the surface area of the conflict without resolving it.
A regulator who accepts encrypted on-chain data as equivalent to erased data is accepting a compromise. A court may not be so accommodating. A future court may rule that encrypted personal data on an immutable ledger is a violation of erasure rights, regardless of whether the key has been destroyed.
block-beta
columns 2
block:IMMUTABLE["Immutability"]
columns 1
I1["Append-only ledger"]
I2["No single party can alter"]
I3["Trust through permanence"]
end
block:ERASURE["Right to Erasure"]
columns 1
E1["Delete on request"]
E2["Withdraw consent"]
E3["Privacy through deletion"]
end
IMMUTABLE -->|"Cannot coexist"| CONFLICT["IRRECONCILABLE"]
ERASURE -->|"Cannot coexist"| CONFLICT7. What This Means for Builders
For builders considering blockchain for applications that handle personal data, the implications are clear.
Do not store personal data on a blockchain. Not directly. Not encrypted. Not hashed. The legal risk is unquantifiable because the relevant case law does not yet exist. But the direction of regulation is clear. Privacy rights are expanding. Immutability is not a defense against erasure obligations.
If you must use blockchain, isolate personal data entirely. Store personal data in a traditional database with full deletion capability. Use blockchain only for integrity proofs that contain no link to personal data. Accept that this limits what the blockchain can do.
Assume that current mitigations will fail. Encryption with key destruction. Off-chain storage with on-chain hashes. These are temporary compromises, not permanent solutions. Build with the assumption that a future court will find them insufficient.
8. Conclusion
Blockchain is not a privacy technology. It is a permanence technology.
Permanence is valuable for some applications. A public record of land titles. An immutable audit trail for financial transactions. A tamper-proof certificate of authenticity.
But permanence is toxic for personal data. The right to be forgotten exists because individuals should not be permanently bound to data about their past. People change. Consent is withdrawn. Data becomes irrelevant. The law recognizes that privacy includes the right to delete.
Blockchain denies that right structurally. Not through malice. Not through oversight. Through design. The thing that makes blockchain valuable is the thing that makes it incompatible with privacy.
This conflict will not be resolved by better encryption, smarter contracts, or more sophisticated off-chain protocols. It will be resolved by law. And the law will not favor immutability over individual rights.
Build accordingly.
References
- European Union. General Data Protection Regulation (GDPR), Article 17: Right to Erasure. 2018.
- Government of India. Digital Personal Data Protection Act, Section 8(6). 2023.
- CNIL. Blockchain and the GDPR: Solutions for a Responsible Use. 2018.
- European Parliamentary Research Service. Blockchain and the General Data Protection Regulation. 2019.
- TELOSIS Research. Privacy-Preserving Architectures for Modern Infrastructure. TELOSIS-RP-2026-005, 2026.
Citation
TELOSIS Research. (2026). The Right to Be Forgotten Is Impossible on a Blockchain. TELOSIS-RP-2026-011.