Réveil au seau d’eau froide pour les holders du token de Elrond le 6 Juin ou nuit très agité pour le couche tard que je suis. Suite à une exploitation détournée de smart contract, EGLD vient faire une petite visite à son ami Luna mais qui, fort heureusement, ne sera que de courte durée.
Alerte à Malibu chez la Team Elrond
Le token a subi une baisse foudroyante de plus de 90% en une petite heure, Beniamin Mincu, le CEO de Elrond, a directement averti Twitter que des transactions frauduleuses étaient en train d’être détectées par son équipe. Comme un sauveteur au bord des plages bouée à la main, il annonce suspendre la plateforme Maiar afin de réaliser une maintenance et de comprendre la nature de celles-ci. À mon grand regret, j’ai découvert la chute du token juste après la mise en maintenance du DEX, ma réaction aurait sûrement été celle-ci, et je vais vous expliquer pourquoi.
Figure 1 : meme bien connu dans la sphère crypto et gaming
Avec une courte vérification, il aurait été limpide que seule la plateforme Maiar soit impactée, le cours sur Binance n’a même pas réagi immédiatement à la baisse et n’a sanctionné cette mauvaise nouvelle que d’un petit -10% jusqu’à la réouverture de Maiar où la dépression du token s’est accentuée. Le seul événement qui, selon moi et que j’estimais peu probable, aurait pu envoyer aussi rapidement son prix dans les profondeurs (et même bien plus bas) de manière globale et définitive est la découverte d’une faille permettant de créer une infinité de token. Donc même sans connaître en détails les faits, on pouvait vite en déduire une crise de liquidité momentanée et surtout une occasion rêvée d’acheter de l’EGLD à 5$. Mais cessons les remords, que s’est-il donc passé ?
Les smart contracts de Wrapping asséchés par le hacker
Le deuil passé et après un court ébahissement devant la chart de l’EGLD, j’ai couru en direction de l’Explorer pour tenter d’analyser la situation. Voici ce que j’y ai découvert :
Figure 2 : compte du pirate ayant reçu 450k EGLD
Après avoir reçu au total 1,65 millions d’EGLD, semblant apparaître de nul part de trois mystérieux smart contracts, trois comptes ont effectué d’énormes ventes successives d’une valeur de 200 000 USDC. Pour vous rendre compte de la quantité faramineuse, ceci représente plus de 7% de la supply totale du token et 124 millions de dollars à ce moment-là. Au total le (ou les) hacker parviendra à vendre 786 000 tokens pour une valeur de 15 600 000 $ et 1,213 million d’UTK. Le contrat de swap EGLD<>USDC n’ayant pas assez de liquidité disponible pour maintenir le prix de l’EGLD autour des 75$, la vente s’est faite avec une perte assez conséquente, réduisant le prix moyen de vente à 19,8$. Sur ces 15,6 millions seulement 5,6 millions quitteront la plateforme via le Bridge Ad Astra, envoyant les fonds sur la blockchain Ethereum, mais aussi 88 000 EGLD qui seront swapé par SimpleSwap via Binance en ETH.
Vous pouvez retrouvez le détail des transactions ainsi que leurs tracking sur la blockchain Ethereum dans ce Google Sheet confectionné par mes soins juste ici
En creusant un peu plus, on se rend vite compte que ces tokens n’étaient pas présents dans les smart contracts appelés avant que la transaction s’effectue, alors d’où peuvent-ils venir ?
Après quelques investigations, ils semblent que le pirate ait subtilisé les EGLDs présent dans les contrats
permettant les échanges EGLD <> WEGLD.
Quelques notions du “””professeur””” Foudres
Je vais essayer d’expliquer l’entièreté du processus de façon à ce que même les curieux néophytes en programmation que nous sommes ou non, soit en mesure de comprendre exactement comment le hacker a abusé de la faille qui à permis ce vol. Mais pour ça je vais devoir introduire quelques notions.
Le Sharding : le sharding est une des spécificités de la blockchain Elrond qui lui permet d’opérer les transactions sur trois chaînes différentes reliées à la chaîne principale, la Metachain, ce qui lui permet sa scalabilité théorique de 15 000 transactions par seconde. Les trois Shards sont nommés Shard 0, Shard 1 et Shard 2.
Fonction : En informatique, une fonction est un ensemble d’instructions réalisant une certaine tâche. À ne pas confondre avec une méthode qui est un terme plus spécifique à un certain type de fonction même si la confusion est souvent faite par abus de langage et similarité.
Appel : un appel est l’utilisation d’une fonction d’une entité par une autre lui demandant de réaliser une certaine tâche.
Prenons l’exemple d’une demande de swap EGLD <> USDC d’une adresse à un smart contract :
Figure 3 : un swap de WEGLD en USDC entre une adresse et un smart contract
Ici l’adresse erd1y…pkm (entité appelante) demande au smart contract erd1qqq…qaq (entité appelé) de réaliser la fonction “SwapTokenFixedInput” qui va swapper les WEGLD envoyé pour des USDC. On dit que l’adresse appelle le smart contract.
Figure 4 : swap d’EGLD en WEGLD entre le contrat du pirate et celui de wrapping
Callback : La smart contract de wrapping peut prendre une fonction en option afin de répondre à l’appelant (ici le contrat pirate), comme on le voit ci-dessus dans le paragraphe “Data” la fonction “wrap_egld_callback” est mentionnée, c’est ce qu’on appelle un “callback”. Dans ce cas c’est “l’appelant” qui a spécifié avec quelle fonction “l’appelé” doit lui répondre (ceci est très important à comprendre en vue des explications du “hack”). Ce sera le point de départ qui amènera le contrat de wrapping à vider ses fonds. Dans la version antérieure de la Virtual Machine (le logiciel utilisé pour lire les smart contracts et mettre à jour l’état de la blockchain) un smart contrat prenait en option une fonction car c’était le seul moyen d’envoyer des tokens à un autre smart contract. Ceci n’est plus obligatoire mais la grande majorité des contrats peuvent toujours utiliser cette fonctionnalité.
C’est d’ailleurs cette fonction qui a mis la puce à l’oreille des investigateurs pour comprendre que les fonds provenaient du smart contract de wrapping d’EGLD.
Le hack, explications détaillées.
Chaque compte ayant été créé pour exploiter un des trois Shards et le processus utilisé étant le même, je l’expliquerai donc pour le compte ayant exploité le Shard 0.
Le pirate a, en réalité, utilisé deux smart contracts par Shard pour arriver à ses fins, un destiné à déclencher une succession de fonctions menant au vol des EGLD (que j’appellerai SC-A), et un autre permettant l’envoi des tokens à l’adresse destinée à les vendre (SC-B).
Selon l’Explorer, rien ne semble relier directement l’adresse du compte et le SC-B avec le SC-A, c’est seulement en investiguant sur le stockage du SC-A que l’on peut apercevoir que l’adresse du SC-B, encodé en Hexadécimal, à été enregistrée !
Figure 5 : 00000000000000000500fffc4c8cda66bc17c0ecebeef2b50cf1a2f9ff234130 = erd1qqqqqqqqqqqqqpgqll7yerx6v67p0s8va0h09dgv7x30nlergycqt2qzmp
Les étapes du piratage :
Figure 6 : création du smart contract frauduleux par le pirate
- Un compte secondaire du pirate a déployé le smart contract SC-A (figure 6 en rouge) et envoyé une petite quantité d’EGLD à wrapper à celui-ci (figure 6 et 7 en vert) :
Figure 7 : compte du smart contract du pirate envoyant un transaction frauduleuse au contrat de wrapping
- le SC-A fait ensuite appel au SC-W afin de wrapper ces EGLD (qui peut donc accepter une fonction en option afin de répondre, appelé callback) et lui spécifie qu’il devra lui répondre avec la fonction “wrap_egld_callback” une fonction interne au SC-A développé par le hacker (figure 7 en bleu). C’est en la capacité du SC-A à faire déclencher cette fonction “pirate” par le SC-W que consiste le vol, ce n’est donc ni un bug, ni un hack à proprement parler, seulement une faille dans la Virtual Machine de Elrond.
- le SC-W répondra donc avec cette fonction au SC-A lui renvoyant au passage la petite quantité de WEGLD qu’il voulait wrapper, mais pas seulement :
Figure 8 : Smart contract déployé par le pirate (SC-A)
En analysant le code de la fonction “wrap_egld_callback” (figure 8 en bleu), on remarque qu’une autre fonction nommée « managedExecuteOnDestContextByCaller » y est incluse ainsi qu’un argument qui représente un montant en EGLD, ici “450 000”.
Dans le cas d’un appel synchrone d’une transaction normale entre deux entités c’est la méthode « managedExecuteOnDestContext » qui est utilisée, demandant à l’entité appelée de réaliser la transaction au nom de l’appelant. Mais ici on aperçoit le supplément “ByCaller”, ce qui signifie que c’est l’appelant de la fonction qui doit réaliser la transaction au nom de l’appelé ! Autrement dit, au lieu de permettre à un smart contract de réaliser une transaction pour nous, c’est le smart contrat qui nous permet de réaliser une transaction pour lui, libre donc à l’attaquant de lui ordonner de lui envoyer tous ses fonds.
Le hacker a découvert qu’on pouvait faire appeler cette fonction par un smart contrat dans le cas d’une transaction acceptant un callback et ainsi drainer ses propres fonds. Le SC-W a donc sagement et sans résistance suivi les instructions données par la fonction avec laquelle le SC-A lui a demandé de lui répondre, résultant d’un envoi de 450 000 EGLD à l’adresse mentionnée, c’est-à-dire le SC-B.
Cette transaction (envoi des 450 000 EGLD par le SC-W au SC-B) n’apparaît pas dans l’Explorer car celui-ci ne supporte pas l’affichage de la fonction « managedExecuteOnDestContextByCaller ». C’est pour cette raison que les fonds semblaient apparaître de nul part sur l’adresse du hacker lors d’une simple recherche dans l’Explorer.
Figure 9 : transaction où le compte du hacker a reçu la liquidité du contrat de wrapping
- Dernière étape, l’adresse du hacker appelle la fonction “Withdraw” du SC-B lui permettant de récupérer les 450 000 EGLD subtilisés au SC-W.
Petit résumé pour être sur d’avoir tout compris, en réussissant à faire déclencher l’appel de la fonction “wrap_egld_callback” par le smart contract de wrapping et le fait que cette dernière contienne la fonction “managedExecuteOnDestContextByCaller », le contrat de wrapping a tout simplement autorisé le contrat pirate à réaliser une transaction avec ses propres fonds d’après le montant spécifié par le hacker, à savoir, la quasi totalité des liquidités qu’il disposait !
Voilà, vous savez maintenant comment voler un million six cent cinquante milles EGLD.
Figure 10 : bon, c’est pour la forme les noms des figures.
Une faille découverte quelque jours avant, qui allait être patché le 8 juin
Comme on l’apprend dans le “Recovery Report” publié par Elrond le samedi 11 Juin, cette faille avait été découverte par la communauté de développeurs d’Elrond quelques jours avant l’attaque. La faille avait été remontée à la Team qui préparait un patch pour les prochains jours et qui devait être effective le 8 juin, soit seulement 2 jours après l’attaque… D’ailleurs Elrond reproche à demi-mot la nonchalance avec laquelle ce sujet était discuté sur le canal public Telegram “Elrond Developers” sachant le patch toujours à l’étude, c’est vrai que sans souci de sécurité et de confidentialité autour d’une faille aussi critique, il n’est pas improbable que le hacker ait découvert cette faille par ce biais ou utilisé certaines information à son avantage.
La faille avait été découverte par un petit groupe de développeur voulant construire un smart contrat de loterie à l’épreuve de toutes exploitations malveillantes, en effet, grâce à un smart contract personnalisé, les utilisateurs pouvaient annuler leurs transactions s’ils ne gagnaient pas la loterie, plutôt embêtant nous en conviendrons. Décidant de contourner le problème en interdisant toutes interactions avec un smart contract, un développeur découvre que cela est contournable avec la fonction “executeOnDestContextByCaller” qui permet de tromper le contrat en utilisant une adresse ordinaire comme leurre alors que la transaction provient bien d’un autre contrat. C’est en jouant et en retournant la fonction dans tous les sens que la communauté comprendra que cette fonction permet un vol de fond si elle est appelée par une adresse et, plus tard, quelle peut être alors dissimulée dans un call back d’un appel asynchrone et ainsi dépouiller n’importe quel smart contract.
Seule condition, l’attaque ne fonctionne que si elle est réalisée alors que le contrat malveillant et la cible sont sur le même shard (justifiant la présence des smart contracts du hacker sur chacun des shards), mettant par ailleurs hors de danger les EGLD stacké qui eux sont sur la Metachain ainsi que les ESDT Token car leurs transferts nécessite l’appel de fonction intégrés, ce qui est interdit par la virtual machine dans ce cas.
En espérant que la divulgation de ces informations sur le canal Telegram n’ait pas aidé le hacker, les développeurs voulant surement bien faire en aidant la team Elrond à comprendre et résoudre cette faille.
Elrond essuie les critiques, souvent infondées : “Maiar DEX n’est pas décentralisé !?!”
Ahh Twitter, quel repaire aussi enrichissant que remplis de chacal près à vous mordre de faux arguments suintant le FUD (quoi ? on dit des chacaux ?). Alors oui, il serait presque légitime de questionner la raison pour laquelle Elrond n’a pas fait un communiqué dès la faille connue en mettant la plateforme en maintenance afin d’éviter cette fâcheuse histoire. Certainement voulait-il passer le correctif en douce afin de ne pas faire trop de remous surtout dans un contexte de marché aussi incertain ? Mais comme dit le vieil adage : “vaut mieux prévenir que guérir”.
Comme argument foireux, on y a tout vu. “La blockchain à été arrêtée ». Faux, Elrond a seulement mis en maintenance sa plateforme Maiar et en pause certains smart contracts ainsi que son API afin de réaliser les correctifs. “C’est un hack du bridge”. Faux, rien à voir avec le bridge, la preuve, il marchait très bien et le hacker l’a utilisé de façon complètement normale pour envoyer des USDC sur Ethereum. “Des EGLD ont été mint” Faux, les Tokens existaient déjà puisque présent dans la pool, par contre les WEGLD n’étaient plus “backés” au taux de 1/1, le voleur ayant retiré tous les EGLD de la pool. “C’est un Rug Pull de la Team”, je m’abaisserai pas à donner d’argument. Le meilleur pour la fin : “OMG LUNA 2.0 c’est le même problème », affirmer ça montre que vous ne connaissez ni le projet de Terra, ni celui d’Elrond et que vos connaissances fondamentales en crypto son proche du néant.
Mais je vais revenir plus sérieusement sur l’argument que j’ai personnellement vu le plus. “S’ils ont pu stopper Maiar, c’est qu’elle n’est pas décentralisée”. À force de ne juger que sur la sainte décentralisation de la Blockchain et du Web3, la crypto-sphère en a galvaudé, le terme ne comprenant finalement que peu de chose à sa signification. Tout d’abord de quelle décentralisation on parle ? Et oui, il y en a plusieurs et ce à quoi elles correspondent dépend de quelle entité on parle, Maiar est certes un “Decentralized Exchange” mais il reste un site Web comme un autre, on ne parle pas ici de la blockchain Elrond :
- La décentralisation architecturale : Qui héberge le site et où sont situés les serveurs ? Que se passe-t-il en cas de panne des serveurs si ceux-ci sont centralisés ? En cas d’une faille/bug sur le site web, qui intervient ?
- La décentralisation politique : qui et combien d’individus/organisations ont l’ultime contrôle du website, du front et du back-end ? Il y a t’il des organisations gouvernementales pouvant exiger l’interdiction d’hébergement des sites liées à la crypto-monnaies ? Qui décide du contenu du site, des pools de farming présentés, des projets choisis pour le Metabounding et le Metastacking ?
- La décentralisation logique : Comment est interconnecté l’écosystème ? Est-ce que tous les acteurs dépendent d’un organisme pour fonctionner ? Peut-on séparer acteur et “client” sans impacter son fonctionnement ?
Maiar est, par exemple, hébergé par AWS et les serveurs sont en Allemagne. Que se passe-t-il si ceux-ci sont indisponibles ou surchargés ? et s’il n’y a pas de vent, que les éoliennes allemandes sont arrêtées et qu’il faut deux jours pour démarrer les centrales à charbon pour fournir en électricité les serveurs ? Vous l’aurez compris, je vous “troll” pour vous montrer l’absolue non sens de croire qu’une décentralisation peut être totale, surtout pour un site web de cette trempe. Sur les 3 points cités, aucun dans ce cadre ne permet une décentralisation convenable hormis peut-être la solution d’Ankr pour l’hébergement par ses serveurs décentralisés. On pourrait penser à une DAO pour l’aspect politique et décisionnel mais ça donnerait extrêmement moins de flexibilité au site web, imaginez si Elrond devait faire un vote auprès d’une DAO pour savoir s’ils doivent stopper Maiar, tous les fonds se seraient envolés. Mais on se fourvoie, personne n’a jamais affirmé que c’était ça la définition du mot décentralisé pour un DEX. Que la Team Elrond soit en capacité de mettre Maiar en maintenance par sa seule décision afin d’enquêter sur des transactions frauduleuses et de stopper le hacker dans sa progression n’a absolument aucun rapport avec sa décentralisation. Comment ferions nous sinon ? Nous laisserions la faille béante être essorée jusqu’au dernier centime présent dans les smarts contracts ? BIEN SUR qu’un site web est centralisé et heureusement pour notre portefeuille je dirais même.
La décentralisation d’un DEX tient dans le fait que vous êtes propriétaire de vos cryptos, contrairement à un échange centralisé comme Binance qui les gère comme le ferait une banque. “Not your keys, not your crypto”. C’est en vous permettant de faire vos transactions directement grâce à votre propre wallet, d’être capable de suivre toutes les transactions de la plateforme, ses interactions avec la blockchain Elrond, et de n’avoir besoin d’aucun tier de confiance grâce aux smart contracts, que Maiar se montre décentralisé car elle n’a absolument aucun pouvoir sur votre argent.
C’est ça, la signification de la décentralisation d’un DEX. Et c’est aussi cela qui ne lui permet pas de récupérer les EGLD volés par le hacker, sauf si bien sûr elle a trouvé un accord avec celui-ci.
Résolution du problème et retour à la normale après un rush de l’équipe Elrond
Les temps sont durs pour l’équipe Elrond, mais on le sait, il ne manque pas de montrer leurs capacités d’adaptation et de réaction lors de problèmes sur leur écosystème, mais celui-ci fût sûrement le plus critique qu’il n’ait jamais eu à résoudre. Bianamin Mincu a écrit un petit thread le 6 au matin pour rassurer la communauté en expliquant que son équipe avait identifié le problème et avait déjà déployé un premier correctif. Dans l’après midi, j’ai aperçu les fonds des 3 wallets du hacker être transféré en intégralité vers l’adresse suivante :
erd1pml9k2tsqsnvtmmalglt2su0sn3cguvr8e8jq0gy69zw2ldcej2qapml9a
Figure 11 : récupération des fonds restés sur les wallets du pirates par la Team Elrond
L’interface de Maiar était arrêtée, mais la blockchain continuait de tourner, on pouvait donc continuer à faire des transactions entre wallet. J’ai d’abord pensé à une recentralisation des fonds de la part du hacker mais en suis vite venu à supposer une récupération des fonds volés par la team Elrond, Beniamin Mincu renforçant cette hypothèse en précisant que les fonds avait été récupéré dans un tweet posté le lendemain du vol, et enfin la validera dans son thread annonçant le retour de l’Exchange le 8 Juin.
D’après le rapport transmis par Elrond résumant la totalité des événements, les fonds auraient été récupérés auprès de “l’attaquant”, ils n’ont malheureusement pas donné plus de détails pour des raisons juridiques, supposant donc une enquête ouverte pour retrouver celui-ci et possiblement le traduire en justice. On peut donc raisonnablement supposer qu’il a remis les fonds, dont il ne pouvait dès lors plus transférer nulle part, à l’amiable afin de se couvrir.
Pour ce qui est du correctif apporté par Elrond, après avoir rendu l’interaction qui permettait de siphonner un smart contract, ils ont décidé de supprimer complètement la fonction “executeOnDestContextByCaller”, estimant qu’elle apportait plus de risque que de bénéfice. Celle-ci avait été introduite pour permettre à l’adresse d’un créateur de NFT de rester propriétaire de celui-ci au yeux de la blockchain même s’il avait été créé à l’aide d’un smart-contract.
Dernier problème à régler avant la réouverture au public de Maiar, la team ayant promis que le cours de son token mère serait ré-indexé sur celui de Binance, ils leur fallaient rebalancer la pool USDC<>EGLD. À ce moment là, le ratio d’EGLD se trouvait au alentour de 6,4 USDC/EGLD et la team devait donc injecter énormément de liquidité dans la pool pour qu’elle retrouve un ratio de ~68 USDC/EGLD (vous l’aurez compris c’est ce ratio au sein du smart contrat de swap qui fixe le prix de l’EGLD). Les 10 millions d’USDC récupérés du pirate et 2,5 millions, ajoutés par ce qui semble être le wallet de la Elrond Fondation, ont donc été utilisés afin de racheter environ 600 000 WEGLD. Le vol de token issu du contrat de wrapping ayant aussi provoqué une disparité entre WEGLD et EGLD dans cette pool, il était donc nécessaire de brûler et de réinjecter des tokens (afin de retrouver une ratio 1 pour 1), tout en prenant en compte les EGLD achetés et vendu dans la panique par la communauté lors du krach ! Ainsi ~728 000 WEGLD seront burn et ~922 000 EGLD ré-injecté dans la pool, retombant bien sur une valeur de 1,65 million d’EGLD initialement volés. Pour cela, Elrond a dû développer spécialement une fonction permettant de whitelist les adresses nécessaires à toutes ces actions pour s’assurer que eux seuls pouvaient interagir avec les smart contracts en question.
Lors du krach, c’est quelque 150 000 EGLD qui ont été achetés par la “communauté”. La majorité de ces tokens ayant été achetés par des bots d’arbitrages, ceux-ci profitant des différences de prix qui peuvent survenir entre Maiar et les exchanges centralisés. Avec parfois un prix d’achat moyen sous les 10$, ils ont dû se régaler. Fusionné ça à un krach qui à pu en décourager certain de holder le token pendant le bear market et un Bitcoin en très mauvaise posture, ceci peut facilement expliquer la forte volatilité à la baisse qu’a connu le token à la réouverture de la plateforme. Si le détail des comptes ayant acheté des tokens pendant le krash vous intéresse, tout est détaillé dans ce Google Sheet
Tout cette fâcheuse histoire rétabli en ordre, Maiar pouvait rouvrir au public le 8 Juin à 10h UTC.
Un petit mot pour la fin
Sacré “résumé” de l’histoire j’en conviens, mais j’avais envie d’écrire quelque chose de vraiment détaillé contrairement aux sites de spécialisé se concentrant sur l’essentiel de l’info. Le but étant d’avoir un article/rapport résumant absolument tout ce qui s’est passé pour garder une trace complète de l’événement. J’y ai croisé toutes les sources possibles et même fait quelques review avec des développeurs afin de s’assurer de la véracité des explications à propos du vol.
J’aimerais aussi accentuer la qualité du travail d’Elrond dans la résolution du problème, je sais que je suis souvent du genre à leur lancer des fleurs, pas parce que je crois à la “prophétie auto-réalisatrice” pour faire pump mon bag, mais bien parce que dans cet écosystème très chaotique et parfois sournois, ils présentent une méthodologie, une transparence et une réactivité dont beaucoup d’équipes devraient prendre exemple. Pouvoir contenir un vol de 120 millions en à peine plus d’une heure, récupérer les fonds tout en sortant un correctif d’urgence 15h après celui-ci, être capable de relancer la machine sans impact majeur dans les 2 jours qui viennent, et dorloter la communauté d’une communication qui, même si elle rebute certain de par son overdose de positivité, se révèle de très bonne qualité. Moi je dis chapeau. Alors certes ça fait mal quand on sait que la faille avait été découverte quelques jours plus tôt et que le correctif était déjà à l’étude. La seule chose que j’aurais à leur reprocher, c’est de ne pas avoir pris l’initiative de fermer Maiar en amont et d’annoncer tout de suite la couleur à la communauté. Il aurait dû endurer du FUD, mais c’est je pense un moindre mal à payer comparé aux risques encourus. Mais je n’en doute pas qu’ils sauront apprendre de cette erreur, je n’imagine pas leurs réactions quand ils ont compris d’où venait le problème. À l’image d’Apple qui travaille le même produit depuis des dizaines d’années afin de faire de l’innovation incrémentale pour le rendre meilleur d’année en année, Elrond a le potentiel de faire de son écosystème un des plus attrayant et adapté aux utilisateurs lambda issu de la réelle adoption “mainstream” tant espéré qui, je l’espère, nous sera réservé pour le prochain cycle. Comme… pour l’entreprise à la pomme. D’abord réservée aux professionnels, puis popularisée avec l’iPhone et l’adoption mondiale des smartphones. Si cela se produit, sans nul doute que nous verrons Elrond dans le Top 10 market cap en 2024/2025.
Mes remerciements à @arda_project, leur cofondateur et développeur @JacobLeygonie, @Contact3w de chez @ecompass_io et @skyzox pour leur aide sur le sujet.
Si vous êtes arrivés jusqu’ici, merci et à la prochaine.
Ah, et courage, la baisse d’aujourd’hui fait très mal, mais on se relèvera tous !
Source :
https://elrond.com/blog/incident-and-recovery-report/
https://twitter.com/beniaminmincu/status/1533950568577781762?s=20&t=Vy0MIAxoHyftJ7bhI0b3FA
https://twitter.com/beniaminmincu/status/1534159591180750850?s=20&t=Vy0MIAxoHyftJ7bhI0b3FA
https://twitter.com/beniaminmincu/status/1534305646262292482?s=20&t=Vy0MIAxoHyftJ7bhI0b3FA
https://twitter.com/Foudres_/status/1533702059001790465?s=20&t=Vy0MIAxoHyftJ7bhI0b3FA
https://twitter.com/Foudres_/status/1534168551199752193?s=20&t=Vy0MIAxoHyftJ7bhI0b3FA
https://twitter.com/Foudres_/status/1534263409969176576?s=20&t=Vy0MIAxoHyftJ7bhI0b3FA
https://twitter.com/Foudres_/status/1534484086722543619?s=20&t=Vy0MIAxoHyftJ7bhI0b3FA
https://twitter.com/Foudres_/status/1534986988889292810?s=20&t=Vy0MIAxoHyftJ7bhI0b3FA
