买方要 Article 36 智能合约声明，里面究竟要有什么？
把欧盟《数据法案》智能合约请求连到具体协议、部署方、停止机制、归档证据和声明，不要把一次代码审计当成全部答案。
重点监测信号
- 数据共享项目点名 Article 36，并询问谁来出具欧盟符合性声明
- 已部署智能合约执行协议的一部分，但终止、中断或归档证据无人负责
- 买方要求代码审计，访问控制与治理控制却不在现有范围里
收到 Article 36 请求时，不能只附上一份通用区块链审计报告。按照欧盟《数据法案》，先要回答三个问题：智能合约在执行哪一项协议、谁以应用供应商或专业部署方身份替另一方部署它、四类基本要求的证据放在哪里。责任方还要完成符合性评估并出具欧盟符合性声明。
这正是智能合约鉴证或数据共享实施服务商销售负责人在获授权的工业数据空间、区块链工程和采购 Telegram 群里要分辨的内容。“Pilot 前需要 Article 36 certificate”值得查看，但它还没有说明应用、协议、部署方和缺失控制。晚一天看到，可能就错过买方分配这些责任人的设计评审。
定义：Article 36 与“执行一项协议”绑定
《Regulation (EU) 2023/2854》把 Article 36 命名为“执行数据共享协议的智能合约基本要求”。条文针对使用智能合约的应用供应商，或在自己的行业、业务或职业活动中替他人部署智能合约的人；具体场景是执行一项协议或其中一部分。
因此，法律连接点不是“区块链”三个字。某个 token contract、内部原型或无关的去中心化应用，不会因为代码不可变就自动进入 Article 36。人工需要找到协议、代码在协议中执行的功能，以及作为应用供应商或专业部署方的具体一方。
“开发者写了代码”也不是完整责任答案。工程作者、应用供应商、系统集成商和替另一组织完成部署的一方，可能是四个不同实体。
界定工作前，先把四份记录连接起来
用一张适用性说明连接四份记录：
- **协议记录：**参与方、数据共享目的、由代码执行的条款或流程、适用版本和生产日期；
- **部署记录：**应用供应商、专业部署方、运营方、代码仓库，以及部署地址或其他唯一实例编号；
- **控制记录：**稳健性、访问控制、终止或中断、归档与连续性证据；
- **声明记录：**符合性评估负责人、受评版本、采用的标准或技术规范、欧盟符合性声明和变更历史。
这张四记录连接表是本文的原创贡献。它把一句松散的合规用语变成可核查的连接关系，同时保留群聊中尚未出现的信息。TOP Prospect 可以帮助找出填入记录的碎片，却不能完成或批准这张说明。如果协议记录无法连到实际部署版本，再漂亮的审计报告也可能描述的是另一份代码。
四类要求有关联，但不能互相替代
Article 36 列出四类基本要求。
**稳健性和访问控制。**智能合约应提供访问控制机制，并具有很高的稳健程度，避免功能错误、抵御第三方操纵。威胁模型、测试结果、角色定义和部署配置可以成为证据，但安全报告只有与部署记录中的应用和实例版本一致才有用。
**安全终止与中断。**系统必须有机制终止交易继续执行。合约应有内部函数，可以重置，或指示其停止、中断运行，尤其要避免将来意外执行。销售负责人真正该问的不是“有没有 pause button”，而是谁能在什么条件下执行哪种动作，审批在哪里留痕，对待处理交易有什么影响。
**数据归档与连续性。**智能合约必须终止或停用时，设计应允许归档交易数据、合约逻辑和代码，使过去对数据执行的操作仍能审计。只保留 repository snapshot，可能会丢掉部署参数、event log 或协议版本。
**多层访问控制。**Article 36 还要求在治理层和智能合约层采用严格访问控制。函数里有 role check，不等于已经回答谁批准角色分配、紧急动作或生产升级。
示例：审计覆盖代码，却没有连上协议
设想设计评审前出现下面两条残缺消息；它们只用于说明，不是客户证据：
“Port-data pilot 下个月 go live。Procurement 要 Article 36 declaration。”
“v1.8 audit 做完了。Pause role 好像在 integrator 那边。Agreement annex 还在改。”
消息里出现了试点日期、代码版本、可能持有暂停权限的一方和仍在修改的协议附件。它没有给出生产实例、执行条款、应用供应商或专业部署方、治理审批、归档路线、评估负责人和声明。
适用性说明会出现三处红色断点：
- 审计写的是 v1.8，但生产版本与部署地址未知；
- 暂停角色可能在集成商手里，但授权依据与审批记录未知；
- 协议附件仍在变，智能合约实际执行的功能还没有稳定。
这些信息足以成为一条值得跟进的鉴证需求，却不能证明系统符合要求，也不能承诺再补一次渗透测试就能完成声明。
声明必须有边界清楚的评估对象
Article 36 要求责任供应商或部署方进行符合性评估并出具欧盟符合性声明。官方条文还规定：遵循相关协调标准或其中一部分时，可对相应要求推定符合。
对鉴证服务商来说，商务范围要点名受评对象：应用、智能合约版本、部署配置、协议功能与控制集合；还要写明代码、角色、endpoint 或协议发生变化后怎样处理。缺少这条边界，“Article 36 ready”就不是可重复核验的判断。
信息跟踪工具不能根据公开讨论生成这种声明。外部审计也不会自动把判断范围与出具声明的责任从法定责任方手里转走。
发现工具能找到断点，不能判断符合性
产品可以筛选、合并用户主动连接且有权访问的 Telegram 群消息，保留原文、来源和时间，把具名协议、部署版本、停止机制与声明请求放在一起，去除明显重复，再按需要人工查看的顺序排列。
它不能读取私有代码库、测试智能合约、判断 Article 36 是否适用、操作终止控制、执行符合性评估、出具声明或联系群成员。定价与访问方案只覆盖发现层。
相邻的连接产品规则可阅读 Article 4 与 Article 5 证据说明；云服务切换讨论则应查看单独的《数据法案》切换需求文章。
关键事实
- Article 36 位于欧盟《数据法案》Regulation (EU) 2023/2854。
- 它处理用于执行数据共享协议或其中一部分的智能合约，不是所有带区块链标签的合约。
- 条文指向使用智能合约的应用供应商，或在相关情境中替他人专业部署智能合约的一方。
- 四类证据是稳健性与访问控制、安全终止与中断、数据归档与连续性，以及治理层和智能合约层的严格访问控制。
- 归档可以包括交易数据、智能合约逻辑与代码，用来保留过去操作的可审计性。
- 责任方要进行符合性评估并出具欧盟符合性声明。
- 代码审计可以支持证据，却不能单独证明适用性或符合性。
常见问题
Article 36 适用于所有区块链 token 或智能合约吗？
不适用。Article 36 针对使用智能合约的应用供应商，或在执行业务时替他人部署智能合约的人，而且要处在执行一项协议或其中一部分的情境。先要明确协议和部署角色，才能判断范围。
渗透测试或代码审计等于 Article 36 符合性吗？
不等于。技术测试可以提供部分证据，但 Article 36 还覆盖访问控制、安全终止与中断、数据归档与连续性，以及符合性评估和欧盟符合性声明。
智能合约终止时应归档什么？
Article 36 要求能够归档交易数据、智能合约逻辑与代码，使过去对数据执行的操作仍可审计。
谁作最终法律与符合性判断？
责任应用供应商或专业部署方及其顾问要判断适用性、完成规定的符合性工作并出具声明。发现工具只能找出并整理请求证据。
给审计报价前，先确认协议、部署对象、控制证据和声明指向的是同一套实现。
常见问题
Article 36 适用于所有区块链 token 或智能合约吗？
不适用。Article 36 针对使用智能合约的应用供应商，或在执行业务时替他人部署智能合约的人，而且要处在执行一项协议或其中一部分的情境。先要明确协议和部署角色，才能判断范围。
渗透测试或代码审计等于 Article 36 符合性吗？
不等于。技术测试可以提供部分证据，但 Article 36 还覆盖访问控制、安全终止与中断、数据归档与连续性，以及符合性评估和欧盟符合性声明。
智能合约终止时应归档什么？
Article 36 要求能够归档交易数据、智能合约逻辑与代码，使过去对数据执行的操作仍可审计。
谁作最终法律与符合性判断？
责任应用供应商或专业部署方及其顾问要判断适用性、完成规定的符合性工作并出具声明。发现工具只能找出并整理请求证据。
资料来源与延伸阅读
值得关注的潜在线索 Signal 是怎样被发现的
了解 Top商业线索怎样发现和整理值得核实的 Signal、保留 Telegram 原始上下文、去掉重复消息并安排查看顺序。是否跟进以及下一步做什么，仍由用户决定。
