You are evaluating L1s for a new project. Sui keeps showing up - 10.6 billion transactions processed, sub-second finality, a programming language that prevents asset bugs at compile time. But most "What Is Sui" content is written for token buyers, not builders. It covers price predictions and ecosystem hype while skipping the technical details that actually determine whether Sui fits your architecture.
Sui launched on May 3, 2023, built by Mysten Labs - a team of former Meta engineers who worked on the Diem blockchain project. The network now has 954 monthly active developers with 219% developer growth year over year. This guide covers what matters for development: the object model that enables parallel execution, Sui Move's resource-oriented type system, Programmable Transaction Blocks, consensus mechanics, and how to connect to Sui infrastructure.
If you are building something and need to understand Sui's design trade-offs, start here.
The Object Model: What Makes Sui Different
Every blockchain needs a way to represent state. Ethereum uses an account model where assets are entries in a contract's global mapping - your ERC-20 balance is a number inside a contract's storage, not something you "own" directly. Solana uses a flat account model where programs and data live in separate accounts. Sui takes a different approach: everything is an object.
Every object on Sui has a unique ID, a version number, and an owner. An NFT is an object. A coin is an object. A smart contract module is an object. This is not a conceptual abstraction - it is the literal storage model. The Sui runtime tracks and resolves objects individually rather than reading from shared global state.
Five Ownership Types
Objects on Sui fall into five ownership categories, and each category has different implications for how transactions execute:
| Ownership Type | Description | Consensus Required? |
|---|---|---|
| Address-owned | Belongs to a specific Sui address | No - fast path |
| Shared | Accessible by any transaction | Yes - Mysticeti ordering |
| Immutable | Frozen, cannot be modified | No - read-only |
| Wrapped | Contained inside another object | Inherited from parent |
| Object-owned | Owned by another object, not an address | No - fast path |

Transactions on Sui must declare their object inputs upfront. Before execution begins, the runtime knows exactly which objects a transaction will touch. This enables static conflict detection - the system can determine at submission time whether two transactions conflict, without running them.
The Owned-Object Fast Path
Transactions that touch only address-owned or immutable objects bypass consensus entirely. The object owner signs the transaction, validators verify the signature and object versions, and finality is near-instant. No ordering protocol needed.
Consider transferring an NFT. The NFT is an owned object. The sender signs a transaction moving it. No global state is touched, no other transaction can conflict with this operation, and no consensus round is required. This differs from Ethereum, where even a simple token transfer must be ordered relative to every other transaction in the same block.
Shared objects - things like a DEX's liquidity pool that multiple users interact with concurrently - do require consensus ordering through Mysticeti. Finality is still fast (around 480ms) but these transactions are serialized. The design implication: minimize your shared object surface area for maximum throughput.
Move: Resource-Oriented Smart Contracts
Move was created for Meta's Diem project as a language specifically designed for digital asset management. Sui Move is a modified variant with meaningful differences from the original specification and from Aptos Move.
The core distinction from Solidity: resources in Move cannot be copied or dropped unless the programmer explicitly grants those abilities. A token type that lacks the copy ability cannot be duplicated. A type that lacks drop cannot be silently discarded. Double-spending is a compile-time error, not a runtime check that relies on correct storage slot management.
The Four Abilities
Move's type system controls what you can do with a struct through four abilities:
key- The struct can serve as a Sui object with a globally unique IDstore- The struct can be embedded inside other objectscopy- The struct can be duplicateddrop- The struct can be discarded without explicit destruction
Asset types intentionally lack copy and drop. The compiler enforces this. You cannot write code that accidentally duplicates a coin or silently drops an NFT - the program will not compile.
public struct NFT has key, store {
id: UID,
name: String,
url: Url,
}
This NFT struct has key (it is a Sui object) and store (it can be embedded in other objects), but no copy or drop. The compiler guarantees every instance is either transferred, wrapped in another object, or explicitly destroyed through a custom function. No other outcome is possible.
Entry Functions and Module Initializers
Functions marked entry are callable directly from transactions but not from other Move modules. This pattern prevents composability where it is not wanted - an entry function that claims a reward, for example, cannot be called by another contract mid-execution.
The init function runs exactly once when a module is published. It is the constructor for your package, used to create admin capabilities, initialize shared state, or mint a fixed supply of tokens at deploy time.
Sui Move vs Aptos Move
Both chains use Move, but the code is not portable between them. Sui uses object ID-keyed storage where objects are first-class citizens with unique identifiers. Aptos uses account-based global storage following the original Move specification more closely. Different storage models, different standard libraries, different transaction semantics.
Programmable Transaction Blocks: Atomic Composability
Programmable Transaction Blocks (PTBs) solve a common pain point in blockchain development: multi-step operations that require multiple transactions, each with its own gas cost and failure risk.
A PTB composes up to 1,024 individual operations into a single atomic execution unit. Available commands include splitCoins, mergeCoins, transferObjects, moveCall, makeMoveVec, and publish/upgrade. The results from one command feed directly into subsequent commands within the same block. If any command fails, the entire block rolls back.
This composability happens at the transaction level, not the smart contract level. You do not need to deploy a custom router contract to split coins, call three different protocols, and transfer results - all in one transaction. A PTB handles this natively.
import { Transaction } from '@mysten/sui/transactions';
const tx = new Transaction();
// Split 1000 MIST from the gas coin
const [coin] = tx.splitCoins(tx.gas, [1000]);
// Transfer the new coin to the recipient
tx.transferObjects([coin], recipientAddress);

