Skip to content

GDPR

Regulation: (EU) 2016/679 — General Data Protection Regulation

Status: Candidate case — constraint check passed, architecture mapped. Smart contract: GDPR Smart Contract — UTxO diagrams, guard table, lifecycle state machines.

The reframing

GDPR does not regulate a product lifecycle. It regulates how organisations handle personal data. The natural instinct is to ask "can we put personal data on a blockchain?" — the answer is no, and that is the wrong question.

The right question: can a blockchain prove that an organisation complied with GDPR, without storing any personal data on-chain?

The "items" in the process trie are not data subjects or personal records. They are compliance evidence: consent hashes, breach notification timestamps, rights-request response proofs, processing activity records, DPIA attestations. The chain never sees personal data. It sees hashes and timestamps that prove the controller did what the regulation requires, when the regulation requires it.

This is pure process mode. No sensors, no physical objects. The trust basis is protocol enforcement, not hardware attestation.

Constraint check

Constraint Assessment Notes
Data cadence Pass Consent events, breach notifications (72h), rights requests (1 month response), DPIAs — all event-driven or periodic. No real-time streaming.
Sequential access Pass Single controller per trie. Rights requests follow a relay: subject → controller → response. Breach: controller → SA.
Liveness Pass Up to €20M / 4% global turnover. 72h breach deadline. 1-month rights response. Strongest penalties of any regulation analysed.
Fee alignment Pass Controllers pay. Compliance cost (~€0.10-0.15 per record) is negligible vs fine exposure. A single breach fine dwarfs lifetime on-chain costs.
Identity delegation Pass Process mode. Data subjects exercise rights through digital channels. The signing function maps to the subject's authenticated request (web portal, app, email verification).

Obligation map

Element GDPR
Regulator Supervisory authorities (national DPAs), EDPB for cross-border consistency
Obligated parties Data controllers, data processors
Reporting obligations Processing records (Art 30), breach notifications (Art 33–34), DPIAs (Art 35), consent records (Art 7), rights-request responses (Art 12–22)
Verification bodies Supervisory authorities (investigative + corrective powers, Art 58), certification bodies (Art 42–43)
Beneficiaries Data subjects (citizens), society (trust in digital economy)
Penalties Tier 1: €10M / 2% turnover. Tier 2: €20M / 4% turnover (Art 83). Plus compensation (Art 82). Member States may also lay down additional penalties under Art 84.
Timeline In force since May 2018. No phase-in remaining.

Schema mapping

Schema role GDPR party Trie contents
Identity provider eIDAS / national ID / corporate registry Attested controller and processor keys
Regulator Supervisory authority (DPA) Controller standing, certification status, enforcement history
Operator Data controller Compliance records: consent hashes, breach notifications, rights responses, Art 30 records
User Data subject Exercises rights via signing function (process mode)

The processor (Art 4(8)) is a secondary operator — they maintain their own compliance trie, governed by the same smart contract, but their processing activity is constrained by the controller's documented instructions. The Art 28 processing agreement is a static leaf in both tries, cross-referencing each other.

Data classification

What goes on-chain is compliance evidence, not personal data.

Compliance record Type Access tier On-chain
Consent given/withdrawn Event-driven Subject + controller Hash of consent record + timestamp
Lawful basis per purpose Static Controller + SA Hash in processing-record leaf
Processing activity record (Art 30) Static + updates Controller + SA on request Leaf in controller's trie
Breach notification to SA Event-driven, 72h Controller + SA Commitment-then-submit
Breach notification to subjects Event-driven Controller + subjects Hash + timestamp
DPIA conducted Event-driven Controller + SA Attestation hash + timestamp
Rights request received Event-driven Subject + controller Commitment (proves receipt time)
Rights request fulfilled Event-driven, 1 month Subject + controller Submission clearing commitment
Processor agreement (Art 28) Static Controller + processor Hash of agreement
Certification (Art 42) Static, 3yr validity Public Token with expiry
Cross-border safeguard Static + event-driven Controller + SA Hash of SCC/BCR/adequacy ref
DPO designation Static Public Leaf in controller's trie

The bright line

No personal data — names, identifiers, health data, location, behavioural profiles — ever touches the chain. Not even encrypted. The chain stores hashes of compliance records. The actual records stay off-chain under the controller's custody.

Whether an on-chain hash constitutes personal data depends on its lifecycle phase:

Phase Pre-image exists? Hash is personal data? Lawful?
Active compliance Yes — controller holds linking data Yes — Breyer (C-582/14): parties with legal means to compel the controller can link the hash Yes — Art 6(1)(c): legal obligation to maintain compliance records
Retention under exception Yes — controller retains for legal claims Yes Yes — Art 17(3)(e): defence of legal claims
Post-erasure No — controller deleted pre-image No — unlinkable, anonymous under Recital 26 N/A — outside GDPR scope

