EU Data Act Smart Contracts for Data Sharing FAQ

Article 36 applies when a vendor of an application using smart contracts, or in the absence of a vendor a professional deployer acting for others, uses a smart contract to execute an agreement or part of an agreement to make data available.

That scope is narrower than the phrase "smart contract" is often used in product teams. A pricing rule, API permission check, workflow automation, or internal data job should not be labelled Article 36 work unless it is the smart-contract mechanism executing data-sharing agreement logic for making data available.

Article 36 lists five requirements. The smart contract must support robustness and access control, safe termination and interruption, data archiving and continuity, access control at governance and smart-contract layers, and consistency with the terms of the data sharing agreement it executes.

A practical control file should translate those requirements into testable evidence: security review results, manipulation-resistance tests, privileged-action controls, stop or reset procedures, archived transaction records, archived logic and code, and a comparison between coded behavior and the signed data sharing terms.

The vendor of the smart contract, or in the absence of a vendor the professional deployer acting for others, must perform a conformity assessment against the Article 36 requirements. Once the requirements are fulfilled, that actor must issue an EU declaration of conformity.

The declaration is not a shortcut around engineering evidence. By drawing it up, the vendor or professional deployer takes responsibility for compliance with the Article 36 essential requirements, so the declaration should be backed by versioned deployment records, tests, access-control evidence, stop-function evidence, archive evidence, and agreement-consistency review.

No. The Commission FAQ states that Article 36 does not affect national contract law and that the Data Act regulates the computer programs used to execute agreements, not the agreements as such.

Teams should therefore maintain two linked records: the data sharing agreement that sets the parties' rights and obligations, and the smart-contract evidence showing that the automated execution is reliable, controllable, auditable, and consistent with those terms. Do not claim that compliant code alone creates, replaces, validates, or overrides the contract.

Robustness covers both reliability and resistance to manipulation. Before deployment, the team should test error handling, boundary conditions, manipulation attempts, dependency failures, and upgrade or migration paths that could change execution outcomes.

Access control needs coverage at two levels. Governance-layer controls should restrict who can deploy, pause, upgrade, terminate, or change parameters. Smart-contract-layer controls should restrict who can trigger functions, submit data, approve transactions, retrieve records, or operate privileged methods.

The smart contract should include internal functions that can reset, stop, or interrupt operation, especially to avoid accidental future executions. The stop mechanism should be tested before production use and documented so authorized personnel know when and how it can be used.

Recital 104 also says the requirement to interrupt and terminate smart contracts implies mutual consent by the parties to the data sharing agreement. Do not design a one-sided kill switch that conflicts with the agreement terms or later claim that a stop function changes the contract by itself.

If the smart contract is terminated or deactivated, Article 36 expects a possibility to archive the transactional data, smart-contract logic, and code so past operations on data remain auditable. The archive should preserve the relevant version, execution history, stop event, consent record, and agreement link.

A smart contract can automate execution of a data sharing agreement, but it does not replace the agreement. The agreement should still state the parties, data, use conditions, access limits, compensation if relevant, trade-secret measures, remedies, and termination terms.

The Commission has published non-binding model contractual terms for Data Act data access and use. Those terms are voluntary implementation tools; they can help structure the agreement that the smart contract executes, but using them does not by itself prove Article 36 conformity.

Article 36 provides two routes to a presumption of conformity. The vendor or covered deployer must assess conformity and issue an EU declaration when the essential requirements are fulfilled, even without a standard or common specification. A smart contract that meets harmonised standards cited in the Official Journal is presumed to conform to the covered Article 36 requirements. If the standards route is unavailable under Article 36 conditions, the Commission may adopt common specifications by implementing act, and meeting those specifications can also create a presumption of conformity for the covered requirements.

Data Act standardisation materials for a European Trusted Data Framework, trusted data transactions, and Article 33 do not by themselves establish Article 36 conformity. Before relying on a presumption, verify the exact Official Journal reference or adopted common specification and map it to the smart-contract requirement it covers.

Keep an Article 36 evidence pack for each smart-contract deployment used to execute a data sharing agreement. The pack should let a reviewer connect the legal agreement, deployed code, controls, tests, conformity assessment, declaration, and later termination or archiving event without reconstructing the decision from tickets.

At minimum, the pack should include the agreement terms being executed, the responsible vendor or professional deployer, code and logic version, deployment address or environment, access-control design, robustness tests, stop and reset tests, archive procedure, conformity assessment, EU declaration of conformity, and review notes for any standard or common-specification updates.

Article 36 does not validate the legal agreement, replace national contract law, certify a blockchain protocol, require a particular ledger technology, or make all automated data-sharing controls smart contracts. It applies essential requirements to smart contracts used by the relevant vendor or professional deployer to execute a data sharing agreement or part of one.

Also avoid using Article 36 to bypass the Data Act rules on data access, trade secrets, unfair contract terms, or technical protection measures. A smart contract can help enforce agreed terms or prevent unauthorized access, but Data Act technical measures must not be used to discriminate between recipients or hinder user and third-party rights.