每周Web3安全事件汇总 | 2026年4月13日 – 4月19日

在过去一周（2026/04/13 - 2026/04/19），BlockSec 检测并分析了四起攻击事件，预计总损失约为 $310M。下表汇总了这些事件，各案例的详细分析见后续小节。

本周重点：KelpDAO

有关后续连锁影响、Arbitrum 链上恢复机制及更广泛治理影响的专题报告，请参阅：去中心化困境：KelpDAO 危机中的级联风险与紧急权力

本事件之所以被重点关注，在于其新颖的基础设施级攻击向量（针对唯一 DVN 的 RPC 投毒，而非智能合约漏洞利用）、通过 DeFi 可组合性对多条链造成的级联影响，以及 Arbitrum 强制状态转换以追回被盗资金所引发的治理问题。

2026 年 4 月 18 日，KelpDAO 的 rsETH LayerZero OFT 跨链桥遭到攻击，损失约 $290M，攻击者被认定为国家支持的行为者，极可能是朝鲜的 Lazarus Group [1]。根本原因在于 KelpDAO 的 1-of-1 DVN 配置，将跨链消息验证简化为单点故障。攻击者毒化了 LayerZero Labs DVN 所信任的 RPC 基础设施，迫使其为一条伪造的跨链消息背书，导致 116,500 枚 rsETH 在以太坊上被释放，而 Unichain 上并无任何对应的源端事件。

背景

LayerZero 是一个基于模块化安全架构构建的跨链消息传递协议。跨链消息完整性的核心由去中心化验证者网络（DVN）强制执行，DVN 是链下实体，负责在目标链执行消息之前，独立验证源链上确实发生了该消息所对应的事件。每个部署在 LayerZero 上的应用程序都自行配置 DVN 设置，包括信任哪些 DVN、需要多少个 DVN，以及必须满足的共识阈值。这种模块化设计赋予应用程序对其安全模型的完全控制权，同时也意味着完全的责任：弱配置无法由协议本身来托底。

KelpDAO 的 rsETH 以 OFT（全链同质化代币）形式部署在 LayerZero 上，跨链路由连接 Unichain（源链）和以太坊主网（目标链）。OFT 标准允许在源链销毁代币并从目标链的锁定中释放，跨链消息是释放操作的唯一授权。以太坊端适配器（0x85d456...e98ef3）负责在有效的跨链消息经过验证和传递后，向接收者释放 rsETH。关键在于，KelpDAO 为该路由配置了 1-of-1 DVN 设置，指定 LayerZero Labs 为唯一验证者。这意味着单个 DVN 的背书即可授权任何代币释放，无需第二方复核。

为履行其验证职责，LayerZero Labs DVN 查询多个 RPC 节点，以确认源链上确实发生了跨链发送事件。这些 RPC 节点包括自营基础设施和外部提供商，DVN 在签署背书之前依赖这些节点的集体响应。该流程的完整性依赖于大多数被查询节点返回真实数据这一假设。

漏洞分析

该漏洞是基础设施和配置层面的系统性失败，由三个相互叠加的薄弱环节构成。

首先，KelpDAO 的 1-of-1 DVN 配置消除了验证层的所有冗余。LayerZero 推荐的安全姿态明确要求具有独立验证者的多 DVN 设置，使得任何单一 DVN 无法单方面授权消息。由于仅依赖 LayerZero Labs DVN，KelpDAO 确保了该单一验证者一旦被攻破，就足以授权任意代币释放。

其次，DVN 的故障转移机制会将验证查询路由到仍然可达的 RPC 节点。这种设计假设节点不可用是偶然的，而非蓄意为之。然而，这造成了一种状况：攻击者无需攻破所有数据源——通过 DDoS 使健康节点下线，并预先准备好被投毒的节点作为唯一可达替代，攻击者就能完全控制 DVN 所接收的数据。

第三，在 RPC 节点上替换 op-geth 可执行文件需要对底层服务器具有操作系统级访问权限。确切的初始访问向量未被披露，但在不同集群上攻破两个独立节点，可能表明这些服务器的访问控制存在共同薄弱点。

这三个条件共同构成了完整的攻击链：第一个确保没有独立的 DVN 来交叉核验被背书的消息；第二个确保攻击者能完全控制唯一 DVN 所接收的数据；第三个提供了使数据操纵成为可能的初始立足点。任何单一薄弱环节单独存在都不足以完成攻击。若非 1-of-1 配置，查询独立基础设施的第二个 DVN 将拒绝伪造消息。若非故障转移行为，健康节点将以多数票压倒被投毒节点。若非服务器被攻破，攻击者将无从注入伪造数据。

