Demystifying Fluid, Part I: Liquidity Layer and Liquidations

Disclaimer: cyber•Fund is investor in FLUID.

Acknowledgements: Special thanks go to DMH and to MixBytes for their invaluable feedback.

Introduction

Since its launch in March 2024, Fluid Protocol has rapidly become a major force in DeFi, combining lending and DEX functionalities into a single capital-efficient platform. Capturing approximately 20 % of Ethereum’s DEX market share, it now ranks as the network's second-largest DEX by trading volume.

Fluid's standout feature is it’s unique dual-purpose architecture. By allowing users to simultaneously utilize their assets as liquidity for both lending/borrowing and trading, Fluid maximizes the productivity of deposited funds. This dual functionality enables users to earn interest while also benefiting from trading fees, all within a unified platform.

An important component of Fluid is its advanced liquidation mechanism. Unlike traditional protocols that liquidate positions individually, Fluid's Vault groups positions into "ticks," enabling batch liquidations. This approach significantly reduces gas costs and minimizes the impact on asset prices during liquidations. As a result, Fluid can offer higher loan-to-value (LTV) ratios with lower liquidation penalties.

This series of articles provides an in-depth exploration of Fluid Protocol's mechanics. We will start by covering the technical foundations: the first article will focus on Fluid’s Liquidity Layer and Vault subprotocol. In the future second article, we’ll dive into Fluid’s DEX architecture and a high-level overview, illustrating how Fluid Protocol seamlessly integrates its lending and DEX functionalities to achieve unprecedented capital efficiency. By the end, you'll clearly understand why Fluid Protocol is not just another DeFi contender, but potentially the industry's next truly major DeFi protocol.

1. The high-level Fluid architecture

Before we dive into Fluid, let’s briefly understand how it operates on a high level.

Fluid’s main component is called Liquidity Layer, a contract where all assets (liquidity) are being stored. Subprotocols are protocols with their own logic which don’t store assets by themselves, but instead direct assets from and to Liquidity Layer. We will go briefly over main subprotocols below.

☝️ We will call all protocols built on top of Liquidity Layer as “subprotocols”.

The Liquidity Layer provides a shared pool of liquidity for multiple higher-level whitelisted subprotocols built on top of it, which include:

• Lending subprotocol: Fluid’s Lending subprotocol is a pure “supply‑and‑earn” layer: deposit any supported token and receive “fTokens”—ERC‑4626 vault shares—whose exchange rate rises as interest accrues.

  There is no “borrow” functionality in the Lending subprotocol. Instead, Vaults borrow from the liquidity supplied to Lending subprotocol.

• XXX/YYY Vault (e.g., ETH / USDC): Vault is a single‑asset‑in, single‑debt‑out position (Morpho‑style) that borrows directly from the Liquidity Layer, namely assets that come from Lending, Smart Lending, as well as other Vaults subprotocols (unlike in Morpho, where rehypothetication doesn’t happen).

• DEX v1: Fluid's first‑generation DEX is an AMM built on top of the Liquidity Layer that combines Uniswap V2-like simplicity with Uniswap V3-like concentration, where liquidity is concentrated into a particular predefined range and auto‑rebalances over time according to specific rules.

  DEX v1 taps into the liquidity of assets deposited via smart collateral/debt/lend. That’s why users who provide smart collateral or lend earn additional trading fees, while those who take on smart debt benefit from reduced borrow APY.

Smart Lending/Debt/Collateral: Fluid's subprotocol users can not only lend, supply, or borrow regular assets, but also a pair of them (e.g. USDC-USDT). Keeping the same properties as other assets, they also will be used to provide liquidity into the DEX subprotocol, which means the proportion of the assets can be changed during rebalances. This makes assets more capital efficient.

Smart lending and smart collateral earn additional fees.

Smart debt makes the borrow APR lower (and even negative in some cases).

Remark: Besides major subprotocols like DEXs and Vaults, Fluid also supports smaller "mini" subprotocols that serve specific functions. For example, there could be a flashloan mini subprotocol. More mini subprotocols will be introduced over time to expand the ecosystem's capabilities.

