Market Maker vs Liquidity Provider: What the Difference Means for a Token

A market maker is a counterparty with a mandate. It runs quoting systems, posts bids and asks on an exchange order book, manages inventory and risk actively, and commits contractually to a spread, a depth, and an uptime. It is a service relationship with obligations, reporting, and a termination clause.

A liquidity provider, in the sense most common in crypto today, is anyone who deposits assets into an automated market maker pool. There is no quoting, no discretion, and no commitment. The smart contract prices trades by formula and the depositor earns a proportional share of fees. It is capital allocation, not a service.

Both produce something a buyer can trade against. What differs is control, cost structure, venue coverage, and who bears which risk.

On a centralised exchange, trades match against resting limit orders. A market maker's job is to keep enough of those resting orders present, on both sides, close enough to the mid price that arriving flow can execute without moving the market. When volatility rises the desk widens; when inventory skews it adjusts to attract offsetting flow.

This is discretionary work, and it is why the mandate is written in numbers. Spread, depth within defined bands, uptime, per venue. It is also why the desk carries inventory risk: it will be bought from as a price falls and sold to as it rises, and managing that exposure is the actual craft.

Centralised order books remain where most institutional flow arrives, which is why a token with meaningful centralised listings almost always needs an active quoting arrangement regardless of how deep its on-chain pools are.

An AMM holds a pool of two assets and prices any trade by the ratio between them. Buying pushes the ratio, and therefore the price, in one direction; selling pushes it back. Depositors earn a share of fees proportional to their contribution.

The defining cost is divergence loss, often called impermanent loss. When the market price of the pooled token moves away from the ratio at the time of deposit, arbitrageurs rebalance the pool at the depositor's expense. Fees may or may not cover it. On a volatile small-cap token, frequently they do not.

Concentrated liquidity designs let a provider allocate capital to a specific price band, which improves efficiency substantially but converts a passive position into one requiring active range management. Ranges that are left unattended after a price move stop earning entirely.

A market making mandate has a visible price: a monthly retainer, or a loan of tokens with options attached. The retainer is a predictable operating cost. The loan structure looks free and usually is not, because it transfers float and upside in a way that only becomes visible in outcome.

Pool provision has no invoice, which is why it is often described as cheaper. Its cost is divergence loss plus the opportunity cost of capital locked in the pool, and for a token that trends in either direction that cost can exceed a retainer comfortably. The difference is that it appears in the treasury's position rather than in an expense line.

The honest comparison sets the modelled cost of each against what it delivers: pool liquidity gives permissionless access at every price with no counterparty; a mandate gives tight quoting and real depth where institutional flow actually arrives.

An on-chain-native token with no centralised listing and a community-held float is usually best served by a well-sized protocol-owned pool position, managed with attention to range rather than deposited and forgotten. Paying a monthly retainer at that stage buys little.

A token with centralised listings is in a different position. Venues impose liquidity obligations as a condition of listing and enforce them, and the buyers who matter at that stage will not enter a book they cannot exit. That requires an active mandate with contractual spread and depth commitments.

Most tokens with any traction end up running both, and that is the correct answer rather than a compromise. The pool provides permissionless base liquidity; the mandate provides quoted depth where size trades.

With a mandate, the issuer holds a contract and can measure performance, withhold payment, and terminate. The risk is counterparty behaviour: a desk that underperforms, or a loan structure whose options create incentives misaligned with the treasury.

With a pool, there is no counterparty to underperform and nothing to enforce, but also nothing to adjust when conditions change other than the position itself. The risk shifts from behaviour to market: divergence loss, range drift, and in poorly audited venues, contract risk.

For a DAO or a treasury with public accountability, that distinction is often decisive. A pool position is visible and self-explanatory on chain; a mandate requires disclosure, reporting standards, and a governance process to be defensible.

Where a token runs pools and a mandate together, define the boundary explicitly. The mandate should cover named centralised venues with numeric obligations; the pool strategy should cover named chains and pairs with a sizing and range policy. Without that boundary, issuers pay a desk to quote venues where the pool was already doing the work.

Report the two together. A monthly view showing spread and depth per centralised venue alongside pool depth, fee income, and divergence gives a treasury the whole liquidity picture in one place, and makes it obvious when one side of the structure is carrying the other.