Blast et Abstract : qui paie pour faire vivre une blockchain ?

Le dernier service utile d’une blockchain peut être celui qui aide ses utilisateurs à la quitter. Il faut retrouver les actifs, choisir une destination, faire traiter une transaction, puis attendre que les conditions de retrait soient remplies. La décision d’un opérateur de fermer transforme ainsi une question abstraite de modèle économique en une série d’opérations très concrètes.

Blast a annoncé le 2 octobre 2026 que ses coûts dépassaient ses revenus et qu’il ne voyait plus de trajectoire crédible vers la rentabilité. Le 6 octobre, Abstract a annoncé à son tour la fin de son activité normale, prévue le 15 décembre. Pour Blast, le 26 octobre concerne la fermeture annoncée de l’interface habituelle ; l’équipe prévoit ensuite des retraits par les contrats sur Ethereum. Ces dates recouvrent des événements différents. ^{[3] [1]}

Abstract pouvait pourtant présenter des compteurs impressionnants. Son annonce revendique plus de 325 millions de transactions et plus de 40 millions de dollars de revenus générés dans son écosystème. Les chiffres viennent de l’équipe, avec une méthodologie et une période de référence peu détaillées. Ils décrivent de l’activité et des recettes générées dans l’écosystème. La continuité de la chaîne dépend d’une autre question : quelle part de cet argent atteint les acteurs qui la font fonctionner ? ^[1]

Luca Netz, dirigeant d’Igloo, affirme qu’Igloo a financé Abstract pendant dix-huit mois et perdu plusieurs dizaines de millions de dollars sur deux ans. Il explique avoir choisi de recentrer les ressources sur Pudgy Penguins. Ce récit rend la décision compréhensible, sans fournir de comptes permettant de reconstituer le déficit ou d’isoler chaque cause. L’enquête doit donc suivre les circuits de paiement, puis les dépendances techniques que l’arrêt révèle. ^[2]

Ce qu’un achat sur une application fait travailler

Imaginez l’achat d’un objet dans un jeu. Une partie du paiement rémunère le vendeur ou l’éditeur. Une transaction modifie ensuite le registre qui associe l’objet à son détenteur. Cette seconde opération consomme du calcul et des services de réseau. L’application peut attirer des clients et vendre des objets pendant que la chaîne perçoit seulement les frais nécessaires au traitement des transactions. Les deux activités ont chacune leur bénéficiaire et leur facture.

Un rollup regroupe des opérations exécutées sur une chaîne secondaire, dite L2, et utilise Ethereum comme chaîne de base, ou L1. Ce regroupement permet de partager certains coûts entre plusieurs transactions. La promesse économique tient à cette mutualisation : offrir un service rapide et peu cher, tout en conservant assez de ressources pour exploiter le système. Sa réalisation dépend de l’architecture et de la demande réellement payante.

Le séquenceur reçoit les transactions et organise leur exécution. D’autres fonctions préparent les lots, publient les données ou les engagements sur Ethereum et maintiennent les services que consultent les portefeuilles. Dans la documentation d’Abstract, le séquenceur et l’opérateur chargé des interactions avec Ethereum ont des rôles distincts. Une expérience qui semble instantanée à l’écran repose sur cette chaîne de tâches. ^[26]

Abstract utilise des preuves cryptographiques pour faire vérifier ses lots sur Ethereum. Produire la preuve mobilise des ressources hors de la chaîne de base ; la soumettre et la vérifier exigent ensuite des transactions sur Ethereum. Les guides Blast décrivent, eux, une preuve de retrait suivie d’une période de contestation. Les fonctions de validation diffèrent. Les deux modèles conservent des besoins de publication, d’exploitation et de suivi. ^{[6] [7] [18] [27]}

