Fluid

Was ist Fluid?

Fluid (ehemals Instadapp) ist eine kettenübergreifende DeFi-Liquiditätsschicht, die versucht, traditionell voneinander getrennte Aktivitäten – überbesicherte Kreditvergabe/-aufnahme und Spot-Swaps – in einem einzigen gemeinsamen Pool aus Sicherheiten und Schulden zu vereinen, mit dem ausdrücklichen Ziel, eine höhere Kapitaleffizienz zu erreichen als „Separate-Pool“-Designs wie eigenständige Geldmärkte und AMMs.

Das Unterscheidungsmerkmal des Protokolls ist eher architektonischer als kosmetischer Natur: In Fluids eigener Darstellung sollen Features wie eine gemeinsame „Liquidity Layer“ und Primitive, die oft als „Smart Collateral“ und „Smart Debt“ beschrieben werden, es ermöglichen, dass dieselbe Kapitalbasis mehr als eine Aufgabe gleichzeitig erfüllt (z. B. Kreditvergabe unterstützen und gleichzeitig als Handelsliquidität dienen). Dies ist der eigentliche Burggraben, sofern er sich unter Stress und bei adverser Selektion als robust erweist – und nicht nur in Backtests oder günstigen Marktphasen –, wie in der ursprünglichen Produkteinführung im Instadapp‑Blog beschrieben.

In Bezug auf die Marktpositionierung ist Fluid eher in der Kategorie „DeFi‑Infrastruktur“ als im Segment „Single‑Product‑dApp“ einzuordnen: Es konkurriert um Liquidität und Volumen mit Geldmärkten und DEXs, erbt aber zugleich Instadapps historische Positionierung als integrationsstarke Plattform über mehrere Chains hinweg.

Anfang 2026 stellten Drittanbieter‑Dashboards wie DeFiLlamas Fluid‑Seite Fluid als großen DeFi‑Marktplatz nach TVL und Spot‑DEX‑Volumen mit ausgewiesenen Protokollgebühren und Umsatzzahlen dar. Die defensivere Interpretation ist jedoch, dass es sich um ein mittelgroßes bis großes Protokoll handelt, dessen Umfang zwar signifikant, aber noch kleiner ist als der der „systemisch dominanten“ DeFi‑Platzhirsche – und dessen Wachstumserzählung davon abhängt, ob vereinheitlichte Liquidität einen dauerhaften Vorteil bietet oder lediglich eine Komplexitätsprämie darstellt, die Nutzer nur dann akzeptieren, wenn die Anreize hoch sind.

Wer hat Fluid gegründet – und wann?

Fluid wird vom Instadapp‑Team entwickelt; Instadapp selbst geht auf das Jahr 2018 zurück und wird üblicherweise den Brüdern Samyak Jain und Sowmay Jain zugeschrieben, wie es in Zusammenfassungen von Research‑Anbietern wie Messari sowie in den eigenen, an Regulierungsdokumente angelehnten Offenlegungen des Projekts dargestellt wird (beispielsweise in einem an MiCA orientierten „Crypto‑Asset‑Whitepaper“, das unter instadapp.io gehostet wird).

Der relevante Startkontext ist, dass Instadapp in der frühen Phase der Ethereum‑DeFi‑Adoption als DeFi‑„Middleware“ begann – zu einer Zeit, als es zwar bereits Komponierbarkeit gab, benutzerorientierte Tools und Positionsverwaltung aber noch unausgereift waren. Fluid hingegen ist besser als spätere Zyklen‑Initiative zu verstehen, die versucht, die Zwänge der Abhängigkeit von Drittprotokollen zu internalisieren, indem eine stärker vertikal integrierte Liquiditäts‑ und Ausführungs‑Schicht bereitgestellt wird.