Subprotocols interoperate through Liquidity Layer: for instance, assets supplied via the Lending subprotocol can be borrowed by Vaults subprotocols, while assets supplied via Smart Lending can be both borrowed by Vaults and also used as liquidity for the DEX subprotocol.

End-users supply or borrow assets via subprotocols, and never interact with Liquidity Layer. Subprotocols, in turn, interact with the central Liquidity Layer to actually custody funds and track interest, via low-level actions (deposits, withdrawals, loans, repayments). Each subprotocol module manages its own risk parameters and user-facing logic.

By serving as the single source of liquidity, the Liquidity Layer ensures that when users migrate between Fluid subprotocols, the underlying capital stays put and interest rates remain stable — lenders don’t need to “move” their funds, and borrowers in new subprotocols can borrow from the same pool. This setup bootstraps new subprotocols with instant liquidity and unified accounting – new Fluid subprotocols don’t need to attract fresh capital; they plug into what’s already there.

2. Liquidity Layer

Before we dive into the Liquidity Layer — the core of the Fluid protocol — please note that the next sections assume you're familiar with basic smart contract and DeFi concepts.

2.1 Actions within the Liquidity Layer

The operate() Function: At the heart of the Liquidity Layer’s contract code is the operate() function, which serves as the single, unified interface for combining any of “deposit”, “withdraw”, “borrow”, and “repay” actions. It is implemented via the operate() function arguments: they include, among other things, a target token and two signed integer parameters: a supplyAmount and a borrowAmount. The Liquidity Layer then understands user’s intention as follows:

1. supplyAmount > 0 ⇒ user wants to deposit

2. supplyAmount < 0 ⇒ user wants to withdraw

3. borrowAmount > 0 ⇒ user wants to borrow

4. borrowAmount < 0 ⇒ user wants to repay

Note that both supplyAmount and a borrowAmount can be non-zero, resulting in a combined action.

Remarks on the four core actions (deposit, withdraw, borrow, repay):

• Remark 1. Every deposit/withdraw/borrow/repay call into the Liquidity Layer must come from a whitelisted intermediary subprotocol contract. Governance explicitly whitelists each contract address to give it access to the Liquidity Layer functions. Similarly, all asset transfers also always happen through the intermediary subprotocols.

  The upshot is that Liquidity Layer acts as a permissioned liquidity pool for the Fluid ecosystem.

• Remark 2. Accounting of users’ shares in Liquidity Layer is not done according to how much user deposits today (X), but rather according to how much users would have deposited into Liqudity Layer on day one (Y) in order to have X today; this quantity Y is commonly referred to as “raw” balance. More on it later.

• Remark 3. Deposits can be set to as either interest‐bearing or interest‐free, based on the whitelisted subprotocol configuration; in most cases, it is interest‐bearing.

• Remark 4. For withdrawals, a withdrawal limit is usually in place (described later) to enhance protocol security during black swan events and maintain predictable utilization rates. These limits protect against protocol draining by controlling potential damage — each protocol and vault has its own thresholds that prevent large instantaneous outflows. Over time, limits are increased for protocols and vaults that have been live for extended periods, as they are considered battle-tested with lower risk profiles.

• Remark 5. When users borrow, the Liquidity Layer itself doesn’t perform any collateral checks or liquidations — those are handled entirely by the higher-level subprotocol (Vault, etc.), which is why there are no liquidation mechanics inside the Liquidity Layer code.

2.2 Roles and Permissions: Governance, Auth, Guardians

Fluid employs a layered security model with clearly defined roles:

Governance (FLUID(prev. INST) Token Holders): The ultimate authority over Fluid is its governance, powered by the FLUID token. Governance can list new assets and subprotocols on the Liquidity Layer, adjust parameters (interest rate model, limits, etc.), upgrade modules and collect revenue.