This example splits a coin from the gas object and transfers it to a recipient in a single atomic transaction. In practice, PTBs handle much more complex flows: minting an NFT, listing it on a marketplace, and transferring the proceeds - all in one block, one gas payment, one confirmation.
Because the entire block executes as a single transaction, you pay gas once instead of per-operation, and atomicity means partial execution never leaves your application in an inconsistent state.
One limitation: PTBs do not support loops. Iterative logic that processes a dynamic number of elements needs to live in a Move package.
Consensus: From Bullshark to Mysticeti
Sui has shipped three consensus iterations since launch, each cutting finality latency. Understanding the progression explains both the current performance numbers and where the network is heading.
The original design paired Narwhal (a DAG-based mempool) with Bullshark (an ordering protocol). Narwhal handled data availability and dissemination while Bullshark established transaction ordering. This worked, but required 3 round trips per commit, which set a floor on achievable finality times.
Mysticeti (July 2024)
Mysticeti replaced the Narwhal/Bullshark stack with an uncertified DAG-based consensus protocol. The critical improvement: 3 message delays instead of 3 round trips, dropping median finality to around 480ms. Validators propose blocks that reference previous blocks in a DAG structure, and the protocol commits blocks once enough validators have built on top of them - without requiring explicit certification rounds.
Mysticeti v2 (November 2025)
The latest upgrade merged validation into the consensus path and introduced the Transaction Driver - a mechanism that lets clients submit transactions to a single validator instead of broadcasting to all validators. Implicit acceptance votes reduced message overhead further. The results: 200,000-300,000 TPS in testing environments and a 35% latency improvement for geographically distributed validators, particularly in Asia.
How Sui Compares
| Metric | Sui | Solana | Aptos |
|---|---|---|---|
| Data Model | Object-centric | Account-centric | Account-centric (Move) |
| Parallelism | Static (compile-time) | Dynamic (runtime locking) | Optimistic (Block-STM) |
| Consensus | Mysticeti DAG BFT | Tower BFT + PoH | Jolteon BFT |
| Finality | ~480ms | ~400ms optimistic / ~12.8s full | Sub-second |
| Smart Contracts | Sui Move | Rust (BPF) | Core Move |
| Monthly Active Devs | 954 | Largest | 465 |

