Smart contracts: legal status in Israel

Service page: Digital commerce and AI lawyer: terms, privacy and direct mailing.

What is a smart contract?

A smart contract is a computer program that runs on a blockchain network and performs actions automatically when conditions defined in advance are met. For example: transferring a payment automatically when goods are approved, or automatic cancellation of a transaction when a deadline was not met.

The blockchain revolution created a market in which billions of dollars are managed by code: without a lawyer, without a bank, and sometimes without any person who can be sued.

Is a smart contract binding in Israel?

The Contracts (General Part) Law, 5733-1973 does not define a “contract”; it provides that a contract is made by way of offer and acceptance (sections 1–8). The legal status of a smart contract is examined by the same criteria: intention to be bound, legal capacity and a lawful purpose.

In practice, code can express an intention to be bound, if both parties knowingly signed a blockchain transaction. The problem is that sometimes one of the parties did not understand what they committed to.

What happens when there is a bug? In 2016, “The DAO” affair showed the problem: a hacker exploited a hole in a smart contract and withdrew tens of millions of dollars in a way that was “legal” according to the code, but contrary to the parties’ intention. The question of liability for bugs in a smart contract (the author’s? the platform’s?) has not yet been decided in Israel.

Enforcement and causes of action

When a smart contract crashes, whom do you sue? If a specific party wrote the code, there may be a cause of action under contract law or tort law. If the code is open source developed by a community, enforcement is much more complicated.

Israel has no dedicated legislation on smart contracts. This does not mean a legal vacuum; quite the opposite: the smart contract is examined through the general laws (contract law, electronic signature law and tort law), and each of them has something to say about it.

What to require when signing a smart contract

• A code audit by a third party
• A choice of law clause that sets the country in which disputes will be examined
• A “kill switch” mechanism to stop the code in an emergency
• A parallel written legal document alongside the technical code

Which laws apply in the absence of a dedicated law

Formation and form: code is no barrier

The argument that “a smart contract is not a contract because there is no signed document” rests on a misunderstanding. Section 23 of the Contracts (General Part) Law, 5733-1973 provides that “a contract may be made orally, in writing or in another form, unless a particular form is a condition of its validity under law or an agreement between the parties”. “Another form” also includes an interaction with code. The real question is the usual one: was there an offer and acceptance (sections 1–8), was there an intention to be bound and sufficient certainty, and is the content lawful (section 30).

Note the exception at the end of section 23: transactions for which the law requires a particular form will not be “fulfilled” by code alone. Alongside this, section 2 of the Electronic Signature Law, 5761-2001 provides that where legislation requires a signature, the requirement can be met in an electronic message: with a certified electronic signature, or with another signature “provided that the purposes of the signature requirement are met, with a sufficient level of certainty in the circumstances”, except for types of documents excluded in the First Schedule to the Law.

Evidence: what a wallet signature is worth in court

Section 3(a) of the Electronic Signature Law provides that “the admissibility of a signature shall not be denied only because it is an electronic signature”. Beyond that, a message signed with a secure electronic signature (unique to the holder of the signature device, allowing prima facie identification of that holder, produced with a device under the holder’s sole control, and allowing a change in the message after signing to be detected (section 1)) is prima facie evidence that the message was not changed after signing (section 3(b)). This fits a cryptographic signature well, but it does not prove who was behind the wallet.

That is why section 3A matters: when a “designing party”, a party to the contract that had the upper hand in designing how signing is done, seeks to rely on the other party’s signature on an electronic message in connection with the contract, it bears the burden of proving that the other party actually signed. On a platform you operate, the burden is on you.

Interpretation: from 7 January 2026 the code is read by its wording

This is the most significant change for the field. Following the amendment of section 25 of the Contracts (General Part) Law, a business contract made or renewed on or after 7 January 2026 that sets no provisions on how it is to be interpreted will be interpreted according to its wording alone, unless the wording leads to an unreasonable result or to a contradiction between provisions; section 25(a)(1) even allows the parties to agree in advance on how the contract will be interpreted. In a world where “the code is the contract”, the meaning is clear: an accompanying document that defines the economic intention becomes a real interpretive tool, but only if it states expressly that it is part of the contract and how it relates to the code in case of a contradiction.

When the transaction is flawed: voidness and rescission

The code can run and the transaction can still be rescinded. Chapter B of the Contracts Law allows rescission for mistake (section 14), misleading (section 15), duress (section 17) and unconscionable exploitation (oshek) (section 18): grounds that do not disappear because performance was automatic. And section 30 provides that a contract whose making, content or purpose is illegal, immoral or contrary to public policy is void. Perfect technical performance does not make improper content legitimate.

