Fluid

Qu’est‑ce que Fluid ?

Fluid (anciennement Instadapp) est une couche de liquidité DeFi multi‑chaîne qui tente de regrouper, dans un seul et même pool partagé de collatéral et de dette, des activités traditionnellement cloisonnées comme l’emprunt/le prêt surcollatéralisé et les échanges au comptant, avec l’objectif explicite d’obtenir une efficacité du capital plus élevée que les conceptions à « pools séparés » comme les marchés monétaires et AMM autonomes.

Le facteur différenciant du protocole est architectural plutôt que cosmétique : dans le propre cadrage de Fluid, des fonctionnalités telles qu’une « couche de liquidité » partagée et des primitives souvent décrites comme « smart collateral » et « smart debt » sont censées permettre à une même base de capital de remplir plusieurs fonctions simultanément (par exemple, servir de collatéral d’emprunt tout en constituant de la liquidité de trading), ce qui constitue le principal avantage concurrentiel si le modèle se montre robuste en période de stress et d’anti‑sélection, et pas uniquement dans les backtests ou des régimes de marché favorables, comme décrit dans la présentation initiale du produit sur le blog Instadapp.

En termes de positionnement de marché, Fluid s’inscrit dans la catégorie « infrastructure DeFi » plutôt que dans celle de la « dApp mono‑produit » : il se bat pour attirer la liquidité et le flux face aux marchés monétaires et DEX, tout en héritant du positionnement historique d’Instadapp comme plateforme fortement intégrée à travers plusieurs chaînes.

Début 2026, des tableaux de bord tiers tels que la page Fluid de DeFiLlama présentaient Fluid comme un important protocole DeFi en termes de TVL et de volume DEX au comptant, avec des estimations publiées de frais et revenus de protocole, mais une lecture plus prudente consiste à le considérer comme un protocole de taille moyenne à grande, dont l’ampleur est significative mais encore inférieure à celle des acteurs DeFi « systémiquement dominants », et dont la trajectoire de croissance dépend de la question de savoir si la liquidité unifiée constitue un avantage durable ou bien une complexité supplémentaire que les utilisateurs ne tolèrent que lorsque les incitations sont élevées.

Qui a fondé Fluid et quand ?

Fluid est développé par l’équipe Instadapp ; Instadapp remonte elle‑même à 2018, généralement attribuée aux frères Samyak Jain et Sowmay Jain dans des documents synthétisés par des acteurs de recherche comme Messari et réitérés dans les documents de type réglementaire du projet (par exemple, un « livre blanc crypto‑actif » orienté MiCA hébergé sur instadapp.io).

Le contexte de lancement pertinent est qu’Instadapp a commencé comme « middleware » DeFi pendant la phase initiale d’adoption de la DeFi sur Ethereum, à une époque où la composabilité existait déjà mais où les outils orientés utilisateurs et la gestion de position étaient encore immatures ; Fluid, à l’inverse, se comprend mieux comme une tentative plus tardive d’internaliser les contraintes liées à la dépendance à des protocoles tiers en proposant une pile de liquidité et d’exécution plus verticalement intégrée.

Au fil du temps, la narration est passée de la « gestion de portefeuille et des smart accounts » vers la « conception de la liquidité au niveau du protocole ». Instadapp a présenté publiquement ce changement dans son annonce de Fluid, et des documents de gouvernance ont ensuite formalisé la consolidation de la marque : une proposition communautaire y décrit un rebranding et un plan de croissance dans lequel « Fluid » devient la bannière de l’orientation du protocole tout en conservant l’identité on‑chain du token, comme discuté dans le fil du forum de gouvernance sur gov.fluid.io.

Concrètement, l’enseignement principal est que l’identité du projet a évolué, passant d’un optimiseur au‑dessus de la DeFi à une tentative de devenir un lieu de base à travers lequel d’autres front‑ends, stratégies et intégrateurs peuvent router leurs flux.

Comment fonctionne le réseau Fluid ?

Fluid n’est pas une blockchain L1/L2 autonome et n’exécute pas son propre consensus ; il s’agit d’un protocole de couche applicative déployé sous forme de smart contracts sur des chaînes existantes (notamment Ethereum et plusieurs L2 majeures), qui hérite du modèle de sécurité du réseau sous‑jacent (par exemple, la finalité proof‑of‑stake d’Ethereum et les hypothèses de fraude/validité spécifiques aux L2 lorsque c’est pertinent).

