The European Data Protection Board today adopted the final version of its Guidelines 02/2025 on processing of personal data through blockchain technologies, closing a public consultation process that began after the board's earlier version 1.1 was published on April 8, 2025. Version 2.0 was formally adopted on July 7, 2026, and announced alongside two other new frameworks - guidelines on anonymisation and guidelines on web scraping in the context of generative AI - during the board's latest plenary session, held in Brussels.

The document runs 26 pages plus two annexes covering recommendations and a glossary of blockchain terminology. It lands at a moment when marketing technology providers, loyalty program operators, and identity verification vendors are increasingly experimenting with distributed ledger systems for customer data management.

What changed between versions

According to the version history table included in the guidelines, the EDPB adopted version 1.1 on April 8, 2025, before opening the document for public consultation. Version 2.0, adopted after that consultation closed, represents the board's response to stakeholder feedback. The main text does not itemise every change between the two versions, though the EDPB has separately published a track changes document alongside the final guidelines and a report on the consultation's outcome.

The structural core has not shifted: the document opens with an introduction to blockchain technology, describes how blockchains work, evaluates blockchain-based processing against GDPR principles, and closes with a section on data subject rights. Annex A compiles sixteen numbered recommendations, and Annex B supplies a twelve-term glossary defining concepts including consensus, disintermediation, forks, ledgers, nodes, proof of existence, proof of stake, proof of work, publicity, smart contracts, and wallet addresses.

Why blockchain and GDPR clash

The guidelines describe blockchain, in general terms, as a technology that implements a distributed and consistent database without centralised management, coordinated by an open or predefined set of participants operating under an agreed set of rules. That definition matters because it is broader than any single implementation. As the document notes, there is no unique implementation, and a blockchain used in a given processing activity could modify, extend, or restrict any of the technology's general properties, for example by restraining public access to the underlying data.

Four properties recur as blockchain's defining characteristics: distribution, meaning data is replicated across multiple participants; disintermediation, meaning validation does not require a trusted central party; consistency and tamper-resistance, meaning any unauthorized update can be detected; and transparency, meaning data access is available to participants. Each property creates friction with a different GDPR obligation. The guidelines state plainly that once a transaction is recorded on the chain, it cannot individually be altered or removed without being detected as an inconsistency in the chain.

That immutability collides directly with two GDPR provisions in particular: the right to erasure and the right to rectification. The guidelines are also candid about the scale of the problem, noting that blockchains do not allow for gradual adoption. Once introduced, they offer very limited possibilities to step back, since they do not have a default process to support the deletion of transactions.

The general rule: avoid on-chain storage

The guidelines' most quotable line of guidance is also its simplest. As a general rule, storing personal data on a blockchain should be avoided if this conflicts with data protection principles. Everything else in the document functions as elaboration on that single sentence: how to identify when personal data ends up on-chain, what to do when storage cannot be avoided, and how to document the reasoning behind whatever architecture a controller ultimately selects.

Personal data on a blockchain does not only mean the obvious content of a transaction. The guidelines draw a distinction between metadata, meaning the identifiers of transaction participants, and payload, meaning the substantive content of a transaction such as a cryptocurrency amount, a document link, or a smart contract call. Both categories can qualify as personal data. A wallet address or public key, according to the glossary, qualifies as personal data under Article 4 GDPR whenever it can be associated with an identified or identifiable natural person. Because these identifiers typically remain visible to all participants so that transactions can be verified, the guidelines treat them as a near-constant feature of blockchain processing rather than an edge case.

Three techniques for when on-chain storage cannot be avoided

When storing some form of personal data on-chain proves genuinely necessary, the guidelines lay out three principal mitigation techniques, each with distinct tradeoffs.

Encryption of personal data limits access to those holding the appropriate decryption key. The guidelines are unusually direct about this technique's limits over time: even state-of-the-art encryption perfectly implemented will be overtaken by time if the blockchain is retained indefinitely. Deleting the decryption key renders the encrypted payload unintelligible, though only until the algorithm is broken or the decryption technique advances sufficiently.

