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.