D’un point de vue institutionnel, cela signifie que le « risque de protocole » est dominé par la solidité des smart contracts, la conception des oracles, la mécanique de liquidation et le risque de contagion entre modules plutôt que par la politique du set de validateurs ; les utilisateurs supportent à la fois le risque de la chaîne et le risque du contrat/système, et Fluid augmente intentionnellement ce dernier en composant le prêt et une exécution de type AMM au sein d’un même système.

Techniquement, l’argument distinctif de Fluid est que les contrôles de risque et la comptabilité de la liquidité sont conçus au « niveau partagé », le protocole suggérant que des schémas anormaux d’emprunts/retraits peuvent être contraints à la couche de liquidité et que des contrôles d’urgence peuvent isoler ou mettre en pause certains modules pour limiter les pertes, conformément à la logique de conception exposée dans Introducing Fluid.

Cette approche est attrayante dans son principe — les coupe‑circuits systémiques sont rares en DeFi — mais elle concentre aussi le risque de gouvernance et d’exploitation : si la sûreté repose sur des droits de pause privilégiés ou une gestion très contrôlée des paramètres, alors la « sécurité » devient en partie sociale et administrative plutôt que purement cryptoeconomique.

Côté audits, au moins certains composants de Fluid ont été examinés par des sociétés externes ; par exemple, un rapport d’audit publié figure dans la documentation du projet pour le protocole de vaults, réalisé par MixBytes, ce qui réduit (sans l’éliminer) la probabilité de bugs d’implémentation évitables, en particulier à mesure que le système évolue.

Quelle est la tokenomics d’Instadapp ?

Le token se négocie aujourd’hui sous le ticker FLUID et, d’après les communications de gouvernance autour du rebranding, le changement de nom de INST à FLUID a été structuré comme une transition 1:1 tout en conservant la même adresse de token et un cadre d’offre totale que la gouvernance décrit comme inchangé dans ses grandes lignes, comme indiqué dans la proposition de rebranding sur gov.fluid.io.

En d’autres termes, le profil d’offre se rapproche davantage d’un « plafond fixe avec distribution/déverrouillages » que d’un actif à émissions explicitement inflationnistes typique de l’ère du liquidity mining en DeFi. Pour les analystes, la variable clé n’est donc pas le « max supply terminal » mais le rythme et la destination des déverrouillages, la politique de trésorerie, et la question de savoir si les émissions (là où elles existent) sont productives (permettant d’amorcer une liquidité durable) ou simplement mercenaires (louer du TVL).

La captation de valeur est plus nuancée qu’un simple cadrage « token de frais ». La méthodologie et les métriques de DeFiLlama pour Fluid suivent explicitement les frais de protocole, les revenus du protocole, et une ligne appelée « holders revenue » liée aux programmes de rachat par la trésorerie, ce qui implique qu’une partie de la réflexion économique a porté sur le routage d’une partie de la valeur issue de l’activité du protocole vers des actions liées au token, même si le mécanisme exact dépend de la gouvernance et n’est pas garanti dans la durée.

Ce cadrage apparaît directement sur le tableau de bord Fluid de DeFiLlama, qui décrit le « Holders Revenue » comme une activité de rachat de tokens financée par la trésorerie, tandis que les fils de gouvernance comme la discussion sur les buybacks sur gov.fluid.io montrent que l’ampleur des rachats, leur cadence, et les arbitrages face aux incitations de croissance restent des sujets débattus.

En pratique, l’utilité actuelle de FLUID est la plus claire en matière de gouvernance (pouvoir de proposition et de vote), tandis que les dynamiques de type « flux de trésorerie » — si elles se concrétisent — dépendent d’une génération soutenue de frais, d’une liquidité non purement réflexive, et de la discipline de la gouvernance quant au déploiement de la trésorerie.

Qui utilise Fluid ?

Une lecture lucide de l’usage se décompose en deux réalités partiellement concurrentes : d’une part, il existe une activité on‑chain significative sous forme de demande d’emprunt et de volume DEX ; d’autre part, comme dans la plupart de la DeFi, une part non négligeable de cette activité peut être motivée par les incitations et dominée par des stratégies plutôt que par une « demande organique » d’utilisateurs finaux.

Des tableaux de bord comme DeFiLlama affichent les montants empruntés et le volume DEX aux côtés de la TVL, ce qui aide à distinguer le « collatéral simplement déposé » de l’utilisation effective, mais ils ne peuvent toujours pas séparer complètement la demande réelle des utilisateurs des boucles automatisées, des arbitrages de basis et des comportements liés au liquidity mining.