Auths: In Fluid, Auths are authorized addresses that handle routine administrative tasks within the Liquidity Layer. They can configure interest rate parameters, collect subprotocol revenue, and adjust user settings—ensuring the system can quickly respond to market shifts without requiring a full governance vote. Importantly, Auths cannot alter governance structure, seize user deposits, or bypass system constraints. Their privileges are granted or revoked solely by governance, and strict limits (e.g., maximum utilization) prevent misuse. This setup enables efficient day-to-day management while safeguarding the subprotocol’s core security and user funds.

Guardians: Fluid has a Guardian role – a security backstop – that can pause subprotocol access to the Liquidity Layer in emergencies. A guardian (initially a trusted multisig controlled by the team) can quickly disable a given subprotocol’s ability to borrow or withdraw from the pool, without affecting others. At launch, all subprotocols are classified as Class 0, meaning they can be paused by the guardian if something goes wrong. Over time, once subprotocols are battle-tested, governance can upgrade them to Class 1, which means the guardian can no longer pause them (full trust, only removable by governance). Importantly, a guardian cannot ever move funds or change balances.

2.3 Key Asset Variables: Exchange Prices, Interest Model, and Limits

Each asset listed in Liquidity Layer maintains a set of core state variables that track its interest and usage. Key among these are the exchange prices (for supply and borrow), interest rates, current utilization, and dynamic limits (withdrawal and debt ceilings).

Interest Rate Model & Utilization

Fluid works out the borrow rate for each asset (say XYZ) by looking at its utilization ratio — the share of supplied XYZ tokens that are already borrowed. If that ratio is low, the rate stays in the lower range and grows slowly with utilization. But once utilization hits a preset threshold, the curve steepens forming a kink and the rate climbs faster. Governance may choose a one‑kink curve like Compound and Aave use, or a two‑kink curve that adds another sharp rise for very high utilization. For example, a stablecoin might stay cheap until 85% usage, raise a little faster between 85% and 94% utilization, and could jump steeply after 93% to protect the pool. These curves automatically balance supply and demand, keeping liquidity safe and rewarding suppliers when tokens become scarce.

Supply & Borrow Exchange Prices. Fluid keeps two “exchange prices” for each asset—one for suppliers (supplyExchangePrice) and one for borrowers (borrowExchangePrice)—similar to the interest indexes in Compound and Aave. When you deposit N tokens, the system logs the corresponding amount of raw units, which is N ÷ “supplyExchangePrice”. Variable ”supplyExchangePrice” starts as 1 when protocol launches, and rises as interest accrues with time; so multiplying this variable by user's raw units gives the real amount they can withdraw. Borrowers are tracked the same way: debt sits in raw units, and as ”borrowExchangePrice” climbs with every interest update, each unit comes to represent more tokens owed. In short, the two moving exchange prices grow over time—upward for suppliers to reflect earned yield and upward for borrowers to capture the extra interest they must repay.

Interest Accrual Mechanism (Exchange Price Updates).

Fluid adds interest only when someone interacts with an asset: every operate() call triggers an update of exchange prices for that token. During the call, the contract checks how long it has been since the last update, looks at today’s utilization and its rate curve, and then adjusts supplyExchangePrice and borrowExchangePrice to include the new interest. (Remark: If the time passed is small or the change in utilization is tiny, Fluid skips a full recalculation and applies a quick proportional tweak to save gas.)

This “on‑demand” approach is similar to the one used in Compound’s ”accrue interest” and Aave’s “index updates”, where nothing accrues until the next action, keeping idle assets cheap to hold. As a result, one simple update brings every supplier and borrower up to date in one step, balancing accuracy with gas efficiency.

Withdrawal Limits. Fluid introduces a unique mechanism called Automated Withdrawal Limits to protect protocol security by preventing instantaneous large-scale liquidity drains (i.e., during black swan events). For each subprotocol, baseWithdrawalLimit is set per asset — e.g. for USDC it might be some fixed amount in the USDC pool. If supply of a subprotocol is less than baseWithdrawalLimit, withdrawalLimit is not active and subprotocol can withdraw whole supply. If it’s more, withdrawal limits are activated.

