KelpDAO обвинила LayerZero в инфраструктурном сбое после взлома rsETH
KelpDAO опубликовала большой разбор инцидента с rsETH-бриджем и оспорила позицию LayerZero, согласно которой основной причиной взлома была конфигурация Kelp с 1-of-1 DVN.
Инцидент произошёл 18 апреля 2026 года. По версии KelpDAO, атака исходила из инфраструктуры LayerZero Labs и привела к потерям более чем на $300 млн в DeFi. Речь идёт о forged messages, из-за которых были высвобождены 116 500 rsETH.
Отдельно KelpDAO заявила, что ещё две forged-транзакции на сумму более $100 млн были подписаны и обработаны LayerZero Labs DVN, но не привели к дополнительному ущербу, потому что команда Kelp успела вмешаться и поставить контракты на паузу.
Главный спор между сторонами — кто несёт ответственность за 1-of-1 DVN setup. LayerZero ранее указывала, что Kelp использовала single-DVN configuration, то есть один verifier мог подтвердить cross-chain message без второго независимого DVN.
KelpDAO утверждает обратное: такая конфигурация не была уникальной для Kelp и использовалась широко в экосистеме LayerZero. В своём посте Kelp ссылается на Dune-анализ, по которому из примерно 2 665 LayerZero OApp contracts около 47% работали с 1-1 DVN security floor, 45% — с 2-2, и только около 5% — с 3-3 или выше.
Kelp также утверждает, что более 120 OFT использовали 1-1 DVN setup, а около 90% LayerZero messages за предыдущие 90 дней требовали только один или два DVN для verification.
Отдельный аргумент KelpDAO — LayerZero Labs DVN был системно важной частью экосистемы. По версии Kelp, за последние 90 дней 1-1 LayerZero Labs DVN был третьей по использованию конфигурацией, с более чем 100 000 messages.
KelpDAO заявляет, что LayerZero Labs DVN входит в default configurations в документации LayerZero, а LayerZero Labs также выступает sole executor в default configs. В посте Kelp отдельно указывает на LayerZero OFT Quickstart и OFT default template, которые, по её версии, направляют разработчиков к 1-1 setup с LayerZero Labs как required DVN и без optional DVNs.
Kelp также опубликовала скриншоты коммуникаций с представителями LayerZero. По версии Kelp, LayerZero знала о 1-1 DVN configuration, обсуждала её с командой и не предупредила, что такая настройка создаёт material security risk.
Отдельно Kelp указывает на противоречия в публичных заявлениях LayerZero. В частности, Kelp приводит прежние заявления о том, что якобы не было приложений, которые используют только LayerZero Labs DVN, и сопоставляет их с примерами production-сетапов и публичными данными по другим OFT.
В технической части Kelp ссылается на независимые отчёты, согласно которым атака была направлена на off-chain infrastructure, используемую LayerZero Labs DVN для наблюдения за source chain. По этой версии, attackers скомпрометировали RPC-инфраструктуру, заставили DVN подписать сообщение о транзакции, которой не было в canonical chain state, и это привело к выпуску/разблокировке rsETH.
LayerZero в своём postmortem описывала событие как RPC-spoofing attack и указывала, что core protocol, DVN instances и private keys не были скомпрометированы. Kelp спорит с такой рамкой и считает, что с точки зрения integrator именно DVN infrastructure является частью security stack, за которую LayerZero должна нести ответственность.
Kelp также ставит под вопрос тезис LayerZero о том, что protocol “functioned exactly as intended”. Аргумент Kelp: если LayerZero Labs-operated DVN подписал forged messages, то проблема не может быть сведена только к “ошибке пользователя” в настройке.
После инцидента LayerZero объявила, что больше не будет подписывать или attesting messages для приложений с 1-1 DVN configuration. Kelp трактует это как подтверждение того, что такая конфигурация была достаточно широко распространена и была изменена только после крупного сбоя.
KelpDAO также поднимает вопросы к независимости DVN. В посте говорится, что одних повышенных thresholds может быть недостаточно, если разные DVNs имеют общие operational dependencies, shared admin roles или другие централизованные control paths.