Most blockchain explainers start with the token. Sui is more interesting if you start with the thing you actually own on it: an object. If you have read a generic "what is this L1" post before, this one takes a different route. We will look at why the object model changes how you design an app, what kinds of applications that model naturally produces, and what you need to know about connectivity before you write your first line of client code.
What Sui Mainnet Is Actually For
Sui Mainnet is the production network of an object-centric Layer 1. Instead of treating the world as a flat list of accounts with balances, Sui models state as discrete objects with owners. A coin is an object. A game character is an object. A digital collectible, a listing on a marketplace, a piece of an order book, a shared pool: each of those can be its own object with its own lifecycle.
That distinction is not cosmetic. Objects with a single owner can be used in transactions that do not need to touch shared state, which is why the design is associated with fast, scalable handling of assets, DeFi, gaming, and consumer-facing applications. Applications that move individual assets around a lot tend to feel natural here; applications whose logic is fundamentally a single global contract that everyone mutates may need more thought about how they split work into objects.
Execution and State, at a High Level
Sui programs are written in Move, a language built around resources that cannot be silently duplicated or dropped. On Sui, transactions are typically signed by an address and reference the objects they intend to consume or modify. Execution then produces updated objects, and the effects of that execution are what clients read back.
Several consequences follow for builders:
Objects have identity. You can ask a full node for a specific object by ID, or ask for batches of them, rather than reconstructing state from event logs alone.
Ownership matters. Owned objects and shared objects have different access patterns, and that shapes whether two users can transact without contending for the same state.
Indexing is a design decision. If your app needs to find "all objects of type X," that is not a single built-in query. You will either use the object and event query surfaces carefully or run your own indexer.
Application Patterns That Fit
A few patterns show up again and again. Wallets and exchanges care about balances and object ownership, plus a reliable stream of transactions so deposits and withdrawals can be credited quickly. Indexers and explorers combine historical ledger queries with live subscriptions to keep a searchable view of the network. DeFi teams read object and balance state, simulate a transaction against current state before submitting it, then stream protocol activity to drive dashboards and alerts. Games and consumer apps use objects for characters, inventory, and collectibles, and lean on real-time streams so the interface updates as the chain produces new activity.
In each of those, the same primitive questions come up: can I read a specific object; can I simulate before I sign; can I get a steady feed of new checkpoints, transactions, and events without hammering an HTTP endpoint in a polling loop.
Connecting: RPC and the Move to gRPC
This is where a lot of newcomers get tripped up. Sui has deprecated Full Node JSON-RPC in favour of gRPC and GraphQL. If you follow an older tutorial that calls sui_getObject or subscribes via sui_subscribeEvent, you are looking at a legacy path. Practical network RPC access still exists for compatibility, and an endpoint such as a public JSON-RPC URL is useful for early testing, but new integrations should be planned around gRPC.
The gRPC API is organized into typed services rather than a bag of method names. LedgerService covers reading objects, transactions, checkpoints, epochs, and events. StateService covers balances, coin info, dynamic fields, and owned objects. TransactionExecutionService handles executing and simulating transactions. SubscriptionService provides streaming checkpoints, transactions, and events, which replaces the polling patterns many builders used to write by hand. MovePackageService exposes package, datatype, and function information, and NameService and SignatureVerificationService round out the surface.
Two practical details are worth internalizing before you wire anything up.
First, use field masks. When you request a checkpoint or a transaction, you can specify which paths you want returned. A checkpoint read mask asking only for transactions returns a much smaller payload than a full object dump, and that directly affects how much data crosses the wire and how fast your client parses it. For high-volume indexers this is not a micro-optimization; it is the difference between a manageable pipeline and a memory problem.
Second, choose your transport deliberately. gRPC runs over HTTP/2 with TLS and supports streaming, so a single connection can carry both ordinary request-response calls and live subscriptions. JSON-RPC over HTTPS is simple and familiar, but it is the compatibility path, not the forward-looking one. A sensible migration is to keep legacy JSON-RPC calls working while you move each one to its typed gRPC equivalent: sui_getObject becomes GetObject, sui_getTransactionBlock becomes GetTransaction, suix_queryTransactionBlocks becomes ListTransactions, and the old subscription methods become the streaming service.
For teams that do not want to operate their own Sui full node, managed connectivity is the usual answer. OnFinality provides production-oriented Sui Mainnet RPC and gRPC access, including a gRPC host reachable with grpcurl, a public endpoint for initial testing, and API-key authenticated traffic for applications. That matters most during migration: you can point an existing JSON-RPC client at a compatible endpoint, verify behaviour, then progressively rewrite calls against the typed services without rebuilding your infrastructure from scratch.
A Quick Orientation Checklist
Before you build, answer these questions. Does your app read state as objects and balances, or does it need derived views that require an indexer? Do you need to simulate transactions against current state before signing? Is your data flow bursty request-response, or continuous streaming? Which calls are still legacy JSON-RPC, and in what order will you migrate them? And how will you keep payload sizes sane as your query volume grows?
Sui Mainnet rewards builders who take the object model seriously and treat connectivity as part of the design rather than an afterthought. Start with a clear picture of the objects your app owns and the streams it consumes, choose gRPC for new work while you migrate legacy calls, and the infrastructure side becomes far less mysterious.
Useful Resources:
• Practical network RPC
Useful Resources: