A first Sui transaction: from funding to finality

A first Sui transaction is a chain of checkpoints: fund an address, identify the asset, choose one action, review the signing request, wait for network confirmation, and match the digest to the resulting state. Each checkpoint answers a different question, so a screen saying “complete” should not be treated as proof of every later step.

1. Fund and identify

Start with a compatible wallet and Sui mainnet selected. Compare the destination address and network in the funding service with the address shown by the wallet. When the asset arrives, check its full coin type and amount. A ticker can be shared by assets on other networks or by native and bridged forms.

Keep enough SUI for the transaction's gas unless the specific flow documents another payment path. The Sui getting-started guide provides general wallet orientation, while the gas documentation explains why a fixed reserve cannot predict every transaction's final cost.

2. Choose one action

Make the first action concrete. You might send a coin to a known recipient, interact with a collectible, or request a swap. For a hypothetical SUI-to-USDC route in Swap, select the pair, enter an amount, and request the current quote. Read output, minimum received, route, slippage, application commission, and network gas as separate values.

This example is a product illustration, not a recommendation or a live quote. A direct transfer, a DEX trade, and a provider deposit have different inputs and completion evidence. Do not treat a vault preview as a trade quote or a provider's “sent” state as a settled wallet balance.

3. Review and sign

Connection gives an app a way to identify the wallet and prepare a request. The signature authorizes the transaction that the wallet displays. Compare the account, network, asset type, amount, recipient or package, commands, gas budget, and any output condition. If the request differs from the action you intended, reject it and rebuild from the corrected details.

Sui's object model explains why the transaction can name owned or shared objects and produce new versions or outputs. A programmable transaction block can chain commands atomically, but that does not reduce the need to inspect the entire block before signing.

4. Follow the digest to finality

After approval, keep the transaction digest and wait for a network result. The digest and effects show which objects changed, which assets were transferred, and whether the transaction succeeded. A product UI, wallet history, or indexer may take longer to reflect that state. Do not sign the same request again just because an application panel is still loading.

A rejected prompt has no network digest for that action. A failed transaction can have a digest and a gas charge while leaving intended state changes unapplied. A confirmed transaction proves network state, while a provider or application record can establish a separate offchain step. Use the record that matches the question.

When the path breaks

• A pending funding transfer means the source has not yet proved delivery to the selected address.
• An unsupported coin type means the app cannot use the displayed asset merely because its ticker looks right.
• A rejected signature means the requested state change was not authorized.
• A failed transaction means the digest and effects need inspection before any retry.
• Delayed indexing means the network result and product display are temporarily out of sync.

Keep the last prompt, address, asset type, digest, and visible state together when asking for help. For the boundaries behind this journey, read wallet ownership and signing, USDC asset identity, and Sui gas budgets.