Auteur :Yacht (鸭特TATAYA)
En tant que vétéran de la cryptosphère, vous connaissez certainement bien cette question mème :
Comment as-tu commencé à te plonger dans la cryptosphère ?
A : Un ami m'a présenté. B : Je l'ai découvert en ligne. C : Je l'ai appris d'une institution financière. D : Un ennemi m'a piégé.
Mais arrivé en 2026, nous sommes confrontés à une question de plus en plus amère :
Comment le projet que tu utilisais a-t-il disparu de la cryptosphère ?
A : L'équipe a officiellement annoncé l'arrêt et a mis fin aux services selon le plan. B : Un jour comme un autre, le site web, le frontend et l'API ne répondent plus.
C : Appris soudainement via une proposition de gouvernance, des documents judiciaires ou des nouvelles. D : Ce n'est qu'en lisant cet article que j'ai réalisé qu'il était inactif depuis longtemps.
L'analyse des données révèle une ligne de démarcation claire dans la liste des départs de 2026 : après l'arrêt d'un projet, ses fonctionnalités continuent de migrer dans l'industrie. Les modèles de produits tels que les contrats perpétuels, le scaling ZK, l'agrégation d'actifs, le crédit on-chain, la propriété non-custodiale ne disparaissent pas avec l'équipe d'origine. De nombreuses capacités sont déjà intégrées par défaut dans les bourses, les portefeuilles, les protocoles et les plateformes de données. Pour les investisseurs, le statut d'un projet ne fait que consigner la fin d'une organisation ; c'est le flux des fonctionnalités qui explique ce qu'une innovation a réellement laissé derrière elle.
La fermeture de BitMEX place cette démarcation sous son jour le plus saisissant. Fondée en 2014, BitMEX a lancé le XBTUSD en mai 2016, créant ainsi le contrat perpétuel sur Bitcoin. Son design avec frais de financement et sans date d'expiration s'est adapté au marché crypto sans interruption, faisant du contrat perpétuel un produit central des dérivés cryptos mondiaux. Le 23 juillet 2026, BitMEX a annoncé son intention de fermer la bourse : passage en mode « réduction de position uniquement » le 26 août, arrêt des transactions et clôture des positions restantes le 23 septembre, suivis du traitement des retraits.
Pourquoi la même entreprise peut-elle obtenir une note élevée dans l'histoire des produits tout en se dirigeant vers sa fin dans l'histoire des affaires ? L'évaluation historique s'intéresse à ce qu'elle a défini, au nombre d'utilisateurs éduqués, aux concurrents modifiés ; l'évaluation des investissements continue de questionner où reste la liquidité, qui contrôle l'entrée des utilisateurs, comment les frais de transaction se matérialisent, et le coût de migration après la diffusion de la technologie. Superposer ces deux critères rend l'évaluation complexe : la contribution des pionniers peut être effacée par leur fin opérationnelle, et les risques opérationnels peuvent être masqués par leur aura de pionnier.
Respecter les pionniers n'équivaut pas à renoncer au jugement sur la durabilité. Cet article sélectionne 110 échantillons sur la base de données publiques. Cet échantillon couvre sept catégories principales, avec des différences notables en notoriété et en capital : Échange et Finance Décentralisés (31), Consommation, Social et Divertissement (28), Infrastructure et Services aux Développeurs (14), Échange et Services Financiers Centralisés (13), le reste étant réparti entre Organisation & Financement, Portefeuilles & Données, Émission d'Actifs et RWA, etc. 45 projets ont divulgué leur financement, totalisant 516,52 millions de dollars ; 65 n'ont pas divulgué de montants. Les plus importants incluent Loopring (45 M$), ICON (43 M$), Goldfinch (37 M$), ainsi que plusieurs sociétés soutenues par a16z, Pantera, Coinbase Ventures, Polychain, etc.
L'échantillon couvre des projets très connus comme BitMEX, Loopring, Zapper, Foundation, Goldfinch, ainsi qu'une longue traîne d'équipes peu discutées publiquement, avec des matériaux insuffisants pour confirmer leur statut de sortie. Les nouvelles vont des annonces d'arrêt progressif (BitMEX, BitMart) à la mise hors ligne de produits (Loopring, Zapper), en passant par la mise en mode maintenance par gouvernance (Goldfinch), l'échec de vente (Foundation), l'entrée en Chapter 11 (Poolin), l'arrêt des opérations (AscendEX) et les conflits post-incident de sécurité (Ionic). Ces matériaux conservent l'histoire des produits, du capital et des crises, fournissant un contexte commun pour suivre la migration des fonctionnalités et le transfert de valeur.
Les informations les plus précieuses que nous souhaitons obtenir proviennent de la chaîne « Départ du projet — Diffusion des fonctionnalités — Transfert de valeur ». Elle sépare trois résultats indépendants : l'innovation initiale, l'adoption par l'industrie et la capture commerciale. Elle permet également aux investisseurs de voir plus tôt : lorsqu'une fonctionnalité est largement adoptée, l'horloge commerciale du projet original peut déjà être en compte à rebours.
Quatre conclusions principales :
- Après le départ d'un projet, ses fonctionnalités continuent de migrer. 82/110 projets (74,5 %) ont vu leurs fonctionnalités principales largement héritées ou partiellement diffusées. La durée de vie organisationnelle des projets Web3 est souvent plus courte que la durée de vie de leurs paradigmes de produit.
- La vitesse de réplication réduit la fenêtre de commercialisation. Parmi les 47 projets fondés entre 2023 et 2025, 39 (83,0 %) ont vu leurs fonctionnalités héritées ou diffusées, contre 72,7 % pour les projets 2019–2022.
- Le capital est très concentré, mais les issues divergent. Les 45 projets ayant divulgué leur financement ont levé 516,52 M$. Les 10 premiers en ont absorbé 60,1 %. Les produits comme Loopring, Goldfinch et Zapper ont respectivement abouti à une mise hors ligne, une maintenance par gouvernance et un arrêt ordonné.
- La forme publique la plus courante de départ est la disparition silencieuse au niveau opérationnel. Parmi les 31 projets où la modalité de sortie est confirmée, 17 se sont traduits par la mise hors ligne du produit ou du réseau. De nombreux projets ne sont identifiés par le marché qu'après l'arrêt du frontend, de l'API ou de l'activité de l'équipe. La surveillance des investissements doit avancer au niveau des signaux de maintenance, d'activité, de revenus et d'équipe.
I. Après la disparition du projet, où vont les fonctionnalités ?
Le départ n'emporte pas tout l'héritage du produit. Sur 110 projets, 42 ont vu leurs fonctionnalités principales largement héritées ou commoditisées, 40 ont connu un héritage partiel ou une diffusion adjacente, soit 82 au total (74,5 %). Cette statistique ne concerne pas la propriété des brevets ; elle s'intéresse à la capacité de l'industrie à continuer d'assurer les tâches des utilisateurs après le départ du produit original.
Par catégorie, la migration des fonctionnalités suit trois chemins. L'échange et finance décentralisés (31 projets) : 25 cas d'héritage/diffusion, dont 21 largement hérités. Portefeuilles, données et outils (9 projets) : 8 laissent un héritage identifiable. Émission d'actifs, RWA et paiement (6 projets) : tous largement hérités. Les modules comme le routage de transactions, l'agrégation d'actifs, le règlement en stablecoin, le crédit on-chain s'intègrent facilement dans des systèmes de capitaux et de comptes plus larges, créant toujours de la valeur transactionnelle et data après absorption.
Consommation, social et divertissement (28 projets) : 27 cas d'héritage/diffusion (96,4 %), dont 26 de diffusion partielle. Cette structure est clé : les produits de consommation laissent souvent des designs d'interaction, des mécanismes d'incitation, des formats de contenu ou des mécaniques communautaires qui se transforment dans des produits adjacents, rarement conservés comme standards complets de l'industrie. L'échange et services financiers centralisés (13 projets) : seulement 4 largement hérités. Les capacités de matching, de custodie, de gestion des risques et de licence des bourses sont fortement couplées ; une fonction individuelle peut être copiée, mais la migration de l'ensemble des capacités institutionnelles est plus lente.
Ce graphique croisé donne un critère plus utile que le nombre de catégories : le niveau de modularité d'une fonctionnalité affecte sa vitesse de diffusion ; la capacité du projet original à connecter son module à des systèmes de distribution, de comptes, de liquidité et de frais détermine à qui appartient la valeur après diffusion. Un tableau de bord rapidement intégré dans un portefeuille peut avoir un impact historique important, mais son espace de revenu indépendant se réduit rapidement ; un produit nécessitant du souscripteur, de la conformité et un bilan se réplique plus lentement, avec des coûts d'exploitation à long terme plus lourds.
Les 42 projets largement hérités montrent que l'éducation des utilisateurs est achevée. Les 28 projets non vérifiés signalent un autre type de risque : le marché n'a peut-être jamais formé une tâche claire, ou les matériaux existants sont insuffisants pour identifier son héritage. Les deux laissent des leçons différentes : pour les premiers, vérifier quelles ressources rares subsistent après la réplication par les concurrents ; pour les seconds, vérifier si le problème lui-même dispose d'un budget stable. Plus la diffusion d'une innovation réussit, plus les investisseurs doivent suivre les données, la marque, la liquidité, les revenus du protocole et le contrôle des canaux, au lieu de se contenter d'une liste de fonctionnalités.
II. La vitesse de réplication dépasse désormais celle de la commercialisation
98 projets ont une année de fondation valide. Parmi les 7 projets fondés en 2018 ou avant, 4 (57,1 %) ont vu leurs fonctionnalités héritées/diffusées. Pour 2019–2022 : 32/44 (72,7 %). Pour 2023–2025 : 39/47 (83,0 %). Un codage manuel ne peut prouver que les concurrents aient copié ces projets un par un ; de nouvelles startups peuvent aussi choisir des directions de produit très similaires dès le départ. Mais quelle que soit la source – imitation directe, assemblage open-source ou développement concurrentiel – les conséquences commerciales sont similaires : la période de rareté des fonctionnalités se raccourcit.
Cette différence temporelle doit être interprétée avec prudence, mais les implications pour l'investissement sont claires : dans un environnement de code open-source, d'infrastructure modulaire, de fournisseurs de liquidité matures et de SDK standardisés, des produits similaires peuvent apparaître plus rapidement. L'évaluation technologique doit donc intégrer une « demi-vie d'avance » : combien de temps les concurrents mettent-ils à refaire la fonctionnalité clé ? Combien de temps les plateformes mettent-elles à l'intégrer ? Quel coût de migration pour les utilisateurs ? La valeur du premier lancement existe toujours, mais elle ressemble davantage à une option à durée limitée.
La comparaison BitMEX—Hyperliquid illustre la différence entre le premier lancement et la capture systémique. BitMEX a défini le contrat perpétuel Bitcoin et accompli l'éducation des utilisateurs la plus coûteuse. Hyperliquid a repris une catégorie mature, intégrant le carnet d'ordres, la marge, la liquidité, la distribution aux développeurs et le recyclage des frais dans un système unifié. Chez Hyperliquid, les frais de transaction vont vers HLP, le fonds d'assistance et les déployeurs ; le fonds d'assistance convertit automatiquement les frais en HYPE et les brûle ; les Builder Codes permettent aux applications de percevoir des frais on-chain pour les ordres envoyés en leur nom ; le HIP-3 permet aux déployeurs de créer des marchés perpétuels sur le carnet d'ordres et la pile de marges HyperCore partagés, en assumant la responsabilité des oracles, du levier et du règlement.
Les données trimestrielles complètes montrent l'ampleur de cette boucle fermée. DefiLlama rapporte pour Hyperliquid Perps au Q2 2026 : Revenu Brut du Protocole de 193,65 M$, dont 177,27 M$ de frais perpétuels, 16,38 M$ de frais Builder Code, et Bénéfices de 143,12 M$. Ces chiffres montrent comment les frais traversent la pile de produits DEX et forment des relations de distribution entre développeurs, liquidité et protocole.
Une plateforme arrivant après peut partir d'une demande mature et déplacer la compétition vers les capacités systémiques : une liquidité unifiée réduit les coûts de lancement, les frais pour développeurs transforment les entrées externes en partenaires de distribution, les mécanismes de déploiement de marchés élargissent la gamme, la destruction des frais crée un recyclage de valeur. La contribution historique de BitMEX reste valide, mais Hyperliquid montre qu'après le premier lancement, une course plus longue commence – verrouiller produit, distribution, liquidité et système économique dans une boucle vertueuse.
III. L'avantage technologique ne s'est pas transformé en droit à la survie
Pour qu'un avantage technologique se transforme en capacité de survie, il doit successivement créer une tâche utilisateur, un avantage de distribution, une capacité de génération de revenus et un budget de maintenance à long terme. Si une couche se brise, la technologie peut être héritée par l'industrie, mais le projet original ne peut continuer. Loopring et Zapper partent respectivement de l'architecture technique et de la définition produit, mais rencontrent le même problème : l'avantage du premier lanceur ne s'est pas transformé en une position écosystémique et un flux de trésorerie suffisamment stables.
Loopring était un projet Layer 2 précoce combinant ZK-Rollup, une architecture transactionnelle dédiée, un portefeuille non-custodial et un DEX. Il a aidé l'industrie à comprendre la valeur de l'exécution hors-chaîne, de la vérification sur la chaîne principale et des transactions en self-custody. Il a levé environ 45 M$, avec des investisseurs comme Fundamental Labs, Eden Block, Zero Age Ventures. Avec la maturation des Rollup génériques, des environnements compatibles EVM et d'écosystèmes développeurs plus grands, le centre de la compétition s'est déplacé des performances d'exécution vers la compatibilité des outils, la composabilité des applications, la liquidité et les entrées utilisateurs.
Une architecture dédiée peut améliorer l'efficacité de certaines tâches transactionnelles, mais elle nécessite que l'équipe attire continuellement des applications, des ressources de market making et des partenariats commerciaux. Loopring n'a pas transformé son avantage technique initial en une échelle d'adoption et d'écosystème suffisante. Le 28 juin 2026, son site web est passé à une page d'adieu « Loopring Has Shut Down », son DEX principal a été mis hors ligne, le projet a organisé le remboursement des actifs des utilisateurs via une mise à niveau de contrat, et le LRC a perdu son utilité produit principale. L'arrêt est confirmé directement par le site ; l'adoption insuffisante, les limitations architecturales et le développement commercial sont documentés par des déclarations d'équipe conservées par des médias fiables.
L'avance de Zapper était davantage liée à la définition produit. Dès 2019, il a agrégé les positions, les rendements et les récompenses à réclamer de multiples protocoles DeFi dans une interface unifiée, s'étendant ensuite à l'agrégation de transactions, aux NFT, au mobile et à l'API, présentant pour la première fois des combinaisons on-chain complexes comme des comptes d'actifs compréhensibles pour l'utilisateur moyen. Zapper a levé environ 16,5 M$, dont un tour de seed de 1,5 M$ et un tour Series A de 15 M$ mené par Framework Ventures.
La tâche utilisateur du tableau de bord d'actifs a été validée, mais l'exploitation continue doit couvrir les coûts d'indexation multi-chaînes, d'adaptation aux protocoles, de mise à jour des données et de service API. Parallèlement, les portefeuilles, bourses et plateformes de données peuvent intégrer des interfaces similaires comme fonctionnalités par défaut, réduisant l'espace de distribution et de revenus pour un produit indépendant. DeBank et Rabby offrent un mécanisme de référence : DeBank étend les données d'adresses et de protocoles en API à volume et en ciblage d'adresses ; Rabby intègre les capacités de données dans l'entrée à haute fréquence d'un portefeuille. Cette comparaison n'explique que la couche de revenus et de distribution manquante à Zapper, et ne constitue pas un jugement sur la sécurité ou la valeur d'investissement des projets en activité.
Le 8 juillet 2026, une déclaration du fondateur conservée par les médias a annoncé la sortie ordonnée de Zapper ; le site, l'application mobile et l'API ont cessé le 3 août. Ces matériaux confirment la date et la portée de l'arrêt. L'équipe n'ayant pas divulgué de détails sur les revenus, la consommation de trésorerie ou les négociations, « la fonctionnalité absorbée par les plateformes, l'espace de revenus indépendant compressé » ne peut être qu'une inférence de mécanisme commercial.
Replacés dans la base de financement des 110 projets, ces cas montrent une forte concentration du capital. Les 45 projets ayant divulgué leur financement totalisent ~516,52 M$, avec une médiane d'environ 5,28 M$ ; les 10 premiers absorbent 60,1%, les 65 autres projets n'ayant pas divulgué de montants. Les non-divulgations sont considérées comme des valeurs vides, non comptées comme zéro.
Trois cas très connus présentent des issues différentes : Loopring (45 M$) aboutit à une mise hors ligne produit ; Goldfinch (37 M$) passe en maintenance par gouvernance, avec rachat de Prime et poursuite du recouvrement pour les pools restants ; Zapper (16,5 M$) procède à un arrêt ordonné. Ainsi, l'avantage technique et la capacité de financement ne remplacent pas une boucle commerciale fermée. Le capital peut prolonger la fenêtre de validation, mais la position à long terme dépend toujours de la connexion entre adoption, distribution, revenus et budget de maintenance.
IV. L'innovation à forte densité de responsabilités : les coûts de survie se situent hors-chaîne
Certains produits Web3 assument bien plus que la maintenance logicielle. Le souscripteur, la custodie, l'isolation d'actifs, le recouvrement légal, les licences, le service client et la gestion de crise nécessitent tous une organisation et un budget permanents. Cet article appelle cet ensemble d'obligations « densité de responsabilité » : plus un produit s'approche du crédit, de la custodie, des actifs réels ou de l'échange centralisé, plus les obligations hors-chaîne sont nombreuses, et l'interface entre le système technique et le système opérationnel devient une source de risque potentielle. Goldfinch, Foundation, Poolin et AscendEX exposent respectivement cette responsabilité dans l'exécution du crédit, la continuité de service, les dettes de la société et la sortie des clients.
Goldfinch, fondé en 2020, était l'un des premiers protocoles DeFi à étendre le crédit on-chain à des emprunteurs réels sans nécessiter de collatéral crypto. Il a levé ~37 M$, avec des investisseurs comme a16z, Alliance, SV Angel. Il a élargi les frontières des actifs DeFi, mais a aussi introduit dans les coûts à long terme du protocole la sélection des emprunteurs, la vérification des informations financières, la gestion des défauts, l'exécution judiciaire et le recouvrement transfrontalier.
En juin 2026, la GIP-87 a proposé d'arrêter le développement de nouveaux produits et les dépenses de croissance, de mettre le protocole en mode maintenance, et de fermer Goldfinch Prime. Les documents de gouvernance montrent que le protocole original a facilité ~100 M$ de prêts sur plus de deux ans, plusieurs pools ayant de graves problèmes de performance ; l'adoption de Prime était insuffisante pour justifier des investissements continus. La proposition alloue un budget fixe de 150 000 $ pour la transition, la maintenance et le recouvrement des actifs restants, et prévoit de transférer les droits et ressources de recouvrement à un trust américain. Une mise à jour du 7 juillet confirme que les investisseurs Prime ont été rachetés au principal complet plus un mois d'intérêts, tandis que les pools de prêts restants attendent toujours remboursement ou recouvrement.
Le point de rupture de responsabilité de Goldfinch se situe dans l'exécution du crédit. L'enregistrement on-chain peut améliorer la visibilité des flux financiers, mais le bilan de l'emprunteur, la saisie des garanties, l'ordre des créances et la juridiction sont déterminés par des faits hors-chaîne. Le rachat de Prime et le recouvrement des pools restants correspondent à deux processus d'actifs distincts ; une narration combinée surestimerait l'avancement du règlement. Les rendements RWA doivent aussi être ajustés des pertes sur défauts, des coûts légaux, du budget de gouvernance et de l'immobilisation de capital pour approcher le rendement réel de l'investisseur.
Passant de l'exécution du crédit à l'affichage d'actifs numériques, Foundation expose une autre responsabilité. Fondée en 2020, Foundation était l'un des premiers marchés NFT mettant l'accent sur la propriété des créateurs et les transactions non-custodiales, soutenu par a16z, Variant Fund, Standard Crypto, etc. (aucun montant de financement cumulé confirmé n'a été divulgué publiquement). La plateforme avait tenté de se vendre à un tiers, mais la transaction a échoué ; l'équipe n'avait plus les conditions financières et opérationnelles pour reprendre et maintenir la plateforme à long terme. Le site a confirmé en avril 2026 que la plateforme était définitivement hors ligne.
Le point de rupture de responsabilité de Foundation se situe dans la couche de service autour des actifs numériques. Les NFT et smart contracts restent sur la chaîne, les utilisateurs contrôlent toujours leurs actifs dans leurs portefeuilles ; les NFT listés dans des contrats doivent être retirés manuellement, la disponibilité à long terme des médias dépend de redondances supplémentaires, et la découverte, l'indexation et les relations sociales nécessitent un nouveau frontend. L'équipe s'est engagée à maintenir la passerelle IPFS jusqu'au 27 avril 2027, laissant du temps à la migration communautaire. Le non-custodial protège la propriété, mais le frontend, les métadonnées, le service client et le support à la migration consomment toujours un budget réel.
Poolin pousse la responsabilité davantage dans le bilan de la société. Fondée en 2017, elle a commencé comme pool de minage crypto, s'étendant ensuite aux portefeuilles, à la gestion de patrimoine et aux investissements dans des fermes. Le hashrate, la production de blocs et les revenus on-chain d'un pool sont assez observables, mais les passifs des portefeuilles de custodie, les transactions avec entités liées, les hypothèques sur fermes et les coûts fixes élevés se répartissent dans des contrats et entités juridiques hors-chaîne. Plus il y a de produits, plus la propriété des actifs des utilisateurs, l'ordre des créances et les arrangements de garantie doivent être vérifiés séparément.
Le 22 juillet 2026, Poolin Technology PTE. LTD., Lonestar Taproot LLC et Lonestar Dream, Inc. ont déposé une demande de Chapter 11 aux États-Unis, les cas étant gérés conjointement par le tribunal des faillites du New Jersey. Cette procédure légale confirme que trois entités débitrices sont entrées en restructuration ; cela ne signifie pas que tous les services de pool ont cessé le même jour. Les résultats pour les clients et autres créanciers dépendront de la vente d'actifs et de la restructuration, la valeur des actions venant après les créances. Le point de rupture de Poolin se situe entre les comptes produits et le bilan de la société : le hashrate public ne peut remplacer une analyse approfondie des passifs de custodie et des transactions liées.
AscendEX concentre technologie, licence et sortie des clients sur une même plateforme. Elle proposait du trading spot, de l'échange, du staking, du prêt et d'autres services d'actifs cryptos. Une lettre officielle aux utilisateurs a confirmé l'arrêt des opérations à partir du 1er juillet 2026, citant un manque d'autorisation MiCA, des facteurs financiers et opérationnels plus larges, et l'échec d'un contrepartie stratégique à finaliser les arrangements. Les retraits sont ensuite passés en examen manuel, avec des incertitudes sur les délais et montants.
Le point de rupture d'AscendEX se situe entre les engagements de la plateforme et la sortie des actifs des utilisateurs. Le volume de transactions ne décrit que l'activité de matching ; la validité des licences, l'isolation des actifs, les retards de retrait, les expositions aux parties liées et la communication de crise déterminent l'accessibilité des actifs en période de tension. Ces quatre cas montrent ensemble que les smart contracts peuvent exécuter automatiquement des règles prédéfinies, mais l'identité, les actifs, les procédures légales et les utilisateurs restants nécessitent toujours une organisation qui en assume la responsabilité. Lorsque les revenus ne couvrent pas ces obligations fixes, l'adoption technologique ne suffit pas à soutenir un service à long terme.
V. Les projets choisissent souvent de partir en silence
La distribution des preuves pour les 110 échantillons est très déséquilibrée. Concernant le statut de sortie : seulement 7 projets sont directement confirmés par site web, documents de gouvernance ou documents légaux ; 24 sont corroborés par des sources fiables ou ont leur déclaration officielle bien conservée par les médias ; les 79 autres (71,8 %) manquent encore de matériaux suffisants pour confirmer leur modalité de sortie spécifique. La cause première est encore plus difficile à retracer : 4 projets sont directement expliqués par des documents officiels, de gouvernance ou légaux ; 8 sont soutenus par des sources fiables ; 1 ne peut être inféré qu'à partir d'une chaîne d'événements et de signaux opérationnels ; les 97 autres causes sont inconnues, soit un taux d'inconnu de 88,2 %. Ainsi, seuls 31 projets ont une modalité de sortie confirmée, et seulement 13 ont une cause première confirmée.
Parmi les 31 projets confirmés, 17 (54,8 %) se sont manifestés par la mise hors ligne du produit ou du réseau ; 7 (22,6 %) par un arrêt ordonné ; 4 (12,9 %) par une entrée en liquidation judiciaire ; 1 chacun par résolution de gouvernance, arrêt soudain et échec de vente. La mise hors ligne du produit/réseau est le point d'atterrissage public le plus fréquent, montrant que de nombreux départs se manifestent d'abord par l'arrêt du frontend, de l'API, du réseau ou de la maintenance de l'équipe, la raison officielle apparaissant souvent plus tard.
Les lacunes de preuves varient aussi par catégorie. Pour l'infrastructure et services aux développeurs (14 projets), 12 (85,7 %) manquent de matériaux pour confirmer le statut de sortie spécifique ; aucun n'a de cause première confirmée. Ce résultat décrit l'exhaustivité des divulgations publiques, et ne signifie pas que les projets d'infrastructure échouent plus facilement. Les équipes orientées backend, développeurs ou couche protocole ont souvent moins de visibilité utilisateur et peuvent disparaître plus discrètement après l'arrêt de la maintenance.
La chronologie montre aussi que le « départ » est une série d'événements : annonce, arrêt des nouvelles activités, mise hors ligne du service, retour des actifs et traitement légal peuvent être espacés de semaines, voire d'années. Les services principaux de Loopring et Zapper sont terminés ; Goldfinch est en maintenance et recouvrement ; Poolin est en procédure légale ; certains jalons de BitMEX et BitMart sont postérieurs à la date de rapport ; Ionic n'a pas de date attribuée de force. Pour les équipes de données, une table d'événements conservant temps, portée métier et statuts inconnus est plus adaptée à une mise à jour continue qu'une simple étiquette « fermé ».
VI. Traverser les cycles nécessite un système composé
Les 110 cas de départ montrent ensemble qu'un avantage technologique isolé soutient difficilement une valorisation à long terme. Les projets plus robustes connectent généralement six types de capacités : un besoin réel fournit le budget, la distribution réduit le coût d'acquisition, la pile de produits prolonge la relation utilisateur, les revenus couvrent les dépenses opérationnelles et de risque, le bilan absorbe la volatilité, une entité responsable gère les obligations hors-chaîne. Si une partie dépend longtemps de subventions, le système transmettra la pression aux autres parties.
Premier contrôle : la nécessité d'existence. Un projet doit clairement expliquer la tâche utilisateur, la fréquence d'utilisation, les alternatives et le bénéfice net apporté par l'architecture on-chain. Si la valeur du produit baisse significativement en retirant le jeton ou la couche de gouvernance, alors le composant Web3 remplit une fonction nécessaire. Le livre blanc, l'activité réelle et la tokenomie doivent se corroborer, évitant la séparation entre récit technique et sources de revenus.
Deuxième contrôle : besoin réel et distribution. La croissance des utilisateurs doit être décomposée en rétention naturelle, rétention subventionnée, conversion payante et coût d'acquisition ; les produits développeurs doivent suivre les clés actives, les appels payants, la concentration de la clientèle et le renouvellement ; les produits de trading doivent distinguer le volume passif dû aux conditions de marché de la part stable. La comparaison Zapper—DeBank/Rabby montre que des entrées à haute fréquence et de multiples points de revenus offrent plus d'options commerciales, tandis qu'un outil gratuit unique est plus facilement absorbé par les plateformes.
Troisième contrôle : le recyclage de la valeur. Le fait qu'un protocole génère du volume, du TVL ou des rendements ne garantit pas que l'entité opérationnelle reçoive un budget. Il faut cartographier le chemin des frais de l'utilisateur vers les market makers, déployeurs, trésorerie, jeton et équipe, puis vérifier les dépenses en sécurité, conformité, service client et développement. La comparaison BitMEX—Hyperliquid montre qu'après l'acceptation d'un produit par l'industrie, les incitations des distributeurs, la liquidité partagée et les règles de frais déterminent où la valeur s'arrête.
Quatrième contrôle : le bilan et la densité de responsabilité. Les activités RWA, plateformes de trading, custodie et levier nécessitent une analyse approfondie simultanée de l'entité légale, des garanties, de l'isolation des actifs, de l'ordre de liquidation, de la capacité de retrait et de la juridiction. La transparence on-chain doit être combinée avec le souscripteur, la gestion des garanties, les arrangements de liquidité et l'entité responsable pour entrer dans une évaluation des risques institutionnalisée.
Cinquième contrôle : l'atténuation de la maintenance. Établir un tableau de signaux hebdomadaires ou mensuels, plaçant sur la même chronologie le rythme des publications, les contributeurs de code, le taux de disponibilité de l'API, l'activité naturelle, les frais, les délais de retrait et les changements d'équipe. Lancer une vérification manuelle lorsque les signaux opérationnels se détériorent pendant deux périodes d'observation consécutives ; augmenter le poids du risque après trois périodes sans explication officielle. Ce cadre est plus précoce qu'attendre une mise à jour de base de données et plus facile à reproduire pour les équipes de données.
Sixième contrôle : la synergie réelle du « Web3+ ». L'intégration de l'IA, des RWA, du social et des jeux avec des systèmes on-chain doit apporter des capacités vérifiables d'attribution, de règlement programmable, de distribution ouverte ou de nouvelle tarification des risques. L'empilement de mots-clés ne crée pas de barrière. Le plus conforme doit être encore plus conforme, le plus innovant encore plus innovant. Les produits institutionnels ont besoin d'une isolation d'actifs, d'une divulgation et d'un contrôle des risques plus forts ; les produits à la pointe peuvent maintenir une vitesse expérimentale tout en clarifiant le budget sécurité, les permissions, la migration des données et les limites de responsabilité.
Ces six contrôles pointent vers un changement d'objet de valorisation. Lorsque le code, les SDK et l'infrastructure de liquidité rendent la réplication plus rapide, la prime du premier lanceur de fonctionnalité acquiert une durée de vie claire. Les investisseurs doivent continuer à questionner : quelle partie de la distribution le projet contrôle-t-il ? Quelles dépenses à long terme ses revenus couvrent-ils ? Comment le risque est-il absorbé par le bilan ? Qui assure la maintenance et le traitement si l'équipe part ? Lorsque besoin, distribution, revenus, maintenance et responsabilité forment une boucle fermée, l'avantage technique a une chance de se transformer en avantage organisationnel.
La rareté dans l'industrie migre aussi. Inventer une nouvelle fonctionnalité reste difficile, mais faire collaborer à long terme un ensemble de fonctionnalités déjà validées est plus rare encore. La sécurité, les actifs, la conformité et la responsabilité envers les utilisateurs ne peuvent pas être forkés aussi vite que le code ; elles nécessitent un budget stable, une prise de décision continue et une entité pouvant être tenue pour responsable. L'avantage concurrentiel des projets de la prochaine génération proviendra probablement de cette capacité organisationnelle peu visible mais très exigeante.
Il faut donc deux critères : l'un pour l'apport historique, l'autre pour le résultat d'investissement. Le premier mesure ce qu'un projet a validé et diffusé ; le second mesure combien de capacité de distribution, de revenus et de responsabilité il a conservé. BitMEX, Loopring, Zapper et Goldfinch ont inscrit les contrats perpétuels, le scaling ZK, l'agrégation d'actifs et le crédit on-chain dans l'histoire des produits de l'industrie ; mais leur fin opérationnelle rappelle au capital que la diffusion d'une innovation peut élargir la valeur sociale tout en raccourcissant le temps de valeur exclusive pour le projet d'origine.
Après l'effondrement des étoiles, ce qui reste, ce sont les paradigmes de produits hérités par l'industrie, les lacunes commerciales exposées, et un ensemble d'exigences systémiques plus strictes. Les projets vraiment rares de la prochaine génération seront ceux qui pourront faire revenir les utilisateurs continuellement, retenir la valeur dans le système, faire assumer les risques par les bonnes entités, et assurer un budget à long terme pour la maintenance. Ni l'avantage technique ni la capacité de financement ne peuvent remplacer une boucle commerciale fermée. Le meilleur héritage des pionniers est de permettre à leurs successeurs de voir plus tôt : pour qu'une innovation devienne infrastructure, il faut un système complet pour en assumer le succès.