La facture peut également être payée par un acteur différent de l’utilisateur final. Un service peut financer certaines opérations pour simplifier l’accès ou attirer des clients. Cette possibilité oblige à regarder l’origine économique du paiement : la présence de frais dans une transaction démontre un transfert de ressources, tandis que la répétition d’un usage durable exige de comprendre qui accepte de le financer. ^[9]

Le succès d’une application ouvre donc plusieurs perspectives. L’éditeur voit son chiffre d’affaires, le détenteur d’un actif voit son solde, et l’opérateur cherche des recettes capables de couvrir les fonctions précédentes. Leur intérêt peut converger lorsque l’activité crée assez de valeur à partager. Il peut diverger lorsqu’une application conserve l’essentiel de ses ventes et sollicite une infrastructure dont le tarif reste très faible.

Les recettes suivent leurs propres chemins

Les revenus de l’écosystème annoncés par Abstract peuvent correspondre à des services et à des droits commerciaux très différents. Pour qu’ils financent la chaîne, il faut un mécanisme de captation : frais d’exécution, contrat de partage, abonnement, prélèvement ou soutien d’une entreprise. Une activité économique installée sur un réseau lui apporte des usages ; elle ne lui attribue automatiquement aucun droit sur chaque vente. La distinction apparaît aussi dans les définitions de DefiLlama, qui classe séparément les frais des applications et ceux des chaînes. ^{[1] [13]}

Même au sein du paiement technique, plusieurs destinations coexistent. La documentation OP Stack distingue les frais d’exécution et la composante liée aux données publiées sur Ethereum. Des versions et configurations ajoutent une composante destinée à l’opérateur. Les paramètres exacts doivent être examinés pour la chaîne considérée. Le montant affiché au portefeuille répond d’abord à la question du coût d’une opération pour son payeur. ^[22]

Blast a poussé cette séparation plus loin en proposant une redistribution aux applications. Sa documentation prévoit un mode par défaut, nommé Void, où les frais du séquenceur vont à l’opérateur, et un mode Claimable, où un contrat peut réclamer les frais qui lui sont attribués, nets des frais L1. L’allocation dépend du calcul consommé par le contrat. Cette conception fait de la rémunération de l’infrastructure un instrument pour attirer des développeurs. ^[8]

Le guide décrit des paramètres de lancement : une réclamation immédiate donnerait 50 % de la tranche concernée au bénéficiaire et 50 % à l’opérateur ; sa maturation sur trente jours permettrait au bénéficiaire d’atteindre 100 %. Ces paramètres documentaires illustrent le mécanisme. Nous n’avons effectué aucune lecture des contrats permettant de confirmer les taux en vigueur pendant la fermeture, ni mesuré un taux global effectivement redistribué. ^[8]

Pour l’application, ce partage crée une source de financement supplémentaire. Pour l’opérateur, il réduit la part de certains frais qu’il peut conserver. L’effet sur la viabilité dépend alors de la croissance des usages, de leur coût et des autres recettes. Les sources disponibles permettent d’expliquer cet arbitrage ; elles laissent inconnue sa contribution précise à la décision de Blast.

Sources et périmètre

Schéma de circulation fondé sur les descriptions des frais d’Abstract, de ZKsync et de l’OP Stack, ainsi que sur la redistribution documentée par Blast. Le financement est également décrit dans la déclaration d’Igloo. [2] Les flèches représentent des fonctions et des destinations, avec des branches conditionnelles selon l’architecture et les accords de financement. Leur largeur ne mesure aucun montant. [6] [7] [8] [22] [27]

Un mois de frais avant les annonces

Pour donner une échelle au flux observable, nous avons retenu septembre 2026, dernier mois civil complet avant les annonces. La série de frais de chaîne publiée par DefiLlama totalise 2 067,07 dollars pour Blast et 121 283 dollars pour Abstract, du 1er au 30 septembre en UTC. Les deux séries comportent trente dates uniques, toutes présentes. Elles ont été collectées le 8 octobre à 15 h 06 UTC et contrôlées de nouveau le même jour. ^{[10] [11]}

