Sui is built for Move objects and parallel execution

Sui is a layer-1 blockchain - an independent network - where Move objects represent assets or data and separate objects execute in parallel. It uses delegated proof of stake, programmable transaction blocks and the SUI token to settle games, payments, trading and digital-asset workflows on one onchain state.

Address balances broaden the app entry path

Address balances make Sui applications easier to enter because apps can source fungible value without selecting individual coin objects.

One balance, two representations

Fungible value now has two interoperable forms: traditional Coin objects and one address-owned balance for each coin type. The TypeScript SDK’s coinWithBalance helper checks the address balance first, withdraws the requested amount when funds are available and otherwise selects coin objects. Developers retain object-based composition while removing routine coin selection from many user flows. An empty gas-payment array also lets a transaction draw SUI gas from the address balance when the gas price, budget and validity window are set.

Gas can sit with the app

Four payment strategies cover standard SUI gas, address-balance gas, app-sponsored gas and eligible zero-gas stablecoin transfers. A sponsored transaction separates the user signature from the gas payer’s signature, which supports onboarding through Enoki or zkLogin without requiring the user to hold SUI first. Eligible stablecoin transfers set both gas price and gas budget to 0, leave the gas payment empty and write no objects. Product design therefore starts with two concrete decisions: who funds execution and whether the flow must mutate object state.

Ethereum, Solana and Aptos reward different state models

Ethereum centers most app state on contracts and EVM storage, while Solana programs read and write declared accounts. Aptos also uses Move, yet its global state is organized around accounts and resources. Sui makes uniquely identified objects the transaction inputs, so disjoint object sets expose parallelism directly. This favors asset-heavy applications and composable item state; shared objects still require ordered consensus. Choose among these chains by runtime compatibility, state design, tooling and the contracts an application must call.

Games, markets and digital assets fit the object model

Sui’s object model suits applications where individual assets, positions and records must retain distinct identities and rules.

Game state becomes portable inventory

Game state maps cleanly to address-owned or object-owned assets. A sword, ticket or land parcel keeps a 32-byte object ID while its 8-byte version advances with each mutation. Move modules define who creates it, how it changes and which transfer rules apply. Kiosk supplies a standard trading and policy layer for digital assets, while Walrus stores large media blobs outside the execution state. The chain therefore carries ownership and rules without forcing every artwork or game file into a Move object.

Markets combine shared liquidity with atomic actions

Markets use shared objects for liquidity and order state that multiple users need to access. DeepBook provides an onchain central limit order book, while Pyth supplies price data to applications that require external market inputs. A programmable transaction block holds up to 1024 commands and commits them as one atomic transaction. One flow can split a coin, call a market, deposit the output and transfer the remainder; results from earlier commands become later inputs. If one command aborts, the block leaves no partial application effects, though gas is still charged.

Payments hide chain mechanics

Payment flows can use native USDC, sponsored transactions and Payment Kit components. zkLogin turns supported OAuth credentials into a Sui address through zero-knowledge proofs, while passkeys use WebAuthn authenticators. Enoki packages those onboarding primitives for applications. This stack matters in a realistic checkout: the customer approves a transfer, the merchant or app pays gas and the transaction records the resulting balance change without asking the customer to source SUI first.

Beyond these categories, Move objects represent credentials, memberships, tickets and regulated asset records. Seal adds programmable access control for encrypted data, and SuiNS supplies human-readable naming. The deciding question is whether the application benefits from portable state with explicit ownership rather than a single contract-owned database.

A local Move package is the cleanest first build

A first Sui build should move from Localnet to Testnet before any production deployment on Mainnet.

Build and test against Localnet

The toolchain exposes four environments: Localnet for isolated development, Devnet for new network features, Testnet for staging and Mainnet for production value. Start a Move package with the Sui CLI, define a struct whose first field is id: UID and grant the key ability so it can live as an object. sui move build checks compilation and sui move test runs package tests. Localnet gives fast repeatable state; Testnet then shows how the package behaves with validators, gas and network APIs.

Connect a client and inspect effects

A client built with the TypeScript SDK assembles a programmable transaction block, supplies object and pure-value inputs, chooses a signer and simulates the transaction before submission. Sui addresses and object IDs are 32 bytes, so interfaces should preserve the full value even when they display an abbreviated label. Query transaction effects through gRPC or GraphQL and record the digest, created objects and mutated versions. That record makes the next balance check or routine adjustment depend on settled state, not an optimistic screen.

Move packages should expose the smallest useful public interface and keep authority in explicit capability objects. Publish to Mainnet only after the transaction path, display data, event indexing and package-upgrade policy behave predictably on Testnet. The next decision is whether the app owns upgrade authority alone or distributes it through a governed process. The wider context is laid out in Sui walkthrough.

Ownership rules create both speed and design obligations

On the operational side, Sui ownership types determine who may use an object and whether consensus must order its mutations. The five forms are address-owned, immutable, consensus-address-owned or party, shared and wrapped. Address-owned objects suit private inventory; shared objects expose common markets; immutable objects provide read-only inputs. A party object has one address owner but still goes through consensus, giving builders a middle position between private control and unrestricted shared access.

Every object carries a 32-byte ID, an 8-byte version, a 32-byte transaction digest and a 32-byte owner field. Those references make stale state visible: a transaction that names an old owned-object version does not apply. Shared-state design carries a different constraint because operations touching the same mutable object need a common order and may enter an object-based local fee market. Partitioning a busy game, exchange or registry across independent objects preserves more parallel work.

Move adds four abilities - copy, drop, store and key - that determine which operations a type permits. Resource-like values omit abilities that would allow accidental duplication or disposal, while package code controls creation and mutation. Published package objects remain immutable; an UpgradeCap authorizes compatible successor versions under the selected policy. These rules improve clarity, but the application still needs tests for capability transfer, shared-object contention and upgrade governance before production use.

Objects reach execution through consensus and parallel scheduling

Declared object inputs let the network expose independent work and schedule it before Move execution begins.

The Sui execution path starts with a signed transaction and the exact object references it expects to read or mutate. Validators use delegated proof of stake, and a quorum requires more than two-thirds of total voting power; with 4 equally weighted validators, 3 form a quorum. Mainnet epochs last about 24 hours, after which validator membership, voting power and the reference gas price may change. The network has 2 node roles: validator nodes participate in consensus and full nodes validate history and serve state.

Mysticeti orders consensus traffic through a directed acyclic graph and needs 3 message rounds to commit blocks. Shared objects depend on that order, while transactions touching different shared objects execute across cores. Owned and immutable inputs expose independent paths without forcing unrelated state through one serial queue. Two transaction classes cover the network: user-submitted programmable transaction blocks and validator-submitted system transactions. Each user block remains atomic, so commands either produce one coherent set of effects or stop together. The final implementation choice is how finely to divide mutable shared state.

Gas combines computation, storage and a refundable component

Gas on Sui adds computation and storage charges, then subtracts any rebate created by deleted data. Computation starts at 1,000 units and aborts above the 5,000,000-unit ceiling; storage maps 1 byte to 100 units, with 99% initially rebateable and 1% retained. Worked example using hypothetical inputs: a 750 MIST computation price, a 75 MIST storage price, the fixed 1,000-unit bucket and 40 stored bytes cost 750,000 + 300,000 = 1,050,000 MIST, or 0.00105 SUI before any rebate.

Quick answers