Smart Contracts in Hungarian Law: Validity, Evidence, and Liability

A smart contract is a self-executing program code deployed on a blockchain that automatically performs the contractual consequences defined within it when predetermined conditions are met – initiating payment, transferring tokens, granting or revoking access. By 2026, this technology has expanded far beyond crypto-asset markets, appearing in supply chain management, insurance claims processing, and numerous other areas. Below, we examine how this new technological reality fits within the framework of Hungarian civil law.

Doctrinal Classification: Contract Type or Mode of Performance?

Smart Contracts Are Not an Independent Contract Type

From the perspective of Hungarian civil law, a smart contract is not an independent, named contract type. Book Six of the Civil Code (Ptk.) classifies contracts by their content and economic function, not by their technical implementation. A smart contract is in fact dual in nature:

• A means of expressing contractual intent: the parties express contractual terms and legal consequences in program code;
• An automated mode of performance: the code executes performance without human intervention when conditions are met.

Under the freedom of contract principle (Ptk. Section 6:58), the parties may freely choose a smart contract as their instrument of contracting and performance, provided that the law does not prescribe mandatory form requirements for the given contract type, or that the smart contract satisfies those requirements.

Form Requirements: Written Form and Electronic Documents

The Civil Code’s Form Rules

Under Section 6:7(1) of the Ptk., a legal declaration is deemed to be in writing if signed by the declaring party. Subsection (2) extends this to electronic documents: a legal declaration is also to be regarded as written if communicated in a form suitable for unchanged retrieval of its content, identification of the declaring person, and identification of the time the declaration was made.

The key question for smart contracts is whether a blockchain-recorded transaction satisfies the threefold requirement of Section 6:7(2):

1. Unchanged retrieval of content: given the cryptographic nature of the blockchain, data once recorded is immutable – this condition is met.
2. Identification of the declaring person: this is the critical point. Blockchain addresses are inherently pseudonymous – they do not identify natural or legal persons. Identification is only assured where the transaction is signed with a qualified electronic signature (or at least an advanced electronic signature), in accordance with the eIDAS Regulation ((EU) 910/2014).
3. Identification of the time of declaration: blockchain block timestamps provide this, though the precise timing depends on block mining duration.

The eIDAS Regulation and Qualified Electronic Signatures

Under Article 25(2) of the eIDAS Regulation (Regulation (EU) 910/2014), a qualified electronic signature has the equivalent legal effect of a handwritten signature. Where the parties use a qualified electronic signature when concluding a smart contract, the form requirement is satisfied for any contract type for which the law prescribes written form.

It is important to emphasise: signing a transaction with a private key on the blockchain does not in itself constitute a qualified electronic signature under eIDAS. A qualified electronic signature requires a qualified certificate and a qualified signature creation device. Without these, a blockchain transaction may qualify as an electronic signature, but its evidentiary weight is lower.

Evidentiary Value of Blockchain in Civil Proceedings

Distinguishing Public and Private Documents

Contrary to what is sometimes claimed: blockchain transaction logs do not qualify as public documents (közokirat). Under Section 323 of the Code of Civil Procedure (Act CXXX of 2016, Pp.), a public document is one issued by a court, notary, or other authority or public institution within its competence and in the prescribed form. The blockchain is a decentralised technology independent of any authority – data recorded on it may qualify as a private document.

Private Documents with Full Evidentiary Force

Section 325(1) of the Pp. exhaustively lists the conditions for a private document to have full evidentiary force. A blockchain transaction may qualify as such if:

• the declaration was signed with a qualified or advanced electronic signature (Section 325(1)(e) of the Pp., in conjunction with Act CCXXII of 2015 on electronic administration and trust services); or
• the document was affixed with a qualified electronic time stamp.

If these conditions are not met – for instance, the transaction was signed merely with a pseudonymous blockchain address – the blockchain data is to be assessed as a simple private document, the evidentiary value of which the court weighs under Section 279 of the Pp. in accordance with the principle of free evaluation of evidence, together with other evidence.

The DLT Pilot Regime and the EU Framework

The EU-level framework for applying distributed ledger technology was established by the DLT Pilot Regime Regulation ((EU) 2022/858), which since March 2023 permits the operation of DLT-based market infrastructures in financial markets. While this regulation directly concerns the trading of financial instruments, the technological recognition it embodies may serve as a model for the procedural acceptance of blockchain-based evidence.

Divergence Between Code and Intent: Interpretation Issues

General Rules of Contract Interpretation

One of the most critical questions in Hungarian contract law regarding smart contracts is the divergence between code and intent expressed in natural language. If the program code operates differently from how the parties recorded their contractual intent in textual form, which prevails?

Under Section 6:86 of the Ptk., the content of a contract is determined by the mutual and concordant declarations of intent of the parties. In interpretation, under Section 6:8(1), a declaration must be construed with regard to its context, the circumstances prevailing at the time the declaration was made, and customary usage, in accordance with the presumed intent of the declarant.

This rule is decisive: the code itself is not the contract, but rather the instrument of the contract’s execution. If the code is defective (a bug) and execution therefore deviates from the parties’ agreement, the parties’ true intent prevails, not the result produced by the code. Performance resulting from a code error may constitute unjust enrichment (Ptk. Section 6:579) or breach of contract.

Practical Consequence: The Importance of Natural Language Documentation