Cette observation fixe une période et une définition de fournisseur. Elle permet de regarder la dimension du canal de frais suivi par ses adaptateurs. Elle ne fournit ni les recettes exhaustives conservées par chaque société, ni les coûts d’exploitation. Les différences d’architecture demandent aussi une lecture de la méthode avant d’interpréter les hauteurs des barres comme un classement économique.

Pour Blast, le code examiné calcule le produit du gas consommé et du prix effectif du gas sur la chaîne secondaire. Pour Abstract, il additionne le champ tx_fee de la table gas.fees. Le gas mesure les ressources facturées à une opération. Sur l’OP Stack, la documentation distingue une composante de données L1 facturée séparément. Cette méthode définit le périmètre des frais recensés ; la réconciliation complète des paiements demanderait de vérifier toutes les composantes, les remboursements et les redistributions. ^{[12] [22]}

Données et méthode

Sommes des trente observations quotidiennes UTC du 1er au 30 septembre 2026, champ totalDataChart des réponses dailyFees : Blast, 2 067,07 USD ; Abstract, 121 283 USD. Collecte le 8 octobre 2026 à 15:06:02 UTC, sommes identiques au second contrôle. Aucune annualisation. Les recettes des applications et les coûts de fonctionnement ne sont pas inclus. L’adaptateur et les modèles de facturation limitent l’interprétation du montant recensé ; les séries ne constituent pas des comptes audités. [10] [11] [12] [13] [22]

Les tableaux de bord emploient souvent le mot « revenu » pour une mesure plus étroite que le compte d’une entreprise. DefiLlama définit ses revenus de rollup à partir des frais et de certains paiements à la couche de règlement. Growthepie appelle onchain profit la différence entre recettes observées et coûts de publication ou de vérification, en excluant explicitement le fonctionnement et le développement hors chaîne. Blast et Abstract ne figurent pas dans son périmètre consulté ; cette définition sert ici à comprendre la mesure, sans leur attribuer une série. ^{[13] [9]}

Une limite supplémentaire apparaît dans les données examinées pour Abstract : les séries dailyRevenue et dailyFees coïncident, tandis que le code de calcul possède des valeurs de remplacement à zéro lorsque des sommes de coûts manquent. Un champ égal à zéro peut alors refléter le chemin suivi par le programme plutôt qu’une facture Ethereum inexistante. Nous avons conservé les frais publiés et renoncé à en tirer une marge. ^{[11] [12]}

Le point utile au lecteur est le passage entre observation et conclusion. Compter des paiements dans un registre reste une opération vérifiable. Établir le résultat d’un opérateur exige ensuite de savoir ce qu’il garde, ce qu’il redistribue et ce qu’il dépense ailleurs. Les annonces de pertes proviennent ici des dirigeants ; les séries on-chain éclairent un circuit particulier de financement.

Le coût du lot et celui du service

Le regroupement des transactions peut réduire le coût de publication par opération. Les blobs introduisent sur Ethereum un espace de données avec son propre marché de frais. Abstract y publie des différences d’état et du bytecode compressé, puis fait vérifier les preuves de ses lots. Une hausse du nombre d’opérations peut partager certains coûts de publication entre davantage d’usages. ^{[14] [6]}

La fréquence de publication introduit toutefois un autre arbitrage. Attendre permet de remplir un lot ; publier rapidement donne plus tôt les garanties attendues par les utilisateurs et les services qui les entourent. Un travail de Davide Crapis, Edward Felten et Akaki Mamageishvili étudie précisément cet équilibre entre coût de publication et coût du délai. Son modèle date de 2023 et porte sur les stratégies prévues autour d’EIP-4844. Il éclaire le mécanisme, avec ses hypothèses propres, plutôt qu’un coût mesuré aujourd’hui pour Blast ou Abstract. ^[15]