Par secteur, Fluid est clairement une infrastructure DeFi — activité de marché monétaire, stratégies à effet de levier et exécution au comptant — plutôt qu’une solution de gaming ou de paiements grand public ; toute lecture institutionnelle doit partir du principe que les flux de « power users » et d’acteurs quant/adjacents au MEV sont structurellement importants pour ses volumes.

En matière de partenariats crédibles, l’exemple le plus net dans la recherche publique est le récit d’intégration côté Solana, où la technologie de Fluid a été présentée comme une infrastructure pour un produit de prêt ; Messari, par exemple, mentionne une annonce de partenariat entre Fluid et Jupiter pour soutenir une initiative de prêt sur Solana, décrite dans son rapport Understanding Fluid.

Ce type de partenariat est plus significatif que les listings d’exchange ou les collaborations marketing, car il représente un protocole externe confiant des mécanismes centraux de bilan à la conception de Fluid, mais il doit malgré tout être lu comme un « risque d’intégration » : les partenariats peuvent être révoqués, les volumes peuvent migrer, et la contagion réputationnelle est bidirectionnelle en cas d’incident.

Quels sont les risques et défis pour Fluid ?

Le risque réglementaire tient moins à la classification au niveau de la chaîne (ce n’est pas un réseau de base) qu’à la caractérisation du token, au degré de centralisation de la gouvernance et aux points de contact front‑end/opérationnels. Dans le contexte de l’UE, l’existence d’un document de divulgation de type MiCA hébergé par le projet sur instadapp.io suggère une prise en compte du régime de divulgation applicable aux crypto‑actifs, mais cela ne tranche pas la manière dont tel ou tel régulateur traitera le token dans le cadre d’actions coercitives ou de contentieux, en particulier si les attentes des détenteurs de tokens commencent à se focaliser sur les buybacks ou sur une captation de valeur liée aux frais.

Dans le contexte américain, début 2026, aucune action d’application de la loi largement citée et spécifique au protocole n’est publiquement associée à Fluid dans les sources grand public, mais le schéma plus large de la DeFi demeure : des tokens de gouvernance qui dérivent d’outils de coordination vers Les « droits économiques par anticipation » ont tendance à accumuler le risque, et les propres discussions de gouvernance de Fluid autour des rachats, documentées publiquement sur gov.fluid.io, constituent exactement le type de surface que les équipes de conformité sophistiquées surveillent.

Les vecteurs de centralisation sont également loin d’être négligeables. Le cadre de sûreté de Fluid inclut une capacité d’intervention d’urgence et une mise en pause au niveau des modules, conformément à la présentation du protocole sur le blog Instadapp ; bien que l’on puisse considérer cela comme prudent, cela implique des rôles privilégiés, un contrôle par multisig et des surfaces d’attaque liées à la gouvernance (concentration des délégués, capture du pouvoir de vote et conception des seuils de proposition).

À cela s’ajoute la centralisation technique courante dans la DeFi : dépendance à des piles d’oracles spécifiques, comités de paramètres de risque, et réalité opérationnelle selon laquelle la plupart des utilisateurs accèdent au protocole via un petit nombre de front-ends et de fournisseurs RPC.

Quelle est la perspective d’avenir pour Fluid ?

Les perspectives à court terme se formulent mieux comme une question d’exécution par rapport à une feuille de route crédible plutôt que comme une question de bêta de marché. Les documents de gouvernance indiquent clairement que l’ère post-rebranding vise à aligner l’expansion produit avec la tokenomique et la restructuration de la gouvernance, conformément au plan de rebranding sur gov.fluid.io, tandis que les débats de gouvernance en cours montrent que les rachats financés par la trésorerie et la conception de la capture de valeur restent des sujets ouverts plutôt que des engagements arrêtés, comme on le voit dans le fil de discussion sur les rachats.

Sur le plan produit, les analyses de protocoles tierces suggèrent que Fluid fonctionne déjà à l’échelle sur plusieurs chaînes, et les prochains jalons pertinents pour les institutions porteront probablement sur le renforcement des contrôles de risque (performance des liquidations en période de volatilité), le maintien d’une liquidité non incitative et l’extension des intégrations sans créer de dépendances opérationnelles inter-chaînes fragiles, avec des métriques de base de taille et de performance financière régulièrement suivies par des plateformes comme DeFiLlama.