It follows that when using smart contracts, parallel documentation of the parties’ agreement in natural language is essential. In practice, the best approach is the dual-layer method: the contract text is documented in natural language, and the program code is treated as its technical implementation. In case of divergence, the natural language version prevails.

Automated Performance and Liability

The Legal Framework for Automated Compensation

One of the most promising applications of smart contracts is automated compensation – for example, immediate blockchain-based payment of compensation due to an airline passenger in the event of flight delay, without human intervention. From a legal framework perspective, this represents the automation of compensation under Regulation (EC) No 261/2004 (air passenger rights).

Layers of Liability

Where a smart contract malfunctions – receiving incorrect data, applying faulty code logic, or where an external data source (oracle) conveys inaccurate information – determining liability is complex:

1. Developer liability: the developer may bear contractual liability for code errors under the service contract; additionally, general tortious liability under Section 6:519 of the Ptk. may arise where defective code causes damage to a third party.
2. Platform (service provider) liability: the platform operator making the smart contract available to users may be held liable under Section 6:142 of the Ptk. (general terms and conditions) and consumer protection legislation.
3. Oracle provider liability: where the cause of erroneous execution is incorrect data from an external source (e.g., a flight information API incorrectly signals a delay), the oracle provider may be liable under its own contractual relations and Section 6:519 of the Ptk.
4. Product liability: where a smart contract-based service qualifies as a product, the product liability rules under Sections 6:550–6:559 of the Ptk. may apply – particularly in light of the 2024 modernisation of the EU Product Liability Directive ((EU) 2024/2853), which brings software within the product definition.

The AI Act Connection

Where a smart contract contains artificial intelligence elements – for example, a predictive algorithm determines the compensation amount – the transparency and risk management requirements of the AI Act ((EU) 2024/1689) may also apply. In 2026, the full applicability period of the AI Act has not yet concluded, but the rules for high-risk AI systems (Annex III) are already in force.

Consumer Protection and the Right of Withdrawal

The Tension Between Automated Execution and the 14-Day Withdrawal Right

Under Section 20 of Government Decree 45/2014 (II. 26.) on contracts between consumers and businesses concluded at a distance, the consumer may withdraw from the contract within 14 days of its conclusion without giving reasons. This withdrawal right implements Directive 2011/83/EU.

The smart contract problem: if a blockchain transaction is irreversible (immutable), how can the consumer’s withdrawal right be given effect?

The Solution: Ensuring Reversibility

Current Hungarian law does not prescribe a specific “kill switch” obligation for smart contracts – no such specific legislative provision exists as of March 2026. However, the mandatory force of consumer protection rules (Ptk. Section 6:104 – nullity of a declaration waiving a consumer’s rights) means that:

• a smart contract incorporated into a consumer contract may not exclude the 14-day withdrawal right;
• if it does exclude it, the contractual term is void (Ptk. Section 6:104);
• the service provider must ensure a technical solution for the enforceability of withdrawal (e.g., an escrow mechanism, timed execution deferred until expiry of the 14-day withdrawal period, or the ability to initiate a reverse transaction).

Section 29 of Government Decree 45/2014 contains exceptions to the withdrawal right – including loss of the right to withdraw after commencement of digital content delivery (Section 29(1)(m)), provided the consumer gave prior consent. This exception may be relevant for certain types of smart contracts, but its application is conditional on the consumer’s express, informed consent.

Unfair Contract Terms Control

Terms embedded in a smart contract’s program code may constitute unfair general contract terms under Sections 6:102–6:104 of the Ptk. if they are disadvantageous to the consumer and the consumer had no substantive ability to influence them. The “code is law” approach is untenable under Hungarian law: code-based terms are subject to the same unfairness control as general terms drafted in natural language.

Smart Contracts and Hungarian Court Practice

Jurisdiction and Applicable Law

The cross-border nature of the blockchain raises jurisdictional questions. Where the parties have not concluded a choice of law agreement (Ptk. Section 6:62), the Rome I Regulation ((EC) 593/2008) applies; under its Article 4, the law of the habitual residence of the party providing the characteristic performance governs. For consumer contracts, the law of the consumer’s habitual residence applies under Article 6 of the Rome I Regulation.

Code Audit as a Preventive Tool

One of the most effective tools for preventing disputes is independent auditing of the smart contract code before deployment. A code audit is not a statutory obligation, but forms part of sound business practice consistent with the service provider’s duty of good faith (Ptk. Section 1:4) and consumer protection disclosure obligations.

Practical Summary

1. A smart contract is not an independent contract type: in the Ptk. system, it is a technical instrument of contracting and performance – its validity requires the parties’ declarations of intent and compliance with statutory form requirements.
2. Blockchain is not a public document: blockchain transactions qualify as private documents; acceptance as a private document with full evidentiary force requires a qualified or advanced electronic signature.
3. The code is not the contract, but its execution: the parties’ agreement recorded in natural language prevails; code errors may result in breach of contract or unjust enrichment.
4. The consumer’s withdrawal right cannot be excluded: the immutability of a smart contract does not exempt the provider from ensuring the 14-day withdrawal right; technical solutions (escrow, timed execution) must ensure enforceability of withdrawal.
5. Multi-layered liability framework: damage caused by a defective smart contract may give rise to liability on the part of the developer, the platform provider, and the oracle provider – liability rules follow the Ptk.’s contractual and tortious liability regimes, as well as product liability.