Une facture Ethereum devenue faible laisse donc plusieurs fonctions à maintenir : traiter les demandes, conserver l’état nécessaire, produire les éléments de validation, surveiller les incidents et entretenir les services d’accès. La documentation ZKsync décrit ces composantes, et celle de l’OP Stack organise les rôles de ses nœuds et opérateurs. Leur coût économique dépend de la configuration, de l’équipe et des engagements de service. ^{[7] [27]}

Les frais prélevés aux utilisateurs doivent rencontrer cette facture plus large. Un faible tarif peut aider un développeur à proposer un jeu ou un paiement agréable. Il limite aussi la recette obtenue par opération. Le réseau peut chercher davantage de volume, modifier sa tarification, vendre d’autres services ou recevoir un financement extérieur. Chacune de ces voies suppose des acteurs disposés à payer ; aucun compteur d’adresses ne garantit ce consentement futur.

Le choix d’Igloo se comprend dans cette perspective. Selon Luca Netz, poursuivre le soutien à Abstract aurait continué à absorber les ressources de Pudgy Penguins. L’arbitrage porte sur l’usage de moyens financiers à l’intérieur d’un groupe, avec une appréciation de la demande future. Le dirigeant dit avoir écarté un token ou une levée auprès du public, faute de conviction dans une trajectoire soutenable. Ses déclarations attestent son choix, sans démontrer qu’une telle émission aurait nécessairement échoué ou réussi. ^[2]

Une émission de jetons pourrait fournir de l’argent ou des incitations. Les recettes d’exécution, elles, reviennent avec les transactions payantes. La différence de temporalité est essentielle : du financement donne du temps pour construire un service ; la répétition d’un revenu conservé permet de l’exploiter plus longtemps. Évaluer une chaîne demande de relier ces deux temporalités, puis d’examiner les engagements pris envers ceux qui y déposent leurs actifs.

La confirmation arrive avant la sortie vers Ethereum

Pour un utilisateur, la transaction semble souvent terminée dès que l’application affiche le résultat. Dans Abstract, cette première réponse correspond à une exécution accompagnée d’une confirmation provisoire. Le séquenceur prépare ensuite un lot, dont les changements d’état sont publiés sur Ethereum. Une preuve du calcul est produite et vérifiée, puis le lot atteint l’étape permettant sa finalisation. La documentation distingue ces phases par leurs fonctions et leurs appels de contrat. ^[16]

Ce parcours explique pourquoi la conservation d’une clé privée ne règle qu’une partie du problème. La clé permet d’autoriser une demande. Son traitement exige ensuite les composants qui exécutent, publient et finalisent. Un détenteur peut encore voir son solde dans un explorateur pendant qu’un maillon nécessaire à la sortie a cessé de fonctionner. Les conditions d’Abstract attirent précisément l’attention sur cette différence entre solde visible et possibilité de transfert. ^[5]

La vérification cryptographique porte sur la cohérence d’un état ou d’un calcul. La continuité porte sur la capacité à produire les étapes suivantes. Ces garanties se rencontrent dans un rollup, avec des responsabilités distinctes. Une preuve déjà vérifiée demeure utile ; les futures demandes ont encore besoin de traitement. Cette séparation rend le coût d’exploitation directement pertinent pour la sécurité pratique des utilisateurs. ^{[16] [26]}

L2BEAT décrit ainsi une limite du mécanisme d’Abstract : des transactions peuvent être déposées dans une file sur Ethereum, mais le séquenceur peut arrêter entièrement son traitement. Sa fiche indique aussi que la publication des engagements d’état dépend de proposeurs autorisés. Une gouvernance peut tenter de les remplacer par une mise à jour. Il s’agit d’une possibilité de reprise à organiser, avec des pouvoirs et des ressources à mobiliser. ^[17]

