智能合约与土耳其法律：面向外国企业的实务指南

答案是肯定的：智能合约在土耳其可以具有法律约束力。土耳其法律将其视为一份以代码形式表达的普通合同，因此关于形式、意思表示与证据的常规规则决定了它是否站得住脚。到 2026 年，有两点改变了整体格局：某些交易仍受强制性形式要件约束；同时，一套全新的加密资产监管制度如今已对许多与土耳其相关的链上安排实施监管。本指南将说明外国企业如何在土耳其使用智能合约，同时保持合同的可执行性与合规性。

什么是智能合约？

智能合约是一段软件，通常部署在区块链上，当约定条件得到满足时自动执行预先设定的动作。一个典型例子是托管（escrow）安排：一旦链上确认付款，代码便会自动向买方释放某项资产或代币，无需银行、中介或法院手动核验这一步骤。

有必要区分两个常被营销话术混为一谈的概念：

• 法律协议——双方就价格、义务与救济方式达成的合意。
• 执行代码——自动执行该协议部分（或全部）内容的机制。

在土耳其法律下，智能合约并不是一种特殊类别的合同，它只是合同得以表达和履行的一种可能形式。无论条款写在 Word 文档里还是写在 Solidity 代码中，《土耳其债务法》（TBK，第 6098 号法律）的常规规则依旧决定着一份有效、有约束力的协议是否存在。把这一法律层面处理妥当，正是我们在商事合同的起草与审查工作中所围绕的核心。

智能合约在土耳其是否具有法律约束力？

原则上是的。土耳其合同法奉行形式自由原则：除非法律要求特定形式，否则合同因双方相互一致的意思表示而有效成立。因此，合同可以通过电子方式订立，包括通过记录要约与承诺的代码订立。

不过，对外国企业而言，有两项限定值得注意：

• 强制性形式要件依然存在。某些交易必须采用书面形式或在官方机构面前完成——例如不动产买卖（在土地登记处办理）或某些公司股权转让。区块链上的一条记录并不能替代这些法定手续。一份声称转让土耳其不动产的智能合约，单凭自身并不能完成产权转移。
• 行为能力与意思表示规则仍然适用。即使代码执行得毫无瑕疵，错误、欺诈与胁迫（TBK 第 30 至 39 条）仍可使协议归于无效或可撤销。代码运行正确，并不等同于意思表示在法律上有效。

形式要件：代码能做什么、不能做什么

对任何与土耳其相关的智能合约而言，最关键的单一问题就是基础交易的形式要件。土耳其法律将合同大致分为三类，而代码单凭自身只能承载第一类。

外国企业常常弄错两点实务问题：

• 保证与担保。许多担保合同（teminat sözleşmeleri）——其中个人保证（kefalet，连带保证）是最典型的情形——根本无法用电子签名来弥补。它们需要符合严格内容要求的书面或公证形式，因此智能合约无法取而代之。
• 公司股权转让因公司类型而异。有限责任公司（limited şirket）的股权转让需要一份经公证的书面转让协议外加登记（TTK 第 595 条）——代码无法替代公证环节。在股份有限公司（anonim şirket）中，记名股份通常通过背书与交付转让，这为数字化流程留出了更多空间，但仍取决于规范的公司记录。如果您打算在土耳其设立公司并考虑引入链上机制，请从一开始就围绕这些规则设计股权结构。

电子签名与“书面形式陷阱”

在合同必须采用书面形式的场合，土耳其法律承认安全（合格）电子签名等同于手写签名。由经认证的土耳其认证服务提供商（ESHS）签发的合格电子签名，具有与手写（湿签）签名相同的法律效力。

许多跨境智能合约设计正是在此遇到困难。控制区块链钱包的加密私钥并不自动构成第 5070 号法律下的安全电子签名，因为该地位要求由经认证的提供商签发的合格证书，而不仅仅是一把私钥。因此，仅用钱包私钥签署的交易，对自由形式合同而言可能完全有效，却在法律要求书面形式的场合不达标准——在法律完全排除电子签名的场合（例如需要公证形式的保证），甚至根本无法满足要求。

什么情况下加密资产法会适用于您的智能合约？

这是整体格局中最近变化最大的部分，如今已成为许多智能合约项目的核心。在 2024 年之前，土耳其的加密活动处于一个基本不受监管的空间。这一状况已不复存在。