Besides baseWithdrawalLimit, limits have 2 main variables: expandPercentage and expandDuration. expandPercentage shows which fraction of total supply can be withdrawn and expandDuration represent in which time this amount will be unlocked. For example, if supply is 5000 and expandPercentage is 0.1 and expandDuration is 1h, it means in one hour 500 will be unlocked and available to withdraw. Important note, that in Fluid withdrawal limit in this case will be equal to 4500, not 500. Withdrawal Limit represent how much of supply must stay in the liquidity layer after withdrawn.

The parameters for expansion (expandDuration and expandPercentage) can be adjusted via governance. Withdrawal limit is being calculated before any withdraw operation, to check if it’s possible to withdraw the wanted amount.

How the parameter L changes with time and with withdrawals:

1. With time only withdrawal limit L changes: L falls until (1-α)S₀, with speed αS₀÷τ

2. After each withdrawal S₀ ~> S₁: max unlock changes αS₀ ~> αS₁ if S₁<B, then L=0, i.e. withdrawal limit restriction is canceled

Withdrawal Limit Example. Below, you can find an example of how withdrawal limits change over time and after withdrawals.

Debt Limits. Similarly, the Liquidity Layer employs borrowing limits for each asset subprotocol can borrow to control how fast the total debt can grow. It has the same variables as in withdrawal limits: baseBorrowLimit, expandPercentage, expandDuration, and one additional maxDebtLimit - hard limit for borrow

The calculation for debt limits looks almost the same, expect that we also check the debt limits not to increase the maxDebtLimit and instead of max function, min is being used.

How the parameter L changes with time and with borrows:

1. With time only borrow limit L changes: L raise until min((1+α)D₀, M), with speed αD₀÷τ

2. After each borrow D₀ ~> D₁: max unlock changes αD₀ ~> αD₁ if D₁<B, then L=B, i.e. minimal borrow limit

Debt Limit Example. Below, you can find an example of how debt limits change over time and after borrows.

3. Vault

After understanding the basics of Fluid and Liquidity Layer, we’re ready to go deeper and explore how the Vault subprotocol of Fluid works. More specifically, we’ll explain how liquidations work in the Vault subprotocol and why they are so special.

3.1 What is Vault?

Fluid’s Vault is a lending/borrowing subprotocol built on top of Liquidity Layer. For each vault, users supply one asset as collateral and borrow another asset against it (an isolated single-collateral single-debt pair). Each Vault has specific collateral token and borrow token, and user positions are tracked as NFTs containing their collateral and debt data. Vault is designed to be extremely capital efficient — borrowers can get very high maximum loan-to-value (LTV) ratios (up to 92% for uncorrelated pairs, and up to 98.5% for correllated pairs) while enjoying ultra-low liquidation penalties(as low as 0.1%). The key innovation of Fluid’s Vault lies in its liquidation mechanics: instead of liquidating positions one by one, Vault groups positions by risk into ticks and liquidates them in aggregate. This liquidation mechanism makes the system safer and more gas-efficient, by handling multiple risky positions simultaneously.

3.2 The Concept of Liquidations

Before diving into the Vault architecture, we first recall the concept of liquidations. As you may know, to borrow asset y (debt) you need to lend some amount of another asset x (collateral), and value of the collateral should be more than the value of your debt. In the image below you can see the red and green dots, which represent borrowing positions, where on the x-axis is their collateral value in dollars and on the y-axis is their debt value in dollars.

The green dots represent safe positions and the red ones represent risky, liquidatable position. Position is liquidatable if it’s debt ÷ collateral ratio is bigger than a certain specific threshold. Over time this ratio is changing as prices of debt and collateral assets are fluctuating. For example, for specific position, if the debt price stayed the same, but the collateral has dropped, it will shift position to the left on the graphic. A universal goal of any lending protocol is to keep positions in the green safe zone, and if they move to the yellow liquidatable zone, move them to the green zone with the help of liquidations.

The protocol’s main priority is to prevent positions from shifting into the red bad debt zone. If a position moves there, it means the borrower's debt became bad, which means that the value of debt is bigger then the value of borrower's collateral.

