Fluid Vaults

Automated concentrated liquidity for Robinhood Chain

Version 1.0 / September 2026

Abstract

Concentrated liquidity made market making capital efficient and made it a full time job. A liquidity provider who concentrates into a tight band earns multiples of what a passive position earns, right up until price leaves the band. Then the position stops earning entirely, holds the wrong side of the pair, and quietly loses to anyone still quoting.

Fluid is a set of vaults that take that job away from the depositor. You deposit one asset or two. The vault mints you a fungible share, deploys the capital as a concentrated position, watches realized volatility, moves the band when the math says moving is worth more than it costs, and folds harvested fees back into the position. Your share count never changes. Its redemption value does.

The protocol charges ten percent of harvested fees and nothing else. There is no management fee, no deposit fee, and no withdrawal fee. Half of protocol revenue is paid to stakers in the assets it was collected in.

Fluid is an independent protocol. It is not affiliated with, endorsed by, or connected to Robinhood Markets, Inc.

1. The problem

1.1 Passive liquidity is a losing trade

In a constant product pool, a liquidity provider spreads capital across every price from zero to infinity. Almost all of it sits at prices that will never trade. The fees earned per dollar deployed are small enough that, after impermanent loss, a large share of passive positions underperform simply holding the two assets.

Concentrated liquidity solved the capital efficiency half of that problem. A position quoted between P_lower and P_upper behaves, inside that range, like a much larger passive position. The concentration multiplier for a symmetric band of half width w, expressed in log price, is approximately

m(w) ≈ 1 / (2w)

A position quoted plus or minus five percent earns roughly ten times the fee flow of the same capital spread across the full curve, for as long as price stays inside.

1.2 The half it created

Concentration introduced a new failure mode. Outside the band, the position earns nothing and is composed entirely of the losing asset. The expected fee return of a band is not the concentration multiplier alone but the multiplier weighted by the fraction of time the position is actually quoting:

APR_fee ≈ f · V · m(w) · p_in(w) / TVL

where f is the pool fee tier, V is volume over the period, and p_in(w) is the probability of price remaining inside the band. Narrowing raises m(w) and lowers p_in(w). There is an interior optimum, it depends on realized volatility, and it moves.

Public subgraph data across major concentrated liquidity venues consistently shows the majority of open positions sitting outside their range at any given moment, and the median retail position going months without a reposition. Those positions are not providing liquidity. They are holding a leveraged directional bet they did not intend to place.

1.3 Why a new chain makes it worse

A young chain has thin books, wide spreads and violent repricing. That is exactly the environment where a static band breaks fastest, and it is the environment where good liquidity is worth the most to everyone else using the chain. Robinhood Chain will get its passive liquidity for free. It will not get well managed liquidity unless somebody automates it.

2. Design goals

1. One transaction in, one transaction out. A depositor should never see a tick, a range, or a position NFT.
2. Never touch principal. The protocol earns from harvested fees only. If the vault earns nothing, Fluid earns nothing.
3. Rebalance on economics, not on a timer. Every reposition is an expenditure. It happens only when expected incremental fees exceed expected cost.
4. Fungible, composable shares. A vault share is an ERC-20, not an NFT, so it can be lent against, paired, or held by a contract.
5. No custody. Vault logic is immutable per vault. Strategy parameters are bounded on chain, and the bounds cannot be widened by governance after deployment.
6. Fail closed. Every execution path reverts rather than executing at a bad price.

3. Architecture

Fluid is three contracts, one library and an open keeper set.

 depositor
     |
     +--> [ Zap Router ]  periphery, holds nothing, splits one asset into the pair
     |          |
     v          v
 [ Vault ]  fungible ERC20 share, deposits, redemptions, harvest, rebalance,
     |      and it owns the concentrated liquidity position directly
     |
     +--- uses --> [ FlowMath ]  band sizing, volatility estimate, gates
     ^
     |
   keepers (permissionless)

 [ Factory ]  deploys and registers vaults. Cannot upgrade, pause or touch one.

