Recent developments in Brussels have fundamentally shifted the conversation around the EU Data Act. In its recently published Digital Omnibus Package, the European Commission indicate a clear intention to amend the Regulation and remove Article 36 entirely, the highly contested provision on “smart contracts for executing data sharing agreements.” For the blockchain community, and for EUCI in particular, this represents a significant policy victory.
From the earliest stages of legislative drafting, EUCI was the first advocacy organisation to identify how Article 36, as written, posed systemic risks to public blockchains and developers deploying the code. The original text blurred the line between private-sector data-processing automation in the context of connected devices and decentralised, permissionless smart contracts. By treating all “smart contracts” as if they were centrally controlled and subject to unilateral control and shutdown, the Regulation failed to differentiate between code deployed on a private data-sharing infrastructure and code executed on a globally distributed network with no single point of control.
EUCI repeatedly raised these concerns in consultations, bilateral meetings, and technical workshops. We consistently highlighted the danger of adopting a legal definition that would artificially force decentralised protocols into a regulatory model designed for enterprise software.
Our position was clear: Article 36, in its existing form, was incompatible with the architecture of public blockchains, introduced legal uncertainty for developers and enterprises, and risked global competitiveness by discouraging innovation in Europe.
The Commission’s recent move to revisit, and ultimately propose the deletion of, Article 36 is therefore not only a correction of course, but an acknowledgement that the original approach was flawed. It validates the concerns raised by EUCI and the broader decentralised tech community, demonstrating how early, precise, and technically grounded feedback can shape EU policy.
The above is further highlighted by the stated reasoning behind the proposed changes to the Data Act, namely that:
In order to mitigate legal uncertainties that could discourage innovative business models, it is necessary to address the substantial compliance ambiguities and burdens associated with the provisions on smart contracts executing data sharing agreements under Article 36 of Regulation (EU) 2023/2854. The absence of harmonised standards and clear definitions for key concepts such as ‘robustness’, ‘access control’, and ‘consistency with contractual terms’, combined with the requirement for a ‘safe termination or interruption mechanism’, potentially incompatible with decentralised or public blockchain architectures built on immutable ledgers, posed challenges to innovators from a cost and opportunity perspective.
Additionally, the ambiguity surrounding the performance of the conformity assessment under Article 36(2) of that Regulation risks imposing disproportionate burdens. The elimination of Article 36 of Regulation (EU) 2023/2854 would therefore promote the development and market introduction of new business models, foster innovation, and reduce barriers for emerging technologies.
Nevertheless, for the proposed changes to achieve their full intended outcome, the definition of “smart contracts” in Article 2 (39), along with all subsequent mentions of the term, should also be removed from the Data Act.
Proposed changes aside, as of 12 September 2025, the Data Act applies across the European Union. Positioned as a cornerstone of the EU’s broader Digital Strategy, the Regulation introduces common rules on accessing, sharing, and using data generated in the EU. While its scope spans industries reliant on connected devices and cloud infrastructure, its implications reach far beyond conventional tech.
In the remainder of this post, we break down the structure of the Data Act, contextualise its place in the EU’s digital lawmaking, and take a critical look at the now-infamous Article 36 and why its proposed removal is a necessary step for regulatory clarity and technological neutrality.
This analysis remains highly relevant, as the Data Act will continue to be applied in its current version until any edits to the text are adopted and become fully applicable.
Who Needs to Comply?
The EU Data Act applies to a wide range of entities involved in the generation, control, access, or use of data within the European Union. This includes manufacturers of connected (IoT) products and providers of related digital services, who must ensure users can access and share the data generated through their use.
It also applies to cloud and edge service providers and to users themselves who gain rights to access and port their data, as well as to data holders such as platforms or service providers that control access to data and must share it under fair, reasonable, and non-discriminatory terms.
More importantly, the Data Act imposes obligations on vendors of applications utilising smart contracts and deployers of smart contracts used in data-sharing agreements, who must comply with specific technical and legal requirements under Article 36.
Article 36 reads as follows: “The vendor of an application using smart contracts or, in the absence thereof, the person whose trade, business or profession involves the deployment of smart contracts for others in the context of executing an agreement or part of it, to make data available /…/”
The above allocation of responsibility makes the deletion of Article 36 even more important. By its very wording, Article 36 treats smart contracts as if they were centrally maintained software components with an identifiable operator who can be compelled to intervene. This assumption simply does not hold in the public, permissionless blockchain ecosystem.
In the startup-driven environment where most blockchain-based smart contract innovation takes place, vendors often cease to exist within a few years. This process is intentional and usually benefits the security of the underlying infrastructure, as projects pivot, merge, dissolve, or become fully decentralised. Requiring ongoing legal and technical duties from an entity that may no longer exist is not just impractical, but fundamentally incompatible with how open-source, permissionless systems evolve.
More critically, the fallback clause, placing responsibility on “the person whose business involves deploying smart contracts for others”, creates a misplaced liability burden for developers, who typically do not control the system once the smart contract is deployed, have no legal authority or technical ability to “terminate” or “interrupt” code on a decentralised network, and are not the contractual counterparties in the data-sharing arrangement.
This approach would have led to a regulatory landscape where developers bear obligations they cannot realistically fulfil, exposing them to unfair legal and financial risks. It would also discourage open-source development and innovation in Europe, as no rational developer would assume liability for systems they cannot control post-deployment.
By signalling its intention to repeal Article 36, the Commission recognises that smart contracts on public, permissionless blockchains cannot be regulated as if they were centrally managed enterprise software. Deletion is therefore not merely a technical correction—it is essential for legal certainty, innovation, and the continued competitiveness of Europe’s decentralised technology ecosystem.
How does the Data Act affect Blockchain Communities?
Article 36: Essential Smart Contracts Requirements
Data Act proposes essential requirements regarding smart contracts for executing data sharing agreements:
(a) robustness and access control, to ensure that the smart contract has been designed to offer access control mechanisms and a very high degree of robustness to avoid functional errors and to withstand manipulation by third parties;
(b) safe termination and interruption, to ensure that a mechanism exists to terminate the continued execution of transactions and that the smart contract includes internal functions which can reset or instruct the contract to stop or interrupt the operation, in particular to avoid future accidental executions;
(c) data archiving and continuity, to ensure, in circumstances in which a smart contract must be terminated or deactivated, there is a possibility to archive the transactional data, smart contract logic and code in order to keep the record of operations performed on the data in the past (auditability);
(d) access control, to ensure that a smart contract is protected through rigorous access control mechanisms at the governance and smart contract layers; and
(e) consistency, to ensure consistency with the terms of the data sharing agreement that the smart contract executes.
It should be noted that the essential requirements outlined in Article 36, such as safe termination, access control, and auditability, apply specifically to smart contracts used for executing data sharing agreements. However, the Data Act does not define what constitutes a “data sharing agreement,” leaving a degree of legal ambiguity. This lack of clarity raises questions about the scope of Article 36 and creates uncertainty for developers and deployers seeking to understand whether their smart contract use cases fall within the Regulation’s reach.
Termination as a Safeguard or Regulatory Backdoor?
A key point of tension in the discussion around Article 36 of the EU Data Act is the requirement for smart contracts to include mechanisms allowing for termination or interruption. At first glance, this may seem like a sensible safety measure. After all, in conventional software systems, the ability to stop or modify a process is essential for dealing with unexpected bugs, security vulnerabilities, or changing circumstances. However, in the context of smart contracts, especially those deployed on public, permissionless blockchains, the inclusion of such mechanisms introduces a deeper concern: the potential presence of a “backdoor.”
The distinction between a legitimate feature and a backdoor ultimately comes down to transparency, governance, and clarity of purpose. While safe termination under Article 36 looks like a legitimate feature, it is vaguely defined, lacks clear governance, and grants too much discretion to one party. As such, it ceases to function as a protective feature and instead becomes not only a vector of control but a potential single point of failure. And that’s exactly what decentralised systems are designed to avoid.
This is why Article 36, in its current form, has raised significant concern: by mandating termination or interruption features without clearly specifying how they should be implemented or under what conditions they may be triggered, the Data Act risks introducing new and unnecessary points of failure into systems that are otherwise designed to be autonomous and resilient.
Defining Smart Contracts in EU Law for the First Time: What Could Go Wrong?
Article 2 of the Data Act defines a smart contract as “a computer program used for the automated execution of an agreement or part thereof, using a sequence of electronic data records and ensuring their integrity and the accuracy of their chronological ordering.” While this definition attempts to capture the essence of how smart contracts function in a data-sharing context, it has been criticised as an oversimplification. Referring to a smart contract merely as a “computer program” fails to account for the broader technical, legal, and architectural complexities that distinguish smart contracts enabled by decentralised frameworks from traditional software.
Framing them as standard computer programs further risks misleading regulators and stakeholders into assuming they can be interrupted, modified, or terminated as easily as conventional software, when in fact they are often designed to be irreversible and self-executing.
Moreover, while the inclusion of a definition is a significant regulatory milestone, it also carries important spillover effects. EU laws, particularly those relating to the intersection between law, data and technology, may choose to reference this definition for consistency. Notably, the EDPB’s draft Guidelines 02/2025 on the processing of personal data through blockchain technologies already incorporate references to the Data Act and its terminology. If the concept of a smart contract is misunderstood or incompletely framed here, that mischaracterisation could cascade across the regulatory landscape, resulting in definitions that are technically inaccurate or legally misaligned with how smart contracts function in decentralised ecosystems.
This is why it’s crucial to either clarify that the definition does not apply to blockchain-based smart contracts or, ideally, remove it alongside all “smart contracts” mentions from the Data Act. While a narrower interpretation of the term would ensure that future regulations do not rely on this definition in contexts where such characteristics are essential, the removal of its mention from the regulation would cease all subsequent interpretation risks
Based on the European Commission’s own Explanatory Memorandum accompanying the Digital Omnibus proposal, the complete removal of the term is the logical approach, as the current lack of harmonised standards for smart contracts renders their legal definition, or even their mention in a legal text, unjustified.
When Should You Comply?
The Data Act entered into force on 11 January 2024 (20 days after publication in the Official Journal). Full compliance is required 20 months after entry into force, on 12th September 2025.
All in-scope entities, such as data holders, cloud service providers, vendors and those deploying smart contracts for data sharing agreements, are expected to ensure full compliance by that date, regardless of when their systems or agreements were originally established.
While enforcement may be phased in or vary slightly at the national level, there is no formal safe harbour for outdated systems, making early preparation and compliance planning essential.
With the regulation already applicable, the urgency lies in immediate action. Subjects to the Data Act shall understand their obligations, review existing systems and contracts, and seek professional legal and technical advice to ensure they are not in breach of the law.
Fines and Enforcement: The “Teeth” of the Data Act
Although the EU Data Act is directly applicable across the Union, Member States remain responsible for enforcement, which requires them to adopt national implementing laws. This means that the enforcement practice will vary state by state.
Germany has taken the lead in this regard, with the release of the initial draft of the Data Act Implementing Act (Data Act-Durchführungsgesetz or DA-DG). This draft introduces a detailed catalogue of fines, categorising violations as minor, moderate, or serious. Fines may range from €50,000 for minor breaches, up to €500,000 for serious infringements. In some cases, companies may face higher fines and periodic penalty payments. Up to €10 million may be imposed to compel compliance with enforcement orders issued by Germany’s Federal Network Agency (BNetzA).
Legal procedures and criteria for determining fines may vary between EU member states; however, if the German approach is to be taken into consideration, the fines may resemble those used under GDPR, taking into account both the severity of the offence and the offender’s financial capacity.
Further Reading
EUCI has published a position paper highlighting concerns about the Act’s treatment of smart contracts, proposing clearer terminology and distinct treatment for blockchain-related smart contracts to avoid regulatory overreach that could hinder blockchain innovation in the EU.
With this position paper, the EUCI urged co-legislators to differentiate between types of smart contracts and call for exclusions or clarifications to prevent imposing impractical compliance requirements on public blockchain smart contracts. Additionally, the EUCI warned that overly restrictive regulations could reduce entrepreneurial risk-taking and innovation in Web3, blockchain, and virtual world infrastructure projects. Read the paper here.