Un outil open source d’IA, peu suivi, avait signalé il y a 12 jours une vulnérabilité de 292 millions de dollars chez Kelp DAO.
TechFlow SélectionTechFlow Sélection
Un outil open source d’IA, peu suivi, avait signalé il y a 12 jours une vulnérabilité de 292 millions de dollars chez Kelp DAO.
Un agent IA peut constituer une couche de sécurité autonome pour les investisseurs DeFi.
Dédié à des analyses Web3 approfondiesAuteur : Zengineer
Traduction : TechFlow
Introduction de TechFlow : Le 18 avril 2026, Kelp DAO a subi un vol de 292 millions de dollars américains, constituant à ce jour le plus grave incident DeFi de l’année 2026. La faille ne résidait pas dans le code des contrats intelligents, mais dans la configuration du pont interchaînes LayerZero : un nœud de vérification 1-sur-1 (« 1-of-1 »), dont la compromission unique suffisait à falsifier des messages interchaînes. Douze jours plus tôt, le 6 avril, j’avais déjà identifié ce risque à l’aide d’un outil open source d’audit automatisé basé sur l’IA, que j’ai moi-même développé. Cet article retrace intégralement l’attaque, tout en reconnaissant honnêtement trois erreurs commises par cet outil lors de son évaluation.
Kelp DAO, c’est quoi ?
Kelp DAO est un protocole de « re-staking » liquide construit sur EigenLayer. Son mécanisme fonctionne ainsi : les utilisateurs déposent de l’ETH ou des jetons de staking liquides (tels que stETH ou ETHx) dans les contrats de Kelp, qui délèguent ensuite ces actifs à des nœuds opérateurs d’EigenLayer afin d’effectuer un « re-staking » — tout en fournissant simultanément de la sécurité à plusieurs services AVS (Actively Validated Services, ou « services activement validés »). En contrepartie, les utilisateurs reçoivent rsETH comme preuve de leur participation. Contrairement au « re-staking » direct sur EigenLayer (où les actifs sont verrouillés), rsETH est liquide : il peut être échangé, utilisé comme garantie sur des protocoles de prêt tels qu’Aave, ou transféré entre chaînes.
Pour assurer cette liquidité interchaînes, Kelp utilise la norme OFT (Omnichain Fungible Token, ou « jeton fongible omnichaîne ») de LayerZero pour déployer rsETH sur plus de 16 chaînes. Lorsqu’un utilisateur transfère rsETH depuis Ethereum vers une L2 donnée, le réseau DVN (Decentralized Verifier Network, ou « réseau décentralisé de vérification ») de LayerZero vérifie la légitimité de ce message interchaînes. Cette architecture de pont constitue précisément le cœur de l’histoire qui suit.
Kelp a été lancé par Amitej Gajjala et Dheeraj Borra (anciens cofondateurs de Stader Labs), en décembre 2023. Son TVL (Total Value Locked) a atteint un pic de 2,09 milliards de dollars américains. Sa gouvernance repose sur une signature multi-signatures 6/8 assortie d’un délai de verrouillage de 10 jours pour toute mise à jour de contrat. Le jeton de gouvernance KERNEL régule les trois lignes de produits de Kelp : Kelp, Kernel et Gain.
L’incident de vol
Le 18 avril 2026, un attaquant a retiré 116 500 rsETH depuis le pont interchaînes de Kelp DAO, soit environ 292 millions de dollars américains — l’attaque DeFi la plus importante à ce jour en 2026. La cause fondamentale n’était pas une vulnérabilité dans les contrats intelligents, mais un problème de configuration : un paramètre DVN « 1-sur-1 » (c’est-à-dire un seul nœud de vérification, dont la signature unique suffit à valider un message) a permis à l’attaquant de falsifier un message interchaînes après avoir compromis ce seul nœud.
Douze jours plus tôt, le 6 avril, mon outil d’audit de sécurité open source avait déjà signalé cette surface d’attaque.
Précisons-le clairement : ce vol a causé des pertes réelles à des personnes réelles. Des déposants de WETH sur Aave, qui n’avaient jamais manipulé de rsETH, ont vu leurs fonds gelés ; des fournisseurs de liquidités (LP) sur plusieurs protocoles se sont retrouvés contraints d’absorber des pertes qu’ils n’avaient jamais acceptées contractuellement. Cet article analyse ce qui s’est produit et ce que notre outil a détecté — mais le coût réel subi par les utilisateurs dépasse largement toute note ou grille d’évaluation.
Le rapport complet est disponible sur GitHub, avec un horodatage de commit vérifiable par tous. Ce qui suit décrit ce que nous avons identifié, ce que nous avons manqué, et ce que cet événement signifie pour les outils de sécurité DeFi.
46 minutes qui ont secoué le monde DeFi
À 17 h 35 UTC le 18 avril, l’attaquant a compromis ce nœud DVN isolé, puis l’a forcé à « approuver » un message interchaînes falsifié. Le point de terminaison (Endpoint) de LayerZero, voyant que le DVN avait validé le message, l’a transmis via lzReceive au contrat OFT de Kelp — qui, conformément à sa logique, a alors frappé (minté) 116 500 rsETH sur le réseau principal Ethereum. Le message prétendait qu’un montant équivalent d’actifs était verrouillé sur d’autres chaînes comme garantie. Ces actifs n’ont jamais existé.
Suivit alors un processus standard de blanchiment DeFi :
- Dépôt des rsETH volés comme garantie sur Aave V3, Compound V3 et Euler ;
- Emprunt d’environ 236 millions de dollars américains de WETH, en utilisant ces garanties sans soutien réel ;
- Regroupement d’environ 74 000 ETH transférés hors chaîne via Tornado Cash.
Quarante-six minutes plus tard, à 18 h 21, la procédure d’urgence de Kelp — une signature multi-signatures — a gelé les contrats. Deux tentatives ultérieures de l’attaquant (chacune visant 40 000 rsETH, soit environ 100 millions de dollars américains) ont toutes deux été annulées (reverted) — cette suspension a ainsi empêché une perte supplémentaire d’environ 200 millions de dollars américains.
Cependant, les répercussions ont été extrêmement sévères. Aave V3 a absorbé environ 177 millions de dollars américains de pertes non recouvrables. Le jeton AAVE a chuté de 10,27 %. L’ETH a reculé de 3 %. Le taux d’utilisation du WETH sur Aave a immédiatement atteint 100 %, provoquant une ruée des déposants vers le retrait. Sur plus de vingt L2, les rsETH se sont retrouvés, du jour au lendemain, transformés en actifs dont la valeur est devenue incertaine.
Le 6 avril : ce que le rapport avait détecté
Début avril, peu après le vol de 285 millions de dollars américains subi par Drift Protocol le 1er avril, j’ai développé une compétence open source pour Claude Code intitulée crypto-project-security-skill — un cadre d’évaluation des risques architecturaux assisté par l’IA, utilisant des données publiques (DeFiLlama, GoPlus, API Safe, vérifications sur chaîne) pour évaluer les protocoles DeFi. Il ne s’agit ni d’un scanner de code, ni d’un outil de vérification formelle. L’incident Drift m’a convaincu d’une chose essentielle : les pertes les plus importantes ne proviennent pas du code des contrats intelligents, mais bien des failles de gouvernance, des négligences de configuration et des angles morts architecturaux — des zones que les scanners de code ne peuvent jamais observer. J’ai donc conçu un outil spécifiquement dédié à l’évaluation de ces couches : structure de gouvernance, dépendances aux oracles, mécanismes économiques et architecture interchaînes, en comparant chaque protocole aux modèles d’attaques historiques célèbres (Drift, Euler, Ronin, Harmony, Mango).
Le 6 avril, j’ai effectué un audit complet de Kelp DAO. Le rapport complet est publié publiquement sur GitHub, avec un horodatage de commit immuable.
Le score global d’évaluation attribué à Kelp dans ce rapport était de 72/100 (risque modéré). Rétrospectivement, ce score s’est avéré trop indulgent — ces lacunes informationnelles non résolues liées à l’architecture interchaînes auraient dû faire baisser significativement la note. Néanmoins, même avec une évaluation de « risque modéré », le rapport identifiait explicitement la surface d’attaque exploitée par la suite.
La capture d’écran ci-dessous reproduit le passage original du rapport dans la section « Lacunes informationnelles » — la question concernant la configuration DVN de Kelp, qui deviendra par la suite la cause racine du vol de 292 millions de dollars américains :
Légende de l’image : Dans la section « Lacunes informationnelles » du rapport du 6 avril, l’opacité de la configuration DVN est explicitement mentionnée.
Examinons maintenant point par point ce que le rapport avait signalé, et comment cela a effectivement été exploité.
Découverte 1 : Opacité de la configuration DVN (signal d’alerte)
Texte original du rapport : « La configuration DVN de LayerZero (ensemble des validateurs par chaîne, seuils requis) n’est pas rendue publique. »
Ce qui s’est réellement produit : Kelp utilisait une configuration DVN « 1-sur-1 ». Un seul nœud. Un point unique de défaillance. L’attaquant, ayant compromis ce seul nœud, a pu falsifier un message interchaînes. Si la configuration avait été « 2-sur-3 » (seuil minimal recommandé par l’industrie), l’attaquant aurait dû compromettre simultanément plusieurs validateurs indépendants.
Il faut clarifier un point crucial : ceci est une responsabilité de Kelp, non de LayerZero. LayerZero est une infrastructure — elle fournit le cadre DVN, et chaque protocole choisit librement sa propre configuration : nombre de nœuds validateurs (1-sur-1, 2-sur-3, 3-sur-5…), identité des nœuds choisis, seuils par chaîne. Kelp a opté pour une configuration « 1-sur-1 » lors du déploiement de son pont OFT. LayerZero prend pleinement en charge des configurations « 2-sur-3 » ou supérieures — Kelp a simplement choisi de ne pas les activer.
Prenons une analogie : AWS propose l’authentification multifacteur (MFA). Si votre compte est piraté parce que vous n’avez jamais activé la MFA, la faute vous incombe, non à AWS. LayerZero met des mécanismes de sécurité à disposition ; Kelp ne les a pas utilisés.
Notre rapport ne pouvait pas déterminer précisément le seuil DVN utilisé (puisque Kelp ne l’avait jamais divulgué), mais nous avions clairement listé cette opacité comme une lacune informationnelle non résolue et un risque identifié. Le simple refus de divulguer constitue en soi un signal d’alarme.
Découverte 2 : Échec unique affectant 16 chaînes (détection exacte)
Texte original du rapport : « Une défaillance unique du DVN LayerZero pourrait impacter simultanément le rsETH sur les 16 chaînes prises en charge. »
Ce qui s’est réellement produit : Le message falsifié a directement ciblé le réseau principal Ethereum, et ses répercussions se sont propagées à toutes les chaînes où rsETH était déployé. LayerZero a suspendu préventivement tous les ponts OFT partant d’Ethereum. Les détenteurs de rsETH sur plus de vingt L2 se sont retrouvés, du jour au lendemain, incapables de déterminer si leurs jetons conservaient encore une quelconque garantie.
Il s’agit ici d’un risque systémique inhérent au déploiement multi-chaînes : rsETH circule simultanément sur Arbitrum, Optimism, Base, Scroll, etc., mais la valeur de tous ces jetons dépend exclusivement des actifs verrouillés sur le réseau principal Ethereum. Dès que le pont principal est compromis, le rsETH sur chaque L2 perd immédiatement sa garantie — les détenteurs ne peuvent ni racheter leurs fonds, ni vérifier la valeur réelle de leurs jetons. Lido (via earnETH, exposé au rsETH), Ethena (via son pont LayerZero) — tous ont dû suspendre leurs opérations. Le rayon d’impact dépasse largement les limites de Kelp lui-même.
Découverte 3 : Contrôle non vérifié de la gouvernance interchaînes (problème connexe)
Texte original du rapport : « Le contrôle de la gouvernance sur la configuration OFT LayerZero pour chaque chaîne n’a pas été vérifié — notamment : ce contrôle relève-t-il du même dispositif multi-signatures 6/8 avec délai de verrouillage de 10 jours, ou est-il géré par des clés d’administration distinctes ? »
Ce qui s’est réellement produit : La configuration DVN n’était manifestement pas soumise au régime strict de gouvernance du protocole central. Si les modifications de la configuration du pont étaient également soumises à la signature multi-signatures 6/8 avec délai de verrouillage de 10 jours, la configuration « 1-sur-1 » aurait exigé l’accord de six des huit signataires — une configuration peu probable sans surveillance continue.
Cela révèle un angle mort courant de la gouvernance : de nombreux protocoles imposent des exigences strictes (multi-signatures + délai de verrouillage) pour les mises à jour des contrats centraux, mais autorisent souvent des modifications opérationnelles — configuration des ponts, paramètres des oracles, gestion des listes blanches — via une seule clé d’administrateur. La gouvernance du protocole central de Kelp est exemplaire (6/8 multi-signatures + délai de verrouillage de 10 jours), mais ces protections ne s’étendent pas à sa surface d’attaque la plus critique : le pont interchaînes.
Découverte 4 : Alignement avec les modèles d’attaques Ronin/Harmony (détection exacte)
Texte original du rapport : « Le précédent historique le plus pertinent concerne la sécurité des ponts. Le déploiement de Kelp sur LayerZero sur 16 chaînes génère une complexité opérationnelle similaire à celle de l’architecture multi-chaînes de Ronin. »
Ce qui s’est réellement produit : Le chemin d’attaque reproduit presque parfaitement le scénario de Ronin — compromission des validateurs du pont, falsification des messages, vidage des actifs. Le module d’appariement des modèles d’attaques de notre outil, qui compare l’architecture des protocoles aux catégories historiques d’attaques, a correctement identifié ce vecteur comme présentant le risque le plus élevé.
Contexte historique : en 2022, le pont Ronin a perdu 625 millions de dollars américains après la compromission de 5 de ses 9 validateurs ; la même année, le pont Horizon d’Harmony a subi une perte de 100 millions de dollars américains suite à la compromission de 2 de ses 5 validateurs. La situation de Kelp était encore plus extrême — avec un seul validateur, le seuil d’attaque était réduit au minimum absolu. Notre outil a pu identifier ce risque précisément parce qu’il compare automatiquement l’architecture des protocoles à ces modèles historiques d’attaques, plutôt que de se limiter à l’analyse du code.
Découverte 5 : Absence de fonds d’assurance (amplification des pertes)
Texte original du rapport : « Le protocole ne dispose actuellement d’aucun fonds d’assurance spécifique, ni de mécanisme de mutualisation des pertes pour absorber les sanctions (slashing). »
Ce qui s’est réellement produit : En l’absence de réserve d’assurance, la totalité des 292 millions de dollars américains de pertes a été absorbée par les protocoles tiers. La réserve de récupération d’Aave a couvert moins de 30 % de ses pertes non recouvrables de 177 millions de dollars américains. Des fournisseurs de liquidités (LP) totalement étrangers à la décision de configuration du pont de Kelp ont subi l’impact le plus sévère.
L’attaquant a déposé les rsETH volés comme garantie sur Aave V3, Compound V3 et Euler, puis emprunté du WETH réel. Dès que rsETH a été confirmé comme non garanti, ces positions se sont transformées en pertes « non liquidables » — la garantie étant devenue inutilisable, tandis que le WETH prêté avait déjà disparu. Le taux d’utilisation du WETH sur Aave a instantanément atteint 100 %, empêchant les utilisateurs ordinaires de retirer leurs fonds. Si vous êtes déposant de WETH sur Aave, même sans avoir jamais manipulé de rsETH, vos fonds ont été affectés. La collaboration d’assurance entre Kelp et Nexus Mutual couvre uniquement certains produits de trésorerie spécifiques, mais ne protège pas l’exposition centrale au protocole rsETH.
Il y a ici une défaillance bilatérale. Du côté de Kelp : un protocole gérant un TVL de 1,3 milliard de dollars américains, sans fonds d’assurance ni mécanisme d’absorption des pertes. Lors de la compromission du pont, aucune protection n’était en place pour atténuer les dommages. Du côté d’Aave : l’acceptation de rsETH comme garantie sans avoir suffisamment évalué les risques liés à sa configuration de pont interchaînes. Les paramètres de risque d’Aave (taux de prêt sur valeur, seuils de liquidation) sont conçus pour des fluctuations de prix normales, mais ne tiennent pas compte d’un risque « extrême » tel que la « perte totale de la garantie » résultant d’une compromission de la configuration du pont. Sa réserve de récupération ne couvre même pas 30 % des pertes. Fondamentalement, il s’agit d’un échec de tarification du risque : Aave traite rsETH comme un actif soumis à des variations de prix classiques, alors qu’il comporte intrinsèquement un risque binaire « extrême » lié à la défaillance du pont. La combinaison de ces deux défaillances — l’absence d’assurance chez Kelp, empêchant l’entrée de garanties corrompues dans le système, et l’absence d’une modélisation fine du risque chez Aave, limitant l’exposition dans ce scénario — a conduit à cette catastrophe.
Où avons-nous eu tort ?
Trois points auraient dû être traités plus rigoureusement :
Une évaluation de risque trop optimiste. Nous avons qualifié le risque lié au pont interchaînes de « modéré ». Or, le rapport comptait cinq lacunes informationnelles non résolues, dont trois étaient directement liées à la configuration du pont LayerZero, et correspondait au modèle d’attaques historiques de Ronin/Harmony — ce qui aurait dû justifier une qualification de « élevé » ou « critique ». L’opacité, en soi, aurait dû constituer un signal plus fort.
Nous n’avons pas percé la couche de configuration. Le rapport demandait à plusieurs reprises la divulgation du seuil DVN par Kelp, mais nous n’avons pas pu le vérifier de façon indépendante. Il s’agit précisément du même angle mort structurel mis en lumière par l’analyse post-mortem de Cnyes : les outils d’audit existants se concentrent sur la logique du code, et ne détectent pas les risques liés à la couche de configuration. Nous avons signalé le problème, mais nous n’avons pas pu y répondre.
Nous n’avons pas consulté la chaîne. La configuration DVN est en réalité consultable directement sur la chaîne via le contrat EndpointV2 de LayerZero. Nous aurions pu interroger le registre ULN302 afin de vérifier indépendamment le seuil DVN de Kelp, plutôt que de le qualifier de « non divulgué ». Si nous l’avions fait, nous aurions pu voir directement la configuration « 1-sur-1 », sans attendre la divulgation de Kelp. C’est la direction d’amélioration la plus concrète pour l’outil : intégrer une vérification sur chaîne de la configuration DVN dans les étapes d’évaluation interchaînes.
Les découvertes n’étaient pas assez précises, ni assez actionnables. Dire que « la configuration DVN n’est pas divulguée » revient à constater une absence de documentation — ce n’est pas prédire une attaque. Ces risques (concentration des oracles, dépendance aux ponts, absence d’assurance) sont en effet courants dans la plupart des protocoles DeFi interchaînes. Notre outil a bien marqué l’opacité de Kelp, mais il a aussi relevé des motifs similaires sur des dizaines d’autres protocoles non attaqués. Sans publier de taux de faux positifs, affirmer « nous l’avons prédit » constitue une exagération. Une formulation plus honnête serait : « Nous avons posé des questions pertinentes que personne d’autre ne posait, et l’une d’entre elles s’est trouvée précisément sur un point critique. »
À propos de la « divulgation responsable »
Une question légitime se pose : si nous avions signalé ces risques dès le 6 avril, pourquoi n’avons-nous pas alerté Kelp avant l’attaque du 18 avril ?
Nous ne l’avons pas fait. La raison en est que le rapport identifiait une opacité — « la configuration DVN n’est pas divulguée » — et non une vulnérabilité concrète et exploitable. Nous ignorions si la configuration était « 1-sur-1 » ; nous savions seulement qu’elle n’était pas publique. Il n’y avait donc rien de suffisamment précis à divulguer. « Votre configuration de pont n’est pas documentée » est une observation de gouvernance, pas un rapport adapté à un programme de récompenses pour bogues.
Rétrospectivement, nous aurions pu contacter directement l’équipe de Kelp pour leur demander leur seuil DVN. Ce dialogue aurait pu révéler la configuration « 1-sur-1 » et déclencher une correction. Nous ne l’avons pas fait. C’est une leçon : même si une découverte semble trop vague pour suivre une procédure formelle de divulgation, envoyer un message privé pour demander des précisions reste toujours pertinent.
Que signifie cet incident pour la sécurité DeFi ?
Le vol subi par Kelp — tout comme celui de Drift, survenu 17 jours plus tôt — ne résulte pas d’une vulnérabilité dans les contrats intelligents. Des outils automatisés tels que Slither, Mythril, voire GoPlus, ne sont pas capables de les détecter. La faille résidait dans la configuration de déploiement, les lacunes de gouvernance et les décisions architecturales — des éléments situés au-dessus de la couche de code.
C’est précisément là que réside la thèse centrale de crypto-project-security-skill :
La sécurité d’un protocole ne se limite pas à la sécurité de son code. Un protocole peut posséder un code Solidity parfait, avoir bénéficié de cinq audits menés par des sociétés de premier plan, et offrir une prime de 250 000 dollars américains pour la découverte de bogues — et pourtant, être victime d’un vol de 292 millions de dollars américains à cause d’un mauvais choix de configuration des validateurs du pont.
L’outil est open source sur GitHub — chacun peut examiner sa méthodologie, l’exécuter soi-même ou l’améliorer.
Chronologie
Douze jours. Le signal était déjà présent. La question est désormais : comment l’écosystème va-t-il développer des outils capables de détecter ces signaux avant que le prochain pont ne s’effondre ?
Que pouvez-vous faire ?
Si vous détenez des actifs sur des protocoles DeFi dotés d’un pont interchaînes :
- Faites vous-même un audit. L’outil est open source. Ne nous faites pas aveuglément confiance — vérifiez par vous-même.
- Vérifiez la configuration des validateurs du pont. Si un protocole refuse de divulguer son seuil DVN, considérez cela comme un signal d’alarme. C’est exactement ce que faisait notre rapport — et les faits ont prouvé sa justesse.
- Ne supposez pas que les audits de code couvrent tout. Kelp a bénéficié de plus de cinq audits de code réalisés par des sociétés et plateformes renommées (Code4rena, SigmaPrime, MixBytes). L’objectif des audits traditionnels de code ne comprend pas la détection des risques liés à la couche de configuration — tels que le paramétrage du seuil DVN. Ce type d’analyse relève d’une autre catégorie, et ne constitue pas une défaillance des sociétés d’audit.
- Évaluez la couverture d’assurance. Si un protocole ne dispose pas de fonds d’assurance, et que vous êtes fournisseur de liquidités (LP) sur une plateforme de prêt acceptant ses jetons comme garantie, vous assumez implicitement son risque. Les déposants de WETH sur Aave viennent d’apprendre cette leçon de la manière la plus dure qui soit.
Le grand tableau : l’Agent IA comme couche de sécurité
Cet article traite d’un outil et d’un vol. Mais sa thèse sous-jacente est plus large : un Agent IA peut constituer une couche de sécurité autonome pour les investisseurs DeFi.
Le modèle traditionnel de sécurité dans l’écosystème cryptographique fonctionne ainsi : le protocole engage une société d’audit, cette société examine le code, puis publie un rapport. Ce modèle présente des angles morts — l’incident Kelp en est la preuve flagrante, car il se concentre sur la correction du code, tout en négligeant les risques liés à la configuration, à la gouvernance et à l’architecture.
Claude Code et des outils de ce type ouvrent une autre voie : n’importe qui peut utiliser des données publiques pour effectuer, en quelques minutes, une évaluation des risques assistée par l’IA sur n’importe quel protocole. Vous n’avez pas besoin de dépenser 200 000 dollars américains pour engager une société d’audit. Vous n’avez pas besoin de savoir lire du Solidity. Vous demandez à l’agent de comparer l’architecture du protocole aux modèles d’attaques connus, et il vous liste les questions que vous devriez vous poser avant d’investir.
Cela ne remplacera pas les audits professionnels — mais cela abaisse le seuil de la première couche de diligence raisonnable à un niveau accessible à tous. Un fournisseur de liquidités (LP) envisageant d’allouer des fonds à un nouveau protocole de « re-staking » peut désormais lancer la commande audit defi <protocol> et obtenir une évaluation structurée des risques couvrant la gouvernance, les oracles, les ponts et les mécanismes économiques. Pour les investisseurs particuliers et les investisseurs de taille moyenne, cela représente une transformation concrète de leur capacité à se protéger eux-mêmes.
Le rapport sur Kelp n’était pas parfait. Il a qualifié le risque lié au pont de « modéré », alors qu’il aurait dû être « critique ». Il n’a pas percé la couche de configuration. Mais il a posé les bonnes questions — et si l’équipe de Kelp ou n’importe quel LP avait pris ces questions au sérieux à l’époque, la perte de 292 millions de dollars américains aurait pu être évitée.
Bienvenue dans la communauté officielle TechFlow
Groupe Telegram :https://t.me/TechFlowDaily
Compte Twitter officiel :https://x.com/TechFlowPost
Compte Twitter anglais :https://x.com/BlockFlow_News
@liliangjya5
