Fluid

• Name: Fluid
• URL: https://fluid.io/
• Tags: ethereum-ecosystem
• Category: unified liquidity layer / lending-DEX hybrid / vault-based borrowing infrastructure
• Summary: Fluid is best understood as a unified-liquidity control plane rather than as a single lending market or DEX. Its core contract, the Liquidity layer, holds funds for multiple protocols built on top of it, including ERC-4626 lending fTokens, collateralized vault borrowing, a DEX, and specialized unwind flows like stETH redemption. The reusable mechanism insight is that Fluid tries to internalize liquidity once and then let multiple products reuse that same balance sheet, while shifting practical authority into governance/auth permissions, append-only token listings, allow-listed deployers, and factory-level control over what gets built on top.
• What it does:
  • Centralizes funds in a core Liquidity layer that protocols interact with instead of having each product source liquidity independently
  • Offers ERC-4626 lending via fTokens, which act as the supply-side access point into the shared liquidity pool
  • Runs a vault protocol for collateralized borrowing, marketed around high LTVs, low liquidation penalties, and partial liquidations
  • Combines vaults with a DEX layer to enable smart collateral and smart debt, meaning collateral or debt positions can also participate in LP-fee generation
  • Provides specialized flows like stETH redemption to unwind leveraged stETH/ETH positions more cheaply through short-term-loan-assisted redemption
  • Uses dynamic borrow and withdrawal limits plus aggressive gas-optimization techniques like compact storage, BigMath, and packed config slots
• Key claims:
  • The technical docs say Liquidity is the central contract that holds all funds and only interacts with protocols built on top of it, not end users, which makes Fluid closer to a liquidity kernel than to a single consumer app
  • The contracts overview says Lending, Vault, DEX, and stETH redemption all sit on top of that same Liquidity layer, which is the clearest evidence that the protocol is trying to unify multiple DeFi products around one balance sheet
  • The vault whitepaper says the vault layer groups positions by debt-to-collateral ratio into ticks or slots inspired by Uniswap v3, enabling batch-like liquidations that only liquidate the minimum needed and are meant to support higher LTVs
  • The docs and whitepaper materials explicitly connect that liquidation design to claims of up to 95% LTV and liquidation penalties as low as 0.1%, which matters because Fluid’s distinctiveness is tied less to ordinary lending curves and more to liquidation-path design
  • The autogenerated liquidity docs show that governance can add/remove auths and guardians, governance is auth/guardian by default, and once tokens are configured in Liquidity they cannot be completely removed, which makes listing permanence and admin permissions real control surfaces
  • The vault factory auth docs show owner/auth-managed allow-listed deployers, global auths, vault-specific auths, authorized deployment logic, and an arbitrary-call spell function, which means the practical protocol edge sits partly in who is allowed to extend the shared liquidity core
  • The governance repository README says the governance stack is forked from Compound Governance, reinforcing that the protocol is not governance-minimized in the same way as immutable-market systems like Morpho Blue
• Whitepaper: The clearest primary mechanism paper is the official vault whitepaper, supplemented by the technical docs, autogenerated contract docs, and public repositories; see ../whitepapers/fluid-primary-sources-2026-05-09.md.
• Sources:
  • https://fluid.io/
  • https://docs.fluid.instadapp.io/
  • https://docs.fluid.instadapp.io/integrate/understanding-fluid-key-concepts-and-practices.html
  • https://docs.fluid.instadapp.io/autogenerated-docs/liquidity/common/variables.sol/abstract.Variables.html
  • https://docs.fluid.instadapp.io/autogenerated-docs/liquidity/adminModule/main.sol/abstract.FluidLiquidityAdminModule.html
  • https://docs.fluid.instadapp.io/autogenerated-docs/protocols/vault/factory/main.sol/abstract.VaultFactoryAuth.html
  • https://fluid.guides.instadapp.io/vault-protocol/protocol-details/vault-whitepaper.md
  • https://fluid.guides.instadapp.io/vault-protocol/protocol-details/vault-whitepaper.md?ask=What%20is%20the%20core%20liquidation%20mechanism%20and%20why%20does%20Fluid%20claim%20it%20can%20support%20higher%20LTVs%3F
  • https://raw.githubusercontent.com/Instadapp/fluid-contracts-public/main/README.md
  • https://raw.githubusercontent.com/Instadapp/fluid-contracts-public/main/docs/docs.md
  • https://raw.githubusercontent.com/Instadapp/fluid-governance/main/README.md
  • https://github.com/Instadapp/fluid-contracts-public
  • https://github.com/Instadapp/fluid-governance
  • https://gov.fluid.io/

Internal linkages

• Best shared-liquidity and modular-credit reads: euler and dolomite.
• Keep the note on one balance sheet reused across products, not on generic DeFi super app breadth.

Control surface

• Practical authority sits in token-listing permanence, auth and guardian powers, allowed deployers, factory-level extension rights, and the governance path that decides which products get to sit on top of the Liquidity layer.

• Read Fluid as shared-liquidity middleware with lending and DEX modules attached, not as a neutral pool.

• Last reviewed: 2026-06-12 UTC