There is deliberately no separate position manager and no external strategy contract. A vault holds its own liquidity and computes its own band from a pure library, so there is no address a vault has to trust and no upgrade path through which a strategy could be swapped underneath a depositor.

3.1 Vault

The vault holds the pair and issues a single fungible share token, fvPAIR.

Share accounting never reads a price at all. This is the most important design decision in the protocol, and it is worth being precise about why. The obvious approach is to value the vault's holdings in one numeraire and mint shares against that value, which forces you to pick a price, which hands an attacker a target. Fluid does not price anything. A deposit must arrive in the ratio the vault already holds, and mints shares equal to that fraction of the existing supply. A redemption burns shares and returns exactly that fraction of the live position plus the same fraction of idle balances, in both tokens.

The consequence is that the entire class of "move the pool, mint cheap shares, move it back" attacks has nothing to attack. There is no oracle in the mint path to manipulate and no valuation to skew.

What price manipulation can still do is change the composition of the position, since the split between token0 and token1 at any moment is a function of spot. That is why every entry point still checks spot against the TWAP and reverts on deviation. The circuit breaker defends the ratio, not a valuation.

Fees are harvested before any share math runs, so an arriving depositor never captures fees earned before they arrived. Amounts pulled in are rounded up and amounts paid out are rounded down, always in the vault's favour. MIN_SHARES are burned to a dead address on the first deposit, which is what neutralises the classic first-depositor inflation attack. There is no swap on exit, so a redemption cannot be sandwiched.

3.2 Execution

The vault is the position owner. It talks to the pool directly through mint, burn, collect and swap, and it implements the pool's mint and swap callbacks, each of which rejects any caller that is not the pool.

There is no privileged external caller, no rescue function that can reach the pair, and no proxy. The guardian's sweep() exists only for tokens sent to the vault by mistake and explicitly refuses token0 and token1.

Repositioning burns the whole position, collects, trades the balances toward the ratio the new band needs, and mints again. That ratio swap carries a price limit measured from current spot, so a reposition cannot walk the pool an arbitrary distance to fill itself. Whatever the swap does not resolve is left idle, counted in share accounting, and deployed on the next pass: an imperfect split costs a little unused capital and never a loss. A funded vault that somehow ends a reposition without a live position reverts the entire transaction rather than silently parking the deposits.

3.3 The Flow Engine

The Flow Engine decides two things: how wide the band should be, and whether moving is worth it.

Volatility estimate. The engine maintains an exponentially weighted estimate of realized volatility from the pool's own tick observations:

σ²_t = λ · σ²_{t-1} + (1 - λ) · r²_t
r_t  = mean absolute change in the average tick between consecutive windows

with λ = 0.94 and a sampling window equal to the vault's TWAP period, thirty minutes at launch. Everything is denominated in ticks rather than in log price, which is the same quantity to within a constant: one tick is one basis point, so ln(1.0001) ≈ 1e-4 per tick. Working in ticks keeps the whole engine in integer arithmetic.

Two properties matter. The samples are window averages, not instantaneous ticks, so a single manipulated block barely moves the estimate. And the data comes from the pool's own oracle rather than an external feed, so an attacker cannot bias the band without paying to move the very pool the vault trades in.

The estimate is seeded at its steady state on the first deposit rather than decaying up from zero, which would otherwise open the first band far tighter than the market deserves.

Band width. The half width for a strategy with aggressiveness k and horizon H is

w = k · σ_t · √H

H is the target time in range, a per-vault parameter, expressed in the same sampling windows as the volatility estimate. It is not the cooldown and it is not the time between repositions: it is how long the band is being built to survive. A vault sized for the next thirty minutes would reposition itself to death; the genesis vaults target three days.

Higher volatility widens the band automatically. A calm market tightens it. Nobody files a governance proposal to react to a regime change.

