Le montant n'est pas nouveau. Le conflit, lui, change de nature. Le 18 avril, un attaquant a provoqué la libération de 116 500 rsETH, alors valorisés autour de 292 millions de dollars, depuis le système de bridge utilisé par KelpDAO. Le 24 septembre, Evercrest Technologies a déposé une notice of civil claim en Colombie-Britannique. KelpDAO a rendu l'action publique le lendemain.

La plainte vise LayerZero Labs Ltd., LayerZero Labs Canada Inc. et le cofondateur Bryan Pellegrino. Selon les comptes rendus du document, Evercrest invoque notamment la négligence, la présentation négligente d'informations et la diffamation, et demande différents dommages, dont des dommages aggravés et punitifs. Ces accusations sont celles du demandeur : aucune juridiction n'a encore établi la responsabilité des défendeurs.

L'attaque a bien compromis une infrastructure opérée par LayerZero

Sur la mécanique technique fondamentale, il existe désormais davantage de terrain commun qu'en avril. Le rapport d'incident publié par LayerZero en mai reconnaît que l'attaque a commencé le 6 mars par de l'ingénierie sociale visant un développeur de LayerZero Labs. L'assaillant a obtenu des éléments de session, pénétré l'environnement cloud RPC de l'entreprise puis modifié des nœuds internes afin qu'ils renvoient une fausse représentation de l'état de la blockchain au DVN de LayerZero.

L'attaque ne reposait pas uniquement sur ces RPC empoisonnés. LayerZero indique qu'un fournisseur RPC externe a également subi une attaque par déni de service. Son service de signature s'est alors retrouvé à s'appuyer sur les deux nœuds internes compromis et a produit une attestation valide pour un message cross-chain qui ne correspondait pas à l'état réel de la chaîne source.

Le protocole de destination a accepté cette attestation. Le résultat a été la sortie de 116 500 rsETH. LayerZero précise dans son rapport que son protocole onchain lui-même n'avait pas été compromis et qu'aucune autre application n'avait subi le même incident.

Kelp avait donné une première lecture assez proche sur un point dès le 19 avril : son équipe expliquait que l'infrastructure de vérification du bridge, opérée par un fournisseur tiers, avait été compromise et que les contrats principaux de restaking, le token rsETH sur Ethereum et les dépôts EigenLayer sous-jacents restaient intacts.

Le désaccord commence avec un chiffre : 1-of-1

Le bridge concerné exigeait l'attestation d'un seul Decentralized Verifier Network, celui exploité par LayerZero Labs. Dans cette configuration 1-of-1, aucune seconde source de vérification indépendante n'était nécessaire pour rejeter le message falsifié.

La première communication de LayerZero après l'incident a été très dure sur ce point. L'entreprise affirmait alors que KelpDAO avait choisi une configuration à vérificateur unique contrairement au modèle multi-DVN qu'elle disait recommander à ses intégrateurs. Avec deux vérificateurs indépendants ou davantage, compromission du DVN LayerZero ou non, l'attestation falsifiée n'aurait pas suffi à elle seule.

C'est justement cette chronologie que la plainte remet en cause. Evercrest affirme que LayerZero avait examiné la configuration de Kelp et l'avait approuvée par écrit. La société soutient notamment qu'en février 2024 LayerZero n'avait identifié aucun problème avec sa configuration par défaut, puis qu'en mars l'entreprise l'avait orientée vers un montage 1-of-1 utilisant son propre DVN.

Evercrest affirme également ne pas avoir reçu l'avertissement spécifique que LayerZero dit aujourd'hui avoir toujours donné sur ce risque. La plainte avance en parallèle que LayerZero aurait averti au moins un autre développeur des dangers liés à certaines configurations par défaut avant l'exploit de Kelp. Ce sont des allégations qui devront être confrontées aux communications et documents des deux sociétés pendant la procédure.

Entre les deux versions, LayerZero a déjà changé de discours

Un élément complique fortement la lecture binaire « mauvaise configuration contre mauvaise infrastructure ». Le 8 mai, LayerZero a publié une mise à jour beaucoup plus autocritique que son message initial.

L'entreprise y reconnaissait avoir commis une erreur en permettant à son propre DVN d'opérer comme unique vérificateur pour des transactions de grande valeur. Elle expliquait ne pas avoir suffisamment surveillé ce que son DVN sécurisait et assumait cette erreur opérationnelle. Depuis l'incident, le DVN de LayerZero refuse de signer lorsqu'il est l'unique vérificateur requis.

Cela ne revient pas pour autant à reconnaître la thèse juridique de KelpDAO. LayerZero continue de défendre une architecture où chaque application choisit ses propres hypothèses de sécurité et considère qu'un seul DVN crée par construction un point de défaillance unique. L'entreprise recommande désormais au moins deux parties indépendantes, et plutôt trois à cinq pour renforcer la redondance.

Le rapport final de mai conserve cette distinction : l'infrastructure RPC de LayerZero Labs a été compromise, mais l'impact n'a pu se matérialiser que parce qu'une attestation du seul DVN configuré suffisait à valider le message.

Voilà précisément pourquoi la plainte est plus intéressante qu'un simple nouveau tour de la guerre de communication. Les deux causes peuvent coexister techniquement. Une infrastructure peut être compromise et une architecture cliente peut manquer de redondance. La question judiciaire sera de déterminer quelles obligations existaient entre les sociétés, quelles recommandations ont réellement été formulées, ce qui a été approuvé et qui devait supporter le risque associé à cette combinaison.

Le dossier porte aussi sur ce qui s'est passé après le hack

Evercrest ne limite pas son action à la conception du bridge. La société reproche également à LayerZero et à Pellegrino d'avoir publiquement attribué la responsabilité de l'incident à KelpDAO après l'attaque. C'est ce volet qui explique notamment la présence d'une demande liée à la diffamation dans les comptes rendus de la plainte.

Pellegrino rejette la procédure. Après le dépôt, il a qualifié la plainte de « meritless » et indiqué qu'il défendrait sa position à Vancouver. LayerZero n'a donc pas accepté la lecture juridique proposée par Evercrest.

Les conséquences du hack ont entre-temps dépassé le bridge lui-même. rsETH était intégré à de nombreux protocoles DeFi et utilisé comme collatéral. Kelp a également réduit l'empreinte multichaîne du token après l'incident : plusieurs réseaux ont été retirés du système de bridging et un processus de récupération a été organisé pour les détenteurs restés sur ces chaînes.

L'affaire arrive surtout à un moment où une part croissante de la DeFi repose sur des briques opérées par plusieurs entreprises différentes. Une application peut posséder ses smart contracts, déléguer la vérification cross-chain à un DVN, dépendre de RPC externes et déposer ensuite l'actif obtenu dans un protocole de prêt. Quand la première brique transmet une information fausse, le caractère décentralisé des contrats situés plus loin ne corrige rien automatiquement.

Le bridge de Kelp avait un seul vérificateur. Ce vérificateur appartenait à LayerZero Labs. Son infrastructure RPC a été compromise. Le bridge a accepté son attestation. Ces éléments sont désormais documentés par LayerZero lui-même. Ce que le tribunal devra trancher est beaucoup moins mécanique : qui avait promis quoi, qui connaissait quels risques et quelle part de responsabilité juridique découle de ces choix techniques.