How Sui wallets own objects and approve transactions

A Sui wallet does two related jobs: it proves control of an address and presents transactions for signing. A connection lets an app read enough state to prepare a request. A signature authorizes one particular transaction. Keeping those boundaries visible makes a first transfer easier to check.

Ownership is about objects

The Sui object model gives onchain resources stable IDs, versions, and ownership. A wallet address may own SUI coin objects, a collectible, or another Move object. Ownership is not just a balance shown by the wallet: it is the network state that lets the address use an object as an input when the transaction rules allow it.

Fungible coins can be split and merged, so a wallet often presents them as one balance even when the underlying state contains several coin objects. The full coin type matters as well. Two assets can display a familiar ticker while having different type identifiers or networks. Before an action, check the address, network, asset type, and amount together.

A connection is a read boundary

The Sui wallet documentation describes a wallet as storing keys that prove ownership and signing submitted transactions. When you connect a compatible wallet to an app, the app can request the public address and read permitted account or object state. That session does not give the app a signature or a free pass to move an asset.

Compare the address and network shown by the app with the wallet before continuing. If the wallet has several accounts, select the one that owns the intended coin. A connected account can have no usable balance, the wrong coin type, or too little SUI for the transaction's gas. Those are account-state problems, not signing problems.

A transaction changes state

Suppose your wallet owns 3.00 SUI and you want to send 0.25 SUI to a friend on Sui mainnet. The app or wallet builds a transaction that selects enough SUI, splits out 0.25 SUI, transfers it to the recipient, and reserves gas. The signing prompt should show the intended network and recipient. After signing, the network consumes the inputs and produces the recipient's new owned coin state; the sender's remaining balance is lower by the transfer and the actual gas charge.

That example is hypothetical. The exact gas depends on the transaction and current network conditions. Sui's gas guide says a gas budget caps gas use; it is not the same thing as a fixed application fee. If the recipient, amount, coin type, or network in the prompt is wrong, reject the request and start again from the corrected state.

Read the prompt and the result separately

Before signing, check:

• the wallet account and Sui network;
• the asset type and amount being spent;
• the recipient or application target;
• the gas payment and budget;
• any route or application terms shown around the network request.

After signing, keep the transaction digest. A submitted request, a confirmed transaction, and an app's indexed history are separate states. The digest and transaction effects show what Sui accepted. An app may update its own history later, and a connection can remain open even when a transaction was rejected.

The same distinction applies to a multi-step programmable transaction block. Sui can compose commands so that outputs from one command feed the next, but the wallet still asks for one review and signature for that particular block. Read the whole request rather than treating a connection or a familiar asset label as approval.

A compact first-action check

Ask four questions before approving: Which address owns this asset? Is the asset on Sui mainnet with the expected type? What state change does this transaction request? Which digest will prove the result? Those answers are more useful than a generic claim that a wallet is “connected.”

For more context, compare funding a Sui wallet with a first Sui transaction from funding to finality. Both start before the signing prompt because the source, destination, and network determine whether the later request is even the intended one.