Hashing of personal data stores only a salted or keyed hash on-chain, while the unhashed original and its associated secret key or salt remain off-chain under confidential storage. The guidelines caution that unsalted or unkeyed hashes should generally not be considered sufficient to guarantee the necessary level of confidentiality for a public blockchain, and that the hash itself, along with any other identifiers, still qualifies as personal data subject to the full GDPR.

Cryptographic commitments allow a controller to store only a commitment on-chain, keeping the original data off-chain. If the commitment was computed using a scheme that perfectly hides the underlying value, then once the original data and its witness are deleted, the commitment persisting on the blockchain becomes functionally useless: it can neither be reversed to recover the original data nor recognized as related to any specific individual.

The guidelines add that whenever personal data must appear on-chain at all, it is better to store it in a form that functions primarily as a proof of existence, verified against data kept outside the blockchain under a high level of confidentiality, rather than as directly identifying content.

Governance determines who is responsible

A recurring theme across the document is that decentralisation does not dissolve accountability. The guidelines state that neither the decentralised governance model nor the selection of a particular technical infrastructure can be used as a reason not to comply with the GDPR. Determining who counts as a controller, and who counts as a processor, requires a factual assessment of each blockchain's specific governance mechanism, technical architecture, and the relationships among participants.

Permissioned blockchains, where an authority controls who may read, write, or create blocks, receive a clear institutional preference in the guidelines. The document states that this option offers a clearer allocation of responsibilities, which is a key element for the protection of data subjects, and that organisations should favour permissioned blockchains, exploring alternative governance models only where well-justified and documented reasons exist.

Public permissionless blockchains present a harder case. Nodes in these systems may or may not qualify as controllers, depending on whether they exercise decisive influence over the purposes and essential means of the processing. The guidelines describe scenarios in which nodes meaningfully decide to modify purposes or methods to pursue their own objectives, for instance through decisions on forking related to mining and validation. For these circumstances, the EDPB strongly encourages the establishment of a consortium or other legal entity among the nodes, which would then function as the controller for that processing.

Data protection principles under strain

Section 4.3 of the guidelines works through each Article 5 GDPR principle in turn, and blockchain's core features complicate nearly all of them.

Purpose limitation faces particular difficulty because blockchain's disintermediated nature means relationships between participants cannot always be governed by the contracts or legal instruments that would normally bind them to process data only for specified purposes. Data minimisation runs up against the append-only, ever-growing nature of blockchain ledgers, which the guidelines describe as exacerbated by the potential for unlimited persistence and manifold replication across copies. The principle of accuracy takes on an unusual cast in this context: because of the limited margins for intervention once data reaches the chain, the guidelines frame accuracy partly as a data minimisation question about the risk posed by out-of-date information that continues to exist on an immutable ledger.

Storage limitation receives the most direct treatment. Personal data must be erased once processing purposes have been achieved and any regulatory retention periods have expired. The guidelines acknowledge this is technically demanding at the individual level within a blockchain and may, absent design-stage planning, require deleting the entire chain. Where combined on-chain and off-chain architecture has been planned from the outset, erasing off-chain data can sometimes prevent future identification of a data subject even though the on-chain record persists. Whichever approach is chosen, the guidelines insist it must be effective, including, where necessary, deletion of copies held by other nodes or parties.

The guidelines also address a specific retention scenario relevant to regulated sectors. Under the Markets in Crypto-Assets Regulation and the Anti-Money Laundering Regulation, identification and transactional data must be retained for at least five years after the end of a business relationship. The Anti-Money Laundering Regulation becomes applicable from July 10, 2027, with Article 40 of the existing 2015 anti-money laundering directive remaining applicable in the meantime.

Data subject rights, addressed one by one