☝ To be 100% accurate, in Aave and similar protocols positions work a little bit differently, because of the use of the "health factor", but our approach is essentially equivalent and provides helpful visual demonstration of the core idea of risk management for borrowing positions.

Liquidation process. Now let’s understand the liquidation process. As mentioned above, liquidation can occur when position’s debt to collateral ratio is above specific threshold (or in yellow zone on the image). The liquidation of a position is a process of providing debt token back to the protocol by a liquidator third party and getting in return some collateral (which borrower supplied when created position). The amount of collateral received by the liquidator is often calculated as the amount debt * (collateral/debt market price) * (1+discount). On the image above it is visualized with arrow going from red dot to the green one, moving the position from the risky sector to the safe one.

One of the goals of every lending protocol is to balance liquidation price (how much of collateral liquidator receives for one unit of debt) between acceptable for the borrower and profitable for a liquidator.

Another goal is to prevent bad debts, because in that case, no matter how attractive the liquidation price is, it won’t be profitable to liquidate the position. It means the protocol lost money and can’t recover it (unless in future debt price goes down or collateral goes up).

Liquidation Example.

To understand the liquidation concept better let’s take a look at one simple example. Suppose positions in the lending protocol have ETH as collateral and USDC as a debt.

Current price of ETH = 4000 USDC, liquidation threshold = 80%, discount is 10%. Some positions are eligible for liquidation. Liquidator wants to liquidate some of them.

For each position it will look in the following way: let’s take position with collateral of 1 ETH (worth $4000) and debt 3201 USDC (worth $3201), ratio is 0.80025 > 0.8 and so the position is liquidatable.

Liquidator will repay 1600 USDC of debt — maximal possible amount of debt to repay by the lending protocol — and for this he will get ETH in dollar value with discount = 1600 * (1 + 0.1) = $1760, which is 0.44 ETH (at the the 4000$ price at the time of liquidationg).

New position consists of 1601 USDC debt and 0.56 ETH collateral, resulting in ratio 0.71 < 0.8 — now position is considered safe. For each position that can be liquidated, the same actions must be done separately.

This approach has two main drawbacks:

1. Gas inefficiency. The liquidator needs to liquidate each position separately.

2. Unnecessary loss of money for borrowers. Most of the time, liquidators repay more debt than is needed to make a position safe. For instance, Aave allows to liquidate up to 50% of debt — this is done in order to adequately incentivize liquidators to keep the protocol away from bad debt.

   However, this also results in unnecessary losses for borrowers. In the case above for example, the liquidator could have repaid 201 USDC of debt to make the position safe, which would mean the borrower loses not $160 to the liquidator, but only $21.

3.3 Liquidations in Vault

Here we explain main features of the Vault subprotocol and what benefits they give to the users. A step-by-step more detailed explanation of Vault’s liquidations will be covered in the next subsection.

Fluid’s subprotocol Vault uses a different architecture that helps resolve the issues mentioned above: making liquidations more efficient and less harmful for users, while still keeping them attractive for liquidators.

Main innovations. Compared to other lending protocols, the two fundamental Fluid's differentiators are:

1. Use of token quantity directly, instead of their dollar value. Ratios in Fluid are calculated directly by assets quantities, not their dollar value.

2. Aggregation of positions into ticks. Similar to how Uniswap v3 LP positions are concentrated into discrete ticks, in Vault user’s borrowing positions are aggregated by the debt÷collateral ratio tick: once position's ratio is calculated, the ratio is being rounded to the closest tick and placed there.

You can see the visual demonstration of how positions are being stored in the Vault on the image above. Ticks are simply discrete representations of the ratio, helping to optimize protocol’s operations via aggregation.

Important thing to note: during price fluctuations user’s position are not being moved, because their ratio stays the same. What changes is the liquidation tick. Liquidation tick represents the ratio above which positions are considered risky, and it is being calculated as current price Y/X * liquidation threshold. For example, for ETH/USDC Vault with current price 4000 and liquidation threshold 88% the liquidation tick would be ~log_{1.0015}(4000 * 0.88 = 3520) = 5448.