Le principe d’inclusion forcée consiste à utiliser la chaîne de base pour soumettre une instruction lorsque le chemin habituel devient indisponible. Sa portée dépend des règles du L2. La documentation OP Stack explique cette voie de dépôt sur L1 ; celle de ZKsync décrit des opérations placées dans une file prioritaire et traitées dans un lot. Il faut encore examiner la publication des états, la validation et le retrait qui suit. Les étapes forment une chaîne de dépendances, avec une condition de disponibilité à chacune d’elles. ^{[23] [24]}

Sources et limites

Parcours explicatif à partir du cycle d’Abstract, de ses conditions de fermeture, des mécanismes analysés par L2BEAT et des guides Blast. Les procédures exactes varient selon la chaîne, l’actif et le portefeuille. Le 26 octobre concerne l’interface Blast dans l’annonce ; le 15 décembre concerne la fin annoncée du traitement normal d’Abstract. Les sources ne donnent aucune heure universelle ni garantie de récupération après arrêt. [3] [5] [16] [17] [18] [24]

Deux annonces, deux formes de fermeture

Le message de Blast combine plusieurs opérations. L’équipe annonce le désengagement d’actifs placés chez Lido, attendu en environ une semaine, avec une interruption temporaire des retraits. Elle prévoit ensuite leur reprise avec un délai de vingt-quatre heures. L’interface habituelle doit être fermée le 26 octobre, et les utilisateurs doivent alors pouvoir employer les contrats sur Ethereum L1. Ces éléments décrivent un plan annoncé ; le texte ne fixe aucune date précise du dernier bloc ou de l’arrêt du séquenceur. ^[3]

Abstract annonce une autre borne : la fin du traitement normal le 15 décembre. Son message invite à déplacer les actifs avant cette date et annonce une perte d’accès pour ceux qui resteraient sur la chaîne. Ses conditions, mises à jour le 6 octobre, précisent qu’une demande soumise peut encore exiger des étapes sur la chaîne de destination et qu’aucun mécanisme de récupération après l’arrêt n’est promis. Elles permettent de comprendre ce que le fournisseur annonce, avec les réserves habituelles sur les droits impératifs applicables. ^{[1] [5]}

Ces conditions nomment Cube, Inc. comme cocontractant pour les services concernés. Le récit du financement vient d’Igloo, et certaines fonctions de gouvernance relèvent d’autres organes. Les noms se rejoignent dans un même projet tout en renvoyant à des rôles juridiques et techniques distincts. Une enquête sur la continuité doit conserver cette séparation, faute de quoi elle attribuerait un engagement ou un pouvoir à la mauvaise entité. ^{[5] [2]}

L’annonce d’Abstract mentionne un délai attendu de trois heures pour son bridge natif. Le calendrier effectif peut varier selon la route et les étapes encore nécessaires. La date du 15 décembre est donnée sans heure ni fuseau d’arrêt. Ces informations permettent de situer le plan de fermeture, avec une précision limitée. Elles ne justifient aucun compte à rebours exact pour un transfert particulier. ^[1]

Fermer une interface, interrompre la réception de demandes et mettre fin à l’exécution modifient chacun une partie du service. Des contrats peuvent subsister sur Ethereum après la disparition d’un site. Leur utilité dépend alors des états disponibles, des preuves requises, des fonds mobilisables et des personnes capables d’accomplir la suite. La promesse de Blast concernant les contrats mérite donc d’être lue avec ses guides, plutôt que comme un simple prolongement du bouton de retrait. ^{[3] [18]}

Le retrait des ETH et celui des USDB

Le guide Blast destiné aux comptes ordinaires, contrôlés par une clé, décrit un trajet en plusieurs étapes. L’utilisateur initie le retrait sur Blast. Il attend que l’état nécessaire soit disponible sur Ethereum, ce qui peut prendre jusqu’à environ une heure selon le guide, puis soumet une preuve. Après une période de contestation d’un jour, il réclame les ETH sur Ethereum. La procédure compte deux transactions Ethereum après l’initiation sur Blast. Ces délais sont des indications documentaires, avec des conditions de réseau et de traitement. ^[18]

