
How we built Surflux on Sui, and why it had to exist
Surflux started from a very practical problem. Building applications on Sui Network felt faster at the execution layer than anything we had touched before, but slower everywhere else. Not because Sui lacked capability, but because the data surface was fragmented. JSON-RPC exposed raw primitives, gRPC exposed power with sharp edges, and anything beyond simple reads required teams to quietly spin up their own indexers, event listeners, and persistence layers. Everyone was rebuilding the same plumbing, slightly differently, burning time that should have gone into product.
That tension is what motivated Surflux. We were already deep in Sui, building NFT marketplaces, indexers, trading dashboards, and protocol-level tooling. Every project repeated the same pattern: parse objects, track ownership, resolve Kiosks, replay events, maintain checkpoints, recover from reorgs, and keep everything in sync. None of that work differentiated the product, yet all of it was required to ship.
Surflux exists to collapse that entire layer into infrastructure that feels native to how Sui actually works.
Starting from Sui’s mental model, not Ethereum’s
Sui is not account-based. It does not think in balances and logs. It thinks in objects, ownership, and explicit state transitions. That choice is what gives Sui its parallelism and performance, but it also means traditional blockchain APIs leak abstraction very quickly. Asking “what NFTs does this wallet own?” or “what changed after this transaction?” is not a single RPC call. It is a traversal problem across object graphs, ownership rules, and storage patterns.
The first design constraint for Surflux was simple: never fight Sui’s object model. Everything had to be built around it.
That decision shows up everywhere. Our NFT APIs do not just list objects by type. They resolve Kiosks, KioskOwnerCaps, listings, and nested ownership in one coherent response. Our event system does not stream vague logs. It streams concrete object changes, package events, and address-level activity, ordered by checkpoint and resumable by design. Our DeepBook support treats the order book as a first-class on-chain system, not as off-chain market data stitched together later.
Surflux is shaped by Sui’s reality, not by legacy expectations.
Indexed APIs as a production primitive
The first pillar of Surflux is indexed APIs. The goal was not convenience alone. It was determinism and speed.
Indexed APIs exist because raw blockchain interfaces optimize for correctness, not for developer time. When an app needs NFTs by owner, collection snapshots, holder distributions, DeepBook trades, or OHLCV candles, the expensive part is not the query itself. It is everything around it: decoding Move objects, stitching relationships, caching results, and staying in sync as the chain advances.

Surflux handles that entire lifecycle. Data is continuously indexed, normalized, and exposed through predictable REST endpoints that return exactly what applications need. This is why queries resolve in milliseconds, even when the underlying data spans thousands of objects or transactions .
The NFT Indexing API covers wallet ownership, collection views, holder analytics, and Kiosk-aware asset discovery. The DeepBook Indexing API exposes pools, order book depth, historical trades, and OHLCV data suitable for real trading interfaces and analytics dashboards. None of these endpoints require teams to understand how many internal calls or joins are happening underneath. That complexity is intentionally absorbed by the platform.
The click moment for many teams is realizing that indexing is not a feature. It is a long-running operational commitment. Surflux exists so teams do not have to make that commitment themselves.
Real-time as a first-class surface
The second pillar is Flux Streams. Indexed data answers questions about state. Streams answer questions about motion.
Most blockchain apps eventually hit the same wall. Polling feels fine until it does not. Latency grows, infrastructure cost grows, and edge cases pile up. On Sui, this is amplified because object changes can be frequent and granular. Missing one transition can break assumptions downstream.

Flux Streams were built to be boring in the best possible way. They use Server-Sent Events, a simple, well-supported HTTP standard, and they deliver ordered, checkpoint-aligned events directly to applications as they finalize on-chain. No WebSocket management, or custom replay logic. No guessing what changed.
Streams can be scoped precisely. You can follow a wallet, a Move package, a set of objects, or DeepBook pools. Events are persisted and resumable using event IDs, which means disconnects are not catastrophic.
This architecture matters because it lets teams build reactive systems without running reactive infrastructure. Trading dashboards, wallet notifications, protocol monitors, and game state synchronization all become simpler when the chain pushes truth instead of being constantly asked for it.
One platform, multiple surfaces
Surflux is intentionally not a single API. It is a platform with complementary surfaces that fit together.
Indexed APIs provide fast, queryable state. Flux Streams provide continuous change. Together, they remove the need for custom indexers, background workers, and fragile glue code. Teams can start with a REST call and later layer in real-time without rewriting their data model.
On top of that, Surflux embraces gRPC where it makes sense. For teams building deeper infrastructure or cross-language systems, gRPC provides type safety and performance aligned with Sui’s own direction. We do not replace it. We make it accessible within a broader, developer-first ecosystem .

The unifying principle is that Surflux does not force a single way of building. It gives teams the right abstraction at the right layer.
What Surflux has today, and what it enables
Today, Surflux provides production-grade NFT indexing, DeepBook indexing, and real-time streaming across the Sui network. Teams use it to power wallets, marketplaces, trading interfaces, analytics platforms, bots, and monitoring systems. Setup is intentionally lightweight. Accounts are free to start, API keys are generated instantly, and both indexed queries and streams can be tested directly from the dashboard .
What matters more than the feature list is what this unlocks. Builders stop thinking about checkpoints, reorgs, or schema drift. They think about product behavior. They stop maintaining brittle pipelines and start iterating faster.
Surflux is not trying to be everything. It is trying to be the part of the stack that disappears once it is working. When infrastructure fades into the background, teams ship better software.
That was the motivation from day one, and it continues to shape how Surflux is built on Sui.