The same mechanics used for the liquidation threshold is applied to bad debt: there is a specific tick, called the max liquidation tick, above which positions are considered bad. If a position is above this tick, it will be absorbed (i.e., fully liquidated).

“Absorbing” is the protocol’s way of stepping in when a borrower’s position crosses a predefined risk threshold—it isn’t formally bad debt yet, but it is close enough that the protocol wants to limit risk. At that point the position is cancelled for the borrower and its entire debt and collateral are moved into two bookkeeping buckets: absorbed debt and absorbed collateral. Later, when the price is better, liquidators can liquidate the absorbed debt. When they do, they receive a proportion of the absorbed collateral that matches the proportion of absorbed debt they liquidate.

The current price for the Vault pair is fetched using oracles — each vault can have its own unique set of oracles to do so. This can be Uniswap TWAP, Chainlink's oracle, contract backing, rate limits, or a combination of these. In addition, liquidations and borrowings in the vault also use different oracles. When a user is borrowing, the protocol will utilize the lowest possible pricing for the asset. For example, a 30-minute lowest moving average price for user interaction, while simultaneously using the most recent trusted market price (or contract backing) for liquidations to avoid liquidating users early and for the protocol to avoid taking any extra risk.

Animation.

Repercussions & design unlocks. From the liquidator's point of view, they no longer look at each position individually—they look at ticks. It's not about specific user having some debt and collateral, but rather about some debt and collateral existing in a specific tick.

This design helps make things better for both liquidators and borrowers:

1. Simultaneous liquidations. Because debt and collateral are concentrated in ticks, it's possible to liquidate an infinite number of positions with the same ratio simultaneously. This greatly saves gas for liquidators and gives them “more liquidity” to liquidate.

2. Only as much is liquidated as needed. Liquidations in the Vault work in such a way that the liquidator gradually moves positions from one tick to the next non-empty tick (which has some debt), stopping when the liquidation tick is reached or when the liquidator runs out of assets to repay the debt.

3. Lower penalty (good for borrowers). The penalty, or discount on collateral, can be as low as 0.1%, which saves borrowers a lot of money during liquidation events — this is possible because liquidators liquidate multiple positions simultaneously.

4. Higher Liquidation Thresholds. Because of position aggregation and the Vault’s design, all liquidators first target the riskiest positions (the higher ticks) and then move to less risky ones. This allows Vaults to set higher liquidation thresholds and loan-to-value ratios.

5. Democratization of liquidations. Thanks to its design, the Vault liquidation process can be integrated into DEXs or aggregators, since Vault liquidation is as gas-efficient as a simple swap. This opens up the liquidation process to regular traders, not just those who can run bots to monitor available positions.

3.4 Vaults’s Liquidation Process

High level. Liquidations in the Vault might sound like magic, but in reality, the process is quite straightforward—just smart.

From the liquidator’s perspective, the Vault can be seen as an array of non-empty ticks, sorted from the riskiest to the safest. More specifically, it looks like this:

How the red part works. During a liquidation event, when the "liquidate" function is called, the Vault checks if there are any non-empty ticks above the max liquidation tick. If there are, those ticks are absorbed. After absorption, the array looks like this:

During the liquidation, the liquidator has some amount of debt assets he can repay. He has 2 options:

