On 2026/04/18 17:35 UTC, threat actors which have been linked to the DPRK with high confidence stole 116,500 rsETH by fraudulently triggering an attestation from the LayerZero DVN, which was configured as the sole validator for the Kelp DAO OApp. Since 2026/04/18 18:34 UTC, SEAL has been actively coordinating incident response efforts alongside Kelp DAO, LayerZero, and other involved parties. As we do not have discretion to disclose any information from the war rooms, we encourage readers to refer to LayerZero’s and Kelp’s statements for context.
While this is still an ongoing incident, and as such facts and circumstances may change, we wanted to share some initial takeaways. We hope to formalize these recommendations in a SEAL Framework once the incident is fully resolved.
What went right
First, it’s worth recognizing that several things went right to mitigate additional damage. Kelp DAO successfully blocked the attacker within an hour (18:23 UTC), preventing additional funds from being lost, and promptly reached out to SEAL 911 (18:34 UTC). From there, we were able to quickly coordinate across LayerZero, Uniswap, Optimism, and other teams in order to narrow down where the potential compromise had occurred, while downstream protocols took preventative action to pause systems until more information was available. Overall, the speed at which the incident was triaged was commendable.
What you need to know
As a result of this incident, there is understandably a lot of concern and confusion around two questions: what does this mean for me as a user of LayerZero, and as a user of RPC gateways.
For protocols built on LayerZero, the DVN architecture allows you to choose which combinations of validators to trust. LayerZero maintains a list of DVN providers, and it’s recommended to have at least two required validators in order to reduce single points of failure. Double check your OApp’s configuration and ensure that you do not have a single point of failure. You may want to contact the DVN operators and ensure that you are not depending on multiple DVNs operated by the same entity.
For applications which rely on RPC gateways to make business-critical decisions, we strongly recommend that you cross-reference results across multiple RPC gateways and assert that all gateways return the same result. A mismatch could indicate a temporary network desync or an ongoing attack. Note that it is fundamentally impossible to assert that a proper state transition occurred from RPC responses alone, so we also recommend that highly sensitive applications run local nodes and apply standard server hardening procedures.
What this means for the ecosystem
This incident raises serious questions around the increasing number of single points of failure distributed across the ecosystem. Centralized cloud providers such as AWS, OVH, Hetzner, and others host critical infrastructure such as RPC gateways, explorers, and indexers, which are then depended on by protocols which custody hundreds of millions of dollars.
Without redundancy, compromising any single point of failure could result in the next ecosystem-wide incident. Therefore, it’s crucial for those in positions of responsibility to exhaustively explore and map out their entire supply chain in order to understand where risk is hidden. Sometimes, these risks are not immediately obvious, such as in the case of a 3-of-5 multisig where 4 people use the same custodian. In addition, the tradeoffs between failing open to ensure availability and failing closed to ensure integrity should be seriously considered, as failing open can mean giving attackers a mechanism to reduce multiple points of failure back into a single point of failure.
It has become increasingly evident that threat actors have moved beyond targeting smart contracts, and so it’s no longer sufficient to simply conduct a code audit. We recommend security-minded protocols refer to SEAL Frameworks for our curated set of best practices, and to ask their auditor about obtaining a SEAL Certification.