DeepBook: Liquidity as Infrastructure

Access powerful APIs for real-time Sui blockchain data

*Sign Up Now*

Part I. DeepBook

Chapter 1-Liquidity has always been the real boss fight in crypto

If blockchains are about coordination at scale, liquidity is the medium that makes that coordination possible.

It’s the oxygen of markets: invisible when abundant, suffocating when scarce.

And yet each cycle ran into the same wall: liquidity was fragile and scattered. AMMs created markets, but didn’t replace real order books for price discovery. CEXs quietly proved that, when execution quality matters, liquidity aggregation wins.

Chapter 2 — Liquidity isn’t ‘an app’

One of the biggest mistakes we’ve made in Web3 is treating liquidity like it belongs to applications. For years, every protocol tried to build its own moat. One AMM per token, one marketplace per collection.

One silo per ecosystem.

In traditional finance, nobody confuses liquidity for an “app.” Nasdaq isn’t some dApp chasing yield farmers. It’s infrastructure, a base layer. Everyone (retail, brokers, market makers, funds) converges because that’s where depth lives. Price discovery doesn’t come from one-off apps, it comes from aggregation. DeepBook is that for Sui Network, a venue (embedded at the protocol layer) where all liquidity aggregates, and where builders don’t need to reinvent an exchange every time they launch something new.

Crypto never had that and this is the mistake Sui avoids. DeepBook flips liquidity from “app-specific” to “chain-native.”

So in the simplest terms, DeepBook is to digital assets what Nasdaq is to equities: a shared base layer of liquidity, open to every participant and natively enforced by the network itself.

Chapter 3 — Enter DeepBook

DeepBook is a native, on-chain central limit order book, not a standalone DEX competing for fees. You can see it as infrastructure and a core part of the Sui stack, as fundamental as consensus or storage.

Let me translate that.

When you trade on Binance or Coinbase, there’s a matching engine running on their servers. That engine decides whose buy order gets paired with whose sell order, at what price, and in what sequence. It’s fast, but you never see how it works under the hood. You trust the exchange to be fair.

DeepBook shifts this process on-chain. Matching isn’t delegated to a black box, it happens under consensus, every participant sees the same outcome. Settlement isn’t “eventual,” it’s final in under a second. And because Sui Network executes transactions in parallel, throughput isn’t capped by a single queue. It scales horizontally as demand grows.

If this sounds abstract, think of it this way: when you write a Move package on Sui, you’re defining the rules for how your assets live and evolve. DeepBook applies that same logic to trading, and orders are programmable objects, secured by the same execution model as everything else on the chain.

That’s why DeepBook feels less like a DEX and more like Nasdaq baked into the protocol. It’s not an app you choose to use, it’s a shared base layer for price discovery and liquidity.

Chapter 4 — What this unlocks for builders

In crypto, most teams have faced the same roadblock: you build your contract, deploy your app, and then realize you’re on your own for liquidity. That usually means launching your own pool, bribing users with emissions, or relying on fragile APIs that don’t scale. Liquidity becomes a side hustle, not the core of your product.

DeepBook changes the equation. Liquidity lives at the base layer, the same way execution (Sui), storage (Walrus), and privacy (SEAL) do. Instead of standing up your own exchange logic, you can plug directly into a venue that every other app is using.

Here’s what that looks like in practice:

• A game can let players swap assets instantly, without running a marketplace contract.
• A wallet can route trades natively, without relying on a centralized backend.
• A DeFi protocol can execute strategies on top of shared liquidity, instead of fracturing it into dozens of shallow pools.

How DeepBook turns every trade into a growth loop

Liquidity here doesn’t just sit passively. It compounds. Every new project that connects to DeepBook isn’t siphoning from a fixed pool, it’s adding activity that enriches the venue for everyone else.

It’s a flywheel:

• More apps → more orders → tighter spreads
• Tighter spreads → better execution → more users
• More users → thicker markets → more incentive for builders to plug in

Source: https://x.com/DeepBookonSui/status/1955620125949796633

Instead of liquidity silos fighting for survival, you get a shared engine that grows stronger with every participant. What starts as integration quickly evolves into a loop of compounding depth, the kind of loop that makes ecosystems unstoppable.

Chapter 5 — Where DeepBook sits in the Sui Network stack

As Aslan (@aslan_web3), co-founder of DeepBook, wrote when introducing DeepBook Margin:

“DeepBook launched nearly one year ago as Sui’s native central limit order book and public good. Its goal has been consistent: provide a foundational liquidity layer that any Sui DeFi application can integrate. Since launch, more than $6.1 billion in spot volume has been traded through DeepBook. Spreads have been compressed below one basis point, enabling best execution for wallets, aggregators, and protocols across the ecosystem.”

Now comes the margin upgrade. Orders with leverage route through the same liquidity pools as spot. Lending pools feed capital into the system, while liquidations are standardized and open to anyone. That design does two things at once: it deepens markets and it spreads participation. Traders get leverage, lenders get yield, builders get protocol-level incentives for distribution.