Im Laufe der Zeit verlagerte sich die Erzählung von „Portfoliomanagement und Smart Accounts“ hin zu „Protokoll‑Level‑Liquiditätsdesign“. Instadapp stellte diese Verschiebung öffentlich in der Ankündigung von Fluid heraus, und Governance‑Unterlagen formalisierten später die Markenbündelung: Ein Community‑Vorschlag beschrieb ein Rebranding und einen Wachstumsplan, bei dem „Fluid“ zum Dach für die Protokollausrichtung wird, während die On‑Chain‑Identität des Tokens erhalten bleibt, wie im Thread im Governance‑Forum auf gov.fluid.io diskutiert.

Die praktische Quintessenz ist, dass sich die Identität des Projekts von einem Optimierer „on top of DeFi“ hin zu einem Basis‑Venue entwickelt hat, durch das andere Frontends, Strategien und Integratoren ihre Flows leiten können.

Wie funktioniert das Fluid‑Netzwerk?

Fluid ist keine eigenständige L1‑ oder L2‑Blockchain und betreibt keinen eigenen Konsensmechanismus; es ist ein Protokoll auf Anwendungsebene, das als Smart Contracts auf bestehenden Chains (insbesondere Ethereum und größeren L2s) bereitgestellt wird und damit das Sicherheitsmodell der zugrunde liegenden Netzwerke erbt (z. B. Ethereums Proof‑of‑Stake‑Finalität sowie L2‑spezifische Fraud‑/Validity‑Annahmen, soweit relevant).

Institutionell ist dies wichtig, weil das „Protokollrisiko“ primär von der Korrektheit der Smart Contracts, vom Oracledesign, von Liquidationsmechanismen und von Ansteckungseffekten zwischen Modulen bestimmt wird – weniger von der Politik des Validator‑Sets. Nutzer übernehmen sowohl Chain‑Risiko als auch Kontrakt‑/Systemrisiko; Letzteres erhöht Fluid bewusst, indem Kreditvergabe und AMM‑ähnliche Ausführung in einem System zusammengeführt werden.

Technisch beansprucht Fluid, dass Risikokontrollen und Liquiditätsbuchhaltung auf der „Shared Layer“ designt sind. Das Protokoll argumentiert, dass anomale Kreditaufnahme‑/Abhebemuster auf dieser Liquiditätsschicht begrenzt werden können und dass Notfallkontrollen Module isolieren oder pausieren können, um Verluste zu begrenzen – so die Designrationalen in Introducing Fluid.

Das ist in der Tendenz attraktiv – systemische „Circuit Breaker“ sind in DeFi selten –, konzentriert aber Governance‑ und Betriebsrisiken: Wenn Sicherheit von privilegierten Pausenrechten oder stark kontrolliertem Parametermanagement abhängt, wird „Security“ teilweise zu einer sozialen und administrativen, nicht nur zu einer rein kryptoökonomischen Eigenschaft.

Hinsichtlich Audits wurden zumindest einige Fluid‑Komponenten von externen Firmen geprüft; so existiert etwa in der Projektdokumentation ein veröffentlichtes Audit‑Report für das Vault‑Protokoll von MixBytes. Das senkt (aber eliminiert nicht) die Wahrscheinlichkeit vermeidbarer Implementierungsfehler, insbesondere während sich das System weiterentwickelt.

Wie sehen die Tokenomics von Instadapp/Fluid aus?

Der Token wird heute unter dem Ticker FLUID gehandelt. Laut Governance‑Mitteilungen zum Rebranding wurde die Umbenennung von INST zu FLUID als 1:1‑Transition strukturiert, wobei dieselbe Token‑Adresse und ein von der Governance als „unverändert“ beschriebenes Gesamtangebots‑Framework beibehalten wurden, wie im Rebranding‑Vorschlag auf gov.fluid.io dargestellt.

Mit anderen Worten: Das Angebotsprofil ähnelt eher einer „Fixed‑Cap‑Struktur mit Verteilung/Unlocks“ als einem aktiv inflationären Emissionsasset nach dem Vorbild der Liquidity‑Mining‑Ära im DeFi. Für Analysten ist daher nicht die „endgültige Maximalversorgung“ die zentrale Variable, sondern die Geschwindigkeit und Zielrichtung von Unlocks, die Treasury‑Politik und die Frage, ob Emissionen (wo sie existieren) produktiv sind (also dauerhafte Liquidität aufbauen) oder lediglich merkantil (TVL temporär „anmieten“).

