DeFi regulation & security
Data Act Article 36 and smart contracts
Article 36 addresses smart contracts used to execute agreements to make data available. The Digital Omnibus proposes deleting it; the legislative procedure checked on 6 September 2026 has not reached adoption.
- Sources checked
- Published
- Prepared by
- DeFi Security Alliance
Scope: This guide covers the specified EU rule or assessment program and technical preparation. It does not determine a particular business's legal status or replace national filing instructions.
Identify the data-sharing agreement and responsible party
Data Act Article 36 concerns essential requirements for smart contracts executing agreements to make data available. It identifies the vendor of the application or, in the absence of a vendor, the person professionally deploying the smart contract for others. Start with those elements before evaluating a particular implementation.
The presence of Solidity code, automated execution or a DeFi interface does not establish this scope on its own. Identify the agreement, the data made available, the parties' rights and the role performed by the vendor or deployer. The rule should not be summarized as a universal obligation to install a shutdown key in every blockchain protocol.
The regulation's general application date is 12 September 2025 under Article 50, with separate timing rules for specified provisions. Use the provision relevant to the actual product rather than applying the connected-product date to every part of the act.
Keep the current text separate from the deletion proposal
The Commission's Digital Omnibus proposal, COM(2025) 837, proposes deleting Article 36 in Article 1(17). The European Parliament's procedure record checked on says the procedure is awaiting a committee decision. The checked sources therefore do not establish an adopted repeal.
| Document | Status checked | How to use it |
|---|---|---|
| Regulation 2023/2854 | Act in force; Article 36 present in the checked text. | Assess the applicable rule and its stated scope. |
| COM(2025) 837 | Commission proposal to amend the framework. | Track the proposed deletion as a possible future change. |
| Procedure 2025/0360(COD) | Awaiting committee decision in the retrieved record. | Check progress before revising the legal-status conclusion. |
Do not retire a required control merely because a proposal would remove its legal basis. Conversely, a technical control may remain useful for contractual or security reasons even if the law changes. Record each reason separately so that a future legislative update can be assessed without guessing why the control exists.
Map the agreement to the implementation
Article 36(1) covers robustness, access control, safe termination/interruption, archiving/continuity and consistency with the agreement. Paragraphs 2-3 address conformity assessment and the EU declaration of conformity by the specified responsible party. That declaration is not equivalent to an unrelated code-audit badge.
| Requirement area | Agreement question | Suggested evidence | Failure to test |
|---|---|---|---|
| Robustness | Which data actions and outcomes are agreed? | Specifications, threat model and test results for those actions. | Invalid input, unexpected state or third-party manipulation. |
| Access control | Who may access data and change permissions? | Governance and contract-role map with authorization tests. | Unauthorized role change or privilege surviving revocation. |
| Safe interruption | Who can stop execution and under what conditions? | Defined interruption behavior, decision rights and recovery tests. | Accidental future execution or unsafe handling of in-flight work. |
| Archiving and continuity | Which historical operations must remain auditable? | Versioned logic/code, transaction data and retrieval procedure. | Termination leaves records inaccessible or impossible to interpret. |
| Consistency | Does execution reflect the actual agreement? | Mapping from agreement terms to behavior and test assertions. | The interface describes one entitlement while code enforces another. |
| Conformity responsibility | Who performs the assessment and issues the declaration? | Scope, assessment record, identified responsible party and declaration. | An assessment covers a different version or omits a required area. |
This worksheet is an editorial review aid. It does not prescribe a mandatory testing standard, certify conformity or decide whether the article applies to a particular agreement.
Define the technical engagement precisely
Pharos Production describes smart contract security audit and remediation work covering code vulnerabilities, access controls and verification of fixes. Those activities can support a technical evidence file. A commercial audit engagement does not by itself establish Article 36 applicability, issue the responsible party's declaration or demonstrate an accredited certification status.
Give the reviewer the agreement, versioned source, deployment details, role map and expected interruption behavior. Ask the report to identify what was reviewed, how findings were tested and which dependencies remain outside scope. When the agreement or implementation changes, review the affected assertions and the associated evidence.
For a different policy discussion, see the French certification research. For proposals concerning DeFi more broadly, see the MiCA review. These are separate processes with different documents and legal statuses.
Continue your research
Sources and further reading
Legislation and regulator publications establish the legal basis. Technical resources explain implementation. Source checks cover the passages cited in this guide.
- Data Act: Regulation (EU) 2023/2854European Union ·
- Digital Omnibus: COM(2025) 837 finalEuropean Commission ·
- Digital Omnibus: procedure 2025/0360(COD)European Parliament ·
- Smart contract security audits and gas optimizationPharos Production ·