从 yETH 漏洞事件中我们能汲取一个重要的法律教训：必须有意识地将极端情况和协议故障模式纳入实际产品条款，并且这些条款需要随着产品的发展以及市场规范和先例的演变而不断更新。DeFi 架构瞬息万变，法律框架也必须随之调整。如果产品可能以某种特定方式失效，相关协议就应该直接针对该失效模式做出规定。 现在来说说事实。 本周 yETH 遭到攻击。稳定交换式合约中的一个数学漏洞允许攻击者通过单笔交易无限增发 yETH。这并非预言机操纵或闪电贷操纵，而是AMM数学模型的结构性崩溃。不变公式中缺失的除法运算使得攻击者能够增发 2.35e38 个 yETH，然后将这些虚假供应量兑换成资金池中所有真实的抵押品。约 1100 万美元的 stETH、rETH、cbETH 和ETH被盗。约 1000 美元的ETH通过 Tornado Cash 被转移。剩余被盗的 LST 抵押品仍存放在攻击者的钱包中。yETH 实际上已失去担保。 Yearn 已确认此次事件，暂停了资金池，并澄清这是一个独立的 yPool，并非 Vault V2 或 V3 的一部分。SEAL 911 和 ChainSecurity 已介入调查。此次故障模式与近期其他稳定币池崩溃事件极为相似。一个精度或不变性错误就可能导致单笔交易流动性清空，且没有任何保护措施和追索途径。 就法律方面而言：据我所知，Yearn 并未发布针对其 dApp 前端或 yETH 产品的传统服务条款。我也没有找到任何正式的用户协议，其中规定了责任分配、用户确认、放弃索赔、限制担保、确定适用法律或规定争议解决流程。Yearn 发布的只是一个通用的风险页面，警告用户智能合约可能失败，资金可能损失。这些只是高层次的风险披露，并非合同保护条款，也不具备法律效力，不能作为可强制执行的弃权或限制条款。 这种差距在早期 DeFi 领域很常见，但对于现代结构化产品而言是不可行的。而且，这种差距不仅仅存在于 Yearn 等平台。 任何接受 yETH 作为抵押品的协议现在都面临着次要的法律风险。如果其用户头寸受损，他们可能会向这些协议寻求赔偿。他们是否已通过合同免除对上游协议故障的责任至关重要。如果他们的服务条款过于笼统或根本不存在，那么仅仅因为他们距离用户最近，他们就可能无意中成为集成链中损失最大的一方。 同样的问题也适用于 DeFi 聚合器前端，它们通常提供统一的界面，却忽略了每个集成协议的风险或故障模式。如果聚合器将用户引导至 yETH，而用户依赖的是聚合器的用户体验而非协议层面的文档，那么聚合器自身的服务条款（或缺乏服务条款）就显得至关重要。这些平台需要明确制定以下条款： • 它们能做什么和不能做什么 • 他们是否承担底层协议故障的责任 • 当集成资产崩溃时，如何处理用户索赔 • 随着集成的变化，风险披露信息如何呈现和更新 对于建筑商而言，治理负担是实际存在的。您的文档必须反映真实的工程风险面，以及从您集成的协议中继承的风险。这包括： • LST、AMM、包装器和抵押品链之间的依赖关系和级联故障场景 • 破产、脱钩、流动性不足或不可赎回事件 • 损失、漏洞、协议破产、削减和紧急授权的定义 • 如果抵押品受损，用户索赔如何处理 • DAO、贡献者、附属机构和升级密钥持有者之间如何分配责任 • 随着产品及其集成功能的演进，条款将如何更新 这些系统不会以千篇一律的方式失效。法律框架也不应千篇一律。 对用户而言，现实依然如故。DeFi收益伴随着结构性风险，而且由于缺乏约束性条款或保险，一旦合约违约，经济损失将由用户承担。 我正在撰写一篇更深入的文章，探讨技术根本原因、对集成协议和聚合器的法律影响，以及如何通过更有针对性的草案来控制此次事件的影响范围。如果您想审阅或投稿，请私信联系我。 如果你正在开发这类产品，那么这正是我们律所 @DayOneLaw 最为关注的问题类型。我乐于帮助团队提前思考这些风险，以便他们能够快速交付产品，避免日后触及法律雷区。