这为何对智能合约至关重要：您的安排不再仅仅被作为一份合同来评判。如果它涉及与土耳其有关联的加密资产的发行、交易、转移或托管，就可能构成需要 SPK 许可并触发持续监督的受监管加密资产活动。本文开头那些经典例子——代币销售、链上托管、自动化支付平台——恰恰是这套制度可能涵盖的活动类型。

在部署前需检查三个层面：

• 许可（SPK）。作为加密资产平台、托管方或服务提供商向土耳其用户提供服务，通常需要获得授权。在无许可的情况下经营此类服务属于严重的监管风险。
• 反洗钱（MASAK）。加密资产服务提供商是土耳其反洗钱框架下的义务主体，负有客户身份识别（KYC）与申报义务。加密领域的“旅行规则”（Travel Rule）——要求转账时附带发起方与受益方信息——适用于范围内的提供商。
• 边界问题。纯粹的点对点代码，或仅将代币用作支付通道而不提供受监管服务的合同，可能处于许可边界之外。这条界线高度依赖具体事实，值得及早核查。

DAO、DeFi 与灰色地带

外国创始人常问，去中心化结构处于何种法律地位。2026 年的诚实答案是：处于框架的边缘地带。

• DAO（去中心化自治组织）。土耳其法律目前尚未赋予去中心化自治组织独立的法律人格，也没有为其量身定制的定义。与土耳其存在成员或运营关联的 DAO，通常会借由现有类别来分析——普通合伙、公司或一项合同安排——而每一种都带来不同的责任与税务后果。法律上并不承认所谓的“DAO 外壳（wrapper）”。
• DeFi 协议。真正自治、非托管的协议有可能落在加密资产许可边界之外，但一旦出现可识别的运营方向土耳其用户提供服务，分析就会转向监管方向。“去中心化”之类的标签并不能决定问题；起决定作用的是功能与控制。
• 税务处理。代币发行、链上转移及加密资产收益的税务处理在土耳其仍在发展之中。印花税、所得税与企业税问题都可能产生。请把税务当作一个尚未定型的现实问题，寻求专业税务意见，而不要因为某笔转移发生在链上就假定其税务中性。

证据：在土耳其法院中证明智能合约

一个常见的误解是，区块链记录天然具有终局证明力。土耳其的立场更为微妙，而在某一方面比人们预期的更强。

因此，您链上证据的强度取决于其签署方式。与安全电子签名绑定的记录可以达到契据级别的效力；而仅凭钱包私钥的交易，是对时间与内容的有力佐证，但法官仍会将其与卷宗中的其余证据一并权衡。

对外国当事人的实务后果：

• 保留代码意在履行的、人类可读的协议。如果争议进入伊斯坦布尔的法院，法官想读的是文字表述的条款，而非字节码。
• 保存交易哈希值、钱包地址与时间戳，并准备好通过专家鉴定报告（bilirkişi）加以解释。
• 尽早处理语言问题——外文记录在法庭上使用时通常需要经宣誓的土耳其语翻译。

对于含涉外因素的交易，准据法与有管辖权的法院由《国际私法与程序法》（MÖHUK，第 5718 号法律）确定。当事人通常可以选择商事合同的准据法，但该选择应在链下协议中清晰载明，而不能仅凭服务器或节点所在地推定。

区块链上的个人数据（KVKK）

不可篡改是区块链的核心卖点——也是它与数据保护法之间真实张力的来源。土耳其的《个人数据保护法》（KVKK，第 6698 号法律）赋予个人若干权利，包括在特定情形下删除其个人数据。一条无法被更改的链，难以轻易满足删除请求。

对外国企业而言，实务要点是：

• 避免将个人数据直接写入链上。尽可能将其存储于链下，链上只保留引用、哈希值或假名标识符。
• 在上线前对照 KVKK 梳理您的数据流，包括任何向境外的个人数据传输——后者另有专门规则。
• 将“数据将永久留在公链上”视为一个需要在设计阶段加以规避的合规问题，而不是一个中性的技术事实。

商事与公司应用场景

对于在土耳其经营的公司而言，《土耳其商法典》（TTK，第 6102 号法律）是商人交易的背景规范，它已经在某些通知方面接纳了电子记录与注册电子邮件（KEP）。智能合约可以在以下商事场景中带来实际价值：