攻击分析

以下分析基于交易 0x1ae232...4222 及 LayerZero Labs 发布的官方事件声明。

• 步骤 1：攻击者获取了 LayerZero Labs DVN 所信任的特定 RPC 节点列表。该列表构成高价值情报目标，因为知晓确切节点允许攻击者策划精准打击，而非大范围基础设施攻击。

• 步骤 2：攻击者获得了对两个 RPC 节点的操作系统级写入权限，并将正在运行的 op-geth 二进制文件替换为恶意版本。这两个节点被描述为运行在相互独立、没有直接连接的集群上，这表明初始访问向量涉及共享的上游依赖（例如，被攻破的部署凭据、CI/CD 流水线，或对同时拥有两者访问权限的操作员实施社会工程学攻击）。LayerZero Labs 未披露确切的初始访问方法。此步骤是所有后续数据操纵的前提。

• 步骤 3：恶意 op-geth 二进制文件实现了定向响应逻辑：它仅向 DVN 的 IP 地址返回伪造的交易数据，同时向所有其他请求者（包括 LayerZero 自己的监控基础设施、区块浏览器和扫描服务）提供真实的区块链状态。这种选择性投毒使攻击对所有现有可观测系统不可见；从任何外部视角来看，源链表现正常。

• 步骤 4：DVN 的内部共识需要被投毒和未被攻破的 RPC 节点之间达成一致。为解决这一矛盾，攻击者在攻击窗口期间（太平洋时间上午 10:20 至 11:40）对剩余健康节点发动 DDoS 攻击，触发 DVN 的故障转移逻辑，迫使其仅依赖被投毒的基础设施。此步骤是必要的，因为健康节点否则将返回与伪造响应相矛盾的真实数据。

• 步骤 5：由于 DVN 现在只接收攻击者控制的数据，一条伪造的 LayerZero 跨链消息被呈现为有效消息。DVN 在以太坊目标端点为 nonce 308 背书，而该 nonce 在 Unichain 上没有任何对应的出站事件（由源端点仍报告最大出站 nonce 为 307 所证实）。

• 步骤 6：以太坊端的 rsETH 适配器收到经有效背书的消息后，向攻击者的接收地址（0x8b1b6c...0d3b，该地址在数小时前已通过 Tornado Cash 预先注资）释放了 116,500 枚 rsETH。被盗代币随即分散至七个分支钱包，并通过 Aave 抵押头寸、直接兑换 ETH 以及再次跨链至 Arbitrum 的方式变现，最终收益汇聚于以太坊上的 0x5d3919...7ccc 及 Arbitrum 上的对应收集地址。

• 步骤 7：恶意二进制文件在完成后执行了自毁例程，删除自身及所有本地日志和配置文件。这严重阻碍了事后取证恢复工作，充分体现了攻击者高超的作战水平。

• 步骤 8：攻击者随后试图利用相同路径再次盗取 40,000 枚 rsETH（约 $95M），但在 KelpDAO 发现异常并暂停以太坊主网及 L2 上所有相关合约后，该尝试被阻止 [2]。

更广泛的影响

损失远不止初始的 $290M 跨链桥漏洞利用。攻击者在多个市场向 Aave 存入约 89,567 枚 rsETH（约 $221M），以 E-Mode 93% 的 LTV 借出 WETH [4]。由于 Aave 无法区分合法跨链的 rsETH 与通过伪造消息释放的代币，这些"被投毒"的抵押品被视为完全有效。由此引发的 WETH 储备冻结在以太坊、Arbitrum、Base、Mantle 和 Linea 上蔓延，影响了与 rsETH 毫无关联的用户。这种级联传播——从单一跨链桥配置缺陷到多链借贷市场崩溃——生动说明了 DeFi 可组合性如何放大单点故障的影响范围与成本。

事件余波同样引发了关于去中心化运营现实的重要问题。LayerZero Labs 宣布，其 DVN 将不再为使用 1-of-1 配置的应用程序签署消息 [1]，这意味着协议层面的去中心化本身无法弥补应用层配置的薄弱。