During the active phase, the hash is personal data and its processing requires a legal basis — which exists (Art 6(1)(c)). After the controller deletes the off-chain pre-image in response to an erasure request, the on-chain hash becomes an opaque string that no party can link to a natural person. The "means reasonably likely to be used" test in Recital 26 is no longer satisfied — there is nothing to compel and no one to compel it from.

This is the architecture's built-in erasure mechanism: delete the off-chain pre-image, and the on-chain hash falls outside GDPR scope. Analogous to the "encryption with key destruction" approach that CNIL's blockchain guidance discusses as a valid erasure path — but simpler, because hashing requires no key management.

Trust model

Party A Party B Trust Risk Mitigation
Controller Data subject Low Controller claims consent existed, subject denies Immutable timestamped consent hash
Controller SA Medium Controller backdates breach notification Commitment proves on-chain ordering and submission slot once the controller commits
Controller Processor Medium Processor claims it followed instructions On-chain agreement hash, activity proofs
Data subject Controller Low Controller ignores rights request Commitment-then-submit proves response timeline
SA Controller Medium Controller presents selective compliance evidence Completeness via MPT — all records in trie
Controller Controller None Portability disputes — who had data when Transfer records with timestamps
Cert body Controller Medium Controller claims valid certification On-chain token with enforced expiry

Value / token identification

Token GDPR source Behaviour
Consent record Art 7 Created on consent, updated on withdrawal. Proves existence at any point.
Certification seal Art 42 Issued by accredited body, 3-year validity, renewable. Revocable.
Rights-request ticket Art 12–22 Created on request, must be resolved within deadline. Commitment pattern.
Breach receipt Art 33 Proves the submission slot and on-chain ordering of the notification. One-shot commitment.
Adequacy attestation Art 44–49 Reference to transfer safeguard. Static until revoked.

Protocol patterns

Breach notification (72 hours) — the flagship

This is where blockchain adds the most obvious value. Today controllers self-report breach timing. There is no neutral witness.

sequenceDiagram
    participant C as Controller
    participant CH as Chain
    participant SA as Supervisory Authority

    Note over C: Breach detected

    C->>CH: Create commitment in trie leaf<br/>(breach detected, slot recorded)

    Note over C: Prepare notification<br/>(nature, categories, numbers,<br/>consequences, measures)

    C->>CH: Submit notification hash<br/>(clears commitment)

    Note over CH: Chain proves:<br/>how many slots elapsed<br/>between commitment and notification

    SA->>CH: Query: was notification<br/>within 72h window?

    Note over SA: If commitment exists<br/>but no submission → non-compliance<br/>If no commitment and breach<br/>known → non-compliance

The commitment protocol turns part of the 72-hour rule from a self-reported claim into a verifiable on-chain fact. It proves when the controller committed and when it later submitted the notification hash. It does not, by itself, prove the exact off-chain moment when the controller first became aware of the breach. The absence of a timely commitment, when a breach becomes known through other channels, is still evidence of possible non-compliance.

Rights-request response (1 month)

sequenceDiagram
    participant DS as Data Subject
    participant SF as Signing Function
    participant C as Controller (Operator)
    participant CH as Chain

    DS->>SF: Submit rights request<br/>(access / rectification / erasure / etc.)
    SF->>DS: Signed request payload

    DS->>C: Send signed request

    C->>CH: Create commitment in trie leaf<br/>(request type, slot recorded)

    Note over C: Process request off-chain<br/>(retrieve data, prepare response)

    C->>CH: Submit response hash<br/>(clears commitment, within ~43,200 slots)

    Note over CH: Chain proves response<br/>was within 1-month window

    Note over DS: If commitment expires<br/>without submission → provable<br/>non-compliance

Complex requests can extend to 3 months (Art 12(3)). The commitment window reflects this — the controller creates a second commitment with the extended deadline and notifies the subject within the first month.

None → Given → Withdrawn

Each transition is a leaf update in the controller's trie. The chain proves:

  • When consent was given (slot timestamp)
  • For what purpose (hash of purpose description — not the purpose itself)
  • When it was withdrawn
  • That processing stopped after withdrawal (no further activity leaves referencing that consent hash after withdrawal slot)

The data subject never needs a wallet. They interact through the controller's portal. The signing function is the authenticated session.

Processing records (Art 30)

The controller maintains Art 30 records as leaves in their trie:

  • Purposes of processing
  • Categories of data subjects and personal data
  • Categories of recipients
  • Transfers to third countries
  • Envisaged erasure time limits
  • Security measures description

All stored as hashes. The SA queries the trie root via reference input. On audit, the controller produces the pre-images. If a hash matches, the record is proved authentic and timestamped.

Certification (Art 42)

