Swap SUI

How the Sui Network Works: Objects, Validators and Transactions

Sui is a layer 1 blockchain with its own validators, gas asset and Move-based smart contracts. Its distinctive design is that assets and application state are represented as objects with explicit ownership. That detail matters more to a user than a headline transactions-per-second number: it affects which transactions can execute independently, what a wallet signs and why an explorer shows object changes. This guide stays with network behavior; see what Sui and SUI mean for the short introduction.

Golden coin cube connected to a green data stream

Why ownership changes the execution path

An object may be owned by an address or shared. A transfer of an owned SUI coin changes who owns that object. A trading pool, by comparison, is shared state that multiple users can access. Transactions that do not compete for the same input can execute in parallel; shared-object transactions require an agreed order. The transaction lifecycle documentation describes execution through consensus, while consensus documentation explains ordering for shared objects.

This is not a promise that every transfer is faster than every DeFi trade. Network load, contested objects, wallet broadcast and an app’s own processing can all affect the time a user sees. A centralized exchange can add a separate deposit-crediting period after the onchain transaction is final.

Owned objects and shared objects in everyday use

An owned object can be controlled by an address; a shared object is available to multiple users under the rules of its Move package. Sending a coin affects your owned inputs and creates a new ownership outcome. A swap touches shared liquidity state, so other users' transactions may contend for that same pool. This explains why “parallel execution” is conditional on independent inputs rather than a universal property of every transaction.

What does finality mean for a receiving service?

Finality describes the network's accepted transaction outcome. A receiving exchange has a separate ledger and may apply asset and minimum-deposit rules before it credits its customer. Check both records: the onchain digest for what happened on Sui, and the exchange order for whether that transfer matched its instructions. An explorer's success indicator cannot correct a wrong destination or unsupported token type.

Follow one transaction from signature to explorer

Suppose you send native SUI to a friend. Your wallet constructs a transaction containing the recipient, amount, input coins and gas budget. You review and sign it, then the request is submitted. Validators process it, and the result includes a transaction digest, status, gas used and changes to affected objects. An explorer lets you check the digest and the recipient address independently of the sending app.

For a swap inside a Sui DeFi protocol, the same wallet review may show calls to a package and changes to shared pool objects. Read the displayed assets and permissions, not only the app’s large “confirm” button. If a wallet shows a pending signature but no digest, the request may not yet have been submitted. If an explorer shows success, a slow receiving platform may simply be waiting to credit it.

A transaction can be inspected through a short sequence:

  1. Compare the signed request with the intended recipient or app action.
  2. Copy the transaction digest from your wallet or sender.
  3. Search the digest in a Sui mainnet explorer and inspect the success status and object changes.
  4. Compare the actual gas charged with the wallet estimate and the recipient address with your order.
  5. If the onchain record succeeded but a platform shows nothing, contact that platform with the digest and order ID, never your seed phrase.
Explorer fieldWhat it answersWhat it cannot prove
Transaction digestWhich transaction was submittedWho controls the receiving account
StatusWhether network execution succeededWhether a custodian credited a deposit
Balance/object changesWhich assets and objects changedThat an app's future behavior is safe
Gas usedNetwork cost of this transactionA fixed fee for all future swaps

Gas, storage and what a wallet must hold

Gas is paid in SUI, including when you interact with another Sui token. The final amount depends on computation and storage effects, so a fee quoted for a simple transfer is not a universal rate for swaps or NFT operations. Sui also uses a storage fund: storing data has a cost, and deleting eligible data may produce a storage rebate. The Foundation’s storage-fund explanation shows why a transaction can list both storage charges and rebates.

Keep a spendable SUI balance separate from an amount you intend to stake or exchange. If an exchange asks for an arrival amount, its service fee and quoted payout are separate from the Sui gas shown by your sending wallet. For an executable route, exchange SUI to USDT with the source and payout networks checked in the order form; the exchange overview lists other routes.

Abstract red and blue digital network structure

Sui and Solana: compare the actual models

Both networks support applications that use parallel execution where transactions do not conflict. Solana programs work with accounts declared for a transaction; Sui Move uses objects and explicit ownership semantics. The Sui documentation’s comparison for Solana developers explains the difference in more detail. Neither model alone determines a real-world app’s reliability or end-to-end user latency.

Treat claimed TPS as a benchmark with a specified workload and measurement window. A test of nonconflicting transfers is not a live average for a congested shared pool. For practical comparison, inspect a live explorer’s recent transaction digests and a status page for incidents, then test the particular app and operation you need. See Sui apps by category before choosing one.

Why TPS headlines need context

A benchmark can count simple transfers over a defined run; live traffic mixes transfers with shared-object app operations. The unit of measurement, tested hardware, workload, duration and whether the number represents a peak all matter. Sui's design allows independent transactions to execute in parallel, but an application with a contested shared object has its own bottleneck. To evaluate a payment, look at the transaction's real timestamp, explorer status and the destination platform's crediting process rather than projecting a benchmark onto a specific order.

For reliability, distinguish a wallet interface failure from a network incident. A wallet might be unable to reach its chosen RPC while an explorer using another service still works. A protocol's frontend can also be unavailable although the chain continues producing checkpoints.

Verify the network and avoid chain mix-ups

Sui mainnet, testnet and devnet are distinct environments. Testnet SUI is not a transferable mainnet balance. When a wallet connects to an app, verify that both show the same environment. To inspect a payment, use a Sui explorer linked from official Sui resources, paste its digest and compare sender, recipient, asset and status. Do not infer an outage from a single wallet interface; compare the explorer, another RPC interface and the network’s official channels before drawing that conclusion.

FAQ

No. Explorer success establishes the onchain result. A receiving platform may still run asset, network, amount or confirmation checks before crediting its account.

No. Sui is its own layer 1 network and SUI is its native gas asset. A token with the same ticker on another chain needs a supported route to become an asset on Sui.

The digest identifies a particular transaction; the address identifies an account. Support can use the digest to inspect a transfer, but neither identifier grants control of your keys.

No. The transaction’s computation and storage effects differ. Review the wallet’s displayed estimate and the resulting explorer record for the actual charge.