在链的层面，Arbitrum 安全委员会执行了一项紧急行动，冻结攻击者在 Arbitrum One 上持有的 30,766 枚 ETH。据 BlockSec 分析 [5]，这通过链级强制状态转换实现：安全委员会临时升级以太坊收件箱合约，注入一条模拟攻击者地址的未签名 L1 至 L2 消息，并恢复原始实现——整个过程无需持有者签名 [3]。

此举是对治理定义的紧急权力的合法行使，以透明方式进行并与执法机构协调配合。然而，它同时也表明，L2 链在设计上保留了中心化干预能力：原则上，Arbitrum One 上的任何资产都可通过相同机制由安全委员会转移。正如本次事件在每个层面所揭示的，系统理论信任模型与其实际信任边界之间的差距，正是最重大风险所在。

结论

本次事件表明，跨链桥安全不能仅归结为协议正确性。LayerZero 协议本身按设计运行；漏洞完全存在于其上方的运营层。核心教训是：链下验证基础设施是信任边界的一部分，其安全姿态必须与其所保护的价值相匹配。

以下三项缓解措施中的任何一项都能单独防止此次事件的发生：

• 多 DVN 配置：要求多个独立 DVN 达成共识，将使单个 DVN 被攻破不足以授权消息，无论该 DVN 被欺骗的程度有多深。

• 具备故障转移意识的 RPC 节点选择：在活跃验证窗口期间，可达节点数量的突然下降应被视为潜在攻击信号，而非常规可用性事件。DVN 实现应在节点集减少时暂停或发出警报，而非继续运行。

• RPC 基础设施加固：在生产环境 RPC 节点上替换正在运行的可执行文件的能力，表明底层服务器的访问控制不足。DVN 依赖其获取源链真实数据的基础设施，应与 DVN 签名实例本身受到同等安全边界的保护。

更广泛而言，任何依赖链下背书的跨链桥或跨链协议，都应审计的不仅是智能合约层，还包括从源链事件到目标链执行的完整数据管道。当数亿美元资产依赖于此时，默认认为 RPC 基础设施可信的假设已不再站得住脚。

参考资料

[1] LayerZero Labs，"KelpDAO 事件声明"，2026 年 4 月 20 日。https://x.com/LayerZero_Core/status/2046081551574983137

[2] KelpDAO，"4 月 18 日事件：补充背景"，2026 年 4 月 21 日。https://x.com/KelpDAO/status/2046332070277091807

[3] Arbitrum，"安全委员会紧急行动"，2026 年 4 月 21 日。https://x.com/arbitrum/status/2046435443680346189

[4] LlamaRisk，"rsETH 事件报告"，2026 年 4 月 20 日。https://governance.aave.com/t/rseth-incident-report-april-20-2026/24580

[5] BlockSec，"Arbitrum 安全委员会冻结机制分析"，2026 年 4 月 21 日。https://x.com/Phalcon_xyz/status/2046467830498173088

本周更多事件

Rhea Finance

2026 年 4 月 16 日，Rhea Finance 旗下 NEAR 上的借贷与保证金交易协议 Burrowland 因其保证金交易模块中存在业务逻辑缺陷，遭受约 $18.4M 的攻击损失。在开设杠杆头寸时，协议依赖 verify_token_out() 在接受头寸前验证预期的兑换输出。然而，每当代币与最终输出代币匹配时，该函数会错误地累加中间兑换步骤的 token_out 金额，未能考虑到这些中间金额随后被重新用作 token_in 的事实。攻击者部署了虚假代币和流动性池，构造了一条循环兑换路径，将感知输出金额虚增并通过偿付能力检查，从协议中盗取约 $18.4M。

背景

Burrowland 是 NEAR 上的一个开源借贷与保证金交易协议。除标准的存款和借款功能外，它还支持保证金交易，并引入三个关键变量来表示用户的杠杆头寸：token_c（抵押品）、token_d（债务资产）和 token_p（头寸资产）。

对于做多头寸，用户存入 token_c 作为抵押品，并以选定的杠杆（例如 5 倍）借入 token_d。借入的 token_d 随后在 DEX 上兑换为 token_p，即用户希望获得敞口的资产。正常情况下，收到的 token_p 价值约等于花费的 token_d 价值。协议代表用户托管 token_p，同时将借入的 token_d 记录为债务。

对于做空头寸，用户同样存入 token_c 并以杠杆借入 token_d（他们希望做空的资产）。借入的 token_d 被兑换为另一种资产（token_p），从而有效建立对 token_d 的空头敞口。同样，在正常市场条件下，兑换预计能保值。