The final substantive section of the guidelines works through each data subject right and states, without exception, that these rights are technology neutral and apply regardless of whether blockchain is involved. Information obligations, along with the right of access and the right to data portability, must be satisfied before personal data is submitted to nodes for validation, and the guidelines consider these rights broadly compatible with blockchain's technical properties.

The right to erasure receives the guidelines' most cautious treatment. The EDPB observes that actual deletion is often technically impracticable once personal data sits directly on a blockchain, given the strong integrity guaranteed by cryptographic and consensus mechanisms. Where this is the case, controllers must instead ensure that any personal data on-chain can be effectively rendered anonymous upon an erasure request or an objection, which requires that on-chain transaction data not permit direct identification and that any off-chain data enabling indirect identification is erased. Where clear text, encrypted, or hashed personal data has already been recorded on a blockchain, granting rectification or erasure requests is described as technically demanding and often difficult, which is why the guidelines advise against registering personal data in any of those forms on-chain in the first instance.

Rectification sometimes admits a workaround specific to blockchain architecture: a subsequent transaction can announce the cancellation of an earlier one, even though the original transaction remains visible in the chain. Where rectification instead requires erasure of the underlying data, the same solutions used for deletion requests apply to the erroneous record.

Smart contracts introduce one further wrinkle under Article 22 GDPR. Their automated execution can constitute a form of automated decision-making, and where that is the case, controllers must guarantee the safeguards Article 22 requires: the possibility of human intervention and the data subject's right to contest the decision, regardless of whether the smart contract has already executed or what remains permanently registered on the chain.

The impact assessment requirement

Section 4.9 mandates that a Data Protection Impact Assessment be conducted whenever blockchain-based processing is likely to result in high risk to individual rights and freedoms, building on the criteria the Article 29 Working Party previously established. Risk in this context extends well past on-chain storage decisions. The guidelines list the communication of transactions and blocks among stakeholders, the temporary storage of transactions awaiting validation, the management of blocks in dead-end branches, the off-chain storage of data tied to on-chain identifiers or hashes, communication metadata, and cryptographic key and salt management as separate sources of risk that must all be assessed and managed.

The guidelines also flag a longer-horizon risk specific to cryptography: encryption systems have an undetermined but limited lifespan, and controllers assessing risk should weigh the computational effort required to break a given encryption scheme, including the potential future impact of cryptanalytically-relevant quantum computers, against the sensitivity and value of the data at stake. This assessment, the guidelines state, should occur during the design phase and be revisited periodically throughout the processing lifecycle, with contingency plans in place to enhance encryption or migrate to different technologies as needed.

For processing likely to result in high risk, the guidelines note that a DPIA may sometimes need to function as an ongoing process rather than a one-time exercise, particularly where the blockchain infrastructure sits outside the controller's direct control, operates on a permissionless basis, involves international transfers, or could be repurposed for additional processing activities that raise the overall risk profile.

Sixteen recommendations for organisations

Annex A distills the guidelines into sixteen numbered recommendations spanning architecture, information duties, minimisation, trust mechanisms, legal mandates, software vulnerability disclosure, governance, consent, data protection by design, retention duration, security evaluation, limiting the impact of algorithm failure, governance of software evolution, confidentiality, and data subject rights.

Recommendation 9, addressing consent, contains a notably firm instruction: consent should not be used for a processing which requires transactions with individuals if the blockchain architecture does not provide a way to delete the personal data regarding the parties in a transaction. Recommendation 11, on retention duration, states that where a technical solution guaranteeing the appropriate retention period does not exist, no personal data should be stored on the chain at all. Recommendation 2 recommends storing any additional personal data off-chain, beyond the identifiers already present in on-chain transaction metadata, specifically to mitigate data protection risk.

Context within a busy EDPB plenary

The blockchain guidelines were one of three deliverables the board adopted or advanced during the same session. The EDPB simultaneously opened a public consultation on new anonymisation guidelines, a 33-page framework replacing the Article 29 Working Party's 2014 three-criteria test with an updated version that adds a fourth element addressing inference-based re-identification. That anonymisation framework was likewise adopted on July 7, 2026, and remains open for consultation until October 30, 2026, unlike the blockchain guidelines, which have already completed that process. The board also advanced separate guidelines on web scraping in the context of generative AI, addressing the legal basis for large-scale automated data extraction during AI training.