• 供货或建设框架中的自动化付款与里程碑，降低回款风险。
• 并购对赌（earn-out）或代币销售中的托管与附条件释放，只有在可验证条件发生时资金才会划转。在跨境交易中，这可能与外国收购方的经营者集中（反垄断）申报门槛产生交集，而该门槛必须独立于任何链上机制单独清关。
• 在股东或许可人之间自动分配进账款项的特许权使用费与收益分成。

即便在这里，治理问题仍牢牢处于传统法律的范畴。土耳其公司的董事会权限、签字权与公司内部批准由 TTK 与公司章程决定——而不是由谁持有钱包私钥决定。在缺乏适当公司授权的情况下执行的智能合约，可能使公司及其董事承担责任。在构建交易结构的外国收购方，应使链上机制与其公司与并购文件保持一致，并在任何公司资金划转之前确认签字权。

风险、漏洞与“代码即法律”的难题

在土耳其法律语境下，“代码即法律（code is law）”这句口号具有误导性。如果智能合约存在漏洞而转移了错误金额，或者某次攻击（exploit）掏空了资金，链上结果并非最终定论。土耳其法律继续承认基于不当得利（TBK 第 77 至 82 条）、瑕疵履行以及侵权责任（TBK 第 49 条及其后各条）的请求权。因编码错误或黑客攻击而受损的一方，仍可通过法院主张返还或损害赔偿——而在涉及追讨欠款或追回资金时，一份可执行的链下协议正是为您提供穿行土耳其制度的路径。

这造成了每一家外国企业都应提前规划的张力：

• 不可篡改性 vs. 纠错。一旦部署，代码可能难以更改，但法律关系仍可通过协议或法院加以纠正或解除。
• 漏洞与预言机风险的分配。预言机（oracle）是智能合约所依赖的链下数据源（如价格、交付确认、汇率）。预言机可能失灵或被操纵，因此链下协议应明确由谁承担代码失败、预言机错误或第三方攻击的后果。
• 争议解决。明确约定一个管辖机构——土耳其法院或仲裁——以及一项准据法，使“是链做的决定”永远不会成为逃避责任的借口。

实例演练：为土耳其供应商设计的链上托管

设想一家外国软件公司希望通过链上托管向一家土耳其供应商付款：资金锁定在智能合约中，并在确认交付后自动释放。一个周密的结构应当是什么样子？

• 协议层。一份英文书面供货合同，按 MÖHUK 5718 选定准据法与管辖法院，约定价格、交付标准，以及当托管代码或其预言机失灵时由谁承担风险。
• 形式核查。一笔普通的供货交易通常属于自由形式，因此链上执行可接受——但要确认没有任何担保或保证要素将其拉入书面或官方形式。
• 监管核查。如果托管持有的是加密资产而非法定货币，应追问该安排是否构成第 7518 号法律下受监管的加密资产服务或托管活动，以及是否适用 MASAK 义务。
• 证据层。保存交易哈希值；在涉及书面形式的场合，以安全电子签名为协议加固，使该记录能够依 HMK 第 205 条第 2 款承载契据级别的效力。

这个例子的要点很简单：代码负责机制运作，但在任何资金划转之前，应有一位土耳其律师统筹合同、形式、监管与证据各个层面。

面向外国企业的实务步骤

在部署涉及土耳其的智能合约之前，外国投资者与企业应当：

1. 确定每一项交易的形式要件（自由形式、书面形式或官方形式），并据此设计。
2. 核查加密资产监管边界：该安排是否构成第 7518 号法律下需要 SPK 许可并履行 MASAK 合规义务的受监管活动？
3. 保留一份起支配作用、人类可读的英文合同，并附有依 MÖHUK 5718 拟定的清晰准据法与管辖条款。
4. 在强制要求书面形式之处使用合格电子签名——并认清在哪些情形下电子签名被完全排除适用。
5. 在任何公司资金于链上划转之前，依 TTK 确认公司授权与签字权。
6. 对代码进行独立审计，并明确由谁承担漏洞、预言机及攻击风险。
7. 将个人数据保留在链下以管理 KVKK 义务，并保存交易数据与翻译件，以备依 HMK 6100 用作潜在证据。

如果您正在构建与土耳其相关的代币销售、托管机制或自动化支付框架，我们的团队可以同时审查法律与技术层面的契合度。请用中文写信给我们——我们以中文与您沟通往来；如有需要，可另行安排中文翻译陪同会议或庭审（费用另计）。请注意，Lexin Legal 的法律服务以英语和土耳其语提供。联系 Lexin Legal，与会讲英语的土耳其律师探讨您的项目。

常见问题