Antonio Tejeda Encinas | President of the Euro-American Committee of Digital Law – CEA Digital Law | CEO of META Channel Corporation
For years, part of the blockchain ecosystem has worked on the basis of a comfortable assumption: that code could replace law. The formula served to explain projects, attract investment and present automation as though it were a legal category in its own right. But it is not. Code executes instructions. Law determines consequences.
The difference matters when a smart contract moves economic value.
A smart contract can liquidate a position, transfer funds, lock up collateral, trigger payments, depend on an oracle or form part of an investment structure. It can do so automatically and in accordance with its programmed rules. But if the outcome causes a user financial loss, if an interface inspires trust, if a protocol is marketed as safe, or if a structure is presented as decentralised while there are promoters, companies, a treasury, concentrated governance or organised commercial exploitation behind it, the legal discussion cannot end with the statement that the code worked.
That is where the problem begins.
Directive (EU) 2024/2853 on liability for defective products introduces a significant development: software is expressly included within the concept of a product. This covers computer programs, stand-alone software and artificial intelligence systems, regardless of how they are supplied. For those who design, deploy, integrate or operate smart contracts, the consequence is clear: software used on the market can no longer be analysed as a purely technical component, outside the ordinary criteria of liability.
But that advance should not be overstated.
The fact that software can be a product does not mean that every crypto loss is automatically covered by EU product liability. The Directive has significant limits. It applies to products placed on the market or put into service after 9 December 2026. It excludes free and open-source software developed or supplied outside the course of a commercial activity. And it is not designed simply to absorb any pure economic loss arising from a failed transaction.
This limit is essential.
In many disputes involving smart contracts, the typical harm is not personal injury, physical damage to property or the corruption of data in the strict sense. What usually occurs is an economic loss: a liquidated position, lost collateral, a drained pool, transferred tokens, a destroyed expectation or a loss of value linked to the execution of a transaction. The chain may have recorded exactly what happened. The data may remain intact. What is affected is not necessarily the technical integrity of the record, but the user’s financial position.
That is why it is not enough to assert that software is now a product. That assertion opens a route, but on its own it does not resolve the typical crypto loss. The case will have to be built with greater precision: defect, covered damage, causation, the proper defendant, applicable law, competent court, technical evidence and a realistic prospect of enforcement.
This brings us to the real heart of the problem: private international law.
A blockchain transaction may bring together European users, developers on another continent, a foundation incorporated in a favourable jurisdiction, a company operating the interface, oracle providers, auditors, custodians, exchanges, treasury holders, key governance members and a community that formally takes the decisions but in practice may be steered by a handful of players. Technical decentralisation does not automatically eliminate legal connecting factors. Sometimes it spreads them out. Sometimes it conceals them. Sometimes it shifts the focus to whoever controls the real economic relationship with the user.
You do not sue the code. You sue, where appropriate, whoever can be legally linked to the harm.
That party need not be the programmer. In many cases it will not be. It may be whoever commercially operates the front end, whoever structures the token, whoever directs its activity at European users, whoever provides crypto-asset services, whoever controls essential elements of the protocol, whoever manages a treasury, whoever fosters economic trust, whoever markets access, or whoever retains a position of material control behind a decentralised façade.
Liability does not arise from having written code. It arises from the function performed, the control exercised, the benefit obtained, the trust generated and the link between that conduct and the loss suffered.
This distinction avoids two mistakes. The first is automatically looking for a developer to blame for any loss. The second is accepting that the word decentralisation is enough to make any centre of responsibility disappear. Neither answer is serious. The first oversimplifies the technical problem. The second leaves transactions without legal treatment even though they move real value and, in many cases, are promoted, financed, exploited and governed by identifiable actors.
The same caution should be applied to open source.
Open-source code developed or supplied outside the course of a commercial activity cannot become universally liable for what others later build, integrate or exploit. That protection makes sense. But publishing open-source code is not the same as launching a protocol with a token, fees, venture capital, its own interface, financial incentives, a treasury, marketing and organised governance. In that second scenario, the open-source label should not be used as an automatic shield. The key lies not only in the repository, but in the economic exploitation of the system.
Something similar happens with on-chain arbitration.
It can be useful in relationships between professional operators, with identified parties, a valid arbitration agreement, a clear seat, applicable rules, a sufficient amount at stake and enforceable assets. But it cannot be presented as a universal answer to disputes arising from smart contracts. Still less so when the clause appears in standard terms and places the European user in a procedural position that is difficult, costly or simply unworkable.
In relationships with European consumers, the use of blockchain does not remove protective rules. If an operator directs its activity at Europe, attracts European users, offers an interface, structures a product or provides a service aimed at that market, it will have to reckon with rules that limit the choice of law, the choice of forum and the effectiveness of certain contractual clauses. This is not a formality. It is what allows a technical or economic loss to be turned into a viable claim.
Nor does this mean that every crypto loss gives rise to liability.
There are market risks that the user assumes. There are losses resulting from volatility. There are cases with no proven defect. There are failures where causation cannot be established. There are genuinely decentralised structures in which it will not be easy to find a legally reachable party. And there are cases in which the technical evidence will not be strong enough to support a claim with any confidence.
But acknowledging those limits is one thing; accepting that any infrastructure based on smart contracts can move economic value without a minimum structure of attribution is quite another. Where there is organised exploitation, significant control, an appearance of trustworthiness, user acquisition and economic benefit, the legal analysis cannot stop at the technological surface.
The Data Act confirms this direction in a specific area. By imposing on certain smart contracts requirements of robustness, access control, safe interruption or termination, archiving and auditability, the EU legislature makes it clear that a smart contract is no longer treated as a mere neutral tool. When it performs a significant function within a regulated transaction, it is required to meet conditions of design, security and traceability.
For serious developers, this should not be seen as an attack. It is a condition for entering more demanding markets. If a project aims to attract users, move assets, integrate into financial services, work with businesses or deal with consumers, it is not enough to say that the code has been audited. It needs governance, documentation, allocation of roles, incident management, traceability, update criteria, access control where appropriate and a legal structure consistent with the project’s economic reality.
For users and investors, the consequence is practical. Before entrusting funds to a structure based on smart contracts, it is not enough to look at the promised return, the technical audit or the decentralisation narrative. You need to know who is behind the interface, which entity provides the service, which jurisdiction is invoked, what protection the user retains, what assets exist to meet any claim, and what happens if the problem is not an obvious bug but a flawed incentive structure, oracle manipulation, captured governance or an operational decision dressed up as a community decision.
Blockchain does not need to stay outside the law in order to develop. It needs legal structures compatible with the economic function it seeks to perform.
Code can automate execution. It cannot, on its own, resolve the attribution of liability, jurisdiction, applicable law, evidence or enforcement against assets. Before deploying, financing, auditing or using a structure based on smart contracts, the relevant question is not only whether the code works. It is who is answerable if it fails. When that question has no answer, the problem is not decentralisation. It is poorly structured legal exposure.
