On Sui, an address-owned object and a shared object are used under different ownership rules. A wallet can display an object relevant to your activity without owning that object as an ordinary transferable asset. Identify the object’s current ownership form, its type and the application action involved before using Send. Public access to a shared object does not give every visitor permission to withdraw its contents.
Identify what the wallet is showing
Start with one item rather than the whole account total. Is the screen showing a coin balance, a collectible, an application position, a capability or the shared pool with which you interacted? These labels can sit near one another in an interface while representing different rights. Copying an object ID does not answer who controls the associated value or how it can leave the application.
Sui’s object model distinguishes an object’s identity, type and ownership. The owner information matters to transaction use; the type matters to the functions that can act on it. Preserve both when investigating an unfamiliar item. A display name such as ‘position’ is not a technical description of what an arbitrary transfer will do.
Consider a fictional user, Tessa, whose application shows her position beside a pool. Her personal position or capability can be associated with her address while the pool is shared. Transferring the personal item, withdrawing the position and interacting with the pool are different proposed actions. Before approving one, she needs the application’s documented explanation of the resulting asset and destination.
Use ownership as a routing question
| What the item is | Question before acting | What to avoid assuming |
|---|---|---|
| Address-owned object | Is this my address, and does the type permit the proposed transfer? | Ownership makes every application action interchangeable |
| Shared object | Which application function and authorization apply to my request? | Anyone who can reference it can take its funds |
| Immutable object | Am I looking at reference data or a published package? | It can be moved like a coin |
| Object sent to another object | Does the parent’s module provide a valid receiving path? | A familiar-looking ID is necessarily a wallet destination |
| Wrapped object | Which containing object exposes the relevant action? | It remains an independent wallet item |
| Party / consensus-address-owned object | Which single owning address and consensus-based path apply? | The word party means unrestricted public ownership |
The current ownership guide includes party objects as well as the more familiar owned, shared and immutable forms. Party objects have a single owning address but are sequenced through consensus. A simplified rule such as ‘consensus means everyone owns it’ therefore fails. Use the recorded ownership form rather than guessing from processing speed or an application label.
Shared access still has application rules
Sui’s shared-object documentation explains that any address can reference a shared object in a transaction, while privileged actions need authorization enforced by Move code. A shared market is not a shared signing key. Being able to submit an interaction does not establish that a withdrawal request satisfies the application’s conditions.
For Tessa, the useful questions are concrete: which position is hers, which function withdraws it, what authorization that function expects and what asset the function returns. She should not substitute an unrelated generic Send action merely because the application interaction is unfamiliar. Nor should she sign a transaction from an unknown ‘recovery’ interface that promises to turn a shared pool into a personal balance.
A wallet’s simulation or preview can help show the proposed operation, but a familiar shared-object ID is not a complete safety verdict. Check the application source reached independently and the actual action being requested. If the preview and the documented workflow disagree, stop and resolve that difference rather than assuming that public visibility removes the need for scrutiny.
A parent object is not automatically a receiving wallet
The transfer-to-object guide describes a parent-child relationship controlled through the parent’s module. It also warns that a target can lack support for receiving the sent object. A successful transfer to an object ID does not establish that an ordinary wallet can immediately recover or use the child.
Treat the destination’s role as part of its meaning. An account address, object ID and package identifier can look similar in shortened text; they are not interchangeable payment instructions. Follow the recipient application’s documented receiving process. Do not experiment with the intended deposit by copying an identifier from an explorer sidebar and hoping the application will recognize it.
Wrapped objects add another distinction: the ownership guide’s wrapped-object description treats them as accessible through their containing object rather than as independent objects passed directly to an action. Here ‘wrapped’ describes object nesting. It should not be confused automatically with a bridged token representing a coin from another blockchain.
Do not force every fungible balance into a coin-object list
Current Sui documentation describes address balances alongside coin objects. The migration explanation says that coin objects remain valid and are not forcibly converted. It also explains that a balance can be split between the two representations. A client that only understands one representation can show an incomplete picture.
If a received amount is not visible where you expect, establish the representation used and whether the wallet supports it before concluding that an object was stolen or permanently lost. Preserve the transaction reference and the coin type. This is a display and compatibility investigation, not permission to run a conversion from an unfamiliar website. A general balance total and an owned-object query answer different questions.
The presence of a newer model does not prove that every wallet, application or deposit service supports every receiving method. Conversely, an older explanation that treats all funds as individually listed coin objects may no longer describe the whole account. Ask the actual recipient which transfer form it accepts instead of applying an old tutorial universally.
Build the next action from the evidence
- Identify the exact item or amount: object ID and type, or the relevant fungible coin type and balance representation.
- Read the current ownership form rather than inferring it from the item’s display name.
- For an application position, establish the documented action that produces the intended transferable asset.
- Check that the receiving address or object belongs to the required destination process and accepts that item or asset.
- Review the proposed transaction and resolve unexpected permissions or outputs before approving it.
- If the attempt fails, preserve its reference and distinguish ownership or application rules from a stale input, a client display issue or another actual error.
An outdated object reference is a different problem from an object whose ownership form was never suitable for the proposed action. Rebuilding an otherwise legitimate transaction may address the former; it does not grant application permissions or make an immutable package transferable. Avoid repeatedly pressing Send without identifying which kind of condition the error describes.
For an exchange, start with the asset selected by the order, not an arbitrary application object. Compare the SUI information page, supported assets and the actual options in simple swap. These links do not establish that KOT.CASH accepts a position token, capability, collectible or every Sui balance-transfer method as a native SUI deposit. Confirm the exact supported route before moving funds.
FAQ
Does a Sui shared object belong to everyone who uses it?
Shared access allows an address to reference the object, but privileged actions still depend on the application’s authorization rules. It does not grant every caller permission to withdraw the contents.
Are Sui party objects the same as shared objects?
The current documentation describes party objects as owned by a single address and sequenced through consensus. Check that ownership form instead of treating the word party as public spending permission.
Can I use a normal Sui transfer to send an object to another object?
The protocol supports transfer-to-object, but the parent’s module and the item’s type determine whether it can be received and used. Do not treat an arbitrary object ID as an ordinary deposit address.