智能合约在匈牙利法律中的地位：效力、证据价值与责任

智能合约（smart contract）是部署在区块链上的自执行程序代码，当预设条件满足时自动执行合同规定的法律效果——发起支付、转移代币、授予或阻断访问权限。到2026年，这项技术已超越加密资产市场，扩展到供应链管理、保险理赔处理等众多领域。下文分析这一新技术现实如何融入匈牙利民法框架。

教义分类：合同类型还是履行方式？

智能合约不是独立的合同类型

从匈牙利民法的角度来看，智能合约不是独立的有名合同类型。民法典（Ptk.）第六编按内容和经济功能对合同进行分类，而非按技术实现方式。智能合约实际上具有双重性质：

• 合同意思表示的工具：当事人以程序代码表达合同条款和法律效果；
• 自动化履行方式：条件满足时，代码在无人干预下执行履行。

根据合同自由原则（Ptk.第6:58条），当事人可以自由选择智能合约作为缔约和履约的工具，但以法律未对该合同类型规定强制性形式要件或智能合约满足该要件为前提。

形式要件：书面性与电子文件

民法典的形式规定

Ptk.第6:7条第（1）款规定，意思表示由表意人签署的即为书面形式。第（2）款将其扩展至电子文件：意思表示的内容能够不变地再现、表意人能够被识别、意思表示的时间能够确认的形式，也视为书面形式。

智能合约的核心问题是：记录在区块链上的交易是否满足第6:7条第（2）款的三项要件：

1. 内容的不变再现：区块链的密码学特性使得数据一旦记录即不可更改（immutable）——该要件得以满足。
2. 表意人的识别：这是关键争议点。区块链地址本质上是假名的——不能识别自然人或法人。仅当交易以eIDAS规则（（EU）910/2014号条例）项下的合格电子签名（或至少是高级电子签名）进行签署时，身份识别方可获得保障。
3. 意思表示时间的确认：区块链区块的时间戳可提供此信息，但精确时间取决于出块所需时间。

eIDAS条例与合格电子签名

根据eIDAS条例（（EU）910/2014号条例）第25条第（2）款，合格电子签名具有与手写签名同等的法律效力。当事人在智能合约缔结中使用合格电子签名的，法律要求书面形式的所有合同类型的形式要件均得以满足。

需强调的是：在区块链上以私钥签署交易本身并不构成eIDAS意义上的合格电子签名。合格电子签名需要合格证书和合格签名创建设备。缺乏上述条件的，区块链交易可被承认为电子签名，但证据力较低。

区块链在民事诉讼中的证据价值

公文书与私文书的区分

与某些观点相反，区块链交易记录不是公文书。根据民事诉讼法（2016年第CXXX号法律，Pp.）第323条，公文书是法院、公证人或其他机关在其职权范围内按照规定形式制作的文件。区块链是独立于公权力机关的去中心化技术——记录于其上的数据只能被认定为私文书。

具有完全证明力的私文书

Pp.第325条第（1）款穷尽列举了私文书具有完全证明力的条件。区块链交易在以下情形可满足该要件：

• 意思表示附有合格或高级电子签名（Pp.第325条第（1）款e项，与2015年第CCXXII号电子政务和信任服务法衔接）；或
• 文件附有合格电子时间戳。

上述要件未满足的——例如交易仅以假名区块链地址签署——区块链数据被评价为一般私文书，法院依据Pp.第279条规定的自由心证原则，结合其他证据综合判断。

DLT试点制度与欧盟框架

分布式账本技术应用的欧盟层面框架由DLT试点制度条例（（EU）2022/858号条例）建立，自2023年3月起允许在金融市场运营基于DLT的市场基础设施。尽管该条例直接涉及金融工具交易，其中蕴含的技术认可可为法院接受基于区块链的证据提供参考。

代码与意思的背离：解释问题

合同解释的一般规则

与智能合约相关的匈牙利合同法最核心的问题之一是代码与以自然语言表达的意思之间的背离。当程序代码的运行结果与当事人以文件形式记载的合同意思不同时，孰先孰后？

根据Ptk.第6:86条，合同内容由当事人相互一致的意思表示确定。第6:8条第（1）款规定，意思表示应当依据其语境、作出时的情况、通常用法以及表意人的推定意思进行解释。

该规则具有决定性意义：代码本身不是合同，而是合同的履行工具。代码存在缺陷（bug）导致履行偏离当事人合意的，当事人的真实意思优先，而非代码产生的结果。代码错误导致的履行可构成不当得利（Ptk.第6:579条）或违约。

实务启示：自然语言记录的重要性