Never reopen tighter than the move that broke you. A shock followed by a quiet hour reads as low volatility, because the sampled windows all land in the calm. Sized on that estimate alone, a vault would reopen a minimum-width band directly into the teeth of whatever just moved. So the new half width is floored at the drift that forced the reposition: the market has just demonstrated it travels that far, and the band is built to respect it.

Rebalance trigger. Drift alone does not trigger a reposition. Two conditions must both hold:

(1)  | ln(P_now / P_center) |  >  θ · w                     drift gate,  θ = 0.7
(2)  E[ΔFees over H]  >  gas + swapCost + repositionIL      economic gate

The economic gate is the part most vaults omit. Estimated incremental fee flow uses the pool's trailing volume in the same way as section 1.2. Cost includes the gas at current base fee, the slippage of the rebalancing swap at the current depth, and the loss realized by converting the position into its new composition. If the inequality fails, the vault stays where it is and keeps earning whatever it is earning.

Where each gate actually lives. The cooldown, the deviation guard and the drift gate are enforced in the contract: a keeper cannot get past them at any price. The full expected-value inequality is evaluated by keepers off chain, because the trailing volume term needs data a contract cannot read cheaply. What the contract guarantees is a bound, not the optimum: an over-eager keeper can still reposition inside the gates, and what stops that being expensive is the cooldown plus the fact that the bounty comes out of harvested fees. Anyone reading E[ΔFees] > cost as an on-chain invariant would be reading it wrong.

Cooldown. A minimum interval between repositions per vault, enforced on chain, bounds the worst case where an oscillating price causes repeated round trips.

3.4 Keepers

Rebalancing is permissionless. Any address may call rebalance() on a vault. The call reverts unless the on-chain gates pass, so a keeper cannot force a reposition that the vault has not already decided it wants.

A successful keeper receives a share of the fees harvested in that same transaction, five percent at launch and capped by governance inside a hard bound. Sizing the bounty off the harvest rather than off the repositioned notional matters: it means a keeper is paid out of what the position earned, never out of principal, and a vault that earned nothing pays nothing.

The deviation guard removes the need for a keeper bond. A rebalance simply cannot execute while spot sits outside the band around the TWAP, so the sandwich a bond would have punished reverts instead.

3.5 Zap Router

Most depositors hold one asset, not a balanced pair. The zap router accepts a single token, computes the split that leaves the vault balanced at the target band, executes the swap through the deepest available route with a caller supplied slippage limit, and deposits. The whole thing is one transaction and one approval.

3.6 Safety rails

• TWAP deviation guard. Every mint, burn and swap reverts if spot deviates from the thirty minute TWAP by more than the vault's configured cap.
• Bounded parameters. k, θ, H and the cooldown are stored per vault with hard minimum and maximum values written at deployment. Governance can move a parameter inside its bounds. Nothing can move the bounds.
• Per vault deposit caps during the first season, raised on a schedule as each vault accumulates history.
• Bounded swap impact. The vault's own rebalancing swap carries a price limit measured from current spot, so a reposition cannot walk the pool an arbitrary distance to fill itself.
• Pause, not seize. The guardian multisig can pause deposits. It cannot pause redemptions, cannot upgrade a vault, and cannot move funds. sweep() refuses the vault's own pair.
• One automatic exception to open withdrawal. Redemptions pass through the same spot-versus-TWAP circuit breaker as every other entry point, and they have to. Burning liquidity at a manipulated price returns a skewed mix of the two tokens, so without the guard an attacker could shove the pool and redeem at the expense of everyone still in the vault. The breaker is automatic, temporary, and identical for every address including the guardian. No human can hold it open and no human can hold it shut. Outside that window, withdrawal is always available.

4. Strategies

Every vault ships with three published bands over the same pair. A depositor chooses an appetite, not a tick range.

Bands quoted above are indicative at typical volatility. The engine sets the actual width from live volatility every time it repositions.