graph LR
    CB[Certification Body] -->|mints| TOKEN[Certification Token<br/>3-year validity]
    TOKEN -->|referenced by| CTRL[Controller's Trie]
    TOKEN -->|expires| EXP[On-chain expiry check]
    CB -->|can revoke| BURN[Token burn]

The certification body is an authorised party in the regulation trie. The token minting policy reads the certification body's qualification from the regulation trie. The token carries an expiry slot. The controller references it in their compliance trie. Expired or revoked tokens cannot be referenced in new compliance submissions.

The GDPR–blockchain tension

The literature identifies fundamental conflicts between GDPR and blockchain. Every one of them concerns storing personal data on-chain. This architecture stores compliance evidence on-chain — hashes whose personal data status depends on the lifecycle phase (see the bright line above).

Tension Standard framing This architecture Residual risk
Immutability vs erasure (Art 17) Cannot delete on-chain personal data Delete the off-chain pre-image. The on-chain hash becomes unlinkable — anonymous under Recital 26. Analogous to encryption with key destruction. If the controller fails to delete all copies of the pre-image, the hash remains personal data. Operational discipline required.
Immutability vs rectification (Art 16) Cannot correct on-chain records Compliance records are appended (new leaf for correction). The history of corrections is itself evidence of accountability. The original hash persists alongside the correction. Acceptable for compliance evidence but the original inaccurate record's pre-image should be deleted.
Storage limitation (Art 5(1)(e)) On-chain data persists forever During active phase: legitimate retention under Art 6(1)(c). After retention period: delete pre-image, hash becomes anonymous, storage limitation satisfied. The controller must track retention periods and actually delete pre-images when they expire.
Data minimisation (Art 5(1)(c)) Full node replication Only hashes on-chain — one hash per compliance record. Minimal by design. Low. Hashes are fixed-size regardless of the underlying record's complexity.
Controller designation Who is the controller on a public chain? The data controller is the operator of their own trie. Identity provider, SA, and validators are not controllers of compliance data. During active phase the controller is clearly identifiable. Post-erasure the hash is anonymous and the question is moot.
Cross-border transfers (Art 44–49) Nodes worldwide = transfer to every jurisdiction During active phase: hashes are personal data but the controller is the only party holding the link, and the chain nodes don't process the link. Post-erasure: anonymous data, no transfer concern. The Breyer argument could theoretically be applied to chain nodes during the active phase, but the nodes have no practical means to obtain the pre-image.
Automated decision-making (Art 22) Smart contracts make autonomous decisions The smart contract validates format and timing. It does not make decisions about data subjects. Low. No profiling, no legal effects on individuals from the validator logic.
Legal basis No clean basis for on-chain personal data During active phase: Art 6(1)(c) — legal obligation to maintain compliance records. Post-erasure: no legal basis needed — data is anonymous. The legal obligation basis must be established per jurisdiction. Most GDPR obligations create sufficient basis.

The architecture addresses the tensions through two mechanisms:

  1. Design: personal data off-chain, compliance hashes on-chain — minimises the personal data footprint on-chain.
  2. Lifecycle: when the off-chain pre-image is deleted, the on-chain hash transitions from personal data (with lawful basis) to anonymous data (outside GDPR scope). Immutability is not a problem when there is nothing left to link.

This aligns with CNIL's 2018 blockchain guidance, which recommends off-chain storage with on-chain commitment schemes as the primary GDPR-compatible pattern, and explicitly discusses key/pre-image destruction as an erasure mechanism for blockchain data.

Formal invariants

Invariant Meaning Lean statement
Breach timeliness Notification within 72h of commitment breachSubmit leaf → leaf.submitSlot - leaf.commitSlot ≤ 72h_in_slots
Rights response timeliness Response within 1 month of commitment rightsResponse leaf → leaf.responseSlot - leaf.requestSlot ≤ 1month_in_slots
Consent monotonicity Withdrawn consent not re-given for same purpose without new event withdrawConsent leaf → ¬(restoreConsent leaf same_purpose)
Certification validity Expired tokens cannot be referenced referenceCert token → token.expirySlot > currentSlot
Commitment single-use Each commitment cleared exactly once submitResponse leaf → leaf.commitment = none
Processing record completeness All mandatory Art 30 fields present createProcessingRecord leaf → hasAllMandatoryFields leaf

Economics

Operation Frequency L1 cost At scale (1000 controllers)
Controller registration Once ~0.2 ADA Negligible
Consent record (leaf insert) Per consent event ~0.15 ADA Volume × unit cost
Breach commitment Per breach ~0.2 ADA Rare events
Breach notification submit Per breach ~0.15 ADA Rare events
Rights request commitment Per request ~0.15 ADA Moderate volume
Rights response submit Per response ~0.15 ADA Moderate volume
Art 30 record update Per processing change ~0.15 ADA Low frequency
Certification token mint Per certification ~0.3 ADA Every 3 years
Root anchor Per batch ~0.2 ADA Fixed, amortised
Verification (query) Per audit query Free (off-chain) Zero marginal cost

A medium-sized controller processing 1000 consent events/year, 10 rights requests/month, and rare breach notifications would spend ~€50-100/year in on-chain fees. A single GDPR fine (median ~€50,000 for SMEs, millions for large companies) makes this negligible.

The value proposition is not cost savings — it is proof. The controller can prove to any court, SA, or data subject when a compliance action was anchored on-chain, with neutral evidence of inclusion and slot ordering that neither party produced unilaterally.

Comparison with Battery Regulation

Dimension Battery Regulation GDPR
Mode Physical (sensor + secure element) Process (server-side signing functions)
Items in trie Batteries (physical products) Compliance records (abstract evidence)
Key hardware NFC + SE050 None — pure software
Data on-chain Product data hashes (SoH, composition) Compliance evidence hashes (consent, breach timing)
Primary value Provenance and tamper-proof readings Temporal proof and accountability
User interaction Tap a battery Submit a request through a portal
Relay pattern Manufacturer → transporter → consumer Subject → controller → SA
Flagship protocol SoH reading (commitment-then-submit) 72h breach notification (commitment-then-submit)
Scale ~5M batteries/year ~100K+ controllers, millions of events

Open questions

  1. SA adoption — SAs are public authorities with limited technical capacity. The regulator role requires maintaining a regulation trie and publishing a smart contract. Who builds and maintains this for them?

  2. Cross-border consistency — GDPR has 27+ national SAs with a consistency mechanism (EDPB). Does each SA maintain its own regulation trie, or is there a shared EU-level trie? The lead authority mechanism (Art 56) suggests a federated model.

  3. Processor chains — Art 28 allows sub-processors. The processor agreement chain (controller → processor → sub-processor) creates multi-level trie references. How deep can this go efficiently?

  4. Joint controllers — Art 26 allows joint controller arrangements. Two or more controllers sharing a trie, or cross-referencing separate tries? The arrangement must be transparent to data subjects.

  5. Hash-as-personal-data risk — the argument that on-chain hashes are not personal data holds only if the controller's off-chain data is properly segregated. If an attacker compromises both the chain data and the controller's database, hashes become linkable. This is a security boundary, not an architectural one, but it must be addressed.

  6. Consent withdrawal and processing cessation — the chain can prove when consent was withdrawn. But can it prove that processing stopped? This requires the absence of certain leaf updates after a given slot — provable by MPT completeness, but subtle.

Sources

Primary legislation

  • Regulation (EU) 2016/679 — full GDPR text (EUR-Lex consolidated version)
  • Art 4 — definitions (personal data, controller, processor, consent, pseudonymisation)
  • Art 5 — principles (lawfulness, purpose limitation, minimisation, accuracy, storage limitation, integrity, accountability)
  • Art 6 — lawful bases for processing
  • Art 7 — conditions for consent
  • Art 9 — special categories of personal data
  • Art 12 — modalities for exercising data subject rights (1-month / 3-month timeline)
  • Art 15 — right of access
  • Art 16 — right to rectification
  • Art 17 — right to erasure ("right to be forgotten")
  • Art 20 — right to data portability
  • Art 22 — automated individual decision-making, including profiling
  • Art 25 — data protection by design and by default
  • Art 26 — joint controllers
  • Art 28 — processor obligations and processing agreements
  • Art 30 — records of processing activities
  • Art 33 — notification of breach to supervisory authority (72 hours)
  • Art 34 — communication of breach to data subject
  • Art 35 — data protection impact assessment (DPIA)
  • Art 42 — certification
  • Art 44–49 — transfers to third countries (adequacy, SCCs, BCRs, derogations)
  • Art 56 — lead supervisory authority (cross-border)
  • Art 58 — supervisory authority powers
  • Art 82 — right to compensation
  • Art 83 — administrative fines (€10M/2% and €20M/4% tiers)
  • Art 84 — criminal penalties
  • Recital 26 — definition of anonymous data and the "means reasonably likely" test

CJEU case law

  • C-582/14 Breyer v Germany — dynamic IP addresses as personal data; broad interpretation of "identifiable" person even when identification requires third-party data
  • C-311/18 Schrems II — invalidation of EU-US Privacy Shield; requirement for transfer impact assessments alongside SCCs
  • C-362/14 Schrems I — invalidation of Safe Harbor; adequacy decisions can be challenged

Regulatory guidance

GDPR enforcement data

  • GDPR Enforcement Tracker — database of fines issued by EU supervisory authorities (used for median fine estimates in the economics section)