由此得出结论：使用智能合约时，以自然语言并行记录当事人合意是必不可少的。实务中最佳做法是双层方式：合同内容也以自然语言形成文件，程序代码被视为技术实现工具。发生背离时，自然语言版本优先。

自动化履行与责任

自动化赔付的法律框架

智能合约最有前景的应用之一是自动化赔付——例如航班延误时向旅客支付的赔偿金通过区块链即时支付，无需人工干预。从法律框架角度，这是对（EC）261/2004号条例（航空旅客权利）项下赔偿的自动化。

多层责任结构

当智能合约运行异常——接收错误数据、适用有缺陷的代码逻辑、或外部数据源（oracle）传递不准确信息——责任认定十分复杂：

1. 开发者责任：开发者可依据服务合同对代码错误承担合同责任；缺陷代码给第三人造成损害的，还可依据Ptk.第6:519条承担一般侵权责任。
2. 平台（服务提供者）责任：向用户提供智能合约的平台运营者可依据Ptk.第6:142条（格式条款）及消费者保护法规承担责任。
3. 预言机提供者责任：错误履行的原因在于外部数据源的错误数据（如航班信息API错误显示延误）的，预言机提供者可依据其自身合同关系及Ptk.第6:519条承担责任。
4. 产品责任：基于智能合约的服务被认定为产品的，可适用Ptk.第6:550条至第6:559条的产品责任规定——尤其考虑到2024年欧盟产品责任指令现代化（（EU）2024/2853号指令）已将软件纳入产品概念。

AI法案衔接

智能合约包含人工智能要素——例如预测算法确定赔偿金额——的，AI法案（（EU）2024/1689号条例）的透明度和风险管理要求也可能适用。2026年AI法案的全面适用期尚未完成，但高风险AI系统（附件III）的规定已经生效。

消费者保护与撤回权

自动化履行与14天撤回权的紧张关系

根据45/2014.(II.26.)政府令第20条，在远程缔结的消费者合同中，消费者可在缔约之日起14日内无需说明理由行使撤回权。该撤回权是对2011/83/EU号指令的国内转化。

智能合约的问题是：当区块链交易不可撤销（immutable）时，消费者的撤回权如何实现？

解决方案：确保可逆性

现行匈牙利法律未对智能合约规定具体的”紧急停止”（kill switch）义务——截至2026年3月不存在此类具体法律规定。然而，消费者保护规定的强制性效力（Ptk.第6:104条——消费者放弃权利的意思表示无效）意味着：

• 纳入消费者合同的智能合约不得排除14天撤回权；
• 排除该权利的合同条款无效（Ptk.第6:104条）；
• 服务提供者必须确保实现撤回权的技术解决方案（如托管机制、14天撤回期届满前的延迟执行、或启动反向交易的可能性）。

45/2014号政府令第29条包含撤回权的例外——包括开始提供数字内容后丧失撤回权（第29条第（1）款m项），但以消费者事先同意为前提。该例外可能与特定类型的智能合约相关，但其适用取决于消费者的明确知情同意。

不公平合同条款控制

智能合约程序代码中包含的条款，如果对消费者不利且消费者实际上无法影响这些条款的，可构成Ptk.第6:102条至第6:104条项下的不公平格式条款。“代码即法律”（code is law）的方法在匈牙利法中不能成立：基于代码的条款同样受制于与自然语言格式条款相同的公平性审查。

智能合约与匈牙利法院实务

管辖权与准据法

区块链的跨境特性引发管辖权问题。当事人未就准据法达成协议（Ptk.第6:62条）的，适用罗马I条例（（EC）593/2008号条例），根据第4条，提供特征性履行的一方的经常居所地法为准据法。消费者合同的，根据罗马I条例第6条适用消费者经常居所地法。

代码审计作为预防工具

预防争议最有效的工具之一是部署前对智能合约代码进行独立审计。代码审计虽非法定义务，但属于符合诚实信用义务（Ptk.第1:4条）和消费者保护信息提供义务的良好商业惯例的组成部分。

实务总结

1. 智能合约不是独立的合同类型：在Ptk.体系中，它是缔约和履约的技术工具；效力要求当事人的意思表示并满足法定形式要件。
2. 区块链不是公文书：区块链交易被认定为私文书；获得完全证明力须附有合格或高级电子签名。
3. 代码不是合同而是其履行方式：当事人以自然语言记载的合意优先；代码错误可导致违约或不当得利。
4. 消费者撤回权不得排除：智能合约的不可逆性不免除保障14天撤回权的义务；须以技术方案（托管、延迟执行）确保撤回权的可执行性。
5. 多层责任结构：因缺陷智能合约造成的损害，开发者、平台提供者和预言机提供者均可承担责任；责任依据Ptk.合同责任、侵权责任及产品责任体系确定。