Die Wertakkumulation ist nuancierter als das vereinfachte Narrativ eines reinen „Fee Tokens“. Die Methodik und Metriken von DeFiLlama für Fluid erfassen explizit Protokollgebühren, Protokollumsatz und eine Kennzahl „Holders Revenue“, die mit Treasury‑Buybacks verknüpft ist. Das impliziert, dass ein Teil der ökonomischen Design‑Diskussion darum kreist, Wert von der Protokollaktivität zurück in tokenbezogene Maßnahmen zu leiten – auch wenn der genaue Mechanismus Governance‑abhängig ist und nicht dauerhaft garantiert werden kann.

Dieser Rahmen ist direkt auf DeFiLlamas Fluid‑Dashboard sichtbar, wo „Holders Revenue“ als Token‑Rückkäufe beschrieben wird, die aus der Treasury finanziert werden. Governance‑Threads wie die Buyback‑Diskussion auf gov.fluid.io zeigen, dass Umfang und Taktung der Rückkäufe sowie die Abwägung gegenüber Wachstumsanreizen umstritten bleiben.

Praktisch ist der derzeit klarste Nutzen von FLUID im Bereich Governance (Antrags‑ und Stimmrecht) zu sehen, während „Cashflow‑ähnliche“ Dynamiken – falls sie sich herausbilden – von nachhaltiger Gebührenproduktion, nicht‑reflexiver Liquidität und Disziplin der Governance bei der Treasury‑Allokation abhängen.

Wer nutzt Fluid?

Eine nüchterne Betrachtung der Nutzung teilt sich in zwei teilweise konkurrierende Realitäten: Erstens existiert signifikante On‑Chain‑Aktivität in Form von Kreditnachfrage und DEX‑Volumen; zweitens ist – wie bei den meisten DeFi‑Protokollen – ein nicht triviales Aktivitätsvolumen eher an Anreizprogramme und Strategien gebunden als an eine rein „organische“ Endnutzer‑Nachfrage.

Dashboards wie DeFiLlama zeigen Kreditvolumen und DEX‑Umsatz neben TVL an, was hilft, „geparkte Sicherheiten“ von tatsächlicher Nutzung zu unterscheiden. Sie können jedoch nach wie vor nicht vollständig zwischen echter Endnutzer‑Nachfrage und automatisiertem Looping, Basis‑Trades und Liquidity‑Mining‑Verhalten trennen.

Sektorseitig ist Fluid klar als DeFi‑Infrastruktur einzuordnen – Geldmarktaktivität, gehebelte Strategien und Spot‑Ausführung – und nicht als Gaming‑ oder Consumer‑Payment‑Anwendung. Jede institutionelle Analyse sollte davon ausgehen, dass „Power‑User“‑ und „Quant/MEV‑nahe“ Flows strukturell wichtige Treiber der Volumina sind.

Bei glaubwürdigen Partnerschaften ist das sauberste Beispiel in öffentlichen Research‑Quellen die Solana‑Integration, bei der Fluids Technologie als Infrastruktur für ein Kreditprodukt positioniert wurde. Messari verweist etwa auf eine Partnerschaftsankündigung zwischen Fluid und Jupiter zur Unterstützung einer Lending‑Initiative auf Solana, wie in dem Bericht „Understanding Fluid“ beschrieben.

Diese Art von Partnerschaft ist bedeutsamer als Börsenlistings oder Marketing‑Kooperationen, da hier ein externes Protokoll zentrale Bilanzmechaniken auf das Design von Fluid überträgt. Sie sollte aber dennoch als „Integrationsrisiko“ gerahmt werden: Partnerschaften können widerrufen werden, Volumen können migrieren, und Reputationsrisiken wirken im Falle von Zwischenfällen in beide Richtungen.

Welche Risiken und Herausforderungen gibt es für Fluid?