在头寸的整个生命周期内，token_p 保管在协议内，用户无法直接提取。头寸必须平仓才能实现盈亏，届时 token_p 被兑换回 token_d 以偿还债务。

开设保证金头寸由 internal_margin_open_position() 处理，该函数设置头寸参数并向 DEX 发起借款。

在协议接受新头寸之前，它会依次评估四项保护措施：is_min_amount_out_reasonable() 将用户声明的 min_token_p_amount 与 Pyth 预言机隐含的兑换输出进行交叉核验以限制滑点；is_open_position_liquidatable() 验证预期的头寸加抵押品价值超过清算线；is_open_position_forcecloseable() 验证账户在账面上尚未资不抵债；get_open_position_lr() 确保 token_d / token_c 价值不超过最大杠杆率。

所有四项检查都使用 min_token_p_amount 作为头寸资产的价值，因为兑换尚未执行，没有已实现金额可用。因此，每个关卡的正确性都取决于 min_token_p_amount 与 DEX 实际将交付的金额之间的约束关系。而这一约束正是 verify_token_out()（通过 RefV1TokenReceiverMessage::get_token_out() 实现）应在用户提交的兑换消息上强制执行的。

漏洞分析

缺陷位于 verify_token_out() 内部。该函数将最后一个兑换步骤的 token_out 作为最终输出代币，然后对所有产生相同代币的兑换步骤的声明 min_amount_out 求和，假设每次此类产出都对最终输出有贡献。这对于真正的多路径（拆分路由）兑换是正确的，但它不排除那些 token_out 立即被用作下一步 token_in 的步骤。像 A->B->A->B 这样的往返路径会导致每个 ->B 步骤都被计入总和，即使其输出在后续的 B->A 步骤中被消耗，从未到达 Burrowland。verify_token_out() 批准的累计 min_amount_out 不再代表 DEX 实际将返回的金额。

一旦绕过 verify_token_out()，虚增的 min_token_p_amount 在整个 internal_margin_open_position() 中被视为基准事实。每个本应阻止不安全开仓的偿付能力关卡都针对虚假数字进行计算，因此头寸被接受，协议携带循环兑换消息向 DEX 发送借入的 token_d。

攻击分析

以下分析基于交易 GcXEKm...fnFT。

阶段一：部署虚假代币和流动性池

攻击者部署了三种虚假代币并创建了五个虚假流动性池。

1. 虚假代币 ID：

   1. Fake1: 31623e1d98275d2b0db4f50e102f6bf40877c1345e06e4ca6727f58c89564bb2

   2. Fake2: 6a28e3d3c7af1415ec22c6264013e1138bab00f85b8b6055d882d7d46afdf49b

   3. Fake3: e081e03daf58f5bb04cf95a03017e58449b76e704f1974771d7e3bd52835b6e5

2. 虚假流动性池 ID：

   1. Zec-Fake1: 7509

   2. Fake1-Fake2: 7510

   3. USDC-Fake2: 7511

   4. Fake2-Fake3: 7512

   5. Fake3-USDC: 7513

阶段二：开设保证金头寸

• 步骤 1：攻击者利用 Burrowland 的保证金交易功能，以合法有价值的资产作为 token_c、真实储备资产作为 token_d 开设杠杆头寸，并附上一条兑换消息，其操作列表为完全路由经由阶段一攻击者控制流动性池的往返路径 A->B->A->B。

• 步骤 2：由于 verify_token_out() 对所有 token_out 与终端输出匹配的步骤求和 min_amount_out，往返路径使攻击者能够将声明的 min_token_p_amount 虚增至任意值。

• 步骤 3：虚增的 min_token_p_amount 通过了 internal_margin_open_position() 中的所有开仓时健康检查，头寸被接受，协议向 Ref-Finance 发送了 token_d。

• 步骤 4：循环兑换仅返回极少量的 token_p；on_open_trade_return() 在未进行任何重新检查的情况下将其入账，导致头寸从创建起就资不抵债。

• 步骤 5：借入的 token_d 在路径上的攻击者控制流动性池内结算；攻击者通过 remove_liquidity() 将其提取。

• 步骤 6：由于借款是杠杆化的，提取的 token_d 价值超过存入的 token_c。差额即为每次循环的净利润，无法收回的债务被强制平仓至 protocol_debts。攻击者重复此操作，直至从协议中榨取约 $18.4M。

结论