https://docs.sui.io/standards/deepbook-margin

The result is compounding. Liquidity is no longer just sitting in pools, it circulates, grows, and strengthens the entire network every time someone plugs in.

This is the part where the architecture starts to feel whole.

• Sui gives you the execution layer, parallel transactions, sub-second finality, and an object model that actually fits how assets move.
• Walrus takes care of storage, making data tamper-proof and verifiable at scale.
• SEAL locks down access, turning permissions into code instead of trust.
• Nautilus covers the jobs that don’t belong on-chain (heavy or private compute) while still anchoring proofs back on Sui.

DeepBook sits in the middle as the venue for price discovery and liquidity.

Part II. Building on DeepBook with Surflux

There is a predictable arc to building on Sui Network. You learn Move, you build your first package, and then the ground shifts. You cross from the clean world of modules and objects into the messy reality of everything that surrounds them: RPC calls, custom indexers, data pipelines, backend glue, databases, retry logic, pagination tricks, and the quiet fear that you’re rebuilding something a dozen teams before you have already built.

It’s the cost of working directly with a chain designed around explicit state. Sui Network gives you clarity at the protocol level, and that clarity demands structure at the infrastructure level. Without it, every team ends up writing their own indexing layer, their own event processors, their own ad-hoc databases, and their own cleanup scripts. The pattern repeats so consistently that it feels like an extension of the development process rather than a separate burden.

Instead of treating indexing, data access, and real-time event handling as a tax you must pay before building anything meaningful, Surflux turns them into a single, stable surface you can build on from day one. One API, millisecond queries and guaranteed-order streams. Everything shaped and ready, without the overhead of running your own indexing service.

This is the point where the development path smooths out. Instead of engineering your infrastructure, you get to return to what you meant to build in the first place. And once you see this workflow from the right vantage point, the rest of the Surflux API suite starts to make intuitive sense.

1. DeepBook Flux Streams — wiring your app directly into the book

DeepBook Flux Streams are the closest thing you get to plugging your application straight into the DeepBook matching engine, without ever touching raw RPCs or running your own infra. They take DeepBook’s on-chain CLOB and expose it as a live, ordered event feed that any trading interface, bot, or analytics stack can subscribe to.

Under the hood, they use Server-Sent Events (SSE). In practice, that means one long-lived HTTP connection and a continuous stream of JSON messages that represent finalized Sui events, delivered in checkpoint order and typically within one to two seconds of being finalized on-chain. There is no polling loop, no custom socket server, no indexer to keep in sync.

What you actually get out of DeepBook Flux Streams

DeepBook Flux Streams are specialized on a single job: broadcasting market events for DeepBook pools. They currently expose two core event types:

• Live Trades — every fill that happens on a pool, with price, traded quantity, fee data, and order identifiers. This is the tape. It lets you build UIs that show the flow of trades in real time, bots that react to execution, and analytics pipelines that track volume, participation, and microstructure as it unfolds.
• Order Book Depth — updates to bid and ask levels for DeepBook pools: price levels, aggregated sizes, and order counts. This is the ladder. It underpins your depth chart, best bid/ask, spread calculations, and any logic that relies on a current, accurate picture of liquidity.

Those two together are essentially the minimum viable “market feed” for a professional-quality interface. Everything from a simple DEX UI to a quant research stack can be built on the combination of live trades and live depth.

Why it matters for builders

Most infra in crypto stops at “you can query the data.” DeepBook Flux Streams focus on “you can live on this data.”

A few properties are doing real work for you here:

• Finalized events only. You are reacting to on-chain truth, not mempool guesses. That is ideal for anything where correctness matters more than shaving off a few hundred milliseconds.
• Guaranteed ordering. Events are delivered in checkpoint order. If your app applies them sequentially, your local view of the market will never drift out of sync due to reordering. For matching logic, PnL, and risk engines, that’s the difference between “occasionally wrong” and “solid under load.”
• Persistence and replay. Every event is stored and addressable via last-id, so you can replay from 0, resume from a saved event ID like 1755091934020-0, or jump straight to the live tail using $. That gives you exactly-once semantics across deploys, restarts, and transient failures without writing your own log storage layer.
• One client per API key. Flux Streams enforce one active SSE connection per key. That constraint simplifies the problem: keep a single backend consumer, then fan out internally via your own pub/sub, sockets, or message bus. No fan-out duplication at the edge, no weird race conditions where two clients compete to read the same stream.

From a systems point of view, DeepBook Flux Streams let you treat the Sui/DeepBook pair as a single, global event log for trading data, already filtered to the pools you care about, already ordered, already durable.

How you use it

If you are building a DeepBook-powered trading surface, the pattern looks like this:

• Your backend opens a single Flux Stream connection configured for the relevant DeepBook pools (for example, SUI_USDC, DEEP_SUI).

• As Live Trades events arrive, you feed the tape, update per-pool metrics (volume, last price, rolling VWAP), and trigger any strategy logic that reacts to executions. As Order Book Depth events arrive, you keep an in-memory order book updated at the level-2 or level-3 detail your UI needs.
• You persist lastEventId on every processed event. If the connection drops or you redeploy, you reconnect with last-id=<saved> and continue exactly where you left off.

