Smart Contracts Under Data Act Article 36: The Kill-Switch and Archiving Duties Nobody Coded For

Article 36 of the EU Data Act asks a smart contract to do the one thing a great many of them were built to make impossible: stop, cleanly, on command, and leave a record behind.

The Data Act — Regulation (EU) 2023/2854 — has applied since 12 September 2025. Most of the attention has gone to the connected-product and cloud-switching provisions, which is fair, because that is where the money is. But buried in Chapter VIII, the interoperability chapter, sits Article 36, which imposes a short list of essential requirements on any smart contract used to execute a data-sharing agreement. Two of those requirements cut directly against how a lot of on-chain code is designed. The regulation wants a controlled stop, and it wants an archive. Immutable, autonomous execution — the property that a certain kind of engineer treats as the whole point — is precisely what the article refuses to let you rely on.

What Article 36 actually requires

The Data Act defines a smart contract in Article 2 as a computer program used for the automated execution of an agreement, or part of one, using a sequence of electronic data records and ensuring their integrity and the accuracy of their chronological ordering. Note what that definition does not say: it does not say blockchain, and it does not say on-chain. An off-chain program that automatically executes part of a data-sharing agreement is caught just as squarely as a Solidity contract on a public ledger.

Article 36(1) sets out five essential requirements. In plain engineering terms they are: robustness and access control sufficient to avoid functional errors and withstand third-party manipulation; a mechanism for safe termination and interruption; the ability to archive transactional data together with the contract logic and code; protection through rigorous access control at both the governance and the smart-contract layers; and consistency with the terms of the data-sharing agreement the contract executes. The two that catch people out are the second and the third.

Safe termination and interruption. The article expects a mechanism to terminate the continued execution of transactions, and internal functions that can reset the contract or instruct it to stop or interrupt operation. This is a kill-switch requirement stated in law. A contract that, by design, no party can halt does not meet it.

Archiving and continuity. The article expects the possibility of archiving the transactional data, the contract logic and the code, so that the record of operations performed on the data in the past is kept. Stopping a contract is not enough; you have to be able to preserve what it did and how it was built.

Who is on the hook

This is not a duty that floats free. The obligation falls on the vendor of an application that uses smart contracts, or the person whose trade, business or profession involves deploying such a contract to execute a data-sharing agreement. That party has to carry out a conformity assessment against the essential requirements and issue an EU declaration of conformity. Meeting the relevant harmonised standards, once they exist, gives a presumption of conformity — but the responsibility for the assessment, and the declaration, sits with the deployer either way.

If you are the firm wiring a smart contract into an automated data-sharing arrangement — say, to release sensor data to a co-signatory the moment a condition is met — you are the one signing that declaration. Not the auditing firm, not the standards body. You. That is the same accountability logic that runs through the rest of the Act, and it is why treating the Data Act as a pure legal-and-contracts exercise misses where the real work lands.

The immutability problem nobody priced in

Here is the collision. A large share of deployed smart contracts have no owner-controlled stop, no upgrade path and no administrative function that can pause execution, because removing those was sold as a security virtue. An admin key that can halt the contract is also an admin key that can be stolen or abused — which is exactly the failure mode I have written about in the context of smart-contract risk for centralised exchanges. Article 36 does not care about that trade-off. It requires the stop to exist, and it requires you to protect it with rigorous access control. The regulation is telling you to build the very administrative capability that a decade of on-chain culture told you to delete.

Which means the answer is not to bolt a kill-switch onto a contract after it is deployed. On an immutable ledger you cannot; the code is what it is. The control has to be designed in before deployment, with the access rights to operate it governed properly. A stop function guarded by a single hot wallet is not rigorous access control — it is a single point of both failure and capture. This is a kill-switch governance problem before it is a coding problem: who may pull it, under what authority, with what quorum, and how that is evidenced.

Engineering the stop and the archive

At its simplest, a compliant pattern separates three things: normal execution, a controlled termination gated by access control, and an archival event emitted before the contract is halted for good. The archive event is what lets an off-chain indexer preserve the record of operations and a pointer to the logic and code. In Solidity, the skeleton looks like this.

pragma solidity ^0.8.20;

/// @title Data-sharing agreement with Article 36 controls
/// @notice Adds a governed stop and an archival hook so the contract
///         can be terminated safely and its record preserved.
contract DataSharingAgreement {
    address public controller;   // party authorised to stop the contract
    bool public terminated;

    // Archive record written before the contract is halted for good.
    event Archived(bytes32 indexed agreementRef, string logicUri, bytes32 stateHash);
    event Terminated(address indexed by, uint256 atBlock);

    modifier onlyController() {
        require(msg.sender == controller, "not authorised");
        _;
    }

    modifier active() {
        require(!terminated, "agreement terminated");
        _;
    }

    constructor(address _controller) {
        controller = _controller;   // use a multisig, not a single hot wallet
    }

    /// @notice Normal data-sharing action; refused once terminated.
    function shareData(/* ...agreement logic... */) external active {
        // execution of the data-sharing agreement
    }

    /// @notice Article 36(1)(b) safe stop + 36(1)(c) archive-before-halt.
    function terminate(bytes32 agreementRef, string calldata logicUri, bytes32 stateHash)
        external
        onlyController
        active
    {
        emit Archived(agreementRef, logicUri, stateHash);
        terminated = true;
        emit Terminated(msg.sender, block.number);
    }
}

The point of the snippet is not that it is complete — it is not. It is that the controller should be a multisignature or governance contract, not a single address; that the archive is emitted before the state is frozen, so the record survives the stop; and that after termination the core action is refused rather than silently continuing. Those three properties are the difference between a contract you can point at in a conformity assessment and one you cannot.

Off-chain, and the moving target

Because the definition is technology-neutral, the same discipline applies to the automated executors sitting inside ordinary data platforms. If a scheduled job releases a partner’s data the moment a FRAND-style condition is met, that job needs the same governed stop and the same archival record — a point that connects directly to the contract and API pattern for B2B data sharing. Off-chain, this is easier to build and easier to forget, because nobody thinks of a cron job as a smart contract. Article 2 does.

One honest caveat. In November 2025 the European Commission’s Digital Omnibus proposal floated stripping out these prescriptive smart-contract requirements altogether. That is a proposal, not law. Until the Council and Parliament adopt it, Article 36 stands and applies, and anyone deploying a data-sharing smart contract today has to meet it. Betting a deployment on a proposal that may be amended beyond recognition is not risk management; it is hope. Build the stop and the archive now, and treat any future relaxation as a bonus rather than a plan. The contract you deploy this quarter is the one you cannot change next quarter — which is the whole reason the rule exists.