2026 年 7 月 24 日，用以太坊抵押债券与 BondToken 管理资产的去中心化协议 Lien Finance，在看似正常运转的链上逻辑中被撕开了一道口子。攻击者将目标锁定在 BondMakerCollateralizedEth 合约的 exchangeEquivalentBonds 函数，利用其只统计异常债券出现总次数、却缺乏多集合完整性与逐组 bondID 校验的设计缺陷，通过重复使用单个异常 bondID，绕过销毁输入债券的约束，铸造出状态正常却没有真实抵押支撑的 BondToken。随后，这些「空心」BondToken 被发送至预授权地址并兑换为 USDC，据慢雾监测，约 54.2 万美元 USDC 就这样从受害地址中被搬走，在攻击者身份与资金后续流向尚未公开的情况下，这起典型的智能合约逻辑漏洞事件，再次把 DeFi 世界对合约安全边界的信任推到质询台前。
54.2 万美元被盗：校验疏漏
顺着资金被搬走的路径往回追，真正的缺口藏在 BondMakerCollateralizedEth 合约的 exchangeEquivalentBonds 函数里。这个函数的职责本应是核对用户提交的一组债券，与目标 BondToken 之间是否等价，尤其要识别并处理其中的异常债券。然而它的设计只停留在“统计”的层面：只记录异常债券出现的总次数，却没有对每一组 bondID 做逐一比对和完整性校验，也没有强制检查每组债券是否真的被合理消耗。换句话说，系统只关心“异常一共出现了几次”，而不关心“是哪几张债券在起作用”。
这种偷懒式的设计，给了攻击者可乘之机。由于未验证每一组 bondID 的完整性，攻击者可以反复使用同一个异常 bondID 来“刷”异常次数，把本该分散在不同债券上的异常计数集中到一张债券上，却不真正销毁对应的输入债券。在合约看来，异常债券数量条件已经满足，于是允许铸造状态正常的 BondToken；在现实中，这些 BondToken 完全没有等量的真实抵押作为支撑。慢雾的分析点出根源——缺乏充分的多集合/多重集合完整性校验——最终把这一逻辑缺陷演化成 54.2 万美元 USDC 的损失，也把多集合场景下“只数数量、不查集合”的危险暴露得异常清晰。
异常债券如何被无限套用
在实际攻击路径中，这个“只数数量、不查集合”的漏洞被一步步放大。攻击者先锁定了一个异常的 bondID，把它当作唯一的“钥匙”，反复调用 exchangeEquivalentBonds 函数。由于合约只统计异常债券出现的总次数，不逐组核对每一组债券是否真的彼此等价，这个单一的异常 bondID 就被无限复用，用来“消耗”异常计数，在账面上达到可以铸造正常 BondToken 的条件。关键在于，函数并没有要求同步销毁输入的异常债券——异常债券还在，输入集合没有被真正削减，输出端却源源不断地产生状态正常的 BondToken。
随后，攻击者将这些本质上“无抵押”的 BondToken 直接发送至预授权地址。这个地址在合约设计中具备兑换权限，可以把收到的 BondToken 兑换为 USDC，却并不会重新检查这些 BondToken背后是否真的有等量的抵押资产支持。于是，在输入债券未销毁、抵押资产未减少的前提下，预授权地址仍照常放行兑换，把受害地址中的 USDC 转出到攻击者控制之下。据慢雾披露，攻击者正是通过这一链条，从受害地址盗取了约 54.2 万美元 USDC，每一步都形式上走在“铸造—兑换”流程之内，却在逻辑上完全绕开了本应严密的“铸造—销毁”约束。
计数校验失守的连锁后果
从表面流程看，Lien Finance 依然沿用了“债券—抵押—铸造—销毁”的常见 DeFi 模型：正常情况下，用户想铸造新的 BondToken，就必须先销毁等量的输入债券，用债券的消失去证明底层抵押资产已经被重新锁定或重新分配。然而在这一事件的核心函数 exchangeEquivalentBonds 中，合约却只对“异常债券”的总次数做了统计，把多集合、多重集合之间的完整性校验简化成一个累加的计数器，完全没有逐次核查每一次铸造到底有没有对应的债券销毁行为。
一旦把复杂资产集合的约束压缩成单一计数，智能合约在链上就失去了对“资产守恒”的真正把控。Lien Finance 这次，多集合完整性校验失败，攻击者得以反复用同一个异常 bondID 消耗异常计数，在账面上“用完”异常额度，却从未真正销毁任何输入债券，从而绕开了铸造必须对应销毁的核心逻辑。在更广泛的 DeFi 场景中，如果类似的“只看总次数、不查每笔”设计出现在其他铸造—销毁环节，同样可能被构造成一种典型的“空手套白狼”攻击路径：攻击者靠合约自身的计数漏洞制造出无抵押的新资产，再通过后续兑换环节把这些凭空生成的资产变成可套现的收益，链上每一步都像在遵守规则，实际却是在系统内部掏空价值。
Lien Finance 的债券玩法风险
在 DeFi 叙事里，Lien Finance 把传统债券拆进链上，把以太坊抵押品包裹进 BondToken，再通过一套到期、清算、兑换逻辑，让用户在链上持有和交易“结构化债券”。这类玩法的核心支点就是 BondMakerCollateralizedEth 等基础合约：它既要管理抵押的 ETH，又要管理多组 bondID 对应的债券状态，是整个债券模型的账本和铸造机。一旦铸造、销毁与状态校验设计稍有疏漏，合约就等于为攻击者预留了一条“从债券到资产”的捷径，攻击面也随债券结构的复杂度指数级放大。
本次事件正是复杂债券玩法在实现层面的反噬：exchangeEquivalentBonds 函数只统计异常债券出现的总次数，却不逐组验证各 bondID，攻击者便可反复使用同一个异常 bondID 消耗计数，在未实际销毁输入债券的情况下铸造出状态正常的 BondToken。随后，这些毫无真实抵押支撑的 BondToken 被送往预授权地址兑换成 USDC，据慢雾监测，最终造成约 54.2 万美元 USDC 损失。对于这类多集合、多状态的链上衍生品合约而言，每一个校验分支、每一个集合完整性检查都直接对应着实打实的资金安全，任何被忽视的细节都可能演化为一次不可逆的协议级资产挖空。
DeFi 合约该补的安全功课
慢雾将此次 Lien Finance 事件明确归因于多集合、尤其是多重集合完整性校验的缺失，这几乎是给所有 DeFi 开发者上的一堂现成反面教材。像 BondMakerCollateralizedEth 这样的资产管理合约，常常要在多个集合之间处理 bondID、状态标记和异常计数，一旦只做“总次数”这种粗粒度统计，而不对每一组输入逐一验证，就为攻击者留下利用同一异常 bondID 反复消耗计数的空间。对这类关键合约，输入验证必须细到每一个 ID、每一组参数、每一个状态转移路径，并通过独立安全审计刻意“拆解”复杂集合操作，模拟极端和异常场景，才能尽可能提前暴露潜在逻辑缺陷。
更深一层的教训在于：DeFi 协议普遍依赖智能合约自动执行资产铸造与销毁逻辑，一旦逻辑允许“未销毁输入却铸造输出”，后果就是直接的资产被盗。行业内已多次呼吁加强形式化验证、第三方安全审计与开源审查，本质上就是要求开发者在设计类似债券、BondToken 这类新型金融结构时，把“可验证、可推演的安全边界”当成首要约束，而不是事后补丁式地修逻辑。从多集合完整性校验、到细粒度输入验证、再到独立审计与公开审查，只有在设计阶段就将这些安全功课落实为硬约束，链上的复杂金融结构才有可能在长期运行中抵挡住类似的合约级攻击。
这次攻击后仍需盯紧的信号
从这起发生在 2026 年的合约级攻击回头看，Lien Finance 暴露出的核心风险点非常具体：一是 BondMakerCollateralizedEth 合约在 exchangeEquivalentBonds 函数中，仅按总次数记录“异常债券”，却没有做多集合、逐组的 bondID 完整性校验，给了攻击者重复消耗单一异常 bondID 的空间；二是在未销毁输入债券的情况下就能铸造非异常状态 BondToken，再通过预授权地址兑换为 USDC，说明资产路径设计与授权边界同样存在薄弱环节。后续最直接需要盯紧的公开信息，是 Lien Finance 团队是否发布详细事件复盘、明确修复方案以及对受影响用户的处理态度，目前这些都仍是悬而未决的变量；同时，还要观察漏洞修复是否真正落地、多集合校验是否被写进新版本合约逻辑，以及类似采用债券/BondToken 结构的其他协议是否主动完成自查与安全更新。对于普通参与者而言，在攻击者身份和被盗 USDC 去向尚未公开、项目方应对仍不明朗的阶段，持续关注上述信号并据此评估个人风险承受度，才是对这次事故最现实的回应方式。
加入我们的社区，一起来讨论，一起变得更强吧！
AiCoin专属Hyperliquid福利：https://app.hyperliquid.xyz/join/AICOIN88
AiCoin专属Aster福利：https://www.asterdex.com/zh-CN/referral/9C50e2
链上电报（Telegram）社群：https://t.me/AiCoinWhaleData
链上社区：https://www.aicoin.com/link/chat?cid=N6OVMor5g
AiCoin链上推特：https://x.com/aicoinwhaledata
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
