Crypto Market Making Services: Why the Engineering Contract and the Liquidity Provider Contract Are Different Deals
September 8, 2026
When a token issuer or exchange operator starts researching crypto market making services, it's easy to assume it's a single relationship: you hire a firm, and that firm both builds the connection and supplies the liquidity. In practice, these are usually two separate deals with two separate counterparties, and understanding that split early saves a lot of confusion later. As we explain on our about page, we don't provide liquidity, make markets, execute trades, or advise on crypto-assets, we build the engineering layer that connects an operator to whichever liquidity provider they choose.
Two Different Jobs Wearing the Same Label
"Market making" describes an activity: continuously quoting both sides of a market to keep it liquid, managing inventory risk, and adjusting spreads as conditions change. That activity is performed by a liquidity provider, a firm or desk that takes on capital risk and actually places the quotes. Separately, there is the engineering work required to connect an exchange or token to that liquidity provider in the first place: routing logic, API integrations, monitoring dashboards, and the controls that let an operator see what's happening across their liquidity connections, the kind of routing, controls, and monitoring infrastructure we build as a standard engagement. These are genuinely different skill sets, different risk profiles, and, in most serious engagements, different contracts with different parties.
Why This Distinction Gets Blurred
The confusion is understandable. Marketing language across the industry often bundles "market making services" as if it's one product, and some firms do operate on both sides at once. But a firm that positions itself purely as a software engineering provider will typically build the technical integration, the routing, the controls, the monitoring surface, while leaving the actual liquidity relationship to be appointed and contracted separately by the operator. In that model, the engineering firm is not the liquidity provider. It builds the plumbing that connects an exchange or token program to whichever liquidity provider the operator chooses to work with, per our services page.
What the Engineering Side Actually Involves
The technical work in a liquidity integration covers routing logic that directs order flow appropriately, API connections into the liquidity provider's systems, monitoring that shows fill rates, spread behavior, and latency in something an operator can actually watch day to day, and the controls layer that lets an operator pause, adjust, or redirect connections without needing to renegotiate the underlying commercial relationship every time something needs to change. None of this requires the engineering firm to hold capital, take inventory risk, or place quotes itself.
What the Liquidity Relationship Involves
The commercial side, actually providing quotes and managing inventory, sits with a separate liquidity provider that the operator selects and contracts with directly. That relationship carries capital risk, spread economics, and inventory management decisions that are fundamentally different from a software build. It typically comes with its own service-level agreement covering things like minimum quote depth, maximum spread, and uptime, terms that are commercial and financial in nature, not engineering deliverables. We cover what exchange operators should brief their engineering team on when setting this relationship up.
Why Keeping These Separate Is Actually Useful
Splitting engineering from the liquidity relationship gives an operator more flexibility, not less. If a liquidity provider relationship needs to change, whether because terms aren't working or because the operator wants to add a second provider, the underlying technical integration doesn't need to be rebuilt from scratch if it was designed as a general-purpose connection layer rather than something hard-coded to one provider's API quirks. It also creates clearer accountability: if a quote is too wide, that's a conversation with the liquidity provider; if a connection is dropping data or the monitoring dashboard is wrong, that's an engineering conversation.
What to Ask When Evaluating "Market Making Services"
Before signing anything described as crypto market making services, it's worth asking plainly: is this firm the actual liquidity provider taking on quote and inventory risk, or is it building the technical connection to a liquidity provider that will be contracted separately? Who holds capital risk in this arrangement? And if the liquidity relationship changes down the line, does the technical integration need to be rebuilt, or was it designed to be provider-agnostic from the start? Clear answers to these questions upfront make it much easier to structure two clean, appropriately-scoped contracts instead of one confusing one.