The Complex Relationship Between GDPR and Blockchain

Updated: October 2026

Blockchain and the GDPR pull in opposite directions. A blockchain is built so that recorded data cannot be changed without detection. The GDPR gives people the right to have their data erased and corrected, and requires organisations to keep data only as long as they need it.

For years, projects had to work out the answer themselves. On 7 July 2026, the European Data Protection Board (EDPB) adopted the final version of its Guidelines 02/2025 on processing personal data through blockchain technologies. This article sets out what they say, where they leave room for interpretation, and what a project should have in place.

Key Takeaways

• The EDPB’s final guidelines (version 2.0, adopted 7 July 2026) say that decentralisation and technical constraints cannot justify non-compliance with the GDPR. Technical impossibility “cannot be invoked” to excuse a breach.

• Public keys, wallet addresses and other on-chain metadata can be personal data. Encrypted data and hashes stay personal data too.

• The EDPB advises against storing personal data on a blockchain, and recommends keeping additional personal data off-chain. A project must document why a blockchain is necessary and why a less intrusive technology would not suffice. It should favour permissioned blockchains.

• Erasure has to be designed in from the start. The EDPB’s approach is to make sure on-chain data can be rendered anonymous by deleting the off-chain data that links it to a person.

The EDPB Has Finalised Its Blockchain Guidelines

The EDPB published a first version of the guidelines on 8 April 2025 for public consultation. It adopted the final version, version 2.0, on 7 July 2026, together with a report on the consultation outcome.

The guidelines do not treat blockchain as a processing activity in itself. They call it “only a technology, as cloud computing or peer-to-peer networks” and examine how its technical features interact with the data protection principles. Each use case has to be assessed on its own facts.

The EDPB’s position on the central tension is firm. It says that once personal data is stored directly on a blockchain, it will, in most cases, stay there with no practical possibility of deletion or modification, and that “technical impossibility cannot be invoked to justify non-compliance with GDPR requirements.”

Personal Data on a Blockchain Goes Beyond the Transaction Payload

A transaction records metadata and a payload. Either can contain personal data.

Public keys and wallet addresses can be personal data

Each participant in a transaction is usually identified by a public key, a string of characters that looks random. The EDPB says that if the key can be used to identify an individual by means reasonably likely to be used, for example after a data breach, it is personal data. Replacing identifiers with cryptographic alternatives does not settle the question, because the replacement data may still be personal data.

The guidelines also name other on-chain data that can identify a person: transaction identifiers, event logs, receipts, state transitions and smart contract storage. IP addresses collected when a user interacts with a wallet or application are personal data even though they are not stored on the chain.

Encryption and hashing do not take data outside the GDPR

The EDPB is explicit that encrypted personal data is still personal data. It adds that even strong, current encryption will be overtaken by time if the blockchain is kept indefinitely.

The same applies to hashes. A salted or keyed hash of personal data is still personal data, and the guidelines say unsalted or unkeyed hashes generally should not be considered enough to protect personal data on a public blockchain.

The EDPB lists three ways to avoid putting directly identifying data on the chain: encryption, a salted or keyed hash, and a cryptographic commitment. Storing personal data in plain text is “strongly discouraged.” Where personal data does need to go on-chain, the guidelines say it is better to store only a proof of existence, such as a pointer, a commitment or a keyed hash, and to keep the data used to verify it outside the blockchain.

Roles Depend on the Facts, Not on Decentralisation

A blockchain involves many actors, and the guidelines state that neither this fact nor the choice of infrastructure is a reason not to comply. Assess roles under the GDPR for each processing activity by looking at the nature of the service, the governance mechanism, the technical features, and the relationships between the actors.

Two points follow from that assessment:

• In a permissioned blockchain, an authority decides who can take part, which gives a clearer allocation of responsibility. The EDPB says organisations “should favour permissioned blockchains” and should only explore other models if well-justified and documented reasons prevent it.

• In a public permissionless blockchain, nodes may be controllers or joint controllers where they exercise decisive influence over the purposes and essential means of processing. That can happen, for example, through decisions on forking. Nodes with only limited decision-making power that simply validate transactions against technical criteria might not be controllers. Where nodes do act as controllers, the EDPB strongly encourages them to set up a consortium or another legal entity, which would then be the controller.