When there is a bug: the map of liability and remedies

The question “whom do you sue” breaks down into three: who wrote the code, who operated it, and who profited from the failure. Enforcement (section 3 of the Contracts (Remedies for Breach of Contract) Law, 5731-1970) is the natural remedy, but there is no enforcement when the contract cannot be performed or when carrying out the order “requires an unreasonable degree of supervision by a court”; with code that runs on a decentralized network, both exceptions are relevant. Damages (section 10) are limited to damage that the party in breach foresaw or should have foreseen. And liquidated damages (section 15) are awarded without proof of damage, but can be reduced. The practical conclusion: in a significant transaction, keep an asset or a guarantee outside the chain that can be collected from.

A practical route before deploying or signing

1. Identifying the parties. What is the legal entity behind the project? A wallet address is not a defendant.
2. A parallel legal document that defines the economic intention, the relationship between the code and the document in case of a contradiction, and how the contract is to be interpreted (section 25(a)(1)).
3. A code audit by a third party, with documentation of the findings and the fixes.
4. Choice of law and jurisdiction: both in the document and, as far as possible, in the official documentation of the contract.
5. A stop or upgrade mechanism (kill switch / upgradeability), and a definition of who is authorized to activate it and on what conditions.
6. Security outside the chain: a trust, a guarantee or an indemnity, which are the practical way to enforce once the code is already running.

What to document

• The exact version of the code that was deployed, the contract address and the deployment date.
• The interface shown to the user at the time of approval: screenshots of the text and the buttons.
• The code audit report, the messages between the parties, and any change in the terms after deployment.

Common mistakes

• “The code is the law”. An Israeli court will examine intention to be bound, defects in formation and public policy, not only technical performance.
• Doing without an accompanying document. From 7 January 2026 a business contract is read according to its wording; what has no binding wording will not be read into it.
• Relying on enforcement alone. Section 3 of the Remedies Law excludes enforcement that requires unreasonable supervision.
• Assuming that a wallet signature identifies a person. It shows a device, not an identity, and section 3A places the burden on the platform operator.

When a lawyer is worth it, and when not

You can manage on your own: interacting with a known public protocol for small amounts, when you understand the risk and do not rely on any undertaking.

It is worth involving a lawyer: when you publish a smart contract for users; when the smart contract makes payments between identified parties in a commercial transaction; when it involves raising capital or issuing tokens; when there is exposure to personal information; and of course after a failure, when the speed of the response affects the ability to trace funds and obtain relief.

FAQ

Is a smart contract legally binding in Israel?

There is no dedicated law, but there is no barrier of form either: section 23 of the Contracts (General Part) Law allows a contract to be made “orally, in writing or in another form”. The questions are the usual ones: offer and acceptance, intention to be bound, certainty and lawful content. An exception: transactions for which the law requires a particular form, and documents excluded in the First Schedule to the Electronic Signature Law.

Who is responsible when there is a bug in a smart contract?

There is no single answer. Liability is examined against whoever wrote the code, whoever operated it and whoever was enriched by the failure, under contract law and tort law. The remedies: enforcement (section 3 of the Remedies Law, subject to the exception of unreasonable supervision), damages within the limits of foreseeability (section 10), and liquidated damages if they were set (section 15). So it is important to keep an asset or a guarantee outside the chain.

Is a signature with a crypto wallet a “signature” under the law?

Section 3(a) of the Electronic Signature Law provides that “the admissibility of a signature shall not be denied only because it is an electronic signature”, and a message signed with a secure electronic signature is prima facie evidence that it was not changed after signing (section 3(b)). Identifying the person behind the wallet is a separate question, and section 3A places the burden of proof on the “designing party”, meaning the party that designed how signing is done.

How does the 2026 amendment to the Contracts Law affect smart contracts?

A business contract made or renewed on or after 7 January 2026 that sets no interpretation provisions will be interpreted according to its wording alone, except when the wording leads to an unreasonable result or an internal contradiction (section 25). In addition, section 25(a)(1) allows the parties to agree in advance on how the contract will be interpreted. Two reservations: a standard-form contract is interpreted according to the parties’ intention even if it states otherwise (section 25(a)(4)), and parties that were not represented by a lawyer when the contract was drafted are deemed not to have agreed on how it is to be interpreted (section 25(a)(5)(a)). So in a smart contract offered to many users, the code may not be read according to its wording alone. In practice: it is worth stating in the accompanying document that it is part of the contract, and defining expressly which prevails in case of a contradiction between it and the code.