1. Liquidate the absorbed debt (if it's profitable or if they simply want to) and then proceed to the liquidatable ticks in the yellow part.

2. Skip the absorbed debt and go straight to liquidating debt in the yellow ticks.

How the yellow part works. Liquidation in Vault is a loop in which the liquidator moves positions from the current most risky non-empty tick to the next non-empty tick. Thus Liquidation loop moves positions to safer and safer ticks, until they all are moved into the liquidation threshold tick.

For example, if there is a liquidatable tick as you can see in the image (with 1 red dot), after the first iteration in the loop, the exact amount of debt and collateral will be removed from this tick to make its ratio equal to the next non-empty tick (basically moving all positions in it to the safer non-empty tick). On the next iteration, this process repeats until the liquidation threshold tick is met. After this, all positions in the Vault are in the safe zone.

If the liquidator is out of debt assets to repay and the liquidation threshold tick is not met, the process will be stopped at the last tick which was reached in the loop. The subtle complication arises when the liquidator runs out of money at the moment when position is between two ticks. In this situation, partially liquidated ticks occur (pink dots on the image), which represent ticks stopped somewhere in between ticks. When another liquidator comes to liquidate, the process will continue from the position where the previous liquidator stopped (or from a higher tick if it appeared during the time that passed between the two liquidations) and will keep going until all positions are in the safe zone.

Animation Example.

Branches. We haven’t talked about branches or how they work yet. Branches are mostly a technical implementation detail, although a very clever one, that has to do with the tick data structure & opening/liquidation of positions, and that makes Fluid Vault’s architecture possible. They help with position↔tick accounting, for example in cases when partially liquidated positions become safe due to price changes and new safe positions are opened above partially liquidated ones. Explaining branches in full would take much more space, so we’ll leave that as an exercise for those who are truly interested in the Vault.

3.5 Rebalancing

Sometimes, Fluid Vaults intentionally set supply or borrow rates that differ from the market rates provided by the Liquidity Layer. There are several strategic reasons for doing so:

1. Attracting users: New Vaults may temporarily offer higher supply rates or lower borrow rates than the market to encourage user participation.

2. Profit optimization: In periods of high demand, Vaults can strategically adjust rates to increase profitability (as detailed here).

3. Managing usage: Conversely, sometimes rates are intentionally set less favorably to moderate the number of users in a particular Vault.

Magnifiers. To implement these rate adjustments, Vaults use magnifiers. Magnifiers are simply multipliers applied to the base market rates from the Liquidity Layer:

Vault Supply Rate = LL Supply Rate · Magnifierₛ Vault Borrow Rate = LL Borrow Rate · Magnifierᵦ

When magnifiers differ from 1, the protocol experiences financial outcomes:

• If Magnifierᵦ > 1 or Magnifierₛ < 1, the Vault generates more revenue than the Liquidity Layer, thus earning profits.

• Conversely, if Magnifierᵦ < 1 or Magnifierₛ > 1, the Vault intentionally offers more favorable terms, incurring losses.

Rebalancing. These adjusted rates cause discrepancies between the Vault’s accounting and the Liquidity Layer’s actual balances. To maintain a healthy and accurate system, the Vault must periodically correct these inconsistencies through a rebalancing function. Here’s how it operates:

Total Supply in Vault > Total Supply in Liquidity Layer:

The difference (delta) is deposited into the Liquidity Layer on behalf of the rebalancer.

Total Supply in Vault < Total Supply in Liquidity Layer:

The difference is withdrawn from the Liquidity Layer and transferred to the Vault’s revenue contract of the vault.

Total Borrow in Vault > Total Borrow in Liquidity Layer:

The difference is borrowed from the Liquidity Layer and sent to the revenue contract.

Total Borrow in Vault < Total Borrow in Liquidity Layer:

Funds from the revenue contract are used to repay the Liquidity Layer

Importantly, the rebalancing function isn’t open to anyone; it can only be called by Auths. This ensures that rebalancing is executed strategically, protecting the integrity and sustainability of the Vault.

Conclusion.

Fluid Protocol represents a paradigm shift in DeFi architecture.

The Liquidity Layer eliminates the traditional silos between protocols by creating a unified pool where assets flow seamlessly across all subprotocols. Any financial primitive can be built on top of Fluid Liquidity Layer — whether lending, borrowing, trading, perpetuals, options, or other derivatives — and they all utilize and contribute to the same shared liquidity. Currently, lending and DEX protocols are live, with additional financial primitives planned for the future.

Within Vault—the flagship lending/borrowing subprotocol—Fluid delivers unprecedented gas & capital efficiency for liquidators & borrowers (e.g. 98% max LTVs, 0.1% liquidation penalties), by aggregating borrowing positions into ticks.

Stay tuned for Part 2, where we'll dive deep into Fluid's DEX architecture and explore how it seamlessly integrates with the Liquidity Layer to create the most capital-efficient trading experience in DeFi.