A depositor holding all three is running a simple barbell: the narrow leg harvests in calm conditions, the wide leg stays quoting through a shock. Because each is a plain ERC-20 share, splitting between them is a transfer, not a strategy meeting.

5. Fees and revenue

The protocol takes ten percent of harvested fees. It takes nothing else.

No management fee on assets under management. No deposit fee. No withdrawal fee. No performance fee on price appreciation of the underlying, which is not something Fluid produced and not something Fluid should charge for.

Revenue is split at the point of harvest:

The reason the staker share is paid in collected assets rather than in newly minted FLUID is simple. Paying yield in your own inflating token is not yield, it is dilution with a chart. Fluid pays out what it actually earned.

6. Shares as collateral

fvPAIR is an ERC-20 whose value is a monotonic function of harvested fees and the underlying pair. That makes it a better collateral asset than a raw LP NFT: it is fungible, it has a canonical on chain valuation function that uses TWAP rather than spot, and its composition is known and bounded by the band.

Fluid publishes a reference pricing adapter that lending markets can integrate directly. The intended end state is that a depositor can hold a managed liquidity position, borrow against it, and never have unwound it to do so. Integration work begins after the second audit and is deliberately not part of the launch surface.

7. Token

FLUID, fixed supply of 1,000,000,000. No mint function after deployment.

7.1 Staking

Stake FLUID to receive xFLUID. Unbonding takes seven days. xFLUID does two things: it receives fifty percent of protocol revenue, distributed weekly in the assets collected, and it votes gauge weights that direct emissions between vaults.

Gauge voting is how the protocol bootstraps depth where depth is worth the most. A vault with real volume attracts votes because its fees are real. A vault with no volume stops attracting emissions on its own, without a proposal.

7.2 What the token does not do

It does not gate deposits. It does not gate withdrawals. It is not required to use any vault. A protocol that forces you to hold its token to use its product is charging a hidden fee.

8. Governance

Launch governance is a three of five guardian multisig with a narrow mandate: pause deposits, adjust bounded parameters, and approve new vault deployments. It cannot upgrade a live vault, cannot move user funds, and has no ability to pause a redemption. The only thing that ever blocks a withdrawal is the automatic price-deviation breaker described in section 3.6, which the guardian can neither trigger nor suspend.

Vault contracts are immutable. A new strategy is a new vault, and depositors migrate by choosing to migrate. There is no proxy behind a vault and no admin key that can change what one does after people have deposited into it.

Guardian powers expire on a published schedule and transfer to xFLUID governance with the same restrictions intact.

9. Risks

Impermanent loss is managed, not removed. An actively rebalanced position realizes losses that a static one leaves unrealized. In a strong sustained trend, a rebalancing vault can end up worse than holding, and the Narrow strategy is the most exposed to this. Fluid improves fee capture per unit of risk. It does not turn a directional bet into a free one.

Smart contract risk. Two independent audits before mainnet and a public bug bounty from day one. That reduces the risk. It does not remove it.

Oracle and thin pool risk. The TWAP guards make manipulation expensive, not impossible, in a pool with little depth. Vaults on thin pairs launch with lower deposit caps and wider deviation tolerance windows for exactly this reason.

Keeper liveness. If no keeper calls, positions drift. The bounty is sized to stay profitable at realistic gas, and the protocol runs its own keeper as a backstop without any privileged access, competing on the same permissionless interface as everyone else.

Chain risk. Robinhood Chain is new. Sequencer behaviour, bridge risk, and ecosystem depth are outside Fluid's control.

10. Roadmap

11. Launch parameters

12. Closing

The best outcome for a liquidity provider is that they stop thinking about being one. Deposit, receive a share, and let something that watches the pool every block do the part that requires watching the pool every block.

Everything else in this document is implementation detail in service of that.

Fluid is an independent protocol and is not affiliated with, endorsed by, or connected to Robinhood Markets, Inc. Nothing in this document is investment advice. Providing liquidity carries risk of loss, including total loss.