A Blockchain Needs a Documented Reason to Exist

Before choosing a blockchain, the EDPB expects a controller to answer four questions and record the answers:

• Will the data on the blockchain contain personal data?

• If so, why is a blockchain necessary and proportionate, and what were the alternatives?

• What type of blockchain is needed? Would a private or permissioned chain, or a zero-knowledge architecture, be enough?

• What technical and organisational measures apply, including whether personal data is held on or off the chain and which privacy-enhancing technologies are used?

The guidelines add that where well-justified reasons prevent a permissioned model, organisations should also consider whether a blockchain is appropriate at all. If a blockchain cannot provide the necessary level of security, controllers should not use one.

Erasure, Rectification and Objection Must Be Built in From the Start

The EDPB states that the rights to erasure, rectification and objection “must be complied with by design.” Neither a technical choice nor the data subject’s consent can restrict these rights.

Keep additional personal data off-chain

The EDPB recommends storing any personal data beyond the identifiers already present in transaction metadata off-chain. Deleting off-chain data is the main route to compliance with an erasure request.

Erasure works if on-chain data can be rendered anonymous

Where actual deletion is technically impracticable, the EDPB says controllers should make sure data on the chain can be effectively rendered anonymous after an erasure request or an objection. That requires two things: the on-chain data must not allow direct identification, and any off-chain data that would allow indirect identification must be erased. It must also prevent linking existing and future transactions involving the same person.

The guidelines acknowledge the difficulty. They recommend using other tools if a blockchain’s strong integrity is not needed. For rectification, a later transaction that cancels an earlier one can be enough in some cases, even though the first transaction stays in the chain.

The EDPB also adopted draft guidelines on anonymisation in July 2026, which take account of the Court of Justice ruling in EDPS v SRB. They are open for consultation until 30 October 2026, so the test for anonymous data may be refined further.

Privacy-Enhancing Technologies Help but Do Not Settle Compliance

Zero-knowledge proofs and other advanced cryptographic protocols can reduce risk, the guidelines say. They add that these measures should be carefully tested and validated and accompanied by other technical and organisational measures. No single technique makes a blockchain compliant.

Legal Basis and Consent Need Particular Care

No single legal basis covers blockchain processing. Each processing activity needs a basis under Article 6 GDPR and, for special category data, an exception under Article 9(2). A blockchain can also be used where processing rests on legitimate interests under Article 6(1)(f), subject to the necessity and balancing tests.

The guidelines caution against using consent where the architecture cannot delete personal data. Consent has to be freely given, and a data subject must be able to withdraw it without detriment. If consent is withdrawn, the data must be deleted or rendered anonymous. The EDPB’s recommendation is that consent should not be used for processing that requires transactions with individuals if the blockchain does not provide a way to delete the personal data of the parties.

Restrictions on data subject rights are possible only within Article 23 GDPR. The EDPB gives anti-money-laundering requirements and certain asset registers as examples, and says any restriction must be proportionate and strictly defined in law.

The Life of the Blockchain Is Not a Retention Period

The EDPB rejects the idea that data can stay on a chain because the chain is permanent. Retention periods are set by purpose, and data should be deleted or anonymised when processing ends. When retention does not need to match the chain’s lifetime, personal data should not be written to it unless identification can be effectively prevented.

Some laws set minimum periods. The guidelines point to the Markets in Crypto-Assets Regulation (EU) 2023/1114 and the Anti-Money Laundering Regulation (EU) 2024/1624, which require keeping identification and transaction data for at least five years after the end of the business relationship. The AMLR applies from 10 July 2027, and the current Anti-Money Laundering Directive remains applicable until then.

Nodes Outside the EEA Raise Transfer Issues

Blockchains often have nodes outside the EU, and controllers may not choose or vet them. The guidelines state that any transfer of personal data outside the EEA must comply with GDPR Chapter V. They give the example of building standard contractual clauses into the contract a node signs before it is accepted. Transfers should be considered from the design stage.

Smart Contracts Can Trigger the Automated Decision Rules

Running a smart contract may amount to automated decision-making. Where it falls under Article 22 GDPR, the controller must ensure the safeguards in that provision apply. These include human intervention and the right to contest the decision, even if the smart contract has already run and whatever is registered on the blockchain.