The net effect is that DeepBook becomes less “a thing you occasionally query” and more “a stream your product lives on.” You can layer in your own logic on top of it: smart routing, cross-pool execution, risk checks, internal crossing, analytics, you name it. The primitives stay simple, the behavior you build on top can be as complex as you need.

2. DeepBook Indexing API — structure, snapshots, and history

If DeepBook Flux Streams are the motion layer, the DeepBook Indexing API is the shape layer. It gives you indexed, queryable access to DeepBook’s state and history over plain REST, without running your own indexer or touching RPCs.

You use it for three things:

1. Discovering and understanding pools
2. Hydrating your UI and systems with clean snapshots
3. Running historical and analytical queries without building your own data warehouse

Open Dashboard

The four DeepBook endpoints that matter

The API is intentionally small; each endpoint is doing a very specific job.

• Get Pools — your entry point. Returns all DeepBook pools with pool IDs, base/quote assets, decimals, and key parameters. This is what you use to render market lists, pick routing paths, and bootstrap your internal mapping between token symbols and DeepBook pool identifiers.
• Order Book Depth — a point-in-time snapshot of current bids and asks for a given pool, with price levels, aggregated size, and order counts. Perfect for first page load, periodic reconciliation, or non-real-time analytics where you do not need the full streaming feed.
• Recent Trades — historical trade executions for a pool, with price, quantity, and timestamps. This powers your trade history views, recent activity widgets, and any calculation that needs execution data in a time window (like VWAP or volume profiles).
• OHLCV — candlestick data (open, high, low, close, volume) over multiple timeframes, built for charting and technical analysis. Use it to feed your charts without materializing your own candles from raw trades.

Under the hood, Surflux handles keeping this index in sync with the chain so you do not have to decode events, track checkpoints, or manage reorgs. Queries hit a stable, indexed view instead of a shifting RPC surface.

Where it fits in a DeepBook-powered stack

For most teams, the DeepBook Indexing API becomes the first touchpoint when the app loads:

• You call Get Pools to populate the list of markets and their metadata.
• You call Order Book Depth for the default pool to render the initial ladder.
• You call Recent Trades to backfill the last N trades in your tape.
• You call OHLCV to draw a chart with enough history to be useful.

Those calls return in milliseconds, give you a structurally correct picture of the market, and make sure your UI feels fully formed the moment it loads. Then DeepBook Flux Streams take over and keep everything fresh.

For more advanced use cases, the Indexing API also becomes a stable source of truth for:

• backtests and simulations for strategies, using Recent Trades and OHLCV
• monitoring and alerting systems that audit spreads, volume, or depth over time
• off-chain risk engines that periodically reconcile their internal state with indexed on-chain data
• portfolio analytics tools that need to understand liquidity and execution quality across pools

The difference is that you never manage the underlying data pipeline. Surflux runs and hardens it; you consume it.

3. A third (DeepBook) pillar is coming

• DeepBook Flux Streams give you the motion of the market.
• The Indexing API gives you the structure and the history.

But there is one more layer every serious trading venue eventually needs: a way for builders to work directly with positions, inventory, and on-chain risk without stitching together half a dozen subsystems.

We’re not announcing anything until it’s live and battle-tested, but the direction is clear. The same way Surflux unified real-time data and indexed state into a single surface, the next module extends that surface into the parts of DeepBook that sit above raw execution. Think of it as surfacing the higher-order mechanics that every exchange, aggregator, or strategy engine ends up rebuilding on their own.

The goal is simple: if DeepBook is the liquidity layer of Sui, Surflux should be the place where builders interact with all of it, consistently, without reinventing the rails. We’ll share more when we’re ready. For now, just know that the foundation you’re building on is about to get a new load-bearing component.

4. How these two pieces change the developer’s job

If you look at DeepBook purely as a protocol, the problem it solves is aggregation of liquidity. But from a builder’s perspective, aggregation is only half the story. Access is the other half.

DeepBook Flux Streams and the DeepBook Indexing API together turn that access into something very close to “plug-and-build”:

• You do not design a data plane; you subscribe to one.
• You do not maintain an indexer; you query an indexed API.
• You do not chase RPC quirks; you work against stable, documented surfaces.

That frees up time and attention for work that actually differentiates your project: execution strategies, UX, routing, inventory management, products around liquidity instead of scaffolding for liquidity.

For the Sui Network dev community, the forward-looking implication is simple: if DeepBook becomes the default liquidity layer on Sui, these two pieces are the standard interface into it. UIs, aggregators, wallets, margin systems, structured products, and even games can converge on the same primitives:

• DeepBook Flux Streams for real-time market motion
• DeepBook Indexing API for structure, snapshots, and history

Everything else you build (risk, routing, experience) stacks on top of that.

Access powerful APIs for real-time Sui blockchain data

*Sign Up Now*