Das Regulierungsrisiko betrifft weniger die Einstufung auf Chain‑Ebene (Fluid ist kein Base‑Layer‑Netzwerk), sondern vielmehr die Charakterisierung des Tokens, den Zentralisierungsgrad der Governance sowie Frontend‑ und operative Touchpoints. Im EU‑Kontext deutet das Vorhandensein eines MiCA‑ähnlichen Offenlegungsdokuments, das das Projekt unter instadapp.io bereitstellt, auf ein Bewusstsein für das Offenlegungsregime für Krypto‑Assets hin. Das löst jedoch nicht die Frage, wie einzelne Aufsichtsbehörden den Token in Enforcement‑ oder Klagekontexten behandeln werden – insbesondere dann, wenn sich die Erwartungen der Tokenholder zunehmend auf Buybacks oder gebührenverknüpfte Wertabschöpfung konzentrieren.

Im US‑Kontext gibt es Anfang 2026 in Mainstream‑Quellen keine breit zitierte, protokollspezifische Enforcement‑Maßnahme, die öffentlich mit Fluid in Verbindung gebracht wird. Das übergeordnete DeFi‑Muster bleibt jedoch bestehen: Governance‑Tokens, die sich schrittweise von reinen Koordinationstools hin zu wirtschaftlich aufgeladenen Assets mit potenziell wertpapierähnlichen Merkmalen entwickeln, geraten verstärkt in den Fokus von Aufsichtsbehörden – zumal dann, wenn Narrative rund um Ertragsbeteiligung, Rückkäufe oder „Revenue Sharing“ auftreten. „wirtschaftliche Rechte durch Erwartung“ neigen dazu, Risiken zu akkumulieren, und Fluids eigene Governance-Diskussionen rund um Rückkäufe, die öffentlich auf gov.fluid.io dokumentiert sind, sind genau die Art von Angriffsfläche, die ausgefeilte Compliance-Teams überwachen.

Auch die Zentralisierungsvektoren sind nicht trivial. Fluids Sicherheitsrahmen umfasst laut der Protokollvorstellung im Instadapp blog die Möglichkeit zu Notfallmaßnahmen und modulweiser Pausierung; so sinnvoll dies auch sein mag, impliziert es privilegierte Rollen, Multisig-Kontrolle und Governance-Angriffsflächen (Delegierten-Konzentration, Erfassung von Stimmrechten und Ausgestaltung von Vorschlagsschwellen).

Hinzu kommt die für DeFi typische technische Zentralisierung: Abhängigkeit von bestimmten Oracle-Stacks, Risiko-Parameter-Komitees und die operative Realität, dass der größte Teil des Nutzerzugangs über eine kleine Zahl von Frontends und RPC-Providern erfolgt.

Wie sieht der zukünftige Ausblick für Fluid aus?

Die kurzfristige Perspektive lässt sich am besten als Frage der Umsetzung gegenüber einer glaubwürdigen Roadmap beschreiben und weniger als Frage des Markt-Betas. Governance-Unterlagen machen deutlich, dass die Ära nach dem Rebranding darauf abzielt, die Produkterweiterung mit Tokenomics und einer Neustrukturierung der Governance in Einklang zu bringen, wie im Rebranding-Plan auf gov.fluid.io dargestellt, während die anhaltende Governance-Debatte darauf hinweist, dass treasury-finanzierte Rückkäufe und Wertabschöpfungs-Design weiterhin aktuelle Themen und keine feststehenden Zusagen sind, wie im Buyback-Diskussionsthread zu sehen ist.

Auf der Produktseite deuten Analysen Dritter von Protokollen darauf hin, dass Fluid bereits im großen Maßstab auf mehreren Chains operiert, und alle nächsten Meilensteine, die institutionell relevant sind, dürften sich wahrscheinlich um die Härtung der Risikokontrollen drehen (Liquidationsleistung unter Volatilität), die Aufrechterhaltung nicht-inzentivierter Liquidität und den Ausbau von Integrationen, ohne brüchige, kettenübergreifende operative Abhängigkeiten zu schaffen, wobei grundlegende Skalierungs- und Finanzkennzahlen regelmäßig von Plattformen wie DeFiLlama verfolgt werden.