approaches to liquidity in DeFi
The core promise of decentralized finance is that financial systems can be built as software. Exchanges, lenders, derivatives, vaults, indexes, stablecoins, launchpads, and structured products can all be expressed as smart contracts.
But programmable money still needs money.
A trading protocol can have elegant contracts, clean architecture, and a good user interface, but if there is no liquidity, the protocol does not function. Users need someone or something on the other side of their trade. Lenders need borrowers. Borrowers need lenders. Traders need market makers. Derivatives need collateral. Prediction markets need counterparties. Stablecoins need reserves. Launchpads need a pricing mechanism for new assets.
Liquidity is the inventory that allows a financial protocol to operate.
In traditional finance, liquidity is usually supplied by a mix of market makers, banks, brokers, exchanges, dealers, and large funds. In DeFi, the same economic problem exists, but the mechanisms are different because the system has to run through smart contracts, public state, and permissionless participation.
Over time, DeFi has developed several major approaches to liquidity:
DeFi liquidity mechanisms
1. Automated market makers
2. Order books
3. Concentrated liquidity AMMs
4. RFQ systems
5. Prop AMMs
6. Bonding curves
7. Vault based liquidity
8. Intent based liquidity
Each approach answers the same question in a different way:
When a user wants to trade, where does the other side come from?
what liquidity is
Liquidity is the ability to buy or sell an asset without moving the price too much.
A market with deep liquidity lets users trade large size with low slippage. A market with shallow liquidity may technically allow trading, but even small orders can move the price significantly.
For a simple swap, the user experience depends on three things:
1. Price
What exchange rate does the user get?
2. Depth
How much can the user trade before the price gets worse?
3. Execution
Can the trade actually happen when the user wants it?
A liquid market has all three. It gives a competitive price, supports meaningful size, and executes reliably.
An illiquid market may fail on any of them.
Good liquidity:
user wants to sell 100,000 USDC of token A
protocol can execute near the market price
slippage is low
trade clears quickly
Bad liquidity:
user wants to sell 100,000 USDC of token A
pool only has 20,000 USDC of useful depth
price collapses during execution
user gets a much worse fill
Liquidity is not just a nice feature. It is the survival layer of a financial protocol. If users cannot enter and exit positions efficiently, the protocol becomes unusable.
the basic liquidity problem
Every financial trade needs two sides.
Buyer wants asset
Seller wants cash
or
Trader wants long exposure
Counterparty takes short exposure
or
Borrower wants capital
Lender supplies capital
In centralized finance, this matching is usually hidden behind an exchange or broker. In DeFi, the mechanism is more explicit.
The protocol has to decide whether liquidity comes from:
1. Passive pools of deposited capital
2. Active market makers quoting prices
3. On chain order books
4. Off chain quotes settled on chain
5. Protocol owned inventory
6. Mathematical pricing curves
7. Specialized vaults that underwrite risk
8. Solvers competing to satisfy user intents
The design choice matters because it affects capital efficiency, user experience, complexity, latency, decentralization, and risk.
automated market makers
The automated market maker, or AMM, is the classic DeFi liquidity mechanism.
Instead of requiring a buyer and seller to be matched directly, an AMM lets users trade against a pool of assets. Liquidity providers deposit tokens into the pool. Traders swap against the pool. The pool updates prices according to a formula.
The simplest version is the constant product AMM, popularized by Uniswap.
x * y = k
Where:
x = amount of token A in the pool
y = amount of token B in the pool
k = constant product
A pool might hold ETH and USDC.
ETH / USDC pool
liquidity providers
│
▼
┌───────────────────┐
│ AMM pool │
│ │
│ ETH reserve │
│ USDC reserve │
└─────────┬─────────┘
│
▼
traders
When a trader buys ETH with USDC, they add USDC to the pool and remove ETH from the pool. Since the reserves changed, the price changes automatically.
Before trade:
pool has 100 ETH
pool has 300,000 USDC
implied price is roughly 3,000 USDC per ETH
Trader buys ETH:
USDC reserve increases
ETH reserve decreases
ETH becomes more expensive in the pool
The key benefit is that liquidity is always available as long as the pool has reserves. A trader does not need to wait for a matching order. The smart contract itself quotes the trade.
This was a major breakthrough for DeFi because it made markets easy to create. A new token did not need a professional market maker on day one. Anyone could create a pool, deposit two assets, and allow trading.
The tradeoff is capital efficiency.
In a basic constant product AMM, liquidity is spread across all possible prices from zero to infinity. Most of that capital is not being used at the current market price.
Constant product AMM liquidity
price range:
0 ─────────────────────────────── ∞
capital:
spread across entire curve
This makes basic AMMs simple and reliable, but inefficient. A large amount of capital may be needed to support low slippage near the current price.
The second tradeoff is impermanent loss.
Liquidity providers deposit two assets. If the relative price of those assets changes, the pool automatically rebalances against them. Compared to simply holding the assets, the LP may end up worse off.
Example:
LP deposits:
1 ETH
3,000 USDC
ETH price doubles externally:
arbitrageurs buy ETH from the pool
pool loses ETH
pool gains USDC
LP withdraws later:
less ETH
more USDC
total value may be lower than simply holding 1 ETH and 3,000 USDC
Fees compensate LPs for this risk. The AMM model works when trading fees are large enough to make providing liquidity attractive.
So the AMM liquidity model is:
Where liquidity comes from:
passive liquidity providers
How users trade:
against a pool
How prices update:
formula
Main advantage:
always available liquidity
Main weakness:
capital inefficiency and impermanent loss
order books
The traditional exchange model is the order book.
An order book contains bids and asks.
Order book
asks
3,010 sell 5 ETH
3,005 sell 2 ETH
3,001 sell 1 ETH
------------------------ mid price
bids
2,999 buy 1 ETH
2,995 buy 4 ETH
2,990 buy 8 ETH
A buyer can take the lowest ask. A seller can take the highest bid. Market makers provide liquidity by continuously placing limit orders on both sides.
Unlike an AMM, the order book does not automatically create liquidity. The book is only as good as the orders inside it.
Deep order book:
many bids
many asks
tight spread
large size near mid price
Empty order book:
few orders
wide spread
small size
bad execution
Order books are highly capital efficient because market makers can place capital exactly where they want it. They can quote near the current price, cancel stale orders, widen spreads during volatility, and adjust inventory dynamically.
This is why order books dominate traditional finance and centralized crypto exchanges.
The challenge in DeFi is infrastructure.
On chain order books are difficult because every order placement, cancellation, and fill may require a transaction. On slower or more expensive chains, this is not practical for high frequency market making.
A healthy order book requires constant updates.
Market maker loop:
read market data
compute fair price
place bid
place ask
monitor inventory
cancel stale quotes
update prices
repeat
If every step requires an expensive on chain transaction, the market maker cannot quote competitively.
This is why on chain order books are most practical on high throughput, low cost chains, or in systems where the matching engine is off chain and settlement is on chain.
The order book liquidity model is:
Where liquidity comes from:
active market makers and limit order users
How users trade:
against resting orders
How prices update:
makers update quotes
Main advantage:
capital efficiency and precise pricing
Main weakness:
requires active liquidity and fast infrastructure
AMMs versus order books
AMMs and order books represent two different liquidity philosophies.
AMM:
Put money in a pool.
Let a formula quote prices.
Anyone can trade against it.
Order book:
Let makers post quotes.
Match buyers and sellers.
Liquidity exists only where orders exist.
A simple comparison:
┌─────────────────────────┬──────────────────────┬──────────────────────┐
│ │ AMM │ Order book │
├─────────────────────────┼──────────────────────┼──────────────────────┤
│ Liquidity source │ Passive LPs │ Active makers │
│ Pricing │ Formula │ Maker quotes │
│ Execution │ Always available │ Depends on book depth│
│ Capital efficiency │ Lower │ Higher │
│ Complexity │ Lower │ Higher │
│ Best for │ Long tail assets │ Active markets │
│ Main LP risk │ Impermanent loss │ Inventory risk │
└─────────────────────────┴──────────────────────┴──────────────────────┘
AMMs made DeFi work because they solved the cold start problem. Order books are more efficient once enough sophisticated market makers are present.
This pattern shows up repeatedly:
Early market:
AMM works better because anyone can create liquidity
Mature market:
order book can work better because makers compete on spreads
concentrated liquidity AMMs
Concentrated liquidity AMMs sit between basic AMMs and order books.
In a basic AMM, LP capital is spread across the full price curve. In a concentrated liquidity AMM, LPs choose the price range where their capital is active.
Basic AMM:
0 ───────────────────────────────────── ∞
capital spread everywhere
Concentrated liquidity:
0 ───────────────[ active range ]─────── ∞
capital here
For example, an LP in an ETH / USDC pool might decide:
Provide liquidity only when ETH trades between:
2,800 USDC and 3,400 USDC
If the price stays inside that range, the LP earns fees and provides much deeper liquidity than they would in a basic AMM with the same capital. If the price leaves the range, the LP becomes inactive and ends up holding mostly one asset.
This is similar to an order book because LPs are choosing where to place liquidity. But it is still an AMM because trades happen against a pool and prices move according to the AMM formula inside the selected range.
Concentrated liquidity AMM
LP chooses range
│
▼
┌────────────────────┐
│ ETH / USDC pool │
│ │
│ active liquidity │
│ only in range │
└─────────┬──────────┘
│
▼
traders
The benefit is capital efficiency.
A concentrated liquidity pool can provide far more depth near the current price than a basic AMM using the same total capital.
The tradeoff is active management.
If price moves out of range, the LP stops earning fees. To continue earning, they must reposition liquidity.
LP range:
2,800 ───────── 3,400
Price moves to 3,700:
LP no longer provides active liquidity
LP must reposition or remain inactive
This creates a new class of strategies. LPing becomes more like market making. Passive LPs may underperform if they do not manage ranges well. Professional liquidity managers can compete by optimizing ranges, rebalancing, and managing inventory risk.
The concentrated liquidity model is:
Where liquidity comes from:
LPs who choose active price ranges
How users trade:
against an AMM pool
How prices update:
AMM math inside active liquidity ranges
Main advantage:
much better capital efficiency than basic AMMs
Main weakness:
LPs must manage range and inventory risk
RFQ systems
RFQ means request for quote.
Instead of trading against a pool or order book, the user requests a price from one or more market makers. A maker responds with a quote. If the user accepts, the trade settles.
RFQ flow
user
│
│ request quote
▼
┌───────────────┐
│ market makers │
└──────┬────────┘
│ signed quote
▼
user
│ accept
▼
settlement contract
An RFQ quote usually includes:
asset sold
asset bought
amount
price
expiration time
maker signature
settlement instructions
RFQ is useful when liquidity is better sourced from professional market makers than from passive pools. The maker can price the trade using off chain inventory, centralized exchange liquidity, hedging models, or private risk systems.
For the user, RFQ can produce better execution because the maker can quote a specific trade rather than requiring the user to walk through an AMM curve.
For the maker, RFQ is attractive because they only commit liquidity when asked. They do not need to leave large amounts of capital sitting passively in a pool.
AMM:
maker deposits inventory first
user trades later
RFQ:
user asks first
maker decides whether to quote
The tradeoff is availability.
An AMM can always return a price if there is liquidity in the pool. An RFQ system depends on makers responding. If makers are offline, uninterested, or unwilling to quote a volatile asset, the user may get no fill.
RFQ systems also introduce latency and coordination complexity. The protocol needs a way to request quotes, collect responses, verify signatures, and settle the winning quote.
The RFQ liquidity model is:
Where liquidity comes from:
professional market makers
How users trade:
by accepting signed quotes
How prices update:
makers compute prices off chain
Main advantage:
efficient pricing and no passive pool requirement
Main weakness:
depends on maker availability and off chain coordination
prop AMMs
A prop AMM is a hybrid between an AMM interface and a proprietary market making backend.
To the user, it may look like an AMM or swap interface. Under the hood, the liquidity can come from a maker that prices trades dynamically, manages inventory, and hedges externally.
In practice, many prop AMMs resemble RFQ systems.
User experience:
user enters trade
interface returns quote
user accepts
trade settles
Under the hood:
maker prices request
maker signs or commits quote
contract settles trade
The distinction is mostly in product design. RFQ is explicitly quote based. A prop AMM may feel continuous, like a pool, but the quote is still often produced by a market maker or solver.
The advantage is that the protocol can offer clean user experience without requiring a traditional public liquidity pool. The maker can use sophisticated off chain pricing, inventory management, and hedging.
The disadvantage is that liquidity becomes less permissionless. Users are relying on one or more privileged makers to quote fairly and remain available.
The prop AMM liquidity model is:
Where liquidity comes from:
designated or permissioned makers
How users trade:
through an AMM like interface or quote endpoint
How prices update:
maker controlled pricing engine
Main advantage:
better control over pricing and inventory
Main weakness:
less transparent and less permissionless than public pools
bonding curves
Bonding curves are pricing functions used to buy or sell an asset directly from a contract.
They are common in token launches because they provide immediate liquidity before a traditional market exists. Pump style launchpads popularized this model for new memecoins and long tail assets.
A bonding curve defines the token price as a function of supply.
price = f(supply)
As more users buy, supply increases and price rises. As users sell, supply decreases and price falls.
Bonding curve
price
^
│
│ .
│ .
│ .
│ .
│ .
└────────────────────────────> supply
A simple launch flow might look like this:
1. Token starts with low supply and low price.
2. Users buy from the curve.
3. Each buy increases supply and raises price.
4. Once enough capital is raised, liquidity migrates to an AMM.
The key benefit is that there is no need for an initial order book or external market maker. The curve itself provides the first market.
New token launch
buyers
│
▼
┌───────────────────┐
│ bonding curve │
│ price rises with │
│ demand │
└─────────┬─────────┘
│
▼
later AMM liquidity
Bonding curves are powerful for bootstrapping because they create a deterministic path from zero liquidity to some initial market structure.
The tradeoff is that the pricing is mechanical. It may not reflect fair value. It may create reflexive buying behavior. It may also be vulnerable to sniping, bots, and launch dynamics where early buyers have a major advantage.
The bonding curve liquidity model is:
Where liquidity comes from:
the curve contract and incoming buyers
How users trade:
against a deterministic pricing function
How prices update:
price changes with supply or reserves
Main advantage:
easy liquidity bootstrapping for new assets
Main weakness:
mechanical pricing and volatile launch dynamics
vault based liquidity
Some protocols need liquidity that is not simply swap inventory.
Derivatives, options, prediction markets, insurance, leverage products, and structured products often need someone to underwrite risk. In those cases, liquidity can come from vaults.
A vault pools capital from depositors and uses that capital to take the other side of user trades.
Vault liquidity
depositors
│
▼
┌──────────────┐
│ liquidity │
│ vault │
└──────┬───────┘
│ underwrites
▼
user positions
Examples:
Options vault:
sells options to users
Perps liquidity pool:
acts as counterparty to traders
Prediction market vault:
writes outcome exposure or parlays
Insurance vault:
pays claims in exchange for premiums
This model is different from an AMM. The vault is not necessarily quoting a spot swap between two assets. It is underwriting a payoff.
For example, in a parlay market, a vault might accept premium from users and pay out if a set of conditions resolves true. The vault earns premiums but takes tail risk.
User buys payoff
│
▼
┌────────────────────┐
│ vault receives │
│ premium │
│ │
│ vault may owe │
│ payout later │
└────────────────────┘
The major advantage is that complex financial products become investable. Instead of a single market maker writing risk manually, many LPs can deposit into a vault that underwrites a strategy.
The tradeoff is risk management. Vault liquidity is only safe if the protocol can price risk, cap exposure, manage correlation, and prevent insolvency.
The vault based liquidity model is:
Where liquidity comes from:
depositors allocating capital to a strategy
How users trade:
against vault underwritten exposure
How prices update:
pricing engine, oracle, or market maker logic
Main advantage:
supports complex payoff structures
Main weakness:
solvency and risk management are difficult
intent based liquidity
Intent based systems are another liquidity design.
Instead of specifying exactly how a trade should execute, the user signs an intent describing the desired outcome.
User intent:
I want to sell 10 ETH
I want at least 30,000 USDC
I want execution before this deadline
Solvers compete to satisfy the intent. A solver might route through AMMs, fill from its own inventory, use an order book, combine multiple venues, or match against another user.
Intent flow
user signs intent
│
▼
┌─────────────────┐
│ solver network │
└───────┬─────────┘
│ best solution
▼
settlement contract
This is powerful because it abstracts execution away from the user. The user does not need to know which pool, bridge, order book, or route is best. They state the outcome they want. Solvers compete to provide it.
Intent based liquidity is not one liquidity source. It is a routing and competition layer across many liquidity sources.
Solver can use:
AMMs
order books
RFQ makers
private inventory
bridge liquidity
lending markets
other user intents
The advantage is execution quality and abstraction. The disadvantage is solver complexity, trust assumptions around order flow, and the possibility that solver markets centralize around a few sophisticated actors.
The intent based liquidity model is:
Where liquidity comes from:
any source a solver can access
How users trade:
by signing desired outcomes
How prices update:
solvers compete to find execution
Main advantage:
best execution across fragmented liquidity
Main weakness:
solver centralization and system complexity
comparing the mechanisms
Each mechanism is good for a different market structure.
┌─────────────────────────────┬─────────────────────────────┬─────────────────────────────┐
│ Mechanism │ Best for │ Main weakness │
├─────────────────────────────┼─────────────────────────────┼─────────────────────────────┤
│ Basic AMM │ Long tail spot assets │ Capital inefficiency │
│ Order book │ Active liquid markets │ Needs market makers │
│ Concentrated liquidity AMM │ Blue chip spot pairs │ Requires active LPs │
│ RFQ │ Large or precise trades │ Maker availability │
│ Prop AMM │ Controlled quote systems │ Less permissionless │
│ Bonding curve │ Token launches │ Mechanical pricing │
│ Vault liquidity │ Derivatives and risk │ Solvency management │
│ Intent based liquidity │ Cross venue execution │ Solver complexity │
└─────────────────────────────┴─────────────────────────────┴─────────────────────────────┘
Another way to compare them is by asking who prices the trade.
Who sets the price?
AMM:
formula
Order book:
market makers and limit order users
Concentrated liquidity:
formula plus LP selected ranges
RFQ:
professional maker
Prop AMM:
proprietary pricing engine
Bonding curve:
supply based curve
Vault:
risk engine or underwriting model
Intent system:
competing solvers
And another way is to ask where capital sits before the user arrives.
Where is the capital before the trade?
AMM:
already in the pool
Order book:
resting in maker orders
Concentrated liquidity:
active inside selected ranges
RFQ:
often off chain or in maker inventory
Prop AMM:
maker controlled inventory
Bonding curve:
inside the curve contract or raised over time
Vault:
pooled in a strategy vault
Intent:
wherever the winning solver sources it
the liquidity spectrum
These designs are not isolated. They form a spectrum from passive to active liquidity.
Passive liquidity Active liquidity
AMM ── concentrated AMM ── vault ── RFQ ── prop AMM ── order book ── solver network
Passive liquidity is easier to access and more permissionless, but often less capital efficient.
Active liquidity is more efficient, but requires sophisticated operators.
Passive systems:
easier to bootstrap
simpler user experience
more transparent
less capital efficient
Active systems:
tighter pricing
better capital usage
more operational complexity
more dependence on makers or solvers
A mature DeFi ecosystem usually uses many of these mechanisms at once.
A token might launch on a bonding curve, migrate to an AMM, later attract concentrated liquidity, then become available through aggregators and intent solvers. Large trades might route through RFQ while smaller trades hit AMMs. Derivatives might rely on vaults while spot liquidity sits in pools or order books.
Lifecycle example
new token
│
▼
bonding curve
│
▼
AMM pool
│
▼
concentrated liquidity
│
▼
aggregators and intents
│
▼
order books and RFQ for larger flow
why liquidity design matters
Liquidity design determines who takes risk.
In a basic AMM, LPs take inventory risk and impermanent loss.
In an order book, market makers take inventory and adverse selection risk.
In RFQ, makers take quote risk for a short period of time.
In a bonding curve, early and late buyers face curve based price risk.
In a vault, depositors take underwriting and solvency risk.
In an intent system, solvers take execution risk and compete on routing.
There is no free liquidity. Every mechanism moves risk somewhere.
Liquidity is never free.
It is paid for through:
trading fees
spreads
emissions
premiums
rebates
MEV
inventory gains
protocol incentives
A protocol that ignores this eventually runs into problems. Liquidity providers leave if returns do not compensate risk. Market makers leave if flow is toxic. Vaults fail if risk is mispriced. Bonding curves break down if launch dynamics are too extractive. Intent systems centralize if only a few solvers can compete.
The central design question is not only:
How do users get liquidity?
It is also:
Why would anyone provide it?
conclusion
DeFi is often described as programmable money, but programmable money still needs liquidity. Every protocol has to answer the same basic question: when a user wants to trade, borrow, lend, hedge, or take risk, who or what is on the other side?
AMMs answered that question with passive pools and formulas. Order books answer it with active market makers. Concentrated liquidity AMMs make pooled liquidity more precise. RFQ systems bring professional makers into quote based settlement. Prop AMMs hide sophisticated pricing behind simple interfaces. Bonding curves bootstrap new assets from zero. Vaults make complex risk investable. Intent systems let solvers compete across all available sources.
None of these mechanisms is universally best. Each one is a different tradeoff between simplicity, capital efficiency, transparency, permissionlessness, and risk.
The future of DeFi liquidity will likely be hybrid. New assets may start with curves. Spot markets may use AMMs and concentrated liquidity. Large trades may use RFQ. Derivatives may use vaults. Active markets may move toward order books. Users may interact mostly through intents and aggregators that hide the routing complexity.
Underneath every design, the same fact remains:
A financial protocol is only as useful as the liquidity behind it.