本次事件由 Burrowland 保证金开仓路径中的业务逻辑缺陷引起。函数 RefV1TokenReceiverMessage::get_token_out() 在中间输出与最终代币匹配时错误地进行了累加，假设这些金额将作为最终输出保留。然而，循环兑换路径打破了这一假设，因为这些代币可能在路径内被重复使用和消耗。因此，计算出的 min_token_p_amount 可能被人为虚增，导致所有后续偿付能力检查依赖于不正确的值，允许在不验证实际收到金额的情况下针对虚假健康状态开设头寸。

对于生产环境的保证金交易合约，开发者应：

• 将用户声明的 min_amount_out 视为未经验证的输入，要么仅采用最后一跳的 min_amount_out，要么明确拒绝重复消耗之前产生的 token_out 的兑换路径（目标代币不得有循环）。

• 用预言机隐含兑换输出的下限和上限双重包络来约束声明的滑点，使攻击者无法单方面虚增声明值以绕过偿付能力判断。

Hyperbridge

2026 年 4 月 13 日，以太坊上的跨链消息桥 Hyperbridge 因 MMR（Merkle Mountain Range）证明验证逻辑中缺少输入验证而遭受攻击，损失约 $242K。函数 MerkleMountainRange.VerifyProof() 未强制要求 leaf_index < leafCount，允许攻击者伪造跨链证明并执行特权操作，包括铸造 1,000,000,000 枚 DOT 代币。

背景

Hyperbridge 在以太坊侧采用验证者和分发者模型进行跨链消息传递。在以太坊上，合约 HandlerV1 针对存储的 overlayRoot 验证提供的证明，若证明被接受，则将消息分发至目标模块，如合约 TokenGateway。

合约 TokenGateway 是一个特权资产管理模块。除正常的资产跨链外，它还支持治理式操作，如资产创建、注销和管理员管理。对于以 ERC6160Ext20 实现的跨链资产，管理员可通过调用 changeAdmin() 直接转移铸币权，新管理员随后可通过 mint() 铸造任意数量。

这意味着整个资产跨链桥的安全性取决于 HandlerV1 中证明验证路径的正确性。若伪造消息能通过验证，下游模块将把攻击者控制的载荷视为真实的跨链指令。

漏洞分析

核心问题位于合约 HandlerV1（0x6c84ed...6d64）中的 MMR 证明验证流程。入口函数 handlePostRequests() 首先根据攻击者提供的输入构建 MmrLeaf(leaf.kIndex, leaf.index, commitment)，然后调用 MerkleMountainRange.VerifyProof() 执行证明验证。

MerkleMountainRange.VerifyProof(root, request.proof.multiproof, leaves, request.proof.leafCount)

然而，VerifyProof() 仅检查 root == CalculateRoot(proof, leaves, mmrSize)，并未验证每个 leaf.index 是否在范围内（即 leaf.index < leafCount）。通过选择 leafCount = 1 和 leaf_index = 1，攻击者使 CalculateRoot() 跳过将伪造的请求承诺折叠进计算根的步骤，直接返回峰值根。这打破了消息与证明的绑定关系，允许任意载荷通过历史 overlayRoot 的有效性验证。

攻击分析

以下分析基于交易 0x240aeb...1109 [1]。

• 步骤 1：攻击者 EOA 0xC513...F8E7 在同一笔交易中部署了辅助合约 0x518A...8f26 和 0x31a1...ca9AB。

• 步骤 2：辅助合约 0x31a1...ca9AB 通过 HandlerV1 中存在漏洞的验证路径提交了一条伪造请求。由于 VerifyProof() 未拒绝越界的 leaf_index，伪造的请求承诺被从根计算中省略，但证明仍与历史 overlayRoot 匹配。

• 步骤 3：伪造消息被接受后，HandlerV1 将其分发至 TokenGateway，执行 ChangeAssetAdmin 操作。这将 DOT 代币的管理员更改为攻击者控制的辅助合约 0x31a1...ca9AB。

• 步骤 4：辅助合约铸造了 1,000,000,000e18 枚 DOT 代币。

• 步骤 5：辅助合约通过 Odos Router V3 将新铸造的 DOT 代币兑换为 108.2 枚 ETH。

• 步骤 6：攻击者将 108.2 枚 ETH 转移至其 EOA 账户。

结论

本次事件由 Hyperbridge MMR 验证逻辑中的不当证明验证引起。由于未强制要求 leaf_index < leafCount，攻击者能够伪造一条承诺从未实际包含在计算根中的消息，却仍能通过对历史状态根的验证。缓解措施应在证明验证之前强制执行严格的边界检查，例如 leaf_index < leafCount。