An earlier version of these same blockchain guidelines, adopted as version 1.1 in April 2025, had already established the core requirements now being finalised: restrictions on on-chain personal data storage, the preference for permissioned architectures, and mandatory impact assessments before deployment. The intervening consultation gave stakeholders a chance to weigh in before the framework hardened into its present form. The guidelines also follow, by roughly four months, the EDPB's adoption of its first standardised Data Protection Impact Assessment template on March 10, 2026, a document intended to give organisations a common baseline for the risk documentation that blockchain processing frequently requires.

Practical relevance for marketing infrastructure

Distributed ledger technology has found a foothold in specific corners of advertising and marketing operations: supply chain transparency initiatives seeking to verify that ad spend reaches legitimate publishers, loyalty and rewards programs built on tokenized points systems, smart contracts automating affiliate or influencer payments, and identity or age verification systems exploring zero-knowledge architectures as a way to confirm eligibility without exposing underlying personal details.

Each of those use cases now sits within the scope of a finalised, rather than provisional, regulatory document. Organisations already running or planning blockchain-based marketing infrastructure face a settled framework against which their architecture can be measured. The guidelines' insistence that technical impossibility cannot excuse non-compliance removes one commonly cited justification for deferring remediation: a blockchain system that cannot support erasure or rectification is not exempted from those obligations merely because the underlying technology makes compliance difficult.

The document's repeated emphasis on documentation, covering the rationale for choosing blockchain over alternatives, the type of architecture selected, the technical and organisational measures applied, and the results of any impact assessment, suggests that regulatory scrutiny of blockchain deployments will likely focus as much on the paper trail behind an architectural decision as on the architecture itself.

Timeline

  • April 8, 2025: EDPB adopts Guidelines 02/2025 on processing of personal data through blockchain technologies, version 1.1, before public consultation.
  • March 10, 2026: EDPB adopts its first standardised Data Protection Impact Assessment template, relevant to the assessments the blockchain guidelines require.
  • July 7, 2026: EDPB formally adopts Guidelines 02/2025, version 2.0, the final version following public consultation. The board adopts the same day its new Guidelines 02/2026 on Anonymisation.
  • July 8, 2026: EDPB publishes its announcement covering the finalised blockchain guidelines, the new anonymisation guidelines, and guidelines on web scraping in the context of generative AI, together with a report on the blockchain consultation outcome and a track changes version of the document.
  • July 10, 2027: The Anti-Money Laundering Regulation, referenced in the guidelines' retention period discussion, becomes applicable.

Summary

Who: The European Data Protection Board, the body representing data protection authorities across the European Economic Area, chaired by Anu Talus.

What: Adoption of the final version 2.0 of Guidelines 02/2025 on processing of personal data through blockchain technologies, following public consultation on the earlier version 1.1. The guidelines set out how organisations, including those in marketing technology, must handle GDPR compliance when using blockchain, distributed ledger, or related decentralised systems, with particular emphasis on avoiding on-chain personal data storage, favouring permissioned architectures, and satisfying erasure and rectification rights by design.

When: The guidelines were adopted on July 7, 2026, with the announcement published on July 8, 2026. Version 1.1 had been adopted on April 8, 2025.

Where: The guidelines apply across the European Economic Area, and extraterritorially wherever organisations process the personal data of individuals in the EEA through blockchain systems, regardless of where blockchain nodes are physically located.

Why: Blockchain's immutability and decentralisation conflict with several core GDPR principles, including storage limitation, data minimisation, and the rights to erasure and rectification. The guidelines give organisations a finalised framework for assessing whether blockchain is necessary for a given processing activity and, where it is used, how to structure that use to remain compliant.