Le parcours des USDB ajoute une transformation et une attente. Le guide indique que les USDB retirés arrivent sous forme de DAI sur Ethereum. Après la preuve et la période de contestation d’un jour, la finalisation crée une demande dans la file de retrait. Le traitement peut encore prendre jusqu’à un jour avant la réclamation des DAI. Le guide décrit trois transactions Ethereum. Les noms des jetons renvoient ici à des actifs et à des contrats différents ; les étapes précisent comment passer de l’un à l’autre. ^[18]

Les contrats et les portefeuilles intelligents ajoutent d’autres conditions. Le guide de retrait des ETH détenus par un contrat exige la disponibilité de la racine contenant l’opération, puis la preuve, la période prévue et le traitement de la file. Pour les USDB, le guide précise que la réclamation doit être envoyée par le destinataire. Il faut donc que ce destinataire puisse effectuer l’appel requis. L’adresse de réception constitue une condition d’exécution, au-delà du simple endroit où afficher le solde. ^{[19] [20]}

Blast Mobile présente encore un parcours particulier. La documentation demande de sortir du produit Earn, lorsqu’il est utilisé, puis de transférer vers un compte ordinaire sur Blast avant de passer par le bridge. Le portefeuille intelligent et ses modalités de contrôle rendent cette préparation nécessaire. Réutiliser une adresse sur une autre chaîne ne fournit à lui seul aucun des appels ou pouvoirs qu’exige la récupération. ^[21]

Ces procédures montrent pourquoi une fermeture doit rester financée pendant sa propre exécution. Le fournisseur doit maintenir assez de services pour recevoir et suivre les demandes, les utilisateurs doivent payer les transactions nécessaires, et les files doivent continuer à être traitées. La sortie absorbe du temps et des ressources après la décision stratégique d’arrêter. Les actifs déposés transforment la fin du produit en une opération de continuité à durée limitée.

Reprendre une chaîne demande des moyens et des pouvoirs

L’accès au logiciel peut aider un autre acteur à reprendre une partie de l’infrastructure. Le reste de la question concerne les droits de publication, la récupération des données utiles, l’état des contrats et les capacités de validation. Dans un dispositif où les engagements d’état doivent être publiés par des acteurs autorisés, un nouveau serveur doit aussi recevoir les pouvoirs nécessaires. La documentation d’architecture et l’analyse de gouvernance permettent d’identifier ces fonctions, sans constater qu’un repreneur est disponible dans les deux cas étudiés. ^{[17] [27]}

Les proposeurs de rollup publient les engagements utilisés par les étapes de validation ou de retrait. Leur fonctionnement illustre la jonction entre finance et architecture. Maintenir ce service demande une personne ou une organisation disposée à agir, les clés et permissions appropriées, puis un budget. Une reprise peut être techniquement concevable et rester économiquement ou institutionnellement difficile à organiser.

La disponibilité des données pose une autre question de continuité. EIP-4844 organise une conservation temporaire des blobs par les nœuds concernés. La suite d’un service peut donc nécessiter des dispositifs qui conservent ou reconstruisent les données utiles au-delà de cette disponibilité initiale. Le mécanisme de publication offre une garantie précise pendant une période donnée ; l’archivage et la reprise mobilisent encore des fonctions distinctes. ^[14]

Pour les développeurs, déplacer une application signifie davantage que redéployer son code compatible avec l’environnement Ethereum. Les soldes, les jetons, les droits inscrits dans des contrats et les positions de liquidité doivent suivre des procédures adaptées. Un bridge organise un transfert entre systèmes selon ses règles ; il faut ensuite un environnement dans lequel les utilisateurs puissent retrouver leurs droits et continuer les opérations attendues. La documentation d’Abstract décrit ces relations entre ses contrats et Ethereum. ^[25]