参考资料

[1] BlockSec，"Hyperbridge 攻击分析"，2026 年 4 月 13 日。https://x.com/Phalcon_xyz/status/2043601549893738970

Dango

2026 年 4 月 13 日，以 Cosmos AppChain 形式构建的永续合约 DEX Dango 因缺少符号检查而遭受攻击，损失约 $1.5M。函数 replenish_insurance_fund() 使用 is_non_zero() 而非 is_positive() 来验证输入金额，允许攻击者提供负的 UsdValue，从而将保险基金耗尽至其保证金头寸。

背景

Dango 是一个以 Cosmos AppChain 形式构建的永续合约 DEX。用户将 USDC 作为抵押品存入永续合约，并通过链上中央限价订单簿（CLOB）对 BTC、ETH、SOL 等资产开设杠杆多头或空头头寸。每位用户的抵押品余额在永续合约内以保证金账户的形式记录。

为保护流动性提供者（LP）免受坏账损失，协议维护一个保险基金：一笔持有在永续合约内的 USDC 储备，用于弥补被清算头寸的抵押品不足以完全偿还债务时的缺口。若无保险基金，此类缺口将直接由 LP 承担。任何用户都可以从其永续账户中向保险基金捐款。

漏洞分析

根本原因在于合约 0x90bc84...bea4f 的函数 replenish_insurance_fund() 未拒绝负输入金额。该函数有两个守卫，但均无法阻止负的 amount：

1. ensure!(amount.is_non_zero()) 检查金额不为零，但不检查其是否为正数。
2. ensure!(user_state.margin >= amount) 检查用户是否有足够的保证金，但任何正的保证金都满足 >= 负数。

在两个守卫均通过后，函数执行 user_state.margin.checked_sub_assign(amount) 和 state.insurance_fund.checked_add_assign(amount)。当 amount 为负数时，减去它会增加用户的保证金，加上它会减少保险基金，完全颠覆了预期的资金流向。

攻击分析

交易记录：

阶段一：

在交易 1 中，攻击者执行了以下步骤以耗尽 Dango 保险基金中的资产：

• 步骤 1：攻击者通过存入 1e6 USDC 开设了一个保证金头寸。这是调用 replenish_insurance_fund() 的前提条件。

• 步骤 2：攻击者以负的 amount（即 -1500000）调用 replenish_insurance_fund()。由于验证不当，负的 amount 被接受，将保险基金中的资产耗尽至攻击者的保证金头寸。

• 步骤 3：攻击者从保证金头寸中提取所有资产，获得 $1,500,000 的 USDC。

阶段二：

在交易 2-8 中，攻击者调用 transfer_remote() 将被盗资产跨链至以太坊。最终，$410,000 的 USDC 被跨链至以太坊。

结论

本次攻击的本质是在无符号上下文中使用了有符号整数类型，且缺少符号守卫。UsdValue 类型在设计上是有符号的（永续合约盈亏可以为负），但保险基金捐款路径仅对正数贡献有意义。使用 is_non_zero() 而非 is_positive() 留下了一字之差的漏洞，允许任何调用者颠覆资金流向，将 USDC 从保险基金耗尽至其自身保证金。攻击者在单笔交易中完成了整个攻击（存入 $1，耗尽 $1.5M，提取 $1,500,001），随后缓慢将资金跨链转出。跨链桥的速率限制是唯一限制损失的机制：若无此限制，全部约 $1.5M 将被不可挽回地跨链至以太坊。

关于 BlockSec

BlockSec 是一家全栈区块链安全与加密合规服务提供商。我们构建产品和服务，帮助客户在协议和平台的完整生命周期内执行代码审计（包括智能合约、区块链和钱包）、实时拦截攻击、分析事件、追踪非法资金，并履行 AML/CFT 义务。

BlockSec 已在知名会议上发表多篇区块链安全论文，报告了多起 DeFi 应用的零日攻击，阻止了多起黑客攻击并成功挽救超过 2000 万美元，同时为数十亿美元的加密资产提供安全保障。

• 官方网站：https://blocksec.com/

• 官方 Twitter 账号：https://twitter.com/BlockSecTeam

• 🔗 BlockSec 审计服务 : 提交申请

• 🔗 Phalcon Security 应用：预约演示

• 🔗 Phalcon 合规