Sui's static parallelism approach means the runtime knows which transactions can execute concurrently before execution begins. Solana detects conflicts at runtime through account locking. Aptos uses optimistic execution with Block-STM, re-executing transactions that turn out to conflict. Each approach has trade-offs in throughput, latency, and developer complexity.
The Sui Developer Stack and Toolchain
Sui provides a complete toolchain for building, testing, and deploying applications.
The Sui CLI installs via suiup and handles Move compilation, unit testing, package publishing, and direct network interaction. It fills the same role as Foundry in the EVM ecosystem - the primary tool you interact with during development.
On the client side, the TypeScript SDK (@mysten/sui) is the most widely used library, with modular packages for client connections, transaction building, keypair management, and BCS serialization. The Rust SDK (sui-rust-sdk) targets backend infrastructure and is gRPC-native with no JSON-RPC support.
Two features stand out for user onboarding. zkLogin maps OAuth sign-ins (Google, Facebook, Twitch) to Sui addresses using zero-knowledge proofs, eliminating seed phrases and wallet installation. Sponsored transactions let developers pay gas on behalf of users. Combined, these enable applications where users interact with the blockchain without knowing it exists.
The ecosystem includes Walrus, a decentralized storage protocol ($140M raised, mainnet launched March 2025, approximately 833TB capacity) for blob storage with native Sui integration. DeepBook provides an on-chain central limit order book with over $8.7B in cumulative volume and 10M+ users.
Sui runs four network environments: localnet for development, devnet (weekly state wipes), testnet (stable with a faucet), and mainnet. The public RPC endpoint has a rate limit of roughly 100 requests per 30 seconds - sufficient for experimentation but not for production applications.
Connecting to Sui: The gRPC Migration
If you are building on Sui, this section has a hard deadline attached.
Sui is sunsetting JSON-RPC with a hard cutoff of July 31, 2026. After that date, the two replacement APIs are gRPC and GraphQL RPC. For a broader explanation of how RPC works in blockchain, see the companion guide.
gRPC
gRPC uses Protocol Buffers for serialization - binary payloads approximately 70% smaller than equivalent JSON. It runs over HTTP/2 with multiplexed streams, supports server-side streaming for real-time data, and provides strongly typed service definitions. This is the recommended path for high-performance backends, indexers, and infrastructure tooling.
Available gRPC services include Ledger, Live Data, Transaction, Move Package, Subscription, and Signature Verification. Each service maps to a set of strongly typed RPCs that replace their JSON-RPC equivalents.
grpcurl -H "x-api-key: YOUR_API_KEY" \
api-sui-mainnet-full.n.dwellir.com:443 \
sui.ledger.v1.LedgerService/GetLatestCheckpoint
GraphQL RPC
GraphQL collapses multiple calls into single queries with precise field selection. If your frontend needs an object's type, owner, and most recent transaction in one request, GraphQL handles that without over-fetching. Responses arrive as UI-ready JSON. This is the recommended path for frontends and applications that need flexible querying.
Infrastructure Considerations
Dwellir is one of the few infrastructure providers with full gRPC support for Sui, covering all six service endpoints. Pricing follows Dwellir's standard flat-rate model at $1.96 per million calls with no compute-unit multipliers or method-based surcharges. For detailed endpoint configuration, see Dwellir's Sui RPC documentation.
The migration timeline is tight. If your application currently uses Sui's JSON-RPC, the transition to gRPC or GraphQL needs to happen before July 31, 2026. Testing against the new APIs on testnet now prevents surprises on mainnet later. For a comparison of providers supporting the new APIs, see Best Sui RPC Providers.
Getting Started with Sui Development
Install the Sui CLI with suiup and work through the Sui Move Intro Course for a structured path from zero to deploying your first package. Request testnet tokens via the Discord faucet to deploy and test without cost.
For anything beyond local experimentation, connect to a dedicated RPC endpoint. The public endpoint's 100 requests per 30 seconds is too restrictive for iterative development, and the rate limit will interrupt your workflow during testing. Sign up for a Dwellir account to get a dedicated Sui endpoint without rate-limit friction.
The clock is ticking on Sui's JSON-RPC sunset. If you are starting a new project on Sui, build against gRPC or GraphQL from day one - there is no reason to adopt an API that expires in months. If you are migrating an existing application, start testing against the new endpoints on testnet now. Contact the Dwellir team to set up Sui gRPC access, or check the Sui endpoint page for configuration details.