L’équipe d’Abstract annonce une assistance d’ingénierie et d’écosystème aux projets qui migrent. Cette aide peut diminuer le coût de transition, tandis que chaque application conserve ses propres contraintes de contrats, de clients et d’actifs. L’usage accumulé sur la chaîne contient alors une valeur économique à transporter : relations commerciales, habitudes, interfaces, liquidité et information. Une partie de cette valeur dépend du bon déroulement de la fermeture. ^[1]

Les preuves à demander sur la continuité

Le cas des deux réseaux invite à lire une infrastructure à travers les fonctions qu’elle doit assurer. La transaction et sa facture renseignent le service rendu aujourd’hui. Les ressources conservées, les engagements de financement et les conditions de remplacement des acteurs éclairent la possibilité de le maintenir. Enfin, le trajet de sortie montre ce que le détenteur peut effectivement accomplir si ces engagements changent.

Le financement par une maison mère peut construire un produit pendant plusieurs années. Son intérêt dépend toutefois de ce que cette entreprise pense gagner dans la suite du projet. Luca Netz affirme que cet arbitrage a changé pour Abstract. Les déclarations de fermeture de Blast présentent aussi la soutenabilité comme une limite atteinte. Les deux récits révèlent une décision d’allocation de ressources ; la part précise du tarif, du volume, des coûts techniques ou de l’organisation reste à établir avec des comptes plus complets. ^{[2] [3]}

L’analyse fondamentale d’une infrastructure peut suivre ce chemin sans transformer chaque compteur en verdict. Les frais observables donnent un point d’entrée. Il faut ensuite comprendre qui les conserve et ce qu’ils doivent financer, puis regarder les mécanismes de continuité et de reprise. Dans les rollups, cette dernière question appartient au modèle économique : les services qui permettent de quitter la chaîne doivent eux aussi être exploités.

Les fermetures annoncées de Blast et d’Abstract rendent cette dépendance visible. Le registre peut conserver un historique alors que l’organisation qui permettait de l’utiliser retire son financement. La qualité d’une infrastructure se lit alors dans la façon dont elle relie ses recettes à ses obligations, et dans les possibilités concrètes qu’elle laisse à ceux qui doivent transférer leurs actifs.

Périmètre et limites de l’enquête

Cette enquête repose sur les annonces et les documents consultés le 8 octobre 2026. Les motifs et pertes annoncés sont attribués aux équipes et à Luca Netz. Les compteurs d’Abstract sont des seuils déclarés : ses quatre millions de portefeuilles AGW créés coexistent avec une déclaration de plus de 400 000 utilisateurs accueillis. Ils ne permettent pas de transformer le nombre de portefeuilles en nombre de personnes. Leur période et leur méthode restent peu détaillées. ^[1]

Le graphique de septembre utilise uniquement les séries dailyFees de DefiLlama, avec trente dates présentes par chaîne, des montants publiés en dollars et aucune conversion de prix effectuée par l0g. Les valeurs peuvent être révisées par le fournisseur. La méthode des adaptateurs limite leur couverture ; aucun résultat net, coût nul ou déficit mensuel n’a été reconstitué. La documentation des autres tableaux de bord sert à expliquer leurs définitions. ^{[10] [11] [12] [13]}

Les procédures décrites viennent des guides officiels et des analyses techniques citées. Aucune transaction de retrait ni lecture de configuration contractuelle actuelle n’a été exécutée. Les annonces peuvent être complétées, les interfaces modifiées et les routes adaptées. La fiche Blast de L2BEAT signale des changements d’implémentation et des informations potentiellement périmées : ses anciens délais ou permissions ne sont donc pas utilisés comme un audit de la fermeture en cours. ^[17]

Pour prolonger l’analyse : Ethereum et les couches de la finance institutionnelle, les intermédiaires qui organisent l’accès à la DeFi, les transferts d’actifs et leurs règles entre chaînes et la lecture critique de la donnée on-chain.

Sources

1. Abstract, annonce de fermeture du 6 octobre 2026. Texte et image d’origine lus ; calendrier, diagnostic et compteurs déclarés par l’équipe.
2. Luca Netz, décision de financement du 6 octobre 2026. Déclarations du dirigeant sur les pertes, le soutien d’Igloo et l’émission de jetons écartée.
3. Blast, annonce du 2 octobre 2026. Motif économique, désengagement Lido, calendrier de l’interface et route contractuelle annoncée.
4. CoinDesk, fermeture annoncée d’Abstract, 7 octobre 2026. Mise en contexte journalistique ; ses instantanés financiers ne sont pas repris comme données de graphique.
5. Abstract, conditions de service, version du 6 octobre 2026, sections 12.1, 12.5 et 12.6. Disponibilité, étapes de sortie et entités concernées ; dispositions attribuées au fournisseur.
6. Abstract, frais de gas. Composantes de facturation, données et preuves ; les exemples de tarif ne sont pas utilisés comme prix actuels.
7. ZKsync, structure des frais et tarification des données publiées. Publication, preuves et coûts d’infrastructure hors chaîne.
8. Blast, réception et réclamation des frais de gas. Modes Void et Claimable, frais nets L1 et paramètres de maturité documentés.
9. Growthepie, définition de l’onchain profit. Périmètre observable et coûts hors chaîne exclus ; aucune série attribuée à Blast ou Abstract.
10. DefiLlama, série Blast dailyFees. Somme des observations du 1er au 30 septembre 2026 UTC ; collecte le 8 octobre à 15:06:02 UTC.
11. DefiLlama, série Abstract dailyFees et dailyRevenue. Période et collecte identiques ; le second champ ne sert à aucun calcul de marge.
12. DefiLlama, helper des frais L2 au commit 2a5816d4. Méthode de collecte et valeurs de remplacement à zéro, avec limites de couverture.
13. DefiLlama, définitions des données. Frais de chaîne, frais d’applications, revenus et charges.
14. Ethereum, EIP-4844. Transactions à blobs, marché de frais dédié et conservation temporaire ; aucun ancien plafond de capacité repris comme paramètre actuel.
15. Crapis, Felten et Mamageishvili, EIP-4844 Economics and Rollup Strategies, version du 2 octobre 2023. Modèle théorique du coût de publication et du délai.
16. Abstract, cycle d’une transaction. Confirmation provisoire, publication, preuve et finalisation sur Ethereum.
17. L2BEAT, analyse d’Abstract et fiche Blast sous revue. File L1, séquenceur, proposeurs et gouvernance ; consultation le 8 octobre 2026, limites de fraîcheur explicitées dans le texte.
18. Blast, retrait vers Ethereum. Procédures documentées pour ETH, WETH et USDB depuis un compte ordinaire.
19. Blast, retrait d’ETH depuis un contrat. Racines, preuve et file de retrait.
20. Blast, retrait d’USDB depuis un contrat. File USD, DAI et appel de réclamation par le destinataire.
21. Blast, sortie de Blast Mobile. Préparation des actifs et passage par un compte ordinaire avant retrait.
22. OP Stack, frais de transaction. Composantes de la facture, avec paramètres dépendant de la version et de la configuration.
23. OP Stack, inclusion forcée. Soumission via Ethereum en cas d’indisponibilité du chemin de séquençage habituel.
24. ZKsync, opérations initiées depuis L1. File prioritaire et traitement des requêtes dans les lots.
25. Abstract, documentation des bridges. Relations entre les contrats de chaîne et les transferts Ethereum.
26. Abstract, séquenceur et opérateur Ethereum. Rôles de réception, d’exécution et de publication.
27. OP Stack, architecture du réseau. Services et rôles à maintenir autour de l’exécution et du règlement.