The Buyer Asked for an Article 36 Smart-Contract Declaration. What Must It Cover?
Connect an EU Data Act smart-contract request to the agreement, deployer, termination mechanism, archived evidence and declaration instead of treating a code audit as the whole answer.
Signals to watch
- A data-sharing project names Article 36 and asks who will issue an EU declaration of conformity
- A deployed smart contract executes part of an agreement but its termination, interruption or archival evidence has no owner
- A buyer asks for a code audit while the access-control and governance controls remain outside the stated scope
An Article 36 request is not answered by attaching a generic blockchain audit. Under the EU Data Act, the first questions are which agreement the smart contract executes, who vendors or professionally deploys it for another party, and where the four essential requirement areas are evidenced. The responsible party must also perform a conformity assessment and issue an EU declaration of conformity.
That distinction matters to a smart-contract assurance or data-sharing implementation provider’s sales director watching authorised industrial data-space, blockchain engineering and procurement Telegram groups. “Need Article 36 certificate before pilot” may be worth reviewing, but it does not yet identify the application, agreement, deployer or missing control. A one-day delay can still lose the design review where the buyer assigns those owners.
Definition: Article 36 is tied to executing an agreement
Regulation (EU) 2023/2854 calls Article 36 “Essential requirements regarding smart contracts for executing data sharing agreements.” It addresses the vendor of an application using smart contracts, or a person whose trade, business or profession involves deploying smart contracts for others, in the context of executing an agreement or part of one.
The legal hook is therefore not the presence of a blockchain label. A token contract, internal prototype or unrelated decentralised application cannot be placed inside Article 36 merely because its code is immutable. The reviewer needs the agreement, the function the code performs inside it and the party acting as vendor or professional deployer.
This is also why “the developer wrote it” is not a sufficient ownership answer. The engineering author, application vendor, systems integrator and party deploying for another organisation can be different entities.
Join four records before scoping the work
Use one applicability note with four connected records:
- Agreement record: parties, data-sharing purpose, executed clause or workflow, governing version and production date.
- Deployment record: application vendor, professional deployer, operator, code repository and deployed address or other unique instance identifier.
- Control record: evidence for robustness, access control, termination or interruption, archiving and continuity.
- Declaration record: conformity-assessment owner, assessed version, standards or specifications used, EU declaration of conformity and change history.
The note is this article’s original contribution. It turns a loose compliance phrase into a join that can be checked without pretending the Telegram discussion is a complete legal brief. TOP Prospect can help surface the fragments that populate this note; it cannot complete or approve it. If the agreement record cannot be joined to the deployed version, a polished audit report may describe different code.
The four requirement areas are related but not interchangeable
Article 36 sets out four essential areas.
Robustness and access control. The smart contract should offer access-control mechanisms and a very high degree of robustness to avoid functional errors and withstand manipulation by third parties. Evidence may include a threat model, test results, role definitions and deployed configuration. A security report is useful only when its version matches the application and instance in the deployment record.
Safe termination and interruption. A mechanism must exist to terminate the continued execution of transactions. The smart contract should include internal functions capable of resetting it or instructing it to stop or interrupt operations, particularly to avoid future accidental execution. The important sales question is not “Does it have a pause button?” It is who can invoke which action, under what condition, with what logged approval and effect on pending transactions.
Data archiving and continuity. Where a smart contract must be terminated or deactivated, the design should allow transactional data, its logic and its code to be archived so that past data operations remain auditable. A repository snapshot alone may omit deployed parameters, emitted events or the agreement version.
Access control at more than one layer. Article 36 also calls for rigorous access-control mechanisms at governance and smart-contract layers. A function-level role check does not answer who approves role assignment, emergency action or a production upgrade.
Example: the audit covers the code, but not the agreement join
Imagine these incomplete messages arriving before a design review; they are illustrative, not customer evidence:
“Port-data pilot goes live next month. Procurement wants Article 36 declaration.”
“Audit is done on v1.8. Pause role is with the integrator, I think. Agreement annex still being updated.”
The messages contain a pilot date, a code version, a possible pause-role holder and an unfinished agreement annex. They do not identify the production instance, executing clause, vendor or professional deployer, governance approval, archival route, assessment owner or declaration.
The applicability note would show three red joins:
- the audit names v1.8, but the production version and address are unknown;
- the pause role may belong to the integrator, but authority and approval evidence are unknown; and
- the agreement annex is changing, so the function the smart contract executes is not yet stable.
That is a credible assurance discussion. It is not evidence that the system conforms, and it is not a promise that one more penetration test will complete the declaration.
A declaration needs a bounded object
Article 36 requires the responsible vendor or deployer to perform a conformity assessment and issue an EU declaration of conformity. The official text also provides for a presumption of conformity where relevant harmonised standards, or parts of them, are followed.
For an assurance provider, the commercial boundary should name the object being assessed: application, smart-contract version, deployed configuration, agreement function and control set. It should also identify what happens after a code, role, endpoint or agreement change. Without that boundary, “Article 36 ready” is not a reproducible claim.
The declaration is not something a monitoring tool can generate from public discussion. Nor does an external audit automatically transfer the responsible party’s obligation to determine scope and issue the declaration.
Discovery can surface the missing join, not decide conformity
The product can filter and combine fragments from Telegram groups the user deliberately connects and is authorised to access. It can preserve the original messages, sources and times; group a named agreement, deployed version, stop mechanism and declaration request; remove obvious duplicates; and rank the result for human review.
It cannot inspect private repositories, test a smart contract, decide whether Article 36 applies, operate termination controls, perform a conformity assessment, issue a declaration or contact group members. Pricing and access options cover the discovery layer only.
For the neighbouring connected-product access rules, read the Article 4 and Article 5 evidence guide. For cloud-service switching discussions, use the separate Data Act switching-signal article.
Key facts
- Article 36 sits in Regulation (EU) 2023/2854, the EU Data Act.
- Its subject is smart contracts used to execute a data-sharing agreement or part of one, not every contract carrying a blockchain label.
- The addressed actor is an application vendor using smart contracts or a professional deployer acting for others in the relevant context.
- The four evidence areas are robustness and access control, safe termination and interruption, data archiving and continuity, and rigorous access control at governance and smart-contract layers.
- Archival evidence can include transactional data, smart-contract logic and code needed to preserve auditability of past operations.
- The responsible party must perform a conformity assessment and issue an EU declaration of conformity.
- A code audit can support the record, but does not by itself establish applicability or conformity.
FAQ
Does Article 36 apply to every blockchain token or smart contract?
No. Article 36 addresses a vendor of an application using smart contracts, or a person deploying smart contracts for others in a professional capacity, in the context of executing an agreement or part of one. The agreement and deployment role must be identified before scope is assumed.
Is a penetration test or code audit the same as Article 36 conformity?
No. Technical testing may support evidence, but Article 36 also covers access control, safe termination and interruption, data archiving and continuity, and conformity assessment with an EU declaration of conformity.
What should be archived if a smart contract is terminated?
Article 36 calls for the possibility to archive transactional data, smart-contract logic and code so that records of past data operations remain available for auditability.
Who makes the final legal and conformity decision?
The responsible vendor or professional deployer and its advisers must determine applicability, carry out the required conformity work and issue the declaration. A discovery platform can only surface and organise the request evidence.
Before pricing the audit, make sure the agreement, deployed object, control evidence and declaration all refer to the same implementation.
Frequently asked questions
Does Article 36 apply to every blockchain token or smart contract?
No. Article 36 addresses a vendor of an application using smart contracts, or a person deploying smart contracts for others in a professional capacity, in the context of executing an agreement or part of one. The agreement and deployment role must be identified before scope is assumed.
Is a penetration test or code audit the same as Article 36 conformity?
No. Technical testing may support evidence, but Article 36 also covers access control, safe termination and interruption, data archiving and continuity, and conformity assessment with an EU declaration of conformity.
What should be archived if a smart contract is terminated?
Article 36 calls for the possibility to archive transactional data, smart-contract logic and code so that records of past data operations remain available for auditability.
Who makes the final legal and conformity decision?
The responsible vendor or professional deployer and its advisers must determine applicability, carry out the required conformity work and issue the declaration. A discovery platform can only surface and organise the request evidence.
Sources and further reading
How a Signal worth attention is found
See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.