A Data Protection Impact Assessment Is Mandatory for High-Risk Processing

Where processing is likely to result in a high risk to individuals, a DPIA is mandatory. The guidelines say the DPIA should include an evaluation of the blockchain choice. It should cover the blockchain model, roles and responsibilities, on-chain and off-chain processing, smart contracts, how data subject rights will be exercised, international transfers, and whether a less privacy-invasive option could achieve the same goal.

For blockchains outside the controller’s control, permissionless chains, or those with international transfers, the DPIA may need to be an ongoing process.

Security Needs to Cover the Whole Ecosystem

The EDPB recommends evaluating safeguards against misuse by a group of participants, such as 51% attacks, and against compromised wallets or rogue employees. Controllers should have an emergency plan to update algorithms if a cryptographic vulnerability emerges, and the guidelines say they must assess the lifespan of the cryptography, including the potential impact of quantum computing. Breach notification procedures should be in place.

Fines Under the GDPR Follow the Same Tiers

The GDPR has no separate penalty regime for blockchain. Under Article 83, infringements of the basic processing principles, the legal bases and data subject rights can attract fines of up to €20 million or 4% of worldwide annual turnover. Infringements of obligations such as data protection by design and security fall in a lower tier, up to €10 million or 2%.

Projects Can Take Practical Steps Now

• Map every category of data a project puts on-chain and off-chain, including wallet addresses, logs and smart contract storage.

• Write down why a blockchain is necessary and what alternatives were considered.

• Keep personal data off-chain wherever possible, and test that deleting the off-chain data makes the on-chain record anonymous.

• Decide who is controller, joint controller or processor, and put the governance and contracts in place. Consider a consortium where nodes jointly decide the rules.

• Complete a DPIA before launch and review it as the project changes.

• Set retention periods by purpose and check whether MiCA or AML rules apply.

• Identify where nodes sit and what transfer mechanism covers them.

Conclusion

The EDPB’s final guidelines remove much of the uncertainty about how the GDPR applies to blockchain. Their position is that the technology does not change the obligations. Controllers must justify using a blockchain, keep personal data off the chain where they can, and design for erasure and rectification from the start.

For most projects, the practical question is whether the blockchain needs to hold personal data at all. Where it does not, many GDPR conflicts disappear. Where it does, the guidelines set out what regulators will expect to see documented.

If you are planning a blockchain project that touches personal data, our data protection consultants can help you assess it against the EDPB’s guidelines and prepare the DPIA.

Frequently Asked Questions

Does the GDPR apply to blockchain?

Yes. The EDPB’s guidelines state that blockchain is a technology, not an exemption, and that its decentralised structure is not a reason to avoid GDPR compliance. The GDPR applies whenever personal data is processed through a blockchain.

Are wallet addresses and public keys personal data?

They can be. The EDPB says public keys qualify as personal data if individuals can be identified from them by means reasonably likely to be used. On-chain metadata such as wallet addresses and event logs may also be personal data when it enables direct or indirect identification.

Is hashed or encrypted data still personal data?

Yes, according to the EDPB. Encrypted personal data and salted or keyed hashes remain personal data. Unsalted or unkeyed hashes generally do not protect personal data stored on a public blockchain.

How can a blockchain comply with the right to erasure?

The EDPB’s approach is to keep personal data off the chain and ensure on-chain data can be rendered anonymous when an erasure request arrives. That means deleting the off-chain data that links the record to a person and preventing any other linking. The guidelines recommend other tools if blockchain’s strong integrity is not needed.

Who is the controller on a public blockchain?

It depends on the facts. Nodes that exercise decisive influence over the purposes and essential means of processing may be controllers or joint controllers, while nodes with limited decision-making power might not be. The EDPB strongly encourages nodes in that position to form a consortium or another legal entity that would act as controller.

Do blockchain projects need a DPIA?

A DPIA is mandatory where processing is likely to result in a high risk to individuals. The EDPB says the evaluation of the blockchain choice should be part of it, and that the DPIA may need to be ongoing for permissionless chains or those with international transfers.

Disclaimer: This blog post is intended solely for informational purposes. It does not offer legal advice or opinions. This article is not a guide for resolving legal issues or managing litigation on your own. It should not be considered a replacement for professional legal counsel and does